MSEide+MSEgui 3.0beta1
-
- Beiträge: 2013
- Registriert: Do 16. Okt 2008, 10:22
- OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
- CPU-Target: x86,x64,ARM
MSEide+MSEgui 3.0beta1
Hallo
MSEide+MSEgui 3.0beta1 ist da.
https://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/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!
Martin
MSEide+MSEgui 3.0beta1 ist da.
https://sourceforge.net/projects/mseide-msegui/files/mseide-msegui/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!
Martin
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: MSEide+MSEgui 3.0beta1
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 ?
-Michael
-
- Beiträge: 2013
- Registriert: Do 16. Okt 2008, 10:22
- OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0)
- CPU-Target: x86,x64,ARM
Re: MSEide+MSEgui 3.0beta1
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 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.
-
- Beiträge: 657
- Registriert: Sa 9. Jan 2010, 17:32
- OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2
- CPU-Target: 64Bit
Re: MSEide+MSEgui 3.0beta1
Bitte tu das nicht.
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.
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.
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: MSEide+MSEgui 3.0beta1
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.
-Michael
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: MSEide+MSEgui 3.0beta1
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.
-Michael
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.
-Michael
-
- Beiträge: 657
- Registriert: Sa 9. Jan 2010, 17:32
- OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2
- CPU-Target: 64Bit
Re: MSEide+MSEgui 3.0beta1
mschnell hat geschrieben: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.
-
- Beiträge: 203
- Registriert: Di 22. Sep 2009, 13:08
- OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
- CPU-Target: xxBit
Re: MSEide+MSEgui 3.0beta1
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.
-
- Beiträge: 1100
- Registriert: Di 5. Aug 2008, 09:37
- OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
- CPU-Target: 32/64,PPC(+64), ARM
- Wohnort: Eindhoven (Niederlande)
Re: MSEide+MSEgui 3.0beta1
mschnell hat geschrieben:Aus Geschwindigkeits-Gründen (Kompilierung und Ausführung) und wegen der weiten Verbreitung würde ich das gcc Backend vorziehen.
Welches gcc backend würde das sein?
-
- Beiträge: 1100
- Registriert: Di 5. Aug 2008, 09:37
- OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
- CPU-Target: 32/64,PPC(+64), ARM
- Wohnort: Eindhoven (Niederlande)
Re: MSEide+MSEgui 3.0beta1
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
-
- Beiträge: 1100
- Registriert: Di 5. Aug 2008, 09:37
- OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
- CPU-Target: 32/64,PPC(+64), ARM
- Wohnort: Eindhoven (Niederlande)
Re: MSEide+MSEgui 3.0beta1
Patito hat geschrieben:
Für solche Projekte wird es auch langsam Zeit. Pascal braucht definitiv mehr mutige Projekte.
http://pascaland.org/pascall.htm
Fast alle tot....
-
- Beiträge: 657
- Registriert: Sa 9. Jan 2010, 17:32
- OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2
- CPU-Target: 64Bit
Re: MSEide+MSEgui 3.0beta1
marcov hat geschrieben: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.
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: MSEide+MSEgui 3.0beta1
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.
-
- Beiträge: 3444
- Registriert: Mo 11. Sep 2006, 10:24
- OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
- CPU-Target: X32 / X64 / ARMv5
- Wohnort: Krefeld
Re: MSEide+MSEgui 3.0beta1
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.
-Michael