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

Forum für alles rund um die MSEide und MSEgui

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

Beitragvon mse » 1. Nov 2013, 12:48 MSElang, der zukünftige Compiler für MSEide+MSEgui

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

Martin
Zuletzt geändert von mse am 21. Aug 2016, 07:58, insgesamt 2-mal geändert.
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon creed steiger » 1. Nov 2013, 16:11 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

Das hast du dir ganz schön was vorgenommen.
Viel Erfolg mit dem Projekt.
creed steiger
 
Beiträge: 937
Registriert: 11. Sep 2006, 21:56

Beitragvon carli » 1. Nov 2013, 16:18 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.
carli
 
Beiträge: 660
Registriert: 9. Jan 2010, 17:32
OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2 | 
CPU-Target: 64Bit
Nach oben

Beitragvon creed steiger » 1. Nov 2013, 16:27 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

creed steiger
 
Beiträge: 937
Registriert: 11. Sep 2006, 21:56

Beitragvon mse » 1. Nov 2013, 16:40 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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...
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon mschnell » 1. Nov 2013, 22:20 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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: 3159
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon mschnell » 2. Nov 2013, 09:06 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
mschnell
 
Beiträge: 3159
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon mse » 2. Nov 2013, 09:32 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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.
mse
 
Beiträge: 1713
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.4.2,git master FPC 3.0,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon BeniBela » 2. Nov 2013, 15:47 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
BeniBela
 
Beiträge: 229
Registriert: 21. Mär 2009, 17:31
OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4) | 
CPU-Target: 64 Bit
Nach oben

Beitragvon creed steiger » 2. Nov 2013, 15:52 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
creed steiger
 
Beiträge: 937
Registriert: 11. Sep 2006, 21:56

Beitragvon mschnell » 2. Nov 2013, 18:46 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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: 3159
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon mschnell » 2. Nov 2013, 18:54 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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
mschnell
 
Beiträge: 3159
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon carli » 2. Nov 2013, 19:06 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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)
carli
 
Beiträge: 660
Registriert: 9. Jan 2010, 17:32
OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2 | 
CPU-Target: 64Bit
Nach oben

Beitragvon mschnell » 2. Nov 2013, 19:06 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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 2. Nov 2013, 19:10, insgesamt 4-mal geändert.
mschnell
 
Beiträge: 3159
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon carli » 2. Nov 2013, 19:08 Re: MSElang, der zukünftige Compiler für MSEide+MSEgui

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.
carli
 
Beiträge: 660
Registriert: 9. Jan 2010, 17:32
OS, Lazarus, FPC: Linux 2.6.x, SVN-Lazarus, FPC 2.4.0-2 | 
CPU-Target: 64Bit
Nach oben

» Weitere Beiträge siehe nächste Seite »
Nächste

Zurück zu MSEide und MSEgui



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

porpoises-institution
accuracy-worried