Hallo
MSEide+MSEgui 3.0beta1 ist da. https://sourceforge.net/projects/mseide ... /3.0beta1/
Dies ist die erste Version welche nicht mehr von FPC FCL und streaming System abhängt.
Bitte ändert falls notwendig "db" zu "mdb" und fügt "mclasses" nach "classes" in uses eurer units ein.
Auch mit der Entwicklung eines eigenen Compilers/Interpreters wurde gestartet.
Es wird einige Jahre dauern, stay tuned!
mse hat geschrieben:Auch mit der Entwicklung eines eigenen Compilers/Interpreters wurde gestartet.
Ooops ?!?!?!?
Compiler aus dem vollen geschnitzt, oder auf Basis eines bestehenden Codegenerators (gcc oder llvm) ? (wenn nicht auf Basis eines Multi-Arch Codegenerators: für welche Targets)
Compiler in Pascal oder in C programmiert ?
Ich vermute: Object-Pascal ziemlich kompatibel zu fpc und Delphi. Was soll anders / besser werden als bei fpc / Delphi ?
Aus dem Vollen geschnitzt.
Ein sehr schnelles tabellengesteuertes Frontend ohne scanner das als erstes Ziel einen Zwischencode erzeugt, welcher in remote-MSEifi Applikationen interpretiert wird. Später verschiedene backends, vermutlich auch für Mikroprozessoren. Vorerst in FPC programmiert, schlussendlich muss der compiler sich natürlich selber bauen können.
Ein LLVM-basierter Pascal-Compiler wäre eine Sache, die man noch brauchen könnte, damit Pascal-Code endlich mal in C-Geschwindigkeit und schneller laufen könnte.
carli hat geschrieben:Ein LLVM-basierter Pascal-Compiler wäre eine Sache, die man noch brauchen könnte, damit Pascal-Code endlich mal in C-Geschwindigkeit und schneller laufen könnte.
Ich habe gehört, dass die mit dem LLVM Compiler für ARM /IOS von Delphi XE sehr langsam sein sollen...
Ich denke, ein Geschwindigkeits - Manko in Pascal ist (u.a.), dass alle Variablen als volatile angesehen müssen, weil es dieses Keyword nicht gibt. Dadurch kann der Compiler schlechter optimieren.
Aus Geschwindigkeits-Gründen (Kompilierung und Ausführung) und wegen der weiten Verbreitung würde ich das gcc Backend vorziehen.
Allerdings müsste man die Definition der intermediären Information (zwischen "Frontend" und "Codegenerator", auf dieser Stufe wird die "logische" Optimierung unabhängig von Ausgangssprache und Ziel-Architektur um einige Spezifika der Pascal-typischen (nicht 100% c++ kompatiblen) Objekte erweitern. Soweit ich gehört habe, ist es quasi unmöglich, mit der gcc-Community zusammenzuarbeiten, um so etwas zu realisieren.
carli hat geschrieben:Ein LLVM-basierter Pascal-Compiler wäre eine Sache, die man noch brauchen könnte, damit Pascal-Code endlich mal in C-Geschwindigkeit und schneller laufen könnte.
Ich habe gehört, dass die mit dem LLVM Compiler für ARM /IOS von Delphi XE sehr langsam sein sollen...
Ein selbergebastelter Compiler wird noch mal ca. 4 mal langsamer sein. Und mit dem GCC würde mir das Kompilieren zu lange dauern. Ich will nicht warten, wenn ich den grünen Knopf drücke.
mschnell hat geschrieben:Ich denke, ein Geschwindigkeits - Manko in Pascal ist (u.a.), dass alle Variablen als volatile angesehen müssen, weil es dieses Keyword nicht gibt. Dadurch kann der Compiler schlechter optimieren.
-Michael
Leider. Aber man könnte es ja einführen, wenn man einen neuen Pascal-Dialekt und Pascal-Compiler entwickelt.
mse hat geschrieben:
Auch mit der Entwicklung eines eigenen Compilers/Interpreters wurde gestartet.
Es wird einige Jahre dauern, stay tuned!
Für solche Projekte wird es auch langsam Zeit. Pascal braucht definitiv mehr mutige Projekte.
Letztenendes braucht man einen Wettbewerb. Vielleicht gibt es dann auch mal wieder technischen
Fortschritt...
Ohne Konkurenzdruck wird diese absurde Monopolisten-Kacke von Embarcadero, (die dann kritiklos
in FPC reingewürgt wird) bestimmt nicht freiwillig besser.
mschnell hat geschrieben:Aus Geschwindigkeits-Gründen (Kompilierung und Ausführung) und wegen der weiten Verbreitung würde ich das gcc Backend vorziehen.
mschnell hat geschrieben:
Ich denke, ein Geschwindigkeits - Manko in Pascal ist (u.a.), dass alle Variablen als volatile angesehen müssen, weil es dieses Keyword nicht gibt. Dadurch kann der Compiler schlechter optimieren.
mschnell hat geschrieben:
Ich denke, ein Geschwindigkeits - Manko in Pascal ist (u.a.), dass alle Variablen als volatile angesehen müssen, weil es dieses Keyword nicht gibt. Dadurch kann der Compiler schlechter optimieren.
Ich denk das das nur für Systeme mit MMIO gilt
Nicht ganz. Das fängt schon beim Multithreading an.
carli hat geschrieben:Nicht ganz. Das fängt schon beim Multithreading an.
Genau. Und innerhalb eines Programms kann man die Leistung von mehreren Prozessoren - die ja inzwischen völlig üblich sind - nicht ohne Multi-Threading ausnutzen. Neue Konzepte dafür (wie "parallel Loops" und "Futures" - wie in Chrome = "Delphi .NET") gibt es ja auch (noch) nicht.
-Michael
Zuletzt geändert von mschnell am Di 2. Jul 2013, 09:37, insgesamt 2-mal geändert.
marcov hat geschrieben:Ich denk das das nur für Systeme mit MMIO gilt
Du meinst Memory Mapped I/O ?
Unter anderem dafür braucht man natürlich "volatile" in C.
Das Problem ist aber umgekehrt: In Pascal sind alle nicht-Stack-Variablen "volatile", nur weil es manchmal nötig ist. In C nur die, bei denen man es extra dran schreibt. Deshalb können alle normale Variablen optimiert werden: sie werden einmal geladen und erst abgespeichert, wenn die Funktion verlassen wird.
Verein
Links
Suche