hi,

ich hab mal eine verständnisfrage:

warum gibt es keinen compiler der perl-code direkt in ausführbaren cpu-code, also assembler umwandeln kann?

wenn ich mich recht erinnere tut doch der perl-compiler perl-code in einen parse-tree mit perl-internen opcodes zerlegen, dieser parse-tree wird dann vom interpreter ausgeführt, also in assembler umwandelt. warum gibt es keinen compiler der das direkt macht?
klar würde man den vorteil der plattform-unabhängigkeit verlieren, aber wenn man eine applikation ganz gezielt auf einer plattform laufen lassen möchte würde das doch einen gewaltigen geschwindigkeitszuwachs bedeuten gegenüber par beispielsweise.....

hat sich einfach noch keiner die mühe gemacht so ein ding zu schreiben oder gibt es da andere technische gründe die ich übersehen habe?

Stichwort: Variabler Speicherverbrauch von Variablen, Arrays usw.
Der Speicher für entsprechendes muss erst reserviert werden. In C(++) gibt man deshalb bei der definition eines Array immer an wie lang es sein muss und bei Variablen einen spezifischen Typ. Dadurch weiß der Compiler wie viel Speicher(im Ram oder direkt Register) er reservieren muss.
Das Hauptproblem beim Schreiben eines Perl-Compilers würde wohl sein / ist diesen variablen Speicherverbrauch einzukalkulieren(was wohl nur schlecht/gar nicht möglich ist). Man müsste bei jeder Variablen angeben wie lang sie wird(was man auch manchmal nicht weiß(Usereingaben) und jedem Array eine Länge vorgeben; das wäre dann definitiv kein perl mehr(finde ich))

So ich hoffe das ist soweit richtig. Wenn nicht korrigiert mich bitte.

edit: Bessere Formulierung\n\n

<!--EDIT|jemand|1125757929-->

???
@jemand: ich denke, das ist nicht der grund!

assembler hat mit Plattformen nichts zu tun. Assembler geht gezielt auf eine CPU.
Wenn du mit Assembler arbeitest, nutzt du im normalfall die Register der CPU. Also AX, BX, CX und DX. Diese Teile sind sehr sehr klein, was der Speicherverbrauch angeht, wenn man Perl Code da einbetten würde, dann ist es wohl vorprogrammiert, wieviel Speicher das ding benötigen würde...
Noch dazu is Assembler kein Maschinencode. Ein Hello World könnte in Assembler ca so aussehen:

das hat mit 0 und 1 wenig zu tun...

Besonders schlimm ist auch "eval". Im Prinzip muss jedes Programm, welches eval enthaelt, den ganzen Perl-Parser mit einkompiliert bekommen, wenn man es nach Assembler kompiliert.

Und selbst ohne eval muesste man den ganzen Code fuer Regulaere Ausdruecke etc immer mit einbinden, d. h. das wird nicht klein.

[quote=supersucker,03.09.2005, 16:00]warum gibt es keinen compiler der perl-code direkt in ausführbaren cpu-code, [also assembler] umwandeln kann?[/quote]
btw.: So etwas gibt es, perlcc nennt sich das:

Quote

In C(++) gibt man deshalb bei der definition eines Array immer an wie lang es sein muss und bei Variablen einen spezifischen Typ. Dadurch weiß der Compiler wie viel Speicher(im Ram oder direkt Register) er reservieren muss.

ne, wenn das so wäre könnte man ja keine zur laufzeit dynamisch wachsenden arrays und ähnliches in C++ realisieren, man muss halt mit pointern arbeiten

Quote

assembler hat mit Plattformen nichts zu tun. Assembler geht gezielt auf eine CPU.

Noch dazu is Assembler kein Maschinencode.

meinte ich, war unglücklich formuliert

Quote

Wenn du mit Assembler arbeitest, nutzt du im normalfall die Register der CPU. Also AX, BX, CX und DX. Diese Teile sind sehr sehr klein, was der Speicherverbrauch angeht, wenn man Perl Code da einbetten würde, dann ist es wohl vorprogrammiert, wieviel Speicher das ding benötigen würde...

wieso? ist schon ne weile her dass ich assembler programmiert hab, aber soweit ich mich erinnere, kann man mit ausnahme einiger spezialregister auch nur den ram nutzen ohne die restlichen register, oder trügt mich da die erinnerung?

Quote

btw.: So etwas gibt es, perlcc nennt sich das:

thx, kannte ich noch nicht, werd ich mir mal anschauen

@Esskar: Ich bin einfach mal frech und frage: "Sondern? "

