AutoIt Compiler (Project Perseus)

    Hi!

    Ich bin sicher nicht der erste, der mit dieser Idee kommt, aber ich habe bereits einen Ansatz. Es gab in der Vergangenheit Projekte wie AutoIt to C++, oder Großprojekte wie den Falcon Compiler. Alle versuchen AutoIt in eine andere Hochsprache zu übersetzen, mein Ansatz ist aber ein anderer.

    Ich entwickle gerade eine Zwischensprache. Das heißt eine Sprache, die zwischen der Hochsprache (AutoIt) und dem Maschinencode steht. Genannt habe ich diese Perseus (nach einer Idee von chess 8) ). Sie übersetzt sich selbst in Maschinencode, also eine 32Bit Executable.


    Was heißt das in Zahlen?
    Extrem kleine ausführbare Dateien:

    "Test-Exe - 2KB"

    [Blockierte Grafik: http://r82.img-up.net/perseus100d52.jpg]


    [Blockierte Grafik: http://1.2.3.12/bmi/apaste.square7.ch/lasm/rw_common/images/persaus.png]

    Aktuelle Version: 1.5.X (unveröffentlicht)
    Letzten Entwicklungsstand bitte letzen Post entnehmen.

    2 Mal editiert, zuletzt von minx (24. Mai 2013 um 14:35)

    Zitat von Wiki

    Eine höhere Programmiersprache (engl. high level programming language) ist eine Programmiersprache zur Abfassung eines Computerprogramms, die einer der historisch gewachsenen menschlichen Sprachen (Englisch, Japanisch usw.) sehr entfernt ähnelt.

    Denke schon...

    Zitat von i2c

    Müssen wir AutoIt jetzt als Hochsprache bezeichnen?

    Skriptsprache mit Zukunft. :D


    @Topic Ich finde die Idee super, da ich AutoIt an sich für sehr gut halte (die Sprache an sich, nicht die Umsetzung) und darin garantiert noch eine Menge Potenzial steckt. Ich denke zwar nicht, dass ich bei sehr viel helfen könnte, würde aber trotzdem mitmachen.

    Zitat von Christoph54

    Hab ich das richtig verstanden, dass diese "Zwischensprache" dann auch nur wieder mit einem Interpreter zusammen gepackt wird? ?(

    Zitat von Firstpost

    die zwischen der Hochsprache (AutoIt) und dem Maschinencode steht.

    *Hust*

    Nochmal deutlich: AutoIt->Perseus->Exe. Das heißt AutoIt wird in Maschinensprache übersetzt, also kompiliert. Von einem Interpreter ist da keine Spur.

    Du weißt schon was ein Interpreter ist? Der interpretiert den Code und hat nichts mit einer ausführbaren Datei zu tun ^^

    Wie wird aus Perseus Maschinen-Code, na indem er übersetzt / assembliert / compiliert wird. Wie nunmal EXE Dateien erzeugt werden ^^

    ___________

    Ein Assembler nimmt Text-Instruktionen und wandelt sie in OP-Code um. Der OP-Code wird dann in eine .exe Datei geschrieben (einfach FileWrite). Perseus ist als ein Assembler wie FASM, MASM oder TASM, bloß mit einfacherem Syntax.

    Sehr feine Sache das!
    Bin mal gespannt, wo das hinführt... ;)

    Da sich "einfache" AutoIt-Scripte recht einfach 1:1 in Assembler abbilden lassen, sollte das funktionieren.
    Ich hatte schon ein Umwandlungs-Script geschrieben, welches komplette Scripte mit Arrays in Scripte ausschliesslich mit Structs transferiert, incl. Ein/Ausgabe. Structs kann man sehr schön mit Assembler bearbeiten, wesentlich besser als Arrays. So konnte ich ein "SortArray" mit Floats/Integern in Assembler schreiben, welches 1000x schneller war, als das AutoIt-_ArraySort().
    Was mich damals gehindert hat weiterzumachen, war das Problem der Typen bzw. der nicht vorhandenen Typen^^.


    Wie auch schon in anderen Threads, die in diese Richtung gehen, gebe ich wieder mal meinen Senf dazu.
    Für 99% aller Fälle ist ein AutoIt-Script schnell genug, braucht man ausnahmsweise mehr Geschwindigkeit, dann ist Profilen, den "Inner Loop" finden und diesen in einer PowerBasic/C++/Assembler-DLL abbilden und aufrufen imho die schnellste und einfachste Lösung.
    Bei Preisen von <10€ für das Gigabyte RAM und <50€ für ne Terabyte Platte stellt sich auch nicht mehr die Frage nach "kleinen" Dateien (*hust* den Sudoku-Löser in 62 Byte find ich trotzdem oberaffengeil :D )

    minx, hau rein! :thumbup:

    Dern Sinn kann sich in die nächste Ecke stellen ^^.

    Ich glaube es gibt schon dadurch einen Vorteil, dass es bereits Typenlos geschrieben werden kann. Natürlich kann man nie den ganzen Funktionsumfang umschreiben, man muss den Au3 Code sehr sauber verfassen (was auch die Var-Deklaration angeht). Richtig an den Speed geht es dann bei grafischen Dingen. Dort ist man dann nur noch durch den Speed der API Calls beschränkt (obwohl diese direkt mitassembliert werden).

    Klar ist die Personengruppe, die sich noch um Dateigrößen schert extrem klein, aber wenn man dann mal ein paar Photoshop Effekte in 5KB darstelen kann, viel schneller als es eine AutoIt exe mit ihren mind. 300KB oder eine VC++ mit 1MB+ schaffen könnte, erweckt man dann doch Interesse :D

    Schon allein die Größe meines Assemblers. 52KB. Davon passen Dutzende Kopien auf eine Diskette :whistling:

    Wenn ich ein OP-Problem hab nerv ich dich sowieso :D

    Zitat

    Davon passen Dutzende Kopien auf eine Diskette

    Diskette, wasn das? :rofl:

    Zitat

    Wenn ich ein OP-Problem hab nerv ich dich sowieso

    das will ich doch sehr hoffen :thumbup:

    ca. 60 KB, wäre das nicht ne Idee, LASM statt FASM mit AssembleIt zu verheiraten? Dann hätte sich das ganze gerödel mit den Memory- und schlagmichtot-UDF´s erledigt, und man hätte EIN include-file?!
    Oder man könnte den "normalen" AutoItcode auch behalten und zusammen mit "echten" #inline Assemblercode durch deinen Perseus jagen. Im AutoItscript würde Perseus dann aus dem ASM-code einen einfachen CALL machen...
    Das wäre jedenfalls ein einfach umzusetzender Zwischenschritt!

    Daran hab ich auch schon gedacht. Ich versuche gerade LASM ausm Speicher auszuführen, ohne direkte Datei.

    Mal sehen in wie weit ich dafür Zeit finde ^^. Gute Idee jedenfalls.

    Zitat von minx

    Ich entwickle gerade eine Zwischensprache. Das heißt eine Sprache, die zwischen der Hochsprache (AutoIt) und dem Maschinencode steht.

    Ich bin da ehrlich gesagt nicht so der Experte, aber so weit wie ich weiß, ist das das Grundprinzip von LLVM.
    Hierbei wird eine beliebige Sprache genommen und in die LLVM-Zwischensprache umgewandelt.
    Dieser wird dann mit dem entsprechendem Compiler in Maschinencode übersetzt.

    Der Vorteil für dein Projekt wäre, dass du "nur"(!) die Übersetzung in die LLVM-Zwischensprache hinbiegen müsstest.
    Weitere Vorteile wären:

    • Optimierender Compiler von Zwischensprache in Maschinencode existiert schon.
    • Erzeugter Maschinencode ist portabel (kann für zig verschiedene Prozessorarchitekturen kompilieren).
    • Sogar JIT-Kompilierung ist möglich.
    • Haufenweise clevere Leute haben sich über die Eigenschaften der LLVM-Zwischensprache Gedanken gemacht. Daher kann man davon ausgehen, dass diese für Ihren Zweck definitiv geeignet ist.


    Vielleicht nimmt es dir viel Arbeit ab wenn du auf LLVM setzt. Definitiv würden die damit verbundenen Möglichkeiten aber enorm steigen.

    Edit: Achso eh das falsch verstanden wird: Hut ab minx! :)

    Wie viel hast du davon schon gemacht?
    Da ich an dem AutoIt to C++-Compiler arbeite, kann ich sagen, dass es extrem viel Mühe ist, einen Parser zu schreiben und dabei alle Besonderheiten von AutoIt zu beachten. Die Implementierung der Funktionen ist ja später einfach nur Fleißarbeit, aber der Parser ist echt schwer.

    Also wenn ich mich nicht irre was ich wahrscheinlich tuhe:
    Du willst den Autoit Code in Perseus umwandeln und anschließend mit Assembler Compilieren?

    wen ja dann mach weiter, auch wenns Probleme gibt ich wette einige würden auch helfen ^^

    Ich warte schon seit dem ich Autoit kenne auf ein schnelleren / sicheren compiler.

    Sind TV-Quizfragen zu einfach? A) Ja B) Harry Potter

    Spoiler anzeigen

    Ich gebe zu dieser Post hat wahrscheinlich nicht viel geholfen,
    aber ich versuche wenigstens zu helfen :rolleyes:

    Zitat von AspirinJunkie

    Optimierender Compiler von Zwischensprache in Maschinencode existiert schon.


    Tut er doch auch hier schon :P. Spaß beiseite, ich finde es einfach spannend eine Programmiersprache von Grund auf aufzubauen. Der Assembler bzw. der Übersetzer Zwischensprache zu Assembler (LASM) existiert ja schon. Da liegt jetzt der Vorteil in der Entwicklung der Zwischensprache, die kann man nämlich schon richtig in Richtung AutoIt biegen. ^^

    Das ist auch das Grundprinzip von C-- (Ja, Minus) etc. Wenn man aber was eigenes hat, ist das doch viel besser ^^.

    Zitat von Marthog

    Wie viel hast du davon schon gemacht?


    Also nochmal etwas ausführlicher. Der Assembler ist fertig (http://apaste.square7.ch/lasm). Die Zwischensprache an sich ist in der Entwicklung, wann man sie als fertig bezeichnen kann weiß ich nicht ^^.

    Aber danke alle ^^

    Wirst du, wenn der 32Bit-Compiler fertig ist, auch noch einen für 64Bit machen? :D

    Mfg

    There's a joke that C has the speed and efficieny of assembly language combined with readability of....assembly language. In other words, it's just a glorified assembly language. - Teh Interwebz

    C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, you blow off your whole leg. - Bjarne Stroustrup
    Genie zu sein, bedeutet für mich, alles zu tun, was ich will. - Klaus Kinski