Projekt: Pascal-Compiler für AVR

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

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 :)

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

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

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.

>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

Rudolf Grobe schrieb:

> 1) Pascal-to-C converter

p2c

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.

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

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.

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

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

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.

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.

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.

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

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);

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.

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

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.

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

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

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

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

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.