Gut natürlich könnte der Compiler jeder Variable eine überprüfung zuschieben die dann eben schaut ob die Variable größer ist und ihr mehr Platz zukommen lässt. Das wird dann aber groß und ist schlecht optimierbar für den Compiler und somit auch wieder langsam.
Oke ich seh ein dass das mit dem Speicher wohl teilweise in die falsche Richtung ging. Aber es hängt definitiv an vor der Laufzeit unbekannten Operationen die durchgeführt werden müssen/sollen.(siehe betterworlds beitrag)

Btw.: Kennt irgendjemand einen Compiler der nichts von Variablentypen und Arraylängen wissen will?

Wie willst du das Problem variablen Speichers mit Pointern lösen? Versteh ich irgendwie nicht...

Zu Assembler und Registern: Ich kenn zwar kein *86 Assembler nur Avr aber da gibt es jedenfalls Register in denen man seine Daten hat und verarbeiten kann. Wenn man die dann nicht mehr braucht legt man sie auf den Stack um sie später wieder zu verwenden(oder auch nicht; wobei dann das auf den Stack legen unsinnig wäre *g*).

Wenn ich die bisher so gebrachten Vermutungen ansehe, denke ich dass es wenn man alle Gründe zusammennimmt nicht mehr sehr sinnvoll ist einen Compiler für Perl zu schreiben, da dann das Programm fett und lahm sein würde, da eben nicht sehr gut optimiert werden kann.\n\n

<!--EDIT|jemand|1125783606-->

[quote=betterworld,03.09.2005, 16:46]Besonders schlimm ist auch "eval".  Im Prinzip muss jedes Programm, welches eval enthaelt, den ganzen Perl-Parser mit einkompiliert bekommen, wenn man es nach Assembler kompiliert.

Und selbst ohne eval muesste man den ganzen Code fuer Regulaere Ausdruecke etc immer mit einbinden, d. h. das wird nicht klein.[/quote]
Das ist zwar prinzipiell richtig, aber durchaus umgehbar: Wenn man alle statischen regulären Ausdrücke in Maschinencode kompiliert, kann man Programme, die weder eval noch variable reguläre Ausdrücke verwenden relativ klein halten -- und ziemlich viele Programme fallen, denke ich, in diese Kategorie.

Außerdem würde man natürlich das Laufzeitsystem, das System für Codegenerierung zur Laufzeit sowie den Perlparser jeweils in eine eigene dynamische Bibliothek packen, die man dann bei Bedarf linken kann.

Die weiter oben angemerkten Probleme mit der Speicherverwaltung sind auch keine echten Probleme, wie man an der Kompilierbarkeit vieler anderer Sprachen mit automatischer Speicherverwaltung sieht (z.B. Java durch gcj).

Das einzige wirkliche Problem ist also, dass noch niemand sich die Mühe gemacht hat, so einen Compiler zu schreiben, denn perlcc kann man beileibe nicht als ausgereift bezeichnen. Ich habe so das dumpfe Gefühl, dass die Perl Laufzeitbibliothek nicht mit dem Gedanken an einen Compiler entwickelt wurde, so dass man sie eigentlich fast neu schreiben müsste, um etwas anständiges auf die Beine zu stellen. Natürlich hat niemand Lust, so ein Projekt zu starten, zumal mit Perl 6 ja ein compilerbasiertes Perl kommen wird. Da wird man sicherlich wesentlich einfacher neben dem Parrot Backend auch ein native Backend einbauen können.

Was die Effizienz des Codes betrifft, so kann man sich sowieso trefflich darüber streiten, ob ein kompiliertes Programm, dass aber eine komplexe und umfangreiche Laufzeitbibliothek benötigt, wirklich deutlich effizienter ist, als ein gut interpretiertes. Das Konzept, das Perl da verfolgt ist eigentlich ziemlich brauchbar. Notfalls kann man ja immer noch die wirklich zeitkritischen Routinen in C oder direkt in Assembler implementieren und zum Beispiel mittels XSUB einbinden.

[edit: Absatz über Effizienz]\n\n

<!--EDIT|murphy|1125783967-->

[quote=murphy,03.09.2005, 23:39]Programme, die weder eval noch variable reguläre Ausdrücke verwenden[/quote]
Ich meinte eigentlich nicht variable regulaere Ausdruecke, sondern alle. Denn ich ging davon aus, dass man die regulaeren Ausdruecke nicht auch in Assemblercode umwandeln moechte. Aber du hast natuerlich recht: man kann den ganzen Kram auch in eine Shared Library stecken und muss es nicht jedem Programm beifuegen.

Jedenfalls wird es eine widerliche Angelegenheit, zur Laufzeit Maschinencode zu erzeugen, der dann irgendwo in den Speicher gepackt wird und von dort aus ausgefuehrt wird; und genau das ist fuer eval ja noetig.

So oder so muesste man perl so ziemlich neu schreiben.