Hallo, möchte hier mal mein neues Projekt vorstellen: ein Pascal Compiler für AVR lauffähig sowohl unter Windows als auch unter Linux. Der Compiler produziert Assembler-Code, der dann mittels avrasm in Hex compiliert wird. Ob der Compiler je fertig wird, steht noch in den Sternen, aber mittlerweile produziert er schon recht guten Code, so dass man schon mal Leds zum leuchten bringen kann. Zur Zeit werden Globale Byte-Variablen und Konstanten unterstützt, sowie Proceduren, allerdings noch ohne Übergabeparameter. Hier der Download für Win & Linux: http://www.soft-land.de/images/cms/Pheline_Pascal_AVR.zip Würde mich freuen, wenn ihn mal jemand aus der Linux Gemeinde testet, bin gespannt, ob er auch auf anderen Systemen läuft. Unter Linux gibt es noch Probleme mit Kommentaren, warum auch immer, also Kommentare aus den Beispielen einfach rauslöschen vor dem kompilieren. Grüße Marco
Angehängte Dateien:
-
ide.jpg
100 KB
:
Gesperrt durch Moderator
Ich will ja nicht Deinen Enthusiasmus bremsen, aber kennst Du die Compiler von Mikroelektronika (http://www.mikroe.com/en/compilers/)? Die haben schon einen Pascal-Compiler fuer den AVR, um $99 wenn Du ihr Entwicklungsboard kaufst, sonst $149. Und der unterstuetzt den vollen Sprachumfang und kommt ausserdem mit einer umfangreichen Funktionsbibliothek - sowas ist privat schwer zu ueberbieten. Allerdings laeuft er nur unter Windows, wenn also das der Grund fuer Deine Eigenentwicklung ist (oder Du bloss einfach gerne einmal sowas machen wills), will ich Dich keinesfalls davon abhalten. Wolfgang
Komme gerade aus dem Dunkel der Offtopics und sehe das Licht deines Beitrages, mit meiner Leib- und Magensprache PASCAL. Dank dafür. Morgen in aller Frühe werde ich deinem Werk auf die Pelle rücken. Gute Nacht.
Schoen. Er sollte allerdings mindestens so gut wie der AVRCo Pascal Compiler von E-Lab sein. Ich denke mal noch ein paar Jahre zu warten bis er soweit ist.
Hallo, ich kenne den Compiler von mikroe, hab eine Vollversion, und genau das ist der Punkt! Wer mit dem Microe-Compiler schon ein größeres Projekt auf die Beine gestellt hat, weiß was ich meine: Zuviele Bugs, mieser Support, über 1 Jahr kein Update, trotz zahlreicher gemeldeter Bugs, siehe Mikroe-Forum, aber darum gehts ja hier nicht, es juckt mir schon ewig in den Fingern, mich mal an einem Compiler zu versuchen und kein Projekt hat bisher soviel Spaß gemacht, wie dieses :-) Marco
Schönes Projekt! Gerade als Bastler oder Student lohnt es sich auch mal das Rad neu zu erfinden. Man lernt ne unheimliche Menge dabei und am Ende entsteht dann vielleicht sogar etwas, was das vorhandene übertrifft. Früher habe ich sehr gerne mit PASCAL programmiert, heute nutze ich jedoch öfter C und C++. Ich wünsche Dir viel Erfolg, vielleicht findest du ja auch ein paar Mitstreiter :)
Hi Nach Assembler wäre Pascal auch meine erste Wahl (für AVR). War aber bisher noch nicht notwendig. Auf dem PC benutze ich sowieso Delphi. Allerdings hast du dir ganz schön was vorgenommen. Aber selbst wenn es nicht fertig wird (was ich dir nicht wünsche, aber so ein Projekt habe ich auch), kannst du nur dazu lernen. Lass dir das hier nicht kleinreden. MfG Spess
Ich hab auch schon mal an so ein Projekt gedacht. Aber bis es dann auf einem tauglichen Stand ist braucht es einiges an Einsatz. Der Pascal compiler, den ich hab, hat ein Schwergewicht auf nichtoeffentlichen Treibern zu irgendwelchen Einheiten, die ich allerdings mangels Quellcode nicht gebrauche. Ich haett lieber einen besser optimierenden Compiler als Treiber bis zum Abwinken. Die kann ich selber schreiben. Ein Compiler soll mir Arbeit abnehmen, und da sind die Erwartungen speziell bei fehlendem Standard etwas erhoeht gegenueber C.
Mir fallen da zwei Sachen ein, die vielleicht rasch zu realisieren wären: 1) Pascal-to-C converter Also Pascal-source nach C/C++ konvertieren und dann mit gcc-avr fertigstellen (lassen). 2) GNU-Pascal für AVR modifizieren Just my $0.02 ....
@aha: Das ist es auch, was mich am mikroe-Compiler so genervt hat, manchmal habe ich stundenlang nach Fehlern gesucht, bis ich dann festgestellt habe, dass es an einer mikroe-lib lag, die ebenfalls nicht Open-Source sind, so dass man den Fehler nichtmal selbst beheben kann. @Rudolf: Ich glaube es ist einfacher den Code in Assembler oder gleich in Hex auszugeben, als in C. Ausserdem würden mich warscheinlich sowohl die C Anhänger als auch die Pascal-Gemeinde dafür lynchen ;-)lol
Hi >1) Pascal-to-C converter > Also Pascal-source nach C/C++ konvertieren und dann mit gcc-avr >fertigstellen (lassen). Ich halte Pascal als durchweg gleichwertige Sprache zu C. Also wozu? MfG Spess
Naja, schaut so aus als ob Du weisst, was Du tust. Ich selber habe mit Mikroelektronika eigentlich recht gute Erfahrungen gemacht (allerdings mit MikroC fuer Microchip PIC), vor allem der Kundensupport was bisher immer schnell und hilfreich (die MikroE-Leute haben zweimal fuer mich ein kleines Programm innerhalb von 48 Stunden zum Laufen gebracht). Wegen Fehler in der Library - ja, sowas ist sehr aergerlich; allerdings zwingt Dich niemand, die eingbauten Libs zu verwenden, Du kannst ja immer Deine eigenen Funktionen schreiben. Beim Eigenbau-Compiler ist das aber nicht "kann", sondern "muss" - ich persoenlich stecke meine Zeit eben lieber in mein Elektronikprojekt, anstatt das Rad (sprich Library) neu zu erfinden, aber das ist wohl Geschmackssache :-) Wolfgang
>Also Pascal-source nach C/C++ konvertieren...
Ein Witz - spuelen. Ein Pascal kompiler kann zb das EEPROM und Code
gleich wie RAM behandeln. zB
.CSEG
const ....
.DSEG
var ....
.ESEG
var ....
Waehrend C auf Funktionsaufrufen zum Lesen und Schreiben besteht. Man
sollte sich im klaren sein, dass C ein Makroassembler ist, und bei einer
abstrakteren Spache mehr drinliegt.
aha schrieb:
> Waehrend C auf Funktionsaufrufen zum Lesen und Schreiben besteht.
C besteht mitnichten darauf.
Und wohin das führt, wenn man versucht, diese Unterscheidung dem
Compiler zu überlassen, sieht man oft genug beim IAR Compiler.
Auch ein Pascal Compiler kann keinen Code (ohne Speicherverschwendung)
generieren, bei dem das Compilat einem Pointer ansehen kann, ob das nun
eine Adresse im Flash, im EEPROM oder im SRAM ist.
Da ist mir ehrlich gesagt, die avr-gcc Lösung noch die liebste. Der
Compiler gaukelt mir da nichts vor, sondern sagt klipp und klar: Wo
welche Variable liegt, darum musst du dich beim Zugriff selber kümmern.
@marco drück dir die daumen bei deinem projekt. ich versuch mich schon seit jahren an einem compiler (gebs aber immer wieder auf ;-)) viel erfolg. werd mir deinen quellcode mal zu gemüte führen.
Hi, schau dir doch mal das hier an: http://wiki.freepascal.org/AVR Free Pascal ist ziemlich cool (vor allem mit "Lazarus" = Delphi Clone).
>Auch ein Pascal Compiler kann keinen Code (ohne Speicherverschwendung) >generieren, bei dem das Compilat einem Pointer ansehen kann, ob das nun >eine Adresse im Flash, im EEPROM oder im SRAM ist. Aber natuerlich weiss der compiler wo eine Variable ist. Ich kann eine Variable ja als im EEPROM deklarieren. Es ist dann in meinem Interesse eine Zuweisung an eine EEProm Variable nicht alle Sekunden durchzufuehren. Der AVRCo Compiler kann das zum Beispiel. Weshalb soll ich mich um einen zugriffsprozedur kuemmern muessen ? Dasselbe mit Flash. Weshalb sollte ich mich um die Details eines LPM kuemmern muessen?
>Hallo, >möchte hier mal mein neues Projekt vorstellen: >ein Pascal Compiler für AVR lauffähig sowohl unter Windows als auch >unter Linux. Vielleicht kannst du dein Projekt auf Mac OS X erweitern, oder ist das Nichts für "harte Jungs"? Ich denke, Darwin hat viele Gemeinsamkeiten mit Linux. Frank
aua schrieb:
> Man sollte sich im klaren sein, dass C ein Makroassembler ist,
Aua. Das tut echt weh!
Johann
aha schrieb: >>Auch ein Pascal Compiler kann keinen Code (ohne Speicherverschwendung) >>generieren, bei dem das Compilat einem Pointer ansehen kann, ob das nun >>eine Adresse im Flash, im EEPROM oder im SRAM ist. > Aber natuerlich weiss der compiler wo eine Variable ist. Er schrieb "das Compilat", nicht "der Compiler". Ein wesentlicher Unterschied. Zeig doch mal das Compilat von einem einfachen memory copy, bei dem die Quelle in jedem Speichertyp liegen kann.
Ich freue mich sehr über Deinen Pascal-Kompiler. Grund: Pascal-Quelltext ist wesentlich einfacher zu handhaben als Quelltext in C mit Tilden und Ausrufezeichen und weiß der Teufel was noch. Es kann aber auch sein, daß ich das nur so mistig empfinde, weil ich aus der ALGOL-Ecke komme. MfG Paul
Zwei Anmerkungen:
Die PASCAL-Beispiele mit Einrückungen aufhübschen.
Das PASCAL-Hauptprogramm mit einem Punkt ('.') enden lassen.
Noch so eine Idee am Rande: Wenn man den Pascal-Compiler als Frontend für die GCC realisieren würde, dann könnte man eventuell sogar Teile der Optimierungsroutinen wiederverwenden.
Rudolf Grobe schrieb:
> 1) Pascal-to-C converter
p2c
http://de.wikipedia.org/wiki/GNU_Pascal Es gibt doch ein Pascal Frontend für den GCC. Weiß da jemand, ob das mit dem avr-gcc funktioniert?
Es wäre schön, wenn der Thread in der Codesammlung eine neue Heimat findet. Hier wird er sonst mit Randthemen zugepostet.
Martin schrieb: > Es wäre schön, wenn der Thread in der Codesammlung eine neue Heimat > findet. Hier wird er sonst mit Randthemen zugepostet. Da er das inzwischen aber schon ist, wäre es sinnvoller, wenn der OP das gleich nochmal in der Codesammlung postet. Dann kann dieser Thread hier das weiter machen, was er nun ohnehin schon tut: alternative Pascal-Implementierungen für den AVR diskutieren.
>Er schrieb "das Compilat", nicht "der Compiler". Ein wesentlicher >Unterschied. Zeig doch mal das Compilat von einem einfachen memory copy, >bei dem die Quelle in jedem Speichertyp liegen kann. Wenn ich auf das EEProm schreibe : MyEEPromVar:=Somevar Dann muss da natuerlich die Geschichte mit dem Wait(EEPromReady) EEProm- Enable, EEDR=data usw ablaufen. Und wenn man einen String vom Flash liest die LPM Geschichte mit indexregister usw. Falls das jeweils nur einmal in der Applikation geschieht, dann bitte gleich den Code da einfuellen, sonst auf eine (Library-)Prozedur legen und aufrufen. Wo ist das Problem ? Da alle Datentypen deklariert sind weiss der Compiler welcher Art der gemeinte Speicher ist.
Der Thread geht ueber mehr als nur alternative AVR Pascl implentierungen, er geht auch ueber die Wuensche an einen solchen.
Hallo Marco, von welchem Pascal ist hier überhaupt die Rede ? Welcher Standard oder auch kein Standard ?
Meines Wissens gab es nie einen brauchbaren Standard. Der Einzige, der je ausgeufen wurde, wurde von Turbopascal ueberrollt. Das bedeutet man ist nicht an Vieles gebunden.
Hallo Hans Werner, um erhlich zu sein kenne ich für Pascal auch keinen richtigen Standard, der Standard heißt wohl Delphi... Die Syntax wird sich was die Bit-Bearbeitung angeht, an den mikroe Compiler anlehnen, da ich mit diesem schon etliche Treiber geschrieben habe.
Hi Marco Bajerski, könnte was beisteuern. Einen Formel-Parser ala: r16 = r20 or (20 * and (r17 xor r18) + r19) Habs bis jetzt in Basic implementiert, geht aber auch bestimmt im Pascal. Das Projekt ist toll, aber alleine? meld Dich mal Z8.
Hi, wieso nicht alleine, bin doch schon recht weit allein gekommen... Unter dem Formelparser kann ich mir grad nichts so recht vorstellen, in wie fern hast du das in Basic implementiert? Ich habe den Compiler in 3 Module aufgeteilt (ala N.Wirth): Scanner, Parser und Codegenerator, so kann ich ihn ohne weiteres für andere Sprachen wie zB Basic verwenden, oder auch für eine andere Architektur. Gruß Marco
Wiso schreibst du nicht mal den Florean vom FPC an ? Der AVR Support ist zu 90% schon da. Ich hatte vor ca nem Jahr mal mit ihm drüber gesprochen und er meinte das meisste sei wohl noch Tests zu implementieren (avr simulator) u.s.w. Und dann natürlich Registerkonstanten u.s.w. also Bibliothekskram.
>> bin doch schon recht weit allein gekommen...
Das Projekt ist völlig unbrauchbar. 5 MByte Software und der "Compiler"
kann praktisch nichts.
Ein ganz schlauer... von gebrauchen, war hier auch nicht die Rede. der Compiler hat schlanke 303 kb Code und dafür kann er schon ne Menge.
Ich will das Projekt nicht schlechtreden. Ich weiß auch, das es Spass macht einfach mal selbst einen Compiler für sich zu bauen, obwohl es schon freie Pascal-Compiler gibt. Aber wenn der Compiler von anderen eingesetzt werden soll, dann ist es vielleicht doch besser, auf etwas bestehenden aufzusetzen. Man unterschätzt als Einzelperson schnell den riesigen Aufwand, der hinter einem gut funktionierenden, gut wartbaren, gut getesteten, portablen und optimierenden Compiler steckt. Meine Meinung: als Privatprojekt super, wenn es professionell werden soll (also das andere das auch produktiv einsetzen), dann würde ich lieber das GPC frontend an den avr-gcc anpassen, falls überhaupt etwas angepasst werden muss.
>Ich weiß auch, das es Spass macht einfach mal selbst einen Compiler für >sich zu
bauen, obwohl es schon freie Pascal-Compiler gibt. Aber wenn der >Compiler von
anderen eingesetzt werden soll, dann ist es vielleicht doch >besser, auf etwas
bestehenden aufzusetzen.
Ich glaube Visual Basic muss wohl auf diese Weise entstanden sein.
10 GOTO 10
Einfach runterladen und testen! Eine Doku gibts natürlich nicht, so lange der Compiler nicht ansatzweise fertig ist.
>> Eine Doku gibts natürlich nicht, so lange der Compiler nicht ansatzweise >>
fertig ist.
Noch nicht einmal "ansatzweise" fertig! Vielen Dank für deine Warnung,
denn als prealpha Tester bin ich mir zu schade.
Kein Problem, dass hättest du aber auch schon aus meinem ersten Beitrag entnehmen können! Der aktuelle Entwicklungsstand kann hier verfolgt werden: http://www.soft-land.de/index.php?page=embedded-pascal
Und dieser Compiler beinhaltet auch einen simulator ? Optimierer ? Allenfalls spaeter ?
pfft. schrieb: > Und dieser Compiler beinhaltet auch einen simulator ? Optimierer ? > Allenfalls spaeter ? Ein Compiler ist ein Compiler. Was soll ein Compiler denn simulieren? Johann
Hallo, ein Simulator ist auch geplant und soll fest in die IDE integriert werden.
>Ich habe den Compiler in 3 Module aufgeteilt (ala N.Wirth): Scanner, >Parser und Codegenerator, Warum dann nicht gleich Oberon? Für irgendeinen uC hatte Wirth da ja schon viel gemacht (war es Arm?).
Weil Oberon sich nie durchgesetzt hat, obwohl es im Prinzip ein besseres Pascal ist. Wenn du auf die RISC-Architektur aus seinem Buch anspielst, die ist frei erfunden.
>Weil Oberon sich nie durchgesetzt hat, obwohl es im Prinzip ein besseres >Pascal ist. Na wenn Du eh an einem eigenen Compiler arbeitest ist doch dann Oberon besser. Oder soll bestehender Pascal Quelltext von Deinem Pascal Compiler verarbeitet werden? Wohl eher nicht. Wirth hatte doch dieses Helikopter-Projekt gemacht.
Stefan Salewski schrieb: > Ja, war für Arm. Die erste Implementierung war 1985 für eine Maschine auf Basis von NS32000. Auf ARM musste man weitere 14 Jahre warten.
Autor: A. K. (prx) Datum: 13.06.2009 19:21 Ja sicher. Hier ging es um Oberon für uC. Ursprünglich hatte Wirth natürlich Modula und dann Oberon als Nachfolger für Pascal für richtige Desktop-Maschinen entwickelt. Erst für spezielle, vorwiegend ETH-intern genutzte Maschinen, später dann auf normale PCs portiert. Wobei Oberon ja nicht nur die Sprache, sondern auch das zugehörige Betriebssystem bezeichnet. Da Oberon eine recht kompakte Sprache ist, ist es natürlich auch für uC recht gut geeignet. Aber Wirths Helikoper-Projekt kam eben recht spät.
Ich finde Pascal klasse und würde mich freuen wenn dieses Projekt erfolgreich verläuft.
> Na wenn Du eh an einem eigenen Compiler arbeitest ist doch dann Oberon > besser. Oder soll bestehender Pascal Quelltext von Deinem Pascal > Compiler verarbeitet werden? Wohl eher nicht. Doch! Beitrag "Re: Projekt: Pascal-Compiler für AVR" Es wird ein Pascal Compiler, und außerdem habe ich oben ja schon erwähnt, dass der Compiler später ohne weiteres auch für andere Sprachen portiert werden kann.
Ja. Pascal ist eine gute Wahl. Modula2 und Oberon sind beide etwas akademisch. Zum Pascal. Wie werden hier nun zwei Variablen aufeinander gelegt ? Bei Turbopascal gab's das "absolute" statement. Var u:word; b:array[1..2]of byte; absolute u; h:string(32); buf:array[1..32]of byte; absolute h; Ein anderes Pascal, das ich kenn macht's so. var u:word; blo[@u]:byte; bhi[@u+1]:byte; h:string(32); buf[@h]:array[1..32]of byte; Etwas Aehnliches ist vorstellbar, die Funktionalitaet aber ein absolutes Muss.
aha schrieb: > Etwas Aehnliches ist vorstellbar, die Funktionalitaet aber ein absolutes > Muss. Wenn man das ganze so umsetzt, dass man auch feste Adressen angeben kann, hätte man den ganzen SFR-Krimskrams quasi auch gleich erschlagen.
Wenn den I/O-Ports nicht schon im Compiler feste Adressen zugewiesen werden, sondern erst der Linker weiss wo die liegen, dann kann der Compiler auch keine adressabhängigen Optimierungen veranstalten. Bei AVRs nicht ganz unwichtig. Und ohne Peudovariablen für I/O muss man mit Zugriffsfunktionen arbeiten, was auch nicht unbedingt ein Quell steter Freude ist.
aha schrieb: > Ja. Pascal ist eine gute Wahl. Modula2 und Oberon sind beide etwas > akademisch. Zum Pascal. Wie werden hier nun zwei Variablen aufeinander > gelegt ? Bei Turbopascal gab's das "absolute" statement. In der deklaration garnicht, ich dachte da eher an Funktionen wie z.B x := 0x00FF; tmp := LOW(x); tmp2 := HIGH(x);
>ich dachte da eher an Funktionen wie z.B >x := 0x00FF; >tmp := LOW(x); >tmp2 := HIGH(x); Das sind eh benoetigte standardfunktionen. Wie schaut's denn da mit einer Zuweisung aus : zB High(x):=5; Manchmal muss man aber auch die Bytes eines Longword zugreifen koennen. Oder einen string ueber das Uart rausblasen, usw.
aha schrieb: > Zum Pascal. Wie werden hier nun zwei Variablen aufeinander > gelegt ? Bei Turbopascal gab's das "absolute" statement. Eigentlich läuft sowas über RECORD CASE ... Allerdings sollte man sich solche Konstruktionen schon aus Erfurcht vor Wirth höflichst verkneifen, denn mit dem Ansatz, Typkonvertierung oder Bytezerlegung mit Überlagerung von Variablen abzuwickeln, ziehst du garantiert sämtliche Flüche auf dich zu denen er fähig ist.
Man muss dem Compiler natuerlich ein Config-file fuer die SFR unterschieben koennen. Dort steht was wo ist, und welche Moeglichkeiten die Adressen haben. Und fuer die SFR muessen dann Bit Manipulationen moeglich sein, und zwar so, dass der Copiler das schon richtig macht.
Also mit den Fluechen von Wirth koennen wir leben. Wir sind pragmatisch, nicht akademisch. Weshalb soll ich eine Record case definition machen, um schnell was anders herum zuzugreifen ? Das genannte "Absolute" funktioniert natuerlich auch auf Variablen, die lokal zu einer Prozedur sind.
Ich bin auch ein Fan von "absolute" variablen. Da duerfte der Font automatisch fett sein.
pfft. schrieb: >>ich dachte da eher an Funktionen wie z.B >>x := 0x00FF; >>tmp := LOW(x); >>tmp2 := HIGH(x); > > Das sind eh benoetigte standardfunktionen. Wie schaut's denn da mit > einer Zuweisung aus : zB High(x):=5; > Manchmal muss man aber auch die Bytes eines Longword zugreifen koennen. > Oder einen string ueber das Uart rausblasen, usw. Mit @x bekommst du einen Pointer zu x, aber alles zu seiner Zeit.
pfft. schrieb: > Also mit den Fluechen von Wirth koennen wir leben. Wir sind pragmatisch, > nicht akademisch. Weshalb soll ich eine Record case definition machen, > um schnell was anders herum zuzugreifen ? Mein Fokus geht über AVR hinaus. Auch wenn es sich in diesem Fall um einen einfachen Compiler genau nur für AVR handelt, lehne ich solche unsaubere Konstrukte in einer eigentlich sauberen Sprache dennoch ab. Kennst du das Aliasing-Problem in C/C++? Oder das Problem, das bei Caches auftritt, wenn man mit verschiedenen Adressen und Grössen auf die gleichen Daten zugreift? Ist ebenso wie Fragen zum memory ordering die gleiche Baustelle wie dieses "absolute", auch wenn das einen einfachen Compiler für AVR nicht betrifft. Und daher sind solche Ansätze für mich unsauber. Ich weiss zu viel über die Konsequenzen, die sowas haben kann, um es als elegant zu betrachten. Akademisch ist das m.E. eher nicht, weil es in anderem Kontext als AVR durchaus von Bedeutung sein kann wie man so etwas löst. Und wenn man den Compiler als Frontend vor einen Compiler wie GCC setzt, dann kann man u.U. auch bei AVRs Überrschungen erleben. Daher: Wenn man Variablen in anderer Weise verwendet als deklariert, dann sollte das an der Stelle wo dies geschieht deutlich erkennbar sein. Alternativ käme in Frage, alle Variablen, die irgendwie überlagert werden könnten, an Ort und Stelle entsprechend zu kennzeichnen. Im obigen Beispiel also nicht nur "buf" sondern auch "h".
Unsauber ? Der eine Standardansatz waere pointer : Type lwptr=^longword; qbytearray=array[1..4]of byte; baptr=^qbytearray; var lw:longword; lp:lwptr; bap:baptr; code lp:=@lw; bap*:=lp; und endlich : bap[1]:=1; bap[2]:=2; bap[3]:=3; bap[4]:=4; der andere Standardansatz ueber einen Record type myrec=record case x a:longword; b:array[1..4]of byte; end; end; Beides sehr unstaendlich und aeusserst muehsam. Dann kann man gleich bei C bleiben, sorry. Die Staerke von Pascal, wie ich's kenn, ist ein pragmatischer, eleganter Ansatz bei dem man sofort den Ueberblick hat und behaelt. Das hat Wirth leider nicht drauf gehabt, deshalb wurd's auch nichts.
Eine Stärke wäre es, den Mist den man in C machen kann, in Pascal eben nicht zu machen. Ich will versuchen, eines der Probleme zu illustrieren, nämlich das mit dem Aliasing: Wenn eine Funktion mehrere VAR Parameter verschiedenen Typs hat, dann weiss ein Compiler einer Sprache ohne Möglichkeit der Überlagerung, dass diese sich nicht überlappen können. Dass also die Zuweisung an die eine Variable den Wert der anderen nicht ändert. Erlaubt die Sprache Überlagerung, dann muss ein Compiler davon ausgehen, dass alle solchen Parameter in Wirklichkeit identisch sein können. Das hat fundamentale Konsequenzen für Optimierung. Analog dazu wäre eine Zuweisung über einen Pointers zunächst das Ende jeder Zugriffsoptimierung auf viele Variablen, weil der Compiler nicht einmal bei typfremden Variablen sicher sein kann, dass sie nicht mit dem Ziel des Pointers überlappen. Auch ein RECORD CASE löst dieses Problem nicht ganz. Zu lösen ist das beispielsweise, indem sichergestellt wird, dass Variablen, die sich überlappen können, nur direkt aber nicht in Form einer Adresse verwendet werden, also auch nicht als Argument eines VAR Parameters. Ist eine indirekte Verarbeitung nicht zugelassen, dann kann ein Compiler bei Daten innerhalb eines RECORD CASE auf Zugriffsoptimierung verzichten um dem Problem zu entgehen. Dass diese Problem bei ziemlich alten Compilern nicht auftritt, liegt an der dort fehlenden Optimierung.
Das ist doch alles Anwendersache. Oder? ...oder gibt's nichtmal nen Pascal-Standard, der Syntax und Semantik der Sprache festlegt? Meine Pascal-Zeiten sint etwas her, mit war die Sprache zu sperrig. Und ohne Spezifikation ist ne Sprache doch recht witzlos, da kocht dann eh jeder sein eigenes Süppchen und Portabilität und Allgemeinheit interessieren nicht die Bohne. Jedes Gadget, das gerade gut zur Hand steht, wird eingebaut weil's so hüppsch ist und so chic und ein paar Buchstabentippsler spart... Johann
Johann L. schrieb: > > witzlos, da kocht dann eh jeder sein eigenes Süppchen und Portabilität > und Allgemeinheit interessieren nicht die Bohne. Jedes Gadget, das > gerade gut zur Hand steht, wird eingebaut weil's so hüppsch ist und so > chic und ein paar Buchstabentippsler spart... Genau so ist es. Wenn der Compiler ein Exot ist und bleibt, also eine Privatsprache für ein paar Programmierer bleibt, dann ist das völlig egal. Aber wehe das Ding zieht Kreise und wird beliebt. Auf solche Art haben sich Intel wie Microsoft schon etliche Entwicklerflüche eingehandelt. Der Art "wie konnten die nur so kurzsichtig sein".
Kleines Beispiel wie solche Aliasing-Probleme an den überrschendsten Stellen auftauchen und für Ärger sorgen: Als Intel anno 286 definierte, dass der Reload eines Segmentregisters zwingend den Descriptor aus dem Speicher nachläd, auch wenn's das gleiche Handle ist, da war das noch kein Problem. Als sie dann beim PentiumPro angekommen waren, da machte u.A. diese Definition diesen Prozessor für Win95 ziemlich untauglich. Und so mussten sie im Pentium-II zur Optimierung von Segmentregistern nur wegen dieser Kurzsichtigkeit eine komplexe Snooping-Logik einbauen, die alle Schreibzugriffe daraufhin abklopft, ob sie zufällig auf einen geladenen Descriptor gehen. Hätte Intel anno 286 einen entsprechenden Invalidate-Befehl definiert, anfangs als NOP implementiert, wäre das Thema ohne jeden Aufwand für alle Zeit erledigt gewesen.
>Aber wehe das Ding zieht Kreise und wird beliebt.
Genau was mit C passiert ist. Wen interessiert denn Portabilitaet. Wohin
denn ?
Hi! Im Moment nix nennenswertes, mache grad mein Auto Tüv-fertig, hab daher nicht viel Zeit. Nächste Woche tut sich wieder mehr. Gruß Marco
Also, ich hab nen Pascal Compiler: www.e-lab.de/AVRco/index.html und der funzt gut. Gruß Mathias
Weiß jemand, was aus dem AVR Port von Free Pascal geworden ist? Bisher finde ich da nicht viele Informationen drüber http://wiki.freepascal.org/AVR
Es ist natürlich eine gute Herausforderung und mächtiger Spaß einen Pascal-Compiler zu entwickeln. Als Anwender von Programmiersprachen für Mikrocontroller ist mir aber schon Heute das Vorhandensein von Assembler, C und Basic ein Dorn im Auge. Verschiedene Sprachen teilen die Menschen und so macht jede weitere Sprache die Sache nur noch schlimmer. Wie soll man den als Pascal-Programmierer für AVR in einem Forum Hilfe bekommen? Schon Basic-Leute haben es sehr schwer, Gleichgesinnte zum Erfahrungsaustausch zu finden.
Sicher, es wäre einfacher, wenn alle in Assembler programmieren. Dann bräuchte man alles nur einmal zu machen. Alles wäre zu 100% ausgearbeitet Aber das Leben wäre doch langweilig ohne Vielfalt? Nicht jeder möchte Assembler programmieren. Assembler ist nicht unbedingt für jede Aufgabe geeignet. Das gleiche könnte man über C schreiben
>Verschiedene Sprachen teilen die Menschen und so macht jede weitere >Sprache die Sache nur noch schlimmer. Wie soll man den als >Pascal-Programmierer für AVR in einem Forum Hilfe bekommen? Schon >Basic-Leute haben es sehr schwer, Gleichgesinnte zum Erfahrungsaustausch >zu finden. Ziemlicher Quatsch, fast das gesamte Roboternetz besteht aus basic was eines der größten AVR Foren ist. Auch wenn ich kein Basic Freund bin, aber blind nicht. Und problematisch sind die Sprachunterschiede nicht, Registernamen sind überall gleich Datenblätter haben also die selbe Auswirkung und eine schöne Hochsprache wie Pascal kann einem die Arbeit schon sehr erleichtern. >Weiß jemand, was aus dem AVR Port von Free Pascal geworden ist? Nicht viel bisher fürchte ich, er kann Code erzeugen aber das wars im weitesten sinne auch, Florian steckt da nicht zu viel Aufmerksamkeit hinein. Ich denke wenn sich 2-3 Leute finden würden die etwas helfen und ihn nerven würd man da in 2-3 Monaten was vernünftiges hinbekommen ich schließ mich da nicht aus wär auch froh über den Port man muss sich halt nur immer die Zeit abzwacken. lg Christian
Hallo, nur so mal am Rande: Aktuell ist unter http://www.soft-land.de/ nichts mehr von dem Projekt über geblieben. (oder dem Server ist zu heiß bei dem Wetter)
naja war glaub ich eher ne Spielerei. Wobei es damals mit freepascal ähnlich begann, der Florian hatte keine Lust sich sein Schachprogramm in C zu schreiben und damals gabs unter unix kein brauchbares Pascal ... lg Christian
Mahlzeit, der Compiler ist immer noch in Arbeit und nicht in Vergessenheit geraten, aber wegen Familienzuwachs bleibt im Moment nicht soviel Zeit, aber gegegentlich arbeite ich dran. Wie Herbert K. bereits bemerkt hat, leidet auch die Website darunter. Zwischenzeitlich sind ein Assembler und ein Simulator für eine kleine eigene 32 Bit Architektur enstanden, lauffähig auf einem CPLD / FPGA, diese soll ebenfalls vom Pascal Compiler unterstützt werden. Grüße Marco
Hatten wir den schon ?: AVRco Pascal Compiler - AVR Pascal Compiler mit umfangreicher Funktionslibrary http://www.e-lab.de/
Hallo Klaus, was vielleicht Du + andere nicht wissen: Das Projekt ist ja entstanden, weil seinerzeit der mikroPascal Compiler von mikroe so einige Macken hatte, und man damit kein wirkliches Projekt realisieren konnte. ( Marco möge mich bitte korrigieren, wenn das nicht so war ) Mit der aktuellen Version kann man arbeiten und (vielleicht habe ich ja nur Glück gehabt [Lib.Fehler war in 2 Tagen ok]) kümmern Sie sich auch um Fehler. Viele Grüße Herbert
Hallo Herbert, der AvrCo-Compiler hat auch die ein oder andere Macke. Die Funktionsbibliothek ist allerdings recht umfangreich. Der System beherrscht auch Multitasking. Den Compiler für eine Atmega8 und Atmega88 gibt es umsonst. Ich wollte AvrCo nur der Vollständigkeit halber erwähnen. Gruß, Klaus
Der AVRco kostet halt Geld, wenn man mehr als Mega8/88 will und ist Windows only, genauso wie das Zeug von Mikroe. Für Linux User gibt es quasi nix außer dem avr-gcc Marco Bajerski schrieb: > der Compiler ist immer noch in Arbeit und nicht in Vergessenheit > geraten, aber wegen Familienzuwachs bleibt im Moment nicht soviel Zeit, > aber gegegentlich arbeite ich dran. Ich habe zwar auch eigentlich keine Zeit, aber ein wenig Hilfe möchte ich anbieten.
Hallo Marco, seit zwei Jahren hat sich hier nichts mehr getan??? Ich wollte mal diese Diskussion wieder erwecken. Gibt es was Neues zu berichten? Interessiert bin ich nähmlich immer noch. Wie ist der Stand mit dem Nachwuchs?? ;-) Ist die Entwicklung des Pascal-Compiler weitergegangen? . . . . Holger
Beitrag #5173741 wurde von einem Moderator gelöscht.
Beitrag #5173994 wurde von einem Moderator gelöscht.
Beitrag #5174149 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.
Thread beobachten
Seitenaufteilung abschalten