MSElang, der zukünftige Compiler für MSEide+MSEgui
-
- 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
MSElang, der zukünftige Compiler für MSEide+MSEgui
Zuletzt geändert von mse am So 21. Aug 2016, 08:58, insgesamt 2-mal geändert.
-
- Beiträge: 958
- Registriert: Mo 11. Sep 2006, 22:56
Re: MSElang, der zukünftige Compiler für MSEide+MSEgui
Das hast du dir ganz schön was vorgenommen.
Viel Erfolg mit dem Projekt.
Viel Erfolg mit dem Projekt.
-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Hast du ein Konzept für Asynchronität oder Nebenläufigkeit?
Ich finde momentan die Sprache "go" von Google toll.
Ich finde momentan die Sprache "go" von Google toll.
-
- Beiträge: 958
- Registriert: Mo 11. Sep 2006, 22:56
-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Im Durchführen von wahnsinnigen Projekten habe ich viel Erfahrung.creed steiger hat geschrieben: Das hast du dir ganz schön was vorgenommen.

Hat im Moment noch keine grosse Priorität. Für meine Projekte reicht die Nebenläufigkeit von Prozessen auf Betriebssystemebene. Die meist notwendigen Synchronisationsmechanismen zur Nebenläufigkeit im Prozess fressen den Gewinn oft wieder auf sodass vor allem erhöhtem Strombedarf resultiert...carli hat geschrieben:Hast du ein Konzept für Asynchronität oder Nebenläufigkeit?
-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Keine große Priorität: Völlig OK.mse hat geschrieben:Hat im Moment noch keine grosse Priorität. Für meine Projekte reicht die Nebenläufigkeit von Prozessen auf Betriebssystemebene. Die meist notwendigen Synchronisationsmechanismen zur Nebenläufigkeit im Prozess fressen den Gewinn oft wieder auf sodass vor allem erhöhtem Strombedarf resultiert...carli hat geschrieben:Hast du ein Konzept für Asynchronität oder Nebenläufigkeit?
Dass das nichts bringt, halte ich für ein Gerücht. Populärstes Gegenbeispiel: Multiplikation großer Matrizen. Da ist überhaupt keine Synchronisation nötig, außer wenn alles fertig ist. (Anregung für in Delphi-Sprache integrierte Syntax: Prism "do parallel" und "future".)
-Michael
P.S.: die in dem Dokument aufgezählten Forderungen widersprechen sich zum Teil (natürlich) gegenseitig. Es muss immer ein Kompromiss zwischen Einfachheit, für praktischen Einsatz notwendiger Komplexität, Komfort, Portierbarkeit und Performance gefunden werden. Da ist m. E. fpc gar nicht so schlecht (bis auf die aktuelle Delphi-hörige Implementierung von "code aware strings"

-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Geschwindigkeits-Forderung:
Bezüglich der Compilier-Geschwindigkeit gilt es Delphi 2006 zu schlagen: kompiliert super flott, aber die Performance der erzeugten Programme ist nur mittelmäßig und die Protierbarkeit katastrophal. (Die Integration von Compiler, Debugger, Editor und Hilfe-System ist m.E. ebenfalls ungeschlagen).
Bezüglich der Performance der erzeugten Programme müsste sich der Compiler an C messen. GNU-C optimiert schon sehr ordentlich (vor allem die high-level - = Architektur-unanhängige - Optimierung ist beeindruckend). Intel C setzt dann (soweit ich informiert bin) für Intel-Architektur noch eine deutlich bessere low-Level Optimierung drauf. GNU-C ist natürlich ideal bezüglich der Portierbarkeit.
Beide Punkte werden deutlich schwieriger, wenn die Portierbarkeit auf verschiedene Architekturen dazukommt. GNU C ist super portierbar, aber die Kompilier-Geschwindigkeit ist sehr mäßig.
Ich halte die Portierbarkeit für sehr wichtig. X32 und X64 sind momentan wohl unverzichtbar, ARM32 inzwischen eigentlich auch. Ich vermute, dass in absehbarer Zeit Server massiv auf ARM64 umgestellt werden.
-Michael
Bezüglich der Compilier-Geschwindigkeit gilt es Delphi 2006 zu schlagen: kompiliert super flott, aber die Performance der erzeugten Programme ist nur mittelmäßig und die Protierbarkeit katastrophal. (Die Integration von Compiler, Debugger, Editor und Hilfe-System ist m.E. ebenfalls ungeschlagen).
Bezüglich der Performance der erzeugten Programme müsste sich der Compiler an C messen. GNU-C optimiert schon sehr ordentlich (vor allem die high-level - = Architektur-unanhängige - Optimierung ist beeindruckend). Intel C setzt dann (soweit ich informiert bin) für Intel-Architektur noch eine deutlich bessere low-Level Optimierung drauf. GNU-C ist natürlich ideal bezüglich der Portierbarkeit.
Beide Punkte werden deutlich schwieriger, wenn die Portierbarkeit auf verschiedene Architekturen dazukommt. GNU C ist super portierbar, aber die Kompilier-Geschwindigkeit ist sehr mäßig.
Ich halte die Portierbarkeit für sehr wichtig. X32 und X64 sind momentan wohl unverzichtbar, ARM32 inzwischen eigentlich auch. Ich vermute, dass in absehbarer Zeit Server massiv auf ARM64 umgestellt werden.
-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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Das Ziel ist Delphi 7 zu schlagen. Es ist mehr als 10 mal schneller als FPC 2.6.mschnell hat geschrieben:Bezüglich der Compilier-Geschwindigkeit gilt es Delphi 2006 zu schlagen: kompiliert super flott,
Delphi/FPC *war* nicht schlecht, darum habe ich ja auch soviel darin investiert.Da ist m. E. fpc gar nicht so schlecht (bis auf die aktuelle Delphi-hörige Implementierung von "code aware strings")
Hast du mal die neueren Sachen angeschaut (generics, das Gefummel mit den class-Sichtbarkeitsleveln, classhelper, recordhelper, namespace, for in...)? Und wissen wir was Embarcadero sonst noch alles dazuklatschen wird?
Angesichts des grossen Aufwandes ist es höchste Zeit eine Neuentwicklung durchzuziehen.
-
- Beiträge: 320
- Registriert: Sa 21. Mär 2009, 17:31
- OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4)
- CPU-Target: 64 Bit
Re: MSElang, der zukünftige Compiler für MSEide+MSEgui
Das bringt doch nichts.
Der reine Compiler (im Gegensatz zu rtl/lcl) ist doch das was bei FPC am besten funktioniert und nicht voller Bugs ist.
Allerhöchstens ein Pascal LLVM-Frontend könnte sinnvoll sein
Der reine Compiler (im Gegensatz zu rtl/lcl) ist doch das was bei FPC am besten funktioniert und nicht voller Bugs ist.
Allerhöchstens ein Pascal LLVM-Frontend könnte sinnvoll sein
-
- Beiträge: 958
- Registriert: Mo 11. Sep 2006, 22:56
Re: MSElang, der zukünftige Compiler für MSEide+MSEgui
Bei dem was Martin bisher auf die Füsse gestellt hat denke ich
a)er weiß was er tut
b)wenn er durchhält das Ergebnis sehenswert sein wird
a)er weiß was er tut
b)wenn er durchhält das Ergebnis sehenswert sein wird
-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Da dürfen wir ja gespannt sein. Ich stelle mich gerne als Tester zur Verfügung.mse hat geschrieben:Das Ziel ist Delphi 7 zu schlagen. Es ist mehr als 10 mal schneller als FPC 2.6.
Nee davon habe ich mich ferngehalten. Mir hat auch bisher noch keiner erklärt wozu das gut sein soll. Alleine die "code aware strings" machen mir bekanntermaßen Spaß. Meiner Ansicht nach - nach der bekannten vorgeschlagenen Erweiterung - der erfolgversprechendste Weg "Unicode für alle" zu implementieren. (ich schreibe gleich noch was dazu)mse hat geschrieben:Delphi/FPC *war* nicht schlecht, darum habe ich ja auch soviel darin investiert.
Hast du mal die neueren Sachen angeschaut (generics, das Gefummel mit den class-Sichtbarkeitsleveln, classhelper, recordhelper, namespace, for in...)? Und wissen wir was Embarcadero sonst noch alles dazuklatschen wird?
Kann man so sehen...mse hat geschrieben:Angesichts des grossen Aufwandes ist es höchste Zeit eine Neuentwicklung durchzuziehen.
-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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Willst Du wirklich eine remote GUI out of the box anbieten ???MSElang->The Steps hat geschrieben:can be used in MSEifi projects.
Ich habe aufgehört auf sowas zu hoffen (oder es selbst zu versuchen). Ist für mich allerdings auch nicht mehr nötig weil inzwischen auch "kleine" ARM/Linux Systeme mit einem X-Server (z.B. VNC) und einem Window-Manager und Widget-Set ausgestattet werden können.
Meine Kollegen fummeln aber immer furchtbar rum, um für Windows Services, die mit DXE gemacht sind und auf einem neuen Windows Server Betriebssystem laufen, eine optionale Bedien-Oberfläche zu schaffen.
-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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Welche Probleme willst du lösen, bei denen eine 10-fache Geschwindigkeit etwas nützen würde?mse hat geschrieben:Das Ziel ist Delphi 7 zu schlagen. Es ist mehr als 10 mal schneller als FPC 2.6.mschnell hat geschrieben:Bezüglich der Compilier-Geschwindigkeit gilt es Delphi 2006 zu schlagen: kompiliert super flott,
Achja, kleiner Tipp: Wenn du ein großes Projekt brauchst, das Performance in Pascal braucht, könntest du gwX kompilieren (da musst du aber die ganze Objektorientierung einbauen, Threads, Library-Linking, Mengen)
-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Ich vermute Du willst als einzigen String Type UTF-16 codierte 16 Bit Strings unterstützen, und dabei keine besondere Behandlung für Codepoints > 2^12 implementieren. (Das ist dann wie bei Lazarus - mit UTF-8 ohne eingebaute Behandlung für Codepoints > 2^7 - , nur dass Codepoints > 2^15 bei uns naturgemäß sehr viel seltener (eigentlich überhaupt nicht) auftreten.mschnell hat geschrieben:(ich schreibe gleich noch was dazu)
Sollen die Chinesen sich doch ihren eigenen Compiler schreiben !!!
Soll der, der tatsächlich Unicode braucht, für alle String-Operationen eben explizit Library-Funktionen aufrufen !!!
Soll der, der aus Speicherplatz und Performance-Gründen 8 Bit Strings bevorzugt, Lazarus nehmen !!!
Mir ist das zur praktischen Programmierung sehr recht. Das ist leicht zu handhaben und Ich bin ziemlich sicher dass ich nie etwas anderes brauchen werde. Aber "Unicode-Aware" darf man so ein System nicht nennen.
Ich würde allerdings uncodierte 8-Bit Strings als allgemein verwendbaren Datenspeicher sehr vermissen.
-Michael
Zuletzt geändert von mschnell am Sa 2. Nov 2013, 19:10, insgesamt 4-mal geändert.
-
- 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: MSElang, der zukünftige Compiler für MSEide+MSEgui
Inzwischen würde ich es hinbekommen (habe schon LLVM-basierte Sprachen entwickelt; kann inzwischen mit Parsergeneratoren umgehen), habe dafür aber keine Zeit mehr.BeniBela hat geschrieben:Allerhöchstens ein Pascal LLVM-Frontend könnte sinnvoll sein