Programmiersprachen/Umgebungen

[Socke]

Für Linux gibt es den ab FPC 2.1.1

Quelle?
Du hast recht, mein fpc sagt auch, er hätte einen internen ELF-Writer. Aber warum ist der dann nicht Standard?

[Euklid]

Quelle?

Erinnerung. Musst mal nach den Release-Notes googeln.

Bei mir (Lazarus 0.9.28-2) ist der interne Linker von der Installation an eingestellt.

[mschnell]

Der FPC nutzt ja schon den GCC zum linken.....

Das hat alles nicht mit dem hier besprochenen Sprach- und Architektur- unabhängigen Zwischencode zu tun. der in gcc beim Kompilieren aller Sprachen in Objektcode als Zwischenschritt (vor der Architektur-abhängigen Optimierung und Code-Generierung) verwendet wird und den man (vermutlich nach einer Erweiterung der Definition) theoretisch auch für Object Pascal verwenden könnte.

Object Pascal automatisiert nach C übersetzen geht ziemlich schlecht und nur mit Einschränkungen und De-Optimierung.

-Michael

[mschnell]

ein Compiler übersetzt nach Assembler, ein Assembler übersetzt in Maschinencode

Textlicher Assembler -> Machinencode ist ein trivialer Schritt, den (AFAIK) FPC gleich bei der Code-Generierung erledigt.

Wichtiger ist, dass die meisten Compiler vor der Übersetzung nach textlichem oder binären Architektur-abhängigem Assembler einen Architektur-unabhängigen (binären) Zwischencode erzeugen. Auf dieser Ebene tut ein Architektur- (und Quell-Sprachen-) unabhängiger High-Level Optimierer seine Arbeit. Bei CIL wird dieser Code dann als Programm gespeichert, bei native-Code Systemen kommt dann die Architektur-abhängige Optimierung und die Code-Generierung (und schließlich das Linken).

-Michael

[mschnell]

Das schöne an gcc ist, dass man für jeden Microcontroller "nur" ein neues Backend schreiben muss

.. und für jede Sprache "nur" ein Frontend.
Dazwischen gibt es eine sehr ausgefuchste Sprach- und Architektur- unabhängige High-Level Optimierung auf Zwischencode-Ebene.

Allerdings gibt es (AFAIK) in Object-Pascal einige Konstrukte, die sich mit dem momentanen gcc Zwischencode nicht abbilden lassen. Um Object-Pascal gcc zu konstruieren, braucht man also eine Erweiterung der Zwischencode-Definition und damit muss der Zwischencode-Optimierer erweitert werden, was die gcc-Experten vermutlich nicht in Angriff nehmen wollen - und Pascal-Freaks wollen diesen komplexen C-Code wahrscheinlich nicht anpacken.

Da der Optimierer die zusätzlichen Codes eliminieren wird, braucht das Backend vermutlich nicht angepackt werden. Da ist natürlich der Vorteil von gcc offensichtlich.

-Michael

[carli]

Object Pascal automatisiert nach C übersetzen geht ziemlich schlecht und nur mit Einschränkungen und De-Optimierung.

De-Optimierungen sind kein Problem, das bügelt der GCC schon wieder aus.

Ansonsten hast du natürlich Recht, der GCC kann nicht "alles".

bei LLVM hingegen hat man ziemlich gute Kontrolle über alles, was man kompilieren will. Die LLVM sieht sich auch selbst als Nachfolger der GCC-Architektur. Ich sehe das genauso. Allein schon an dem Fakt, dass C/C++ auch schneller kompilieren kann, als man es mit GCC je träumen könnte.

Die Frage ist bloß: Arbeitet Jonas noch am LLVM-Backend des FPC und könnte er eventuell Hilfe dabei gebrauchen?

[mschnell]

Die LLVM sieht sich auch selbst als Nachfolger der GCC-Architektur.

Momentan wird Linux aber - soweit ich weiß, immer mit gcc übersetzt.

Sag' mit Bescheid, wenn man Linux für den NIOS Prozessor mit LLVM übersetzen kann.

-Michael

[carli]

Sag' mit Bescheid, wenn man Linux für den NIOS Prozessor mit LLVM übersetzen kann.

-Michael

Es gibt bereits ein Projekt, das einen komplett neuen Kernel plant, der auf der LLVM basiert.
Abgesehen von der Verbreitung, hat die LLVM einfach ein viel zu gutes Konzept, als dass man es links liegen lassen könnte.

[marcov]

Einen anderen Ausweg der Plattformunabhängigkeit sehe ich in der LLVM:

Warum dann nicht gleich die weit verbreitetste und am weitgehendsten plattformunabhängige Infrastruktur gcc ?

GNU Pascal hat das versucht. Wer? GNU Pascal

Seriös, der Teufel ist nicht die Verbreitung, aber immer im Detail

1. Sehr C-Zentrisch.
2. Sehr aufwendig programmieren (nur C, faengen ernst mit OOP an)
3. Sehr schwierig Patches im Mainline zu bekommen, praktisch ein-weg Verkehr. Kein Problem fuer etwas was Modisch ist, aber Pascal ist das nicht (mehr)
4. Schlechte nicht Unix Unterstutzung.
5. Regelmäßig Migrationen. (jeder major Version).
6. Potentiel zur Optimization ist nicht dasselbe als es "frei" bekommen. Man muss oft da etwas für tun (Daten Optimiert Anlieferen ans backend) Und dafür muss man es ganz (intern) verstehen. Und das ist wieder nähe an alles selber machen.

Der Sprach-unabhängige gcc Codegenerator mit dem low-level-Teil der Optimierung ist vermutlich kaum zu schlagen. Es gibt ja sogar bereits gcc - Pascal (ohne Objekte).

Das Problem dürfte dabei hauptsächlich "politisch" sein. Die gcc-Gemeinde ist vermutlich sehr C-zentriert und wenig bereit Erweiterungen der Infrastruktur für Object-Pascal zuzulassen.

Ja. Aber es gibt mehrere Problem, sie oben. Und es schöne ist das es ein Praxis Beispiel gibt. GNU Pascal hat an in 1987 angefangen, FPC in 1993. Vergleiche nur wo GNU Pascal steht, und wo FPC steht.

[marcov]

Das war einmal.
Der FPC hat einen internen Linker und ist hier nicht auf GCC angewiesen.

Für welche Plattformen gilt das denn überhaupt?

Für Linux gibt es den ab FPC 2.1.1[/quote

Das ist neu für mich. Es gibt nur linker für Windows (win32-i386/x86_64-win64/arm-wince. i386-wince weiß ich nicht genau).

Binwriter (interner Assembler) gibts schon für i386-linux, aber linker nicht.

[Socke]

Ja. Aber es gibt mehrere Problem, sie oben. Und es schöne ist das es ein Praxis Beispiel gibt. GNU Pascal hat an in 1987 angefangen, FPC in 1993. Vergleiche nur wo GNU Pascal steht, und wo FPC steht.

Könnte man daraus jetzt schließen, dass gcc den Höhepunkt seiner Entwicklung bereits erreicht hat und wenige massive Neuerungen zu erwarten sind?
Welche großen Innovationen sind denn beim FPC noch zu erwarten?
Betriebssysteme und CPU-Architekturen zähle ich jetzt mal nicht dazu, da das eigentlich nur Variationen der von-Neumann-Architektur. Vielmehr ist die Frage auf die Entwicklung der Sprache ausgerichtet: Generics, Strings mit Zeichensatz-Informationenen und transparenter Transkodierung...

[marcov]

Ja. Aber es gibt mehrere Problem, sie oben. Und es schöne ist das es ein Praxis Beispiel gibt. GNU Pascal hat an in 1987 angefangen, FPC in 1993. Vergleiche nur wo GNU Pascal steht, und wo FPC steht.

Könnte man daraus jetzt schließen, dass gcc den Höhepunkt seiner Entwicklung bereits erreicht hat und wenige massive Neuerungen zu erwarten sind?

Keine Ahnung.

Welche großen Innovationen sind denn beim FPC noch zu erwarten?

In 2.5.1 gibts schon:
- bessere ARM support
- mehr Delphi support (extended records/rtti usw)
- Objective Pascal und andere Mac-Zentrische entwickelungen (iOS)

Es hat auch ein bisschen Arbeit an Unicodestrings gegeben (D2009+), aber das schlaft heute.

Florian arbeitet von Zeit zu Zeit an MIPS.

Betriebssysteme und CPU-Architekturen zähle ich jetzt mal nicht dazu, da das eigentlich nur Variationen der von-Neumann-Architektur.

Alles was Arbeit kostet soll man dabei zählen. FPC ist kein Akademischer compiler die allein nach neue Wissenschaftliche Konzepte sucht. Es ist gemeint als ein Produktionscompiler.

Vielmehr ist die Frage auf die Entwicklung der Sprache ausgerichtet: Generics, Strings mit Zeichensatz-Informationenen und transparenter Transkodierung...

Siehe oben.

[marcov]

Das Problem dürfte dabei hauptsächlich "politisch" sein. Die gcc-Gemeinde ist vermutlich sehr C-zentriert und wenig bereit Erweiterungen der Infrastruktur für Object-Pascal zuzulassen.

Der FPC nutzt ja schon den GCC zum linken.

Nein. Es nutzt binutils (GNU LD)

Ebenfalls hat der FPC auch ein C-Backend, welches aber zur Zeit nicht so ganz funktioniert (wie mir gesagt wurde).

Dodi hat darueber gesprochen im Vergangenheit, aber ich habe nie gehoert das es sich selbst kompilieren kann. Trunk hat davon nichts.

Die Struktur des GCC zu erweitern ist eine ganz blöde Idee, da es einfach zu viel Aufwand ist. Ein Kapselprogramm ist da schon das richtige.
So macht es zumindest jeder - Makefiles, CMake, QTMake, das sind alles Tools, um C so ne Art Pascal-Feeling mit "uses" zu geben.

Ein ordentliches CBE

?

würde meiner Meinung nach voll ausreichen (der einen Gesamtprogramm-C-Code erzeugt), da eine neue eingebettete Plattform meistens nur mit einem C-Compiler "begehbar" ist.

Und was wann man das Pascal programm nicht als C code ausdrucken kann?

Zudem würde das das Bootstrappen von FreePascal-Code extrem erleichtern.

Ich denke FPC bootstrappen ist einfacher als GCC bootstrappen. Also ich weiß nicht was sie hier mit meinen.

[marcov]

Sag' mit Bescheid, wenn man Linux für den NIOS Prozessor mit LLVM übersetzen kann.

-Michael

Es gibt bereits ein Projekt, das einen komplett neuen Kernel plant, der auf der LLVM basiert.
Abgesehen von der Verbreitung, hat die LLVM einfach ein viel zu gutes Konzept, als dass man es links liegen lassen könnte.

Ja, der kenne ich schon. Setze den mal in denselben Ecke wie WebOS, Singularity usw. Wir werden sie schon sehen wann sie wieder rauskommen (oder nicht)

[carli]

würde meiner Meinung nach voll ausreichen (der einen Gesamtprogramm-C-Code erzeugt), da eine neue eingebettete Plattform meistens nur mit einem C-Compiler "begehbar" ist.

Und was wann man das Pascal programm nicht als C code ausdrucken kann?

Sowohl Pascal als auch C sind Turing-Vollstängig. FAIL

Zudem würde das das Bootstrappen von FreePascal-Code extrem erleichtern.

Ich denke FPC bootstrappen ist einfacher als GCC bootstrappen. Also ich weiß nicht was sie hier mit meinen.

Den FPC kann man nicht bootstrappen. Man kann ihn nur kompilieren, wenn man einen FPC da hat.
Hat man keinen, könnte man es mit Delphi oder so versuchen.
Ein C Compiler wird aber immer da sein, also könnte man sich zur Sicherheit immer ein automatisch übersetztes C-Programm vom FPC aufheben, schon kann man in jede neue Plattform portieren.