Programmiersprachen/Umgebungen

[mschnell]

da Mono .net hinterher hinkt

Microsoft .NET ist also teilweise inkompatibel zum Mono-Standard. Das ist natürlich blöd und - wie gesagt - ist es blöd, dass viele Entwicklungs-Tools dem nicht durch zur Compile-Zeit auswählbare benutzbare Feature-Gruppen (inklusive automatischer Behandlung der Einschränkungen) Rechnung tragen.

Bei Java hat der Hersteller den Standard so festgeschrieben, dass eine Weiterentwicklung fast unmöglich ist. Bei den CIL-Bibliotheken ist es sicher noch zu früh das zu propagieren (abgesehen davon dass Microsoft als "Maintainer" eines Astes des Trees ja nicht gerade für Kontinuität bekannt ist).

-Michael

[mschnell]

Der Zwischencode ist nämlich im Grunde nichts anderes als ein komprimierter und mit bekannten Algorithmen verschlüsselter Quelltext. Wenn man sein Programm also mit .net schreibt und veröffentlicht, kann man es gleich als OpenSource bezeichnen,...

Nö, Man kann aus verschiedenen Sprachen CIL-Code erzeugen (C#, Pascal, Python, Basic, ...) In CIL-Code ist von der ursprünglichen Sprache nicht mehr viel zu sehen. Man kann CIL-Code (soweit ich weiß) nur in C# rück-übersetzen. Damit ist man natürlich auf einer sehr viel höheren Ebene, als wenn man Executables in Assembler rück-übersetzt und der Knacker kann den erzeugten C#-Code viel besser anpassen als den aus einem nativen Executable gewonnenen Assembler-Code.

-Michael

[mschnell]

Das ist neu für mich.

Habe ich vor einiger Zeit auf der MONO-Seite gefunden. Da gab es für bestimmte Prozessoren nur den Interpreter aber noch kein JIT.

Übrigens: Klar hast Dur recht, dass wegen schlechterer Optimierung CIL Code meist langsamer läuft als native Code (hatte ich ja auch schon angemerkt). Ich vermute aber dass das CIL-System- im Gegensatz zu Java - von vorne herein auf Load-Time Kompilierung (JIT) ausgelegt wurde und CIL deshalb deutlich schneller sein kann als Java, das ursprünglich für einen echten Byte-Code Interpreter konzipiert war und JIT hinterher dazu-erfunden wurde.

-Michael

[mschnell]

./.

[marcov]

Die Probleme sind das es extrem schwierig ist ein Projekt eines Umfangs wie FPC/Lazarus von ein ander, sehr Umfangreich Projekt als LLVM (oder GCC) abhängt. Das bezeichnet das LLVM's API extrem stabil sein muss (nicht nur in Detail, aber auch über eine Zeit von 5 Jahre und länger). Eben wann das passieren wurden, ist das noch immer 5 Jahren+ im Zukunft, und muss LLVM zuerst beweisen es sei ein Projekt das bleibt.

Die LLVM ist inzwischen schon extrem weit verbreitet, viele der großen Scriptsprachen, darunter Python und LUA, haben inzwischen einen LLVM-Unterbau, der mesa-Grafikkartentreiber nutzt die LLVM für die Shader, das OpenJDK basiert auf der LLVM, clang sowieso.

Das ist LLVM-Werbung die oft genutzt wird ja. Aber das gibt keine Garantien wann man mit ein mehrjähriges Unternehmen wie FPC völlig auf LLVM unsetzen anfängt. Alles in Teilzeit, und dann eine nicht triviale Zeit stabilisieren. Und:

(1) sind das wirklich die _mainline_ Versionen LUA und Python, oder basteln die nur damit ?
(2) Was ich mich von die MESA Presentation letztes Jahr auf Fosdem erinnern kann, ist das alles auch noch nicht live in heutigen (damals) Distributionen?

markov: kann es sein, dass du google translate benutzt? deine Sätze sind so komisch.

Nein. 4 Jahre Deutsch, und man glaubt das ich Google Translate nutze.
Ich kann fast alles lesen und verstehen (habe damals auch Deutsche Literatur gelesen fürs Abitur), aber ich habe nie viel gesprochen oder geschrieben außer in der Schule. Und wann man drei Sprache kennt die sehr dicht zu einander liegen (Niederländisch, Deutsch und ein lokales Platt), vermischt man oft Ausdrucke.

[marcov]

Bei Java hat der Hersteller den Standard so festgeschrieben, dass eine Weiterentwicklung fast unmöglich ist. Bei den CIL-Bibliotheken ist es sicher noch zu früh das zu propagieren (abgesehen davon dass Microsoft als "Maintainer" eines Astes des Trees ja nicht gerade für Kontinuität bekannt ist).

Microsoft ist dafür schon bekannt. Aber nur mit sich selbst, nicht mit/für anderen.

[marcov]

Das ist neu für mich.

Habe ich vor einiger Zeit auf der MONO-Seite gefunden. Da gab es für bestimmte Prozessoren nur den Interpreter aber noch kein JIT.

Übrigens: Klar hast Dur recht, dass wegen schlechterer Optimierung CIL Code meist langsamer läuft als native Code (hatte ich ja auch schon angemerkt).

Und ich denke das CIL weniger das Problem (sondern Start usw), und mehr die generelle höheren Sprache Ebene für welche CIL/.NET konzipiert würde.

Ich vermute aber dass das CIL-System- im Gegensatz zu Java - von vorne herein auf Load-Time Kompilierung (JIT) ausgelegt wurde

Korrekt, aber ich glaube das Java das in 1.5 folgt.

und CIL deshalb deutlich schneller sein kann als Java, das ursprünglich für einen echten Byte-Code Interpreter konzipiert war und JIT hinterher dazu-erfunden wurde.

Hmm, nein, ich wurde mehr sagen das es den JIT einfacher macht, und nicht wirklich Geschwindigkeitsunterschiede liefert.

[Lori]

Also marcov, ich finde dein deutsch gut.

[mschnell]

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 ? 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.

-Michael

[mschnell]

4 Jahre Deutsch, ...

Ich kenne mehrere Holländer und alle sprechen viel lieber Englisch als Deutsch, obwohl sie restlos alles verstehen. Deshalb unterhalte ich mich mit ihnen lieber gleich Englisch (meine eigenen Fehler in Englisch merke ich ja nicht )

-Michael

[mschnell]

Microsoft ist dafür schon bekannt. Aber nur mit sich selbst, nicht mit/für anderen.

Ich weiß nicht wer die berühmte Microsoft Geschäfts-Grundlage "setze Standards und breche sie" formuliert hat, mit der loyale User abgezockt werden sollen....

[carli]

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.
Ebenfalls hat der FPC auch ein C-Backend, welches aber zur Zeit nicht so ganz funktioniert (wie mir gesagt wurde).
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.
Zudem würde das das Bootstrappen von FreePascal-Code extrem erleichtern.

[Euklid]

Der FPC nutzt ja schon den GCC zum linken.

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

[Socke]

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

Für welche Plattformen gilt das denn überhaupt?
Ich arbeite hier mit Linux und provoziere des öfteren Meldungen, dass ld ein Problem hat...

Des weiteren gilt: ein Compiler übersetzt nach Assembler, ein Assembler übersetzt in Maschinencode und ein Linker verbindet Maschinencode. Mit dem gcc zu linken ist daher mehr oder weniger nicht möglich.

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.

Das schöne an gcc ist, dass man für jeden Microcontroller "nur" ein neues Backend schreiben muss und schon kann man mit allen gcc-Compilern Programme dafür schreiben. Mit GNU Pascal gibt es sogar ein veraltetes Frontend für Pascal.
Bei Pascal muss man immer noch eine recht umfangreiche RTL portieren, wobei ich jetzt auch nicht genau weiß, wo da die Mindestanforderungen liegen (die Unit System?). Die RTL gehört ja praktisch zur Sprache dazu, während C so doof ist und selbst gar keine Funktionen mitbringt. Die libc ist nur per Standard verpflichtend (muss aber nicht unbedingt genutzt werden). Egal ob du den FPC oder einen anderen Compiler auf einer bestimmten Architektur verwenden willst, die Anzahl der Interessenten bestimmt maßgeblich, wie groß das Interesse ist, dass diese auch unterstützt wird -- und in C sind das häufig mehr als bei Pascal.

[Euklid]

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