MSElang, der zukünftige Compiler für MSEide+MSEgui

Forum für alles rund um die MSEide und MSEgui
Antworten
mse
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

Beitrag von mse »

Hier eine Wiki Seite zum Thema:
https://gitlab.com/mseide-msegui/mselang/wikis/home

Martin
Zuletzt geändert von mse am So 21. Aug 2016, 08:58, insgesamt 2-mal geändert.

creed steiger
Beiträge: 957
Registriert: Mo 11. Sep 2006, 22:56

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von creed steiger »

Das hast du dir ganz schön was vorgenommen.
Viel Erfolg mit dem Projekt.

carli
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

Beitrag von carli »

Hast du ein Konzept für Asynchronität oder Nebenläufigkeit?

Ich finde momentan die Sprache "go" von Google toll.


mse
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

Beitrag von mse »

creed steiger hat geschrieben:Das hast du dir ganz schön was vorgenommen.

Im Durchführen von wahnsinnigen Projekten habe ich viel Erfahrung. ;-)
carli hat geschrieben:Hast du ein Konzept für Asynchronität oder Nebenläufigkeit?

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

mschnell
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

Beitrag von mschnell »

mse hat geschrieben:
carli hat geschrieben:Hast du ein Konzept für Asynchronität oder Nebenläufigkeit?

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

Keine große Priorität: Völlig OK.
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" ;) )

mschnell
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

Beitrag von mschnell »

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

mse
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

Beitrag von mse »

mschnell hat geschrieben:Bezüglich der Compilier-Geschwindigkeit gilt es Delphi 2006 zu schlagen: kompiliert super flott,

Das Ziel ist Delphi 7 zu schlagen. Es ist mehr als 10 mal schneller als FPC 2.6.
Da ist m. E. fpc gar nicht so schlecht (bis auf die aktuelle Delphi-hörige Implementierung von "code aware strings" ;) )

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?
Angesichts des grossen Aufwandes ist es höchste Zeit eine Neuentwicklung durchzuziehen.

BeniBela
Beiträge: 308
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

Beitrag von BeniBela »

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

creed steiger
Beiträge: 957
Registriert: Mo 11. Sep 2006, 22:56

Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Beitrag von creed steiger »

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

mschnell
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

Beitrag von mschnell »

mse hat geschrieben:Das Ziel ist Delphi 7 zu schlagen. Es ist mehr als 10 mal schneller als FPC 2.6.

Da dürfen wir ja gespannt sein. Ich stelle mich gerne als Tester zur Verfügung.
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?

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:Angesichts des grossen Aufwandes ist es höchste Zeit eine Neuentwicklung durchzuziehen.

Kann man so sehen...

-Michael

mschnell
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

Beitrag von mschnell »

MSElang->The Steps hat geschrieben:can be used in MSEifi projects.

Willst Du wirklich eine remote GUI out of the box anbieten ???
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

carli
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

Beitrag von carli »

mse hat geschrieben:
mschnell hat geschrieben:Bezüglich der Compilier-Geschwindigkeit gilt es Delphi 2006 zu schlagen: kompiliert super flott,

Das Ziel ist Delphi 7 zu schlagen. Es ist mehr als 10 mal schneller als FPC 2.6.


Welche Probleme willst du lösen, bei denen eine 10-fache Geschwindigkeit etwas nützen würde?

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)

mschnell
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

Beitrag von mschnell »

mschnell hat geschrieben:(ich schreibe gleich noch was dazu)

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.

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.

carli
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

Beitrag von carli »

BeniBela hat geschrieben:Allerhöchstens ein Pascal LLVM-Frontend könnte sinnvoll sein


Inzwischen würde ich es hinbekommen (habe schon LLVM-basierte Sprachen entwickelt; kann inzwischen mit Parsergeneratoren umgehen), habe dafür aber keine Zeit mehr.

Antworten