www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Projekt: Pascal-Compiler für AVR


Autor: Marco Bajerski (earlyperl)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang M. (womai)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rudolf Grobe (rgrobe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolfgang M. (womai)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@aha
Du benutzt den AVRco?

Gruß

Autor: TheMason (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Rik Langobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
schau dir doch mal das hier an:

http://wiki.freepascal.org/AVR

Free Pascal ist ziemlich cool (vor allem mit "Lazarus" = Delphi Clone).

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aua schrieb:
> Man sollte sich im klaren sein, dass C ein Makroassembler ist,

Aua. Das tut echt weh!

Johann

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwei Anmerkungen:

Die PASCAL-Beispiele mit Einrückungen aufhübschen.

Das PASCAL-Hauptprogramm mit einem Punkt ('.') enden lassen.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolf Grobe schrieb:

> 1) Pascal-to-C converter

p2c

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es wäre schön, wenn der Thread in der Codesammlung eine neue Heimat 
findet. Hier wird er sonst mit Randthemen zugepostet.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Thread geht ueber mehr als nur alternative AVR Pascl 
implentierungen, er geht auch ueber die Wuensche an einen solchen.

Autor: Hans-Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Marco,

von welchem Pascal ist hier überhaupt die Rede ?
Welcher Standard oder auch kein Standard ?

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene H. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre es nicht einfacher GPC auf ARM umzuschreiben?

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Z8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Siggi (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
>> bin doch schon recht weit allein gekommen...

Das Projekt ist völlig unbrauchbar. 5 MByte Software und der "Compiler" 
kann praktisch nichts.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Linus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was kann der Compiler denn so alles? Gibt es eine Doku?

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach runterladen und testen!
Eine Doku gibts natürlich nicht,
so lange der Compiler nicht ansatzweise fertig ist.

Autor: Gast (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
>> 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.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und dieser Compiler beinhaltet auch einen simulator ? Optimierer ? 
Allenfalls spaeter ?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
pfft. schrieb:
> Und dieser Compiler beinhaltet auch einen simulator ? Optimierer ?
> Allenfalls spaeter ?

Ein Compiler ist ein Compiler. Was soll ein Compiler denn simulieren?

Johann

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ein Simulator ist auch geplant und soll fest in die IDE integriert 
werden.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?).

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde Pascal klasse und würde mich freuen wenn dieses Projekt 
erfolgreich verläuft.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: aha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Feste Adressen ? Willste Linker spielen ?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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);

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin auch ein Fan von "absolute" variablen. Da duerfte der Font 
automatisch fett sein.

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber wehe das Ding zieht Kreise und wird beliebt.

Genau was mit C passiert ist. Wen interessiert denn Portabilitaet. Wohin 
denn ?

Autor: Tubie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was gibt es neues von diesem Tollen Projekt?

Gruß,
Tubie

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also, ich hab nen Pascal Compiler:
www.e-lab.de/AVRco/index.html
und der funzt gut.

Gruß
  Mathias

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Zwölfliter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Herbert K. (avr-herbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Marco Bajerski (earlyperl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hatten wir den schon ?:

AVRco Pascal Compiler - AVR Pascal Compiler mit umfangreicher 
Funktionslibrary

http://www.e-lab.de/

Autor: Herbert K. (avr-herbi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus Burrer (Firma: Embedit Mikrocontrollertechnik) (_mb_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.