Forum: Projekte & Code Ein kleiner Oberoncompiler für die C16x-Familie

Ist das nicht Pascal?

Alex W. schrieb:
> Ist das nicht Pascal?

Im Prinzip schon, nur etwas moderner, macht mehr Spaß.

Alex W. schrieb:
> Ist das nicht Pascal?

Siehe

http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29

Zitat:

Oberon, 2000 offiziell in ETH Oberon umbenannt, ist eine von Niklaus 
Wirth und Jürg Gutknecht entwickelte, objektorientierte, streng 
strukturierte Programmiersprache. Sie ist den ebenfalls von Wirth 
entworfenen Vorgängern Pascal und Modula-2 recht ähnlich, allerdings 
strukturierter als Pascal und mächtiger, gleichzeitig aber erheblich 
weniger umfangreich als Modula-2.

Für das SVN bekommt man wohl nicht so einfach Zugriff,
deshalb der aktuelle Stand als tgz. Momentan bin ich
dabei strukturierte Variablen als variable Parameter
zu implementieren. Dies ist für mich Voraussetzung für
den Modulimport.

Es sind Buildskripte für Linux und Windows dabei, eventuell
müssen für die ausführbaren Dateien die absoluten Pfade hierin
eingefügt werden.

Ich habe noch ein paar umfangreichere Beispiele hinzugefügt,
dabei nur Buildskripte für Linux, die lassen sich ja aber
leicht in .bat umwandeln.

Viel Spaß damit, Guido

Achso: Einen Artikel im Wiki habe ich unter OberonC16x angelegt,
vielen Dank an Gjlayde für das "Wikifying".

Arrays und Records können jetzt an Prozeduren als variable
Parameter übergeben werden. Im .tgz (wäre .zip vernünftiger?)
sind wieder Executables für Linux und Windows. Als Demo habe
ich das CAN-Beispiel entsprechend angepasst und es gefällt mir
so schon viel besser ;-).

Die Doku habe ich angepasst und noch einen Abschnitt zur
Speicherverwendung angehängt.

Viel Spaß, Guido

Hallo C167,

danke für die Ermunterung. So arg veraltet ist die Familie
noch nicht, die letzten Mitglieder sind ja erst vor ca. 3
Jahren auf den Markt gekommen (XE16x) und werden sicher noch
lange produziert werden. Für das Hobby ärgerlicher ist die
schlechte Verfügbarkeit, es ist ja fast unmöglich sowas zu
kaufen (Darisius ist wohl der einzige Anbieter).

Mit den ärmlichen Controllern hast du natürlich recht, in
meiner ursprünglichen Planung war die C16x-Version nur ein
Framework, das ich auch für andere Controller nutzen kann
(oder auch jemand anders). Aber da ist mir wohl Astrobe
zuvorgekommen, die Australier hatten wohl aber auch Wirths
Code zur Verfügung (das kann ja jeder).

Gruß, Guido

C167 schrieb:
> Die XE16x (oder
> ST10F2XX) ist eine Laufzeitverlängerung der Produkte, ohne aufwendiges
> Redesign - nicht mehr!

Zum Glück, daher Opcodekompatibel. Aber mit MAC-Unit und deutlich
mehr Dampf.

> Jedoch sind die Controller "not recommended for new design".
>

Dazu finde ich nichts, auch nicht bei den XC2xxx.

> ST setzt beim ST10FXXX ganz auf STM32XXX Preisunterschied von ca. 5:1
> und das bei einem Leistungsunterschied von ca. 1:7.
>

Wobei die ST-Derivate wohl noch teurer sind als die Originale und ebenso
schwer zu bekommen.

> Die Strategie bei Infineon ist mir allerdings nicht ganz klar.

Gibt es sowas überhaupt bei Infineon?

> Viele herausragende Leistungsmerkmale, die den Erfolg der C16X-Famile
> ausmachten, hat ARM in der Cortex-Reihe übernommen.

Muss ich mal genauer anschauen. Beim Compilerbau merkt man sehr schnell,
wie genial die C166-Familie designed war. Wenn man bedenkt, dass das
noch Siemensianer waren, die damals ja wie Beamte belächelt wurden.

> Trotzdem, bastle an Deinem Compiler bitte weiter!

Klar, der Modulimport fehlt ja noch ;-).

Gruß, Guido

Hallo C167,

ein paar davon könnte ich schon gut brauchen, insbesondere
ST10F269 und/oder XC164. Eventuell auch wenige der älteren,
dann kann ich den ROMemulator mal wieder benutzen.

Für St10F275 finde ich kein Datenblatt, soviel Flash werde
ich aber wohl auch nicht brauchen.

Gruß, Guido

Naja, erstens ist er Professor ;-) , zweitens entwickelt man sich doch 
im Leben weiter und kann dann irgendwann bessere Konzepte vorlegen.

C war nichts als eine Art Makrosprache für Assembler. Ich glaube, das 
stand auch in einem der frühen Papers zu C. Kurioserweise hat sich diese 
unsägliche Sprache zum Industriestandard entwickelt. Mit der Folge, daß 
es unendlich viele Abstürze und Datenverluste von PCs bisher gab. 
Wildgewordene Pointer, schreiben über die Bounds von Arrays, usw.

Pascal gefällt mir übrigens auch nicht :-)

Hallo,

ein Forumsteilnehmer, mein 1. Sponsor :-), hat mich überzeugt, dass
so ein Projekt ohne Source-Level-Debugger wenig Sinn macht. Also
habe ich mal einen ersten Entwurf hierzu mit Lazarus erstellt. Auch
an diesem lässt sich sicher noch vieles verbessern.

Es gibt erstmal nur eine Linuxversion, sie ist gezipped, wodurch
sie wenigstens etwas handlicher wird. Da sich der Rest der
Dokumentation nicht geändert hat, hänge ich nur den Teil über den
Debugger an. Der Compiler musste für diesen natürlich angepasst
werden, daher noch ein neues tgz.

In den nächsten Tagen werde ich versuchen, den Debugger unter Windows
zum Laufen zu bringen, wenn das klappt, gibt es auch die Quellen dazu.

Viel Spaß, Guido

Ja eben. Du schreibst es selber! C ist für das Implementieren eines BS 
gedacht und nicht für Anwendersoftware! Wer ein BS schreibst, ist 
absolut sattelfest und schreibt im Allgemeinen recht fehlerfreie 
Software. Der Rest der Menschheit <wie ich> ist in einer Skriptsprache 
besser aufgehoben. Alles wird überprüft. Da macht ein Performanceverlust 
von 50% gar nichts.

Forth und NET sind schonmal gute Ansätze.

Gnade bitte,

dass meine kleine Implementierung solche Sachen nicht berücksichtigt,
liegt doch nur an meinen begrenzten Fähigkeiten. Das richtige Oberon
ist ja ein Betriebssystem und kennt natürlich Pointer und OOP, die
auf diesen basiert.

Die Speicherkontrolle gelingt natürlich auch ohne BS, in pascaloiden
Sprachen sind die Längen aller Strukturen ja wohlbekannt. Auch hier
ist es ausschließlich meine Entscheidung gewesen darauf, entgegen dem
dringenden Rat N.Wirths, der mit einer Beispielimplementierung
unterbaut ist, zu verzichten, da auf einem µC halt keine einheitliche
Fehlerbehandlungsmethode zur Verfügung steht. Gegen Nullpointer ist
wohl aber auch unter Oberon kein Kraut gewachsen, obwohl, soweit ich
das überblicke, immerhin das fragwürdige nil abgeschafft wurde.

Grüße, Guido

Salewski, Stefan schrieb:
> Ich meine, nil ist in allen Oberon-Varianten vorhanden, wie z.B. auch in
> Ruby. Eben ein per Definition ungültiger Zeiger.

Also doch noch. :-(. Woran erkennt man einen ungültigen Pointer
( = Adresse)? Wirth umgeht das Problem, indem er einen Wächterpointer
namens Guard anstelle nil verwendet, dies ließ mich vermuten, dass
nil vernünftigerweise obsolet ist.

Danke für den Hinweis, Guido

W.S. schrieb:
> Abdul K. schrieb:
>> Forth und NET sind schonmal gute Ansätze.
>
> Wie bitte??
> Du meinst, dieses unsägliche Forth sei ein guter Ansatz?
> Und DotNet auch? Zu interpretierender Text als EXE verkappt?
> Also, Abdul, du scheinst in diesem speziellen Punkt momentan zum
> Stänkern aufgelegt zu sein, also beruhige dich bitte wieder.

Ich bin Hardware-Mensch, der sich mit kleinen C-Programmen noch 
rumärgern darf. Mehr ist da nicht. Ich brauche also eine Sprache die 
effektiv ist und auch nach Monaten Abstinenz noch benutzbar bleibt.

Aus der Sicht eines täglichen Programmierers ist das Spielzeug, was die 
Software angeht.

Daher kann es keine einheitliche Sichtweise geben.

Ich weiß nicht was an Forth so schlimm ist. Es ist ein interessantes 
Konzept. Leider in Vergessenheit geraten.


Aber mit Oberon hat dies nicht mehr viel zu tun.

W.S. schrieb:
> Schlampige Programmierer haben sich
> eine zu ihnen passende Sprache auserkoren, die Compiler bauen keine
> Indexüberprüfung in den erzeugten Code ein

Grumpf, dann sollte ich das doch wohl strenger handhaben? Anschiss
angekommen, Konsequenzen, weiß noch nicht. :-)

Aber grundsätzlich sind deine Argumente schon korrekt.

Ja Stefan, das ist mir schon klar.

Aber gerade bei einem Controller mit segmentiertem Speicher, über
den reden wir hier ja, gibt es keine definitiv ungültige Adresse.
Ich hätte vermutet, dass dieses Problem schon in Modula beseitigt
wurde. Da muss ich wohl noch mal recherchieren.

Gruß, Guido

Guido B. schrieb:
> Ja Stefan, das ist mir schon klar.
>
> Aber gerade bei einem Controller mit segmentiertem Speicher, über
> den reden wir hier ja, gibt es keine definitiv ungültige Adresse.
> Ich hätte vermutet, dass dieses Problem schon in Modula beseitigt
> wurde. Da muss ich wohl noch mal recherchieren.
>

Es gibt eigentlich alles! Also Vorsicht!
Bei 68K wird z.B. der Speicherzugriff vom Speicherinterface beantwortet. 
War glaube ich /DTACK. Kommt der nicht, gibts Exception!

Ersa schrieb:
> Findest du das tatsächlich?

Meine Aussage bezog sich ausschließlich auf den zitierten Teil
des Beitrags. Aber hier reden wir doch von der µC-Programmierung,
naja Forth gibt es schon, aber Skriptsprachen sind in diesem
Bereich doch eher unüblich.

Salewski, Stefan schrieb:
> Nebenbei: Oberon war ja eher für den PC gedacht. Allerdings gab es ganz
> spät von Wirth eine Version für ARM, die könntest Du dir mal ansehen.

Hi Stefan, die liegt mir vor, in Form vom kommerziellen Astrobe. Dieses
beruht auf den nicht veröffentlichten Quellen N.Wirths. Aber ich rede
nicht von Plänen, sondern stelle hier mein funktionierendes Projekt vor.
N.B.: welche Adresse würde sich für nil denn eignen? Im segmentierten
Speicher gibt es diese erstmal nicht. Und initialisieren muss in
pascaloiden Sprachen der Programmierer!

Schaut man etwas in den Embedded-Zukunft, wird sicherlich nur ARM 
übrigbleiben. Den anderen Architekturen wird die Luft ausgehen und neue 
sind momentan nicht in Sicht. Oder habe ich etwas verpaßt? Ja genau, 
richtig gelesen: Abdul prophezeit das AVR und ähnliche schon bald tot 
sind.

Forth gibt es in Form von IPS-32 für ARM und fliegt über unseren Köpfen 
als 'Hochsicherheitssystem' in Amateur-Satelliten. Gut, man kann nicht 
alles wissen.

C ist einfacher der billige Heinrich. Darauf hat sich die 
Controller-Welt eingeschworen. Ob man will oder nicht. So muß ich es 
leider auch benutzen, denn die Entwicklungsumgebungen bieten meist nur 
ein Assember und ein C Interface.

Aber man darf ja mal über den Zaun schauen.

Guido B. schrieb:
> N.B.: welche Adresse würde sich für nil denn eignen? Im segmentierten
> Speicher gibt es diese erstmal nicht. Und initialisieren muss in
> pascaloiden Sprachen der Programmierer!

Das hängt von der CPU ab. Meist wird -1 verwendet.

Abdul K. schrieb:
> Das hängt von der CPU ab. Meist wird -1 verwendet.

Beim C16x ist -1 = 0xFFFFh, eine gültige Byteadresse. O.k. ein
Pointer benötigt ein Word, es war aber immer eine blöde Idee
und N.Wirth zeigt, wie es besser geht.

Guido B. schrieb:
> Abdul K. schrieb:
>> Das hängt von der CPU ab. Meist wird -1 verwendet.
>
> Beim C16x ist -1 = 0xFFFFh, eine gültige Byteadresse. O.k. ein
> Pointer benötigt ein Word, es war aber immer eine blöde Idee
> und N.Wirth zeigt, wie es besser geht.

Du scheinst undankbar zu sein. Erst fragst du um dann sofort 
rumzumeckern. Natürlich ist für die CPU jede Adresse erstmal korrekt. 
Wirth habe ich nie länger gelesen. Das war mir zu schwülstig.
Der Speicher wird traditionall von Null an belegt mit Hardware und damit 
auch mit Daten. Die letzte Speicheradresse bietet sich also an.
Apple hat z.B. eine Adresse verwendet, die zu einer Exception führt weil 
sie ungerade ist und die 68K nur auf geraden Adressen zugreifen wird, 
denn der Apple Memory Manager bietet der Anwendungssoftware nur gerade 
Adressen an. Greift das Programm auf einen ungeraden Pointer zu, so wird 
es also sofort abgeschossen. Der berühmte Busfehler 1 kommt in einem 
Dialog zum Anwender.
Andere haben sich spezielle Strings ausgedacht, BEEF irgendwas. Näheres 
findest du auf Wikipedia.

Immer diese jungen Hüpfer.

Hallo,

jetzt habe ich den Debugger auch unter Windows kompiliert bekommen.
Getestet unter Win2k und XP. Dabei ist mir aufgefallen, dass sein
"Formular" für ein älteres Notebook doch etwas riesig ist, werde ich
bei Gelegenheit verkleinern. Die aktuellen Quellen dafür hänge ich
als tgz an.

@ Abdul: Ich bin nicht undankbar, die Idee mit der ungeraden Adresse
habe ich doch gewürdigt. Da wäre ich halt nicht darauf gekommen, so
etwas ruft auch bei den C16x einen Trap hervor. Aber den "jungen Hüpfer"
nimmst du gefälligst zurück, sonst streite ich nicht mehr mit dir. ;-)
Als solcher würde ich bestimmt keinen Oberoncompiler in Pascal 
schreiben.

Viel Spaß, Guido

Also mal ehrlich, was soll dieser Flame-War ?!
Nur weil jemand C nicht mag heißt das nicht das C schlecht ist. Und nur 
weil Pascal bestimmte Prüfungen vornehmen kann (!!) heißt das nicht das 
die Programme automatisch fehlerfrei sind.
Und nur weil Zeiger eben nicht ganz unkritisch sind heißt das nicht das 
es automatisch Probleme mit sich bringt. Ein Programm ist immer nur so 
gut wie der der es programmiert hat. Und wenn Zeiger Amok laufen dann 
hat der Programmierer Mist gemacht, und nicht die Programmiersprache. 
Klar gibt es noch den Compiler der da zwischenfunken kann und Mist bauen 
kann. Aber hat das was mit C zu tun ?!
Wenn man halbwegs gescheit programmiert passieren solche Sachen auch 
nicht. Klar kann Pascal Prüfungen auf Arrayüberläufe einbauen. Aber 
Typ-Schweinereien kann man in Pascal auch machen, die dann bestimmt auch 
zu bösen Abstürzen führen. Wenns danach geht wäre C# dann besser. Und 
gibts das auch für nen AVR ?!

Mal im Ernst. Was soll das ?!
C ist nunmal die universelle Programmiersprache die recht nah an der 
Maschine ist und wird zumeist als erste Sprache auf einem neuen 
Prozessor implementiert. Pascal ist einfacher lesbar und durch 
forwarding auch schnell compilierbar, braucht bei Arrayüberlaufprüfung 
aber auch mehr Zeit. Ist ansonsten aber leicht erlernbar und auch 
relativ gut auf uCs zu implementieren. C# ist ne neue Krankheit von 
Microsoft was auf einem uC wahrscheinlich nicht implementierbar ist 
(jedenfalls keinem AVR/PIC/8/16-Bitter und keine kleinen 32 Bitter). 
Java geht auch nur rudimentär auf nem AVR. Wobei die Interpretersprachen 
(also ALLE Sprachen die Bytecode erzeugen der auf einer virtuellen CPU 
läuft) allesamt recht viel Ressourcen brauchen, und je nach Sprache auch 
gar nicht umsetzbar sind (AVR und C# z.b.). Forth gibts eh immer mal 
wieder ohne das es sich so durchsetzen kann. Und Basic ist auch fast 
überall zuhause. Hab ich noch ne Programmiersprache (bis auf vllt Algol, 
Fortran) vergessen ?

Leute leute ...

Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua.
Das ist ja das Problem. Ich brauch nur in den Windoof-Ordner schauen, 
wieviele Libs dort sich sammeln. Von den vielfachen Kopien woanders auf 
der HD gar nicht zu sprechen. Achso, wir waren ja bei Controllern.

>Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua.

Welche von den "vergessenen" ließen sich denn auf einem uC 
implementieren ?

>Ich brauch nur in den Windoof-Ordner schauen, wieviele Libs dort sich
>sammeln.

Dann bleib bei Linux, CP/M oder sonstwas. Jedes Betriebssystem hat seine 
Macken. Klar ist Windows nicht das tollste. Aber es läuft und wird 
benutzt. Egal ob da ein "Hype" hintersteckt oder nicht. Meinst du etwa 
wenn Apples Betriebssystem weltweiter Standard wäre wäre die Welt besser 
? Ich glaube nicht. Ähnlich sehe ich das bei Linux.
Es gibt kein perfektes OS. Also braucht man sich meiner Meinung nach 
auch nicht ärgern. Oder wie stellst du dir das vor das a) für dich zu 
ändern und b) für die Welt zu ändern ?

>Achso, wir waren ja bei Controllern.

Eben. Und da ist weder Pyhton, Ruby, C#, .net oder sonst eine der 
"neueren" Sprachen sinnvoll. Da bleibt als ernstzunehmende Sprache nur 
C, Pascal, Basic und eben Assembler übrig oder ?

Vor allem würde ich Pascal streichen und durch Oberon
ersetzen. ;-)

Rene B. schrieb:
>>Vergessen hast du viele, u.a. Ruby, Phyton, PHP, Lua.
>
> Welche von den "vergessenen" ließen sich denn auf einem uC
> implementieren ?
>

Alle.


>>Ich brauch nur in den Windoof-Ordner schauen, wieviele Libs dort sich
>>sammeln.
>
> Dann bleib bei Linux, CP/M oder sonstwas. Jedes Betriebssystem hat seine
> Macken. Klar ist Windows nicht das tollste. Aber es läuft und wird
> benutzt. Egal ob da ein "Hype" hintersteckt oder nicht. Meinst du etwa
> wenn Apples Betriebssystem weltweiter Standard wäre wäre die Welt besser
> ? Ich glaube nicht. Ähnlich sehe ich das bei Linux.
> Es gibt kein perfektes OS. Also braucht man sich meiner Meinung nach
> auch nicht ärgern. Oder wie stellst du dir das vor das a) für dich zu
> ändern und b) für die Welt zu ändern ?

Es beruhigt zu hören, daß die Softmasochisten auch keine Lösung haben.


>
>>Achso, wir waren ja bei Controllern.
>
> Eben. Und da ist weder Pyhton, Ruby, C#, .net oder sonst eine der
> "neueren" Sprachen sinnvoll. Da bleibt als ernstzunehmende Sprache nur
> C, Pascal, Basic und eben Assembler übrig oder ?

Momentan fällt mir keine ein. Ich konnte mich aber eh nie wirklich 
entscheiden.
Interessant finde ich noch den Propeller-Dialekt. Klar, das ist ein 
Nischenprodukt.

Hallo Tom,

natürlich ist Feedback wichtig, sonst müsste man so ein Projekt ja nicht
veröffentlichen, daher nochmals Dank an dich. Leider ist in diesem
Thread nicht viel davon sichtbar, Stefan Salewski war bisher der
einzige konstruktive Teilnehmer. Es ist aber auch klar, dass nur
Leute mit zufälligerweise vorhandener Hardware mitspielen können.

Zum Thema sicheres Programmieren möchte ich mich eigentlich nicht sehr
weit aus dem Fenster lehnen, da ich gerade hier sehr nachlässig war und
viele Eigenschaften Oberons die hierzu beitragen in meinem kleinen
Compiler (noch) nicht realisiert sind. Natürlich exisistiert die strikte
Typenüberprüfung, die nicht nur triviale Fehler ausschließt, sondern
auch Bufferoverflows bei Prozeduraufrufen unmöglich macht. Durch die
Implementierung des Modulimports kommen Kapselung und typisierte
Bezeichner hinzu, wobei dieser bisher aber erst zu ca. 70 %
implementiert ist.

Andere Punkte hierzu habe ich bisher vernachlässigt, vor allem weil es
bei Mikrocontrolleraufbauten keine definierte Fehlermethode gibt, aber
auch weil ich seit über 30 Jahren programmiere und mir diese Fehler
dementsprechend nicht mehr passieren. Im Zusammenhang mit dem Debugger
muss ich das nocheinmal überdenken.

Ich werde mir überlegen, ob ich Tests auf überlaufende Arrayindizes,
Divisionen durch 0, Stackkollision und ev. noch andere Fehler
realisiere. Jetzt wo auf deine Anregung hin der erste Schritt getan ist,
wäre das vermutlich nur konsequent. Praktisch bedeutet dies nur, dass
außer Debug-An und -Aus zusätzliche Stufen in den Compiler eingebaut
werden müssen.

Grüße, Guido

Hallo mal wieder,

ich habe jetzt optionale Tests im Compiler implementiert. Diese werden
mit der Option -db2 bzw. -db3 aktiviert, wobei letztere zusätzlich
den Monitor anhängt, der natürlich die zusätzlichen Traps bedient.
Ohne Monitor muss sich die Anwendung um diese Traps kümmern, genauere
Angaben finden sich in der Doku. Option -db1 funktioniert wie bisher.

Die Tests beinhalten:
- Stack-Kollision
- Arrayindizes
- Überlauf u.ä. bei arithmetischen Operationen

Habe ich etwas vergessen?

Zusätzlich habe ich das Layout des Debuggers überarbeitet, der sollte
jetzt auch auf das Display eines Netbooks passen. Bei Unterbrechungen
wird jetzt auch das PSW übertragen und aufbereitet dargestellt.

Die Windowsversion des Debuggers hat wohl noch Timingprobleme mit
der ser. Schnittstelle, unter Wine läuft sie bei mir nicht. Das werde
ich mal noch optimieren.

Viel Spaß, Guido

Leider ein ziemlich blöder Fehler im Monitor, gut, dass ihn
noch niemand bemerkt hat ;-).

Es war sicher nicht der letzte, aber wenn jemand ernsthaft testen
möchte, bitte den angehängten Monitor verwenden.

Wer den Fehler erkennt, hat sehr viel von der Arbeitsweise des
Compilers verstanden.

Viel Spaß, Guido

TheMason schrieb:
> Auch hier : Auf einem Mega8 ?!?! Zeig mal ...
>
> Von einem 32-Bitter zu reden ist dann kein Problem. Ich meine Linux auf
> einem ARM/SH2/AVR32 usw ist keine Kunst. Das man bei nem
> Ruby/Python/Linux/C#/.net System meist eh noch Megabyteweise RAM braucht
> um überhaupt gescheit arbeiten zu können ist dann auch normaler
> Verschwendungswahnsinn. Also selbe Welt wie aufm PC, oder ?

Darauf läuft es eh hinaus. Wie ich schon schrieb: Am Ende wird es nur 
noch ARMs geben! Vor allem wenn man jetzt eine Entscheidung für eine 
Softwareumgebung sucht und diese dann realisiert, werden locker 3 Jahre 
vergehen. Bei einem Profi-Programmierer - ich fange erst gar nicht an 
;-)


>
> Aber bleiben wir doch mal bei kleineren Controllern (8/16-Bit). Wo gibts
> Verwendung für .net/Python/PHP usw auf so kleinen Kisten ? Wie gesagt :
> nen ARM mit 128MB RAM ist keine Kunst. Da kann ich prinzipiell auch auf
> nem PC bleiben, und mal eben nen Megabyte allokieren um mir 5 Messwerte
> zu speichern ... So wie es unter "echten" (Ironie) Sprachen wie eben
> PHP, C#, Pyrhon üblich ist.

Ich bin dafür kein Experte im Sinne einer Marktübersicht. Aber zumindest 
gibts z.B. sogar Java auf FPGAs.


> Und solche Leute wundern sich dann das sie mit C nicht klarkommen ...
> warum nur ?

Mir gefällt die Art und Weise von C nicht. Für meine kleinen Projekte 
komme ich mit C klar.


Was den Oberon-Compiler angeht:
Leider ist der C16x ein absoluter Exot. Wenn Guido das für ARM 
rausbrächte, wäre die Resonsanz sicherlich erheblich größer.

Tja Abdul,

da hast du vermutlich Recht. Ich will eine Portierung nicht
ausschließen und habe mir die Cortex M3 diesbezüglich auch
schon angesehen, im Moment kann ich aber nur schreiben, warum
ich das am Anfang nicht getan habe:

1.) Ich habe den Compiler für die C166-Famile geschrieben, weil
ich beim Datenblattstudium erkannt habe, dass diese hierfür ideal
geeignet sind. Ursprünglich wollte ich diese als besseren Ersatz für
die MCS51er verwenden und auch in Assembler programmieren. Ihre
Architektur ist aber optimal für einen Compiler geeignet und das hat
mich überzeugt. Die ARMs sind dagegen viel schlechter für meinen
Compiler geeignet. Ein Kontextswitch in vier Takten bei gleichzeitigem
Verzicht auf die träge Stack-Machine ist auch mit einen M3 nicht
realisierbar.

2.) Es gibt keinen richtigen freien Assembler für die ARMs. Ich kann
aber einen Single-Pass-Compiler nicht mit einem Singel-Pass-Assembler
kombinieren. Also müsste ich die Codeerzeugung in den Compiler mit
übernehmen. Das ist machbar, entsprechende Implementierungshinweise
und -Beispiele sind von N. Wirth mitveröffentlicht. Es beraubt mich
aber des einfachen "Inlineassemblers" und darauf möchte ich nicht
verzichten.

3.) Es gibt mit Astrobe einen Oberoncompiler für einige ARMs und
Chris Burrows ist mit diesem viel weiter als ich. Er unterstützt
Oberon praktisch vollständig mit Pointern und OOP. Astrobe soll
bis zum 1. Quartal nächsten Jahres auf den M3 fertig portiert sein
und, ich mache ja ungern Werbung für die Konkurrenz, die PE ist vom
Preis her auch für Hobbyisten tragbar (vergleichbar mit Bascom).


Ich muss ev. nochmal klarstellen, dass mein Compiler alle C166er
unterstützen soll. Mangels Hardware kann ich nur nicht alle 50
Typen testen. Es ist also garnicht so exotisch, gerade in der
Industrie werden diese Kontroller in großen Mengen eingesetzt.

Gruß, Guido

Naja, frag mal hier rum wieviele Leute den benutzen?! Stückzahlen und 
Design-Wins sind nicht das gleiche.
Rein technisch sehe ich den C16x überlegen gegenüber ARM. Aber das ist 
im Markt leider nicht entscheidend. Oder vielleicht auch gottseidank 
so?? Sonst hätten immer nur die Platzhirsche das sagen und die smarten 
Jungbullen kämen nie zum Zuge.

Ich hatte mal einen i2c-Bitbanger für 8051 in C für Keil-C geschrieben. 
Bekanntermaßen ist das ein sehr guter Compiler, der das letzte aus der 
Architektur rausholt (Ein Punkt der viel zu wenig beachtet wird!). Wie 
ich so bin, hat mein Code endlos viele Unterprogramme aufgerufen. Fast 
wie Forth ;-)
Ein Kunde wollte den Code dann auf einem C166 laufenlassen. Also schrieb 
ich das Ding einfach um. War nicht viel Arbeit, denn:
1. Memorymodell-Bezeichner entfernt
2. Die 3 Routinen für das Port-Bit-Handling geändert, da der C166 
Portbits anders anspricht.
Dann einfach mit Keil-C166 kompiliert. Hat natürlich keinen Fehler 
erzeugt, aber es ging trotzdem nicht!
Das Ende vom Lied: Der C166 hat den praktisch gleichen Code um den 
Faktor 8000 schneller ausgeführt. Was den externen i2c-Bausteinen nicht 
schmeckte. Daraufhin kam dann eine Delay-Routine mit rein.
Dabei lief der C166 noch gar nicht mit voller Geschwindigkeit. Vergleich 
mit 12MHz 8051.

Das als Anekdote.

Abdul K. schrieb:
> Naja, frag mal hier rum wieviele Leute den benutzen?! Stückzahlen und
> Design-Wins sind nicht das gleiche.

Das war mir schon klar, es gab ja aber bisher auch keine freie
Entwicklungsumgebung dafür. Mit seiner Portzahl und seinen 
Schnittstellen
ist er auch ganz sicher keine Konkurrenz zu den AVR. Nach meinem Gefühl
ist er hier im Forum vor allem für die Heimautomatisierer und Robotiker
interessant.

Ich bin mal gespannt, ob ich noch ein paar Mitstreiter für dieses 
Projekt
finde! Immerhin gibt es schon Feedback und Toms Idee mit dem Debugger 
hat
mir schon sehr geholfen. Natürlich hätte ich so was aus eigenem Antrieb
nicht in Erwägung gezogen, es bedeutet ja Arbeit. Die war aber doch sehr
übersichtlich und mittlerweile möchte ich auf den Debugger nicht mehr
verzichten. Auch seine Folgeidee werde ich wohl bei Gelegenheit noch
umsetzen, gefällt mir ;-).

Abdul, lachendes und weinendes Auge wechseln sich ab. Das lachende
deshalb, weil ich im Moment bei ebay noch Hardware zum Einstellungspreis
erwerben kann.

Gruß, Guido

Edit: Faktor 8000 ist nicht realistisch, so um 20, bei neueren Chips
nochmal das 10- Fache ist erreichbar.

Der Faktor 8000 wurde schon real gemessen. Das liegt sicherlich an der 
doch recht umständlichen Verarbeitung von Unterprogrammen beim 8051. Da 
läuft man mit Makros besser.

@guido

Ich weiß nicht ob ich neben der Diskussion um die Sinnhaftigkeit dieser 
oder jenen Programmiersprache schon geschrieben hab das ich das Projekt 
an sich echt gut finde. Vor allem das du einen Debugger "mitlieferst".
Mein Lob dafür schonmal.

Da ich die Idee einer Interpreter/Systemsprache habe interessiert mich 
dein Compiler und dein Debugger von der Umsetzung her.
Da ich selbst mit Pascal nicht mehr soviel mache (zumeist Delphi für den 
PC) bzw keinen C16x Prozessor nutze habe ich leider nicht so die 
Verwendung dafür. Aber bei dem AVR-Basic von Uwe Berger hab ich auch 
keine direkte Verwendung dafür gehabt, aber dennoch "mitgemischt" :-). 
Allein schon um mal zu sehen was man noch da rausholen kann, und weil 
mich Programmiersprachen und deren Interpretation bzw Compilation für 
"kleine" Controller schon interessieren.
Von daher würde mich deine Umsetzung schon interessieren, und dadurch 
das du auch einen Debugger dabei hast erst recht.

Weiter so !

Jo Tom,

habe ich schon. Der CS-LM ist angekommen, vielen Dank. Werde ich
gelegentlich testen. Erstmal habe ich mir den CS8900A vorgeknöpft
;-).

Gruß und Dank, Guido

Hallo,

heute mal was anderes, ein kleiner Webserver in OberonC16x.

Das von tom gesponsorte DevBoard beinhaltet auch einen
CS8900A-Chip mit allem Zubehör, so dass es nahelag, hierfür
eine kleine Ethernetanwendung zu entwickeln.

Dieser Webserver antwortet auf ARP-Requests (auf seine MAC),
auf ICMP-Echo-Requests (vulgo ping) und liefert eine kleine
Webseite aus, die in den Codespeicher eingefügt ist. Seine
Codelänge liegt ohne Debugging-Hilfen bei ca. 5 kBytes,
inklusive der minimalen Webseite.

Das Ergebnis ist sicher nicht optimal, ich habe es mit der
Wikipedia einerseits und tcpdump andererseits auf die Schnelle
zusammengebastelt. Insbesondere TCP ist nur rudimentär
implementiert, es wird nur eine Verbindung akzeptiert, weitere
Anforderungen werden per Reset abgewiesen. Auch sollten einige
weitere Timeout- und Sicherheitsüberprüfungen eingefügt werden.

Der Interrupt für den CS8900 gefällt mir auch nicht, für eine
reale Anwendung würde ich lieber darauf verzichten und per
Polling zugreifen. Die vernünftige Wahl des Pollingintervalls
müsste aber noch ermittelt werden.

Für mich ist diese Implentierung als Testplattform in Ordnung,
meine Interessen tendieren mehr in Richtung CAN-Ethernet-Bridge
mittels UDP und der Nutzung von SNTP.


Viel Spaß, Guido

Hallo,

eine Fehlerbereinigung, da mir bei der Ethernetanwendung vorgeführt
wurde, dass z.B. arithmetische Operationen mit Arrayelementen nicht
funktionieren. Die Workarounds sind in der obigen Anwendung zu finden
aber hoffentlich jetzt nicht mehr nötig. Wie immer sind Executables
für Windows und Linux im trunk zu finden.

Weiterhin habe ich die Inline-Prozeduren INC(x,y), DEC(x,y), wobei
der 2. Parameter entfallen kann, sowie SWAP(x) implementiert. Diese
habe ich auch bei Enet.mod schmerzlich vermisst. Natürlich können
solche Sachen leicht als Oberon-Prozeduren realisiert werden, da
hierfür oft aber nur eine einzelne Assembleranweisung nötig ist,
erscheint mir der zusätzlich Kontextswitch als übermäßiger Overhead.
Das ist im Compiler besser aufgehoben.

Wenn ich in einem anderem Thread hier lese, dass manche Compiler
schon für einen Bootloader den Code um einen Faktor 5 gegenüber
Assembler aufblähen, kann ich nur müde grinsen. Wenn ich das nicht
besser könnte, würde ich weiter in Assembler programmieren.

Viel Spaß, Guido

Hallo,

weiter gehts mit Inline-Prozeduren. Heute gibt es neu
PeekW und PokeW zum Speicherzugriff in Words. Da diesen
u.a. die Speicherseite mit übergeben wird, kann damit auf
den gesamten Speicherbereich des Controllers zugegriffen
werden. Das Ziel ist, dass man Assembler nur noch in
Ausnahmefällen braucht. Momentan fehlt mir hierzu noch
eine Idee, wie man LUTs in Oberon realisieren könnte.

Außerdem habe ich die Relation IN in Form eines
Bitmustervergleichs implementiert. Zwar werde ich den Typ
SET wohl nicht implementieren, weil ich hierfür nie eine
sinnvolle Verwendung gesehen habe, aber diese Relation ist
auch einfach für Ganzzahlen sehr praktisch, zumal sie vom
Compiler sehr effektiv umgesetzt werden kann (3 Assembler-
Anweisungen). Die Auswahlmenge ist auf einem 16-Bit-System
natürlich arg begrenzt (0 .. 15), da hat man mit 32 Bit
deutlich mehr Nutzen, aber um z.B. mehrere Zustände einer
kleinen FSM zusammenzufassen reicht es allemal und viele
verknüpfte Bedingungen mit OR werden damit unnötig. Diese
erzeugen nunmal sehr viel Code.

Da ich mit Kate unter KDE programmiere, habe ich mir
natürlich auch eine entsprechende Sprachdefinitionsdatei
hierfür erstellt (von Pascal.xml geklaut und entsprechend
angepasst). Diese hänge ich auch mal an, zukünftig packe ich
sie einfach in das trunk mit rein. Diese Datei gehört nach
~/.kde/share/apps/katepart/syntax/ und bietet dann
Syntaxhighlighting und Codefolding. Unter Windowws habe ich
das vor längerer Zeit auch mal probiert und für den Crimson-
Editor realisiert. Dieser wird aber wohl nicht mehr gepflegt.:-(
Falls da jemand Bedarf hat, würde ich mir das nochmal ansehen.

Viel Spaß, Guido

Hallo,

für das Netbook ist Kate mit KDE sicher zu schwergewichtig. Auf der
Suche nach Alternativen habe ich mal Geany probiert. Mit der
angehängten, von der Pascal-Definition übernommenen und nur leicht 
angepassten Konfiguration, die nach "homedir"./config/geany/filedefs 
gehört, wird darunter Syntaxhighlighting und Codefolding unterstützt.

Ich habe den Scanner so erweitert, dass er Fehlermeldungen imho exakt so 
wie fpc auf der Konsole ausgibt, trotzdem interpretiert Geany diese
nicht richtig. Wenn jemand eine Lösung hierfür hat, immer her damit.

Mit F8 wird damit die Compilierung gestartet, mit F9 der Assembler,
sofern beide installiert sind. Das geht natürlich auch über die
zugehörigen Quickbuttons.

Schon schön zu sehen, wie sich Geany entwickelt hat. Allerdings
unterscheidet es nicht zwischen Groß- und Kleinschreibung, der Compiler
schon. Daher nicht wundern, wenn Schlüsselwörter trotz Typo
hervorgehoben werden. Die Alternativen sind halt rar, Emacs wäre
natürlich eine Möglichkeit, aber ich habe keine Lust auch noch einen 
Lisp-Kurs zu absolvieren.

Keine neuen Quellen, die gibts wieder, wenn es sich lohnt.

Viel Spaß, Guido

Und dafür musst du einen Zombie über die Sprache Oberon aufwecken?

Hallo igor,

schaue ins User-Manual:

>The number of chip select signals is selected via PORT0 during reset. The 
>selected value
>can be read from bit-field CSSEL in register RP0H (read only) in order to
>check the configuration during run time.

Da geht also mit Software nichts.

Hi Guido,

Danke für die kurze Hilfe an den Fragenden...
Der Support+Doku von ST was diese Derivate betrifft ist - na ja, nicht 
berauschend.

Deswegen ist es schön, wenn jemand weiterhilft.
Hätte Kollege User prx auch machen können ohne sich einen Zacken aus der 
Krone zu brechen IMHO.

Ansonsten viel Spass und Erfolg beim Weiterentwickeln der Toolchain !

Ist übrigens die einzige freie=kostenlose 
Hochsprachencompiler-linker-debugger Toolchain für C16x Derivate.

Und dafür gehört Guido ein dickes Dankeschön vs. Zombie ;o). !

Gruss, tom.

Danke für die Blumen Tom,

ja, es geht weiter aber momentan in kleinen Schritten. Ich probiere
gerade eine nutzbare Lösung mit Flashspeicher hinzubekommen, möglichst
mit Debugger. Dann fehlt noch der Modulimport, den muss ich auf den
Herbst verschieben.

Klar kann ich helfen und tue das gerne, ein bisschen was verstehe ich
mittlerweile ja schon von den Controllern. ;-) Bei der Vielzahl an
Derivaten ist der Überblick natürlich nicht ganz einfach, aber da ich
mir auch gerade einen kleinen Vorrat an F276ern zugelegt habe, kenne
ich auch die etwas.

Warum Leute ohne Sachverstand meinen Forumspolizei spielen zu müssen,
erschließt sich mir allerdings auch nicht ganz.

Grüße, Guido

Hallo Tom,

Haltepunkte im Flash hatte ich garnicht eingeplant, aber so wie dir du
das vorstellst könnte es sogar gehen. Bei den St10F276 ist die erste
Flashseite sehr fein aufgeteilt, zu Anfang in 8-k-Blöcken. Zum Flashen
könnte man in den 2. Block ausweichen oder in das XRAM.

Im Moment spiele ich aber mit einer selbstgekochten Platine mit C167
und AM29F040, damit hätte ich in diese Richtung keine Chance. Mir hat
aber der Debugger schon gefehlt und alles außer Haltepunkten müsste
eigentlich auch im Flash machbar sein. Ich müsste nur die Flashfunktion
in den Debugger integrieren oder diesen ohne BSL betreiben können. Da
muss ich mir mal genauere Gedanken machen, zusammenfrickeln möchte ich
das nicht.

Jaa, sehr langes Wochenende! Aber manchmal möchte ich den Compiler ja
auch nur einfach für Anwendungen nutzen. :-)

Grüße, Guido

asdf schrieb:
> Hey,
> cooles Projekt!
> Hast du vor den Code öffentlich zu machen?
> Mich als (Informatik)Student würde es sehr interessieren, wie das
> Projekt aufgezogen ist.

Danke,

der Code ist doch offen. Du musst nur etwas hochscrollen und das letzte
angehängte "trunk.tgz" auspacken. Ich werde demnächst mal eine neue
Version anhängen.

Für dich als Informatikstudent ist das sicher ein gutes Beispiel dafür,
wie man es nicht machen soll. :-) Gewachsener Code halt.

Moins Guido,

Nun, nur download in 29F040 flashes und ein guter alter C167 ;o).
Die Flash Programmier-Routinen sollten im RAM laufen, read-while-write 
geht mit den 29F0x0 chips nicht.
Falls Du den monitor per BSL ins interne RAM lädst, könnte man den um 
flash-spezifische programmierroutinen erweitern, oder die dynamisch 
nachladen (löschen, schreiben - je nachdem was gerade gebraucht wird).
Falls Du bezüglich der 29f0x0 programmierroutinen hilfe brauchst - 
einfach bei mir melden, ok. ?

Gruss, Tom.

Tomas Kuckenburg schrieb:
> Nun, nur download in 29F040 flashes und ein guter alter C167 ;o).

Tja Tom,

nicht immer braucht man einen Boliden, der mit 40 MHz rennt. ;-)

Danke für das Angebotr aber der Flasher läuft schon, trotz
gekreuzter Datenleitungen zur Layoutvereinfachung. Und ja, der
muss im XRAM laufen. Damit kann ich ihn nicht aus dem Monitor
nutzen, da er mir sonst die Variablen zertöppert. :-( Soweit ich
das überblicke gingen solche Haltepunkte nur mit den "großen" ST10F,
bei denen das Programm in einem Flasblock läuft und daraus den 2.
Block ändern kann.

Ich überlege mir eine andere Möglichkeit: Im Compiler wird die
Inlineprozedur "Breakpoint" eingeführt, die bei entsprechendem
Debuglevel eine illegale Instruktion in den Code einfügt. Durch diese
wird wieder der Monitor aufgerufen, der nach einer Stackmanipulation
das Programm weiterlaufen lassen kann. Singlestepping geht so zwar
nicht, es ist aber besser als nichts.

Erst muss ich aber den Debugger auf Flash umrüsten, da sind schon
einige Änderungen nötig. Da das Flashen aber schön schnell geht, macht
es schon Spaß damit.

Grüße, Guido

Moins Guido,

Guido B. schrieb:
> Danke für das Angebotr aber der Flasher läuft schon, trotz
> gekreuzter Datenleitungen zur Layoutvereinfachung. Und ja, der
> muss im XRAM laufen. Damit kann ich ihn nicht aus dem Monitor
> nutzen, da er mir sonst die Variablen zertöppert. :-(
Ja, da wird es mit dem verfügbaren on-chip RAM schnell knapp. Ist leider 
so und die sector-Granularität bei den 29f0x0 sowie die erase/write 
times sind etwaaaaaas groß ggf. Kann man nix machen ausser ggf. durch 
RAM ersetzen auf der HW. Falls Du mal einen sockel für plcc-32 brauchst, 
so etwas habe ich noch irgendwo rumzuliegen. Leider gab (gibt ?) es kein 
RAM in dem gleichen housing, nur teure steck-adapter mit den 
begleitenden evtl. kontaktierproblemen.

> Soweit ich
> das überblicke gingen solche Haltepunkte nur mit den "großen" ST10F,
> bei denen das Programm in einem Flasblock läuft und daraus den 2.
> Block ändern kann.
Ja, read-while-write war/ist ein klassisches flash-problem. kannst das 
nicht von der gleichen speicherbank (CSx) ausführen...

> Ich überlege mir eine andere Möglichkeit: Im Compiler wird die
> Inlineprozedur "Breakpoint" eingeführt, die bei entsprechendem
> Debuglevel eine illegale Instruktion in den Code einfügt. Durch diese
> wird wieder der Monitor aufgerufen, der nach einer Stackmanipulation
> das Programm weiterlaufen lassen kann. Singlestepping geht so zwar
> nicht, es ist aber besser als nichts.
jepp, ein "statischer" Brechpunkt, definiert zur compile-zeit. Auf jeden 
Fall besser als gar nichts und ein nützliches Feature !

Hast Du in Deiner IDE die Möglichkeit eingebaut, eine Applikation 
zwischen debug (mit moni) und relase-config einfach umzuschalten ? Ist 
ja doch einiges an Unterschied in Lokierung und ISR-table(s) nötig.

Mach weiter so + Grüsse,

tom ;o) !

Hallo Tom,


> Ja, da wird es mit dem verfügbaren on-chip RAM schnell knapp. Ist leider
> so und die sector-Granularität bei den 29f0x0 sowie die erase/write
> times sind etwaaaaaas groß ggf. Kann man nix machen ausser ggf. durch
> RAM ersetzen auf der HW. Falls Du mal einen sockel für plcc-32 brauchst,
> so etwas habe ich noch irgendwo rumzuliegen. Leider gab (gibt ?) es kein
> RAM in dem gleichen housing, nur teure steck-adapter mit den
> begleitenden evtl. kontaktierproblemen.

Ich war auch verblüfft, dass dies völlig unproblematisch ist. Die
Write-Time für ein Byte liegt mit ca. 7 µs weit unter der
Übertragungszeit via RS232 und auch die Erase-Time pro Sektor ist mit
1 s kaum bemerkbar. Da bringt die Umstellung von Intel-Hex auf binär
viel mehr. Die Geschwindigleit hiermit hat den Spaß sofort erhöht und
die spezifizierte Zyklenzahl von 10^6 bei den AM29F040 bremst auch 
nicht.


> Ja, read-while-write war/ist ein klassisches flash-problem. kannst das
> nicht von der gleichen speicherbank (CSx) ausführen...
>

Die großen ST10Fxx bieten dafür die Möglichkeit mit ihren zwei
Flash-Blöcken, das wird mir aber zu controllerspezifisch.


> jepp, ein "statischer" Brechpunkt, definiert zur compile-zeit. Auf jeden
> Fall besser als gar nichts und ein nützliches Feature !
>
> Hast Du in Deiner IDE die Möglichkeit eingebaut, eine Applikation
> zwischen debug (mit moni) und relase-config einfach umzuschalten ? Ist
> ja doch einiges an Unterschied in Lokierung und ISR-table(s) nötig.
>

Jo, ich muss zum Debuggen nur dem Compiler die Option "-db1" mitgeben,
dann kümmert er sich um den Rest.

> Mach weiter so + Grüsse,
>
> tom ;o) !

Mach ich, im Moment läuft aber nicht mal mehr der Monitor. Keine Ahnung,
was schiefläuft, vermutlich patzt der Compiler, da ich ihn natürlich
wieder verändert habe. Wenn ich wieder etwas mehr Zeit habe, werde ich
das genauer untersuchen, auf die Schnelle ist mir nix aufgefallen. :-(

Grüße, Guido

Jo Tom,

habe ich, aber jetzt schreibe ich alles auf Binärübertragung um.
War halt angenehm, dass die Adressen gleich mitübertragen werden
und das Parsen war unproblematisch da ich das ja schon in Oberon
durchführen konnte.

Ich integriere gerade die Funktion des Flashers in den Debugger,
so dass dieser für beides benutzt werden kann. Hoffentlich
übersehe ich nichts, so dass dies auch für die Typen mit internem
Flash funktioniert. Eigentlich sollte nur der Flasher angepasst
werden müssen und der wird ja, als 2. Stufe des BSL, separat
geladen. Die Flexibilität des Memtools werde ich aber sicher nicht
erreichen.

Nebenbei noch ein paar Erweiterungen und Optimierungen im Compiler,
die machen richtig Spaß. :-) Leider momentan halt zu wenig Zeit,
aber das wird auch wieder besser werden.

Grüße, Guido

Hallo,

da ich in der nächsten Zeit wohl nicht viel am Compiler
weiterentwickeln kann, hier mal noch der letzte Stand. Wie immer
sind ausführbare Dateien im tgz unter bin/ zu finden.

Ich habe noch die Inlineprozeduren Intsen und Intsdis implementiert,
so dass man jetzt wohl ohne Inlineassembler auskommen kann. Die
Schreibweise für alle Inlineprozeduren habe ich vereinheitlicht,
s. Doku. Auch der Breakpoint für Module im Flash ist implementiert.
Die Anfangsadresse der Modulinitialisierung wird als letzter Vektor
(0x1FC) übergeben und kann damit vom Debugger an fester Flashadresse
ausgelesen werden.

Den Stackstart habe ich auf 0xFCE0 umgelegt, damit die PEC-Pointer
verfügbar bleiben. Zusätzlich habe ich einen Codelängenzähler
implementiert, mit dessen Hilfe der Compiler weiß, wielang das
Modul wird. Mittelfristig möchte ich damit die Segmentgrenze für
den Code knacken, Genaueres steht in der Doku im Abschnitt über
den Programmspeicher.

Viel Spaß, Guido

Mal was anderes,

die Dokumentation als EBook. Lässt sich auch auf kleinen Readern
prima lesen und gefällt mir gut. :-)

Zur Erstellung habe ich die LaTeX-Quellen mit latex4ht in HTML
umgewandelt und dieses dann in Calibre gefüttert. Toll, wie
einfach das geht.

Viel Spaß, Guido

Hallo,

ganz konnte ich die Finger doch nicht weglassen. Eigentlich
wollte ich nur die Inlineprozedur Adr implementieren, die
die Adresse einer globalen Variablen im RAM liefert. Damit
kann man einfach Arrays als Puffer für PEC-Transfers verwenden.
Dies ist soweit getan.

Dabei sind mir aber noch eine Menge Fehler bei der Behandlung
von Arrays und deren Indizes aufgefallen, die ich natürlich
soweit korrigiert habe. Hoffentlich gibt es jetzt mit globalen
Arrays keine Probleme mehr, für "lange" Prozeduren würde ich
lokale Arrays eh noch als nicht implementiert betrachten.

Zusätzlich habe ich den Scanner mal aufgeräumt, Rudimente meiner
ersten Ideen zum Modulimport beseitigt. Der erfolgt dann
irgendwann doch konform zu N.Wirth.

Viel Spaß, Guido

P.S.: Executables sind wie immer im trunk.tgz.

Hi Tom,

leider gibt es garnichts neues, obwohl ich nicht im Winterschlaf
bin. Ich bin momentan durch anderes so beschäftigt, dass ich nicht
dazukomme, mich um den Compiler zu kümmern. Ideen habe ich noch
genug und es wird ca. Mitte des Jahres sicher wieder weitergehen.

Zum Kitcon-164 noch: Das benutze ich auch, nett ist die Echtzeituhr
im C164, die im C167 nicht vorhanden ist. Mein Kitcon-164 ist daher
zurzeit mit einem TCXO (12,8 MHz) ausgerüstet.

Grüße, Guido

Hallo,

nach längerer Zeit mal wieder eine Erweiterung.

Ich habe einen ersten Versuch zur Implementierung von Funktions-
prozeduren unternommen. Diese ersetzen die von Pascal gewohnten
functions und sehen in Oberon-Syntax z.B. so aus (wobei ich Odd
gelegentlich als Inlineprozedur implemetieren werde):

1

    PROCEDURE* Odd(v: INTEGER): BOOLEAN;

2

    BEGIN 

3

      IF v MOD 2 = 1 THEN RETURN TRUE

4

      ELSE RETURN FALSE; END;

5

    END Odd;

Diese habe ich schon lange vermisst, weil der Notbehelf mit
variablen Parametern nicht gerade zur Lesbarkeit des Programms
beiträgt. So wird das schon klarer:

1

IF Odd(i) THEN Writeln("Ungerade")

2

  ELSE Writeln("Gerade"); END;

Das Problem war, dass ich keine Idee hatte, wo das Ergebnis
abgelegt werden soll. Die Lösung ist simpel: der Compiler legt
sich eine globale Variable namens "_FRESULT" an und speichert
den mit RETURN übergebenen Wert dort. Das wird zwar später noch
viel Spaß beim Modulimport bringen, hat aber den großen Vorteil,
dass alle Zugriffe auf dieses Ergebnis automatisch der strengen
Typenüberprüfung unterliegen, weil es ja eine ganz normale Variable
darstellt, deren Typ auf die jeweilige Prozedur gesetzt wird.

Ausführbare Dateien sind wie immer im bin-Ordner des tgz, erweiterte
Dokumentation folgt demnächst.

Viel Spaß, Guido

P.S.: Ich bin gerade auch an einem Disassembler dran, den ich in den
Debugger integrieren möchte. Auch dazu demnächst mehr.

Hallo Tom,

danke für das Feedback.

Ich bin mir nicht sicher, ob an der ETH diesbezüglich noch viel läuft,
die meisten Webseiten sind seit vielen Jahren im Umbau, also tot.
Selbst wenn, die Jungs da betreiben ja ein Betriebssystem unter Oberon
und sind an meinem kleinen Compiler sicher nicht interessiert. Ich
hätte schon auf den einen oder anderen Mitstreiter gehofft. aber die
Kombination ist wohl doch zu exotisch. Wobei ich die Vorbehalte
gegenüber Oberon nicht verstehe, da es ja doch noch eine Menge
Pascal-Programmierer gibt. Die Unterschiede sind gering und die
Vorteile von Oberon gegenüber Pascal offensichtlich.

Über Astrobe habe ich ja schon weiter oben geschrieben. Ich habe vor
knapp 3 Jahren ein Developementboard mit einem NXP LPC2xxx inklusive
Astrobe-Lizenz gekauft. Der Compiler ist ganz was anderes als meiner,
das "kleiner" in der Threadüberschrift ist daher kein Understatemant.
Astrobe ist natürlich 32-bittig und unterstützt das vollständige
Oberon inklusive OOP und z.B. 32-Bit-real-Typen. Gleichzeitig sind
gerade die NXP-Controller sehr billig. Die Erweiterung auf Cortex M3
ergibt natürlich weitere Kundenkreise.

Mit Astrobe habe ich aber selbst garnichts probiert, es hat mich nur
darin bestärkt meinen eigenen Compiler voranzutreiben. Die Probleme
damit waren, wobei ich mich auf die für Hobbyisten bezahlbare
Personal-Edition beziehe:

- Windows only
- kein Kommandozeilencompiler, also ZwangsIDE
- kein Assembleroutput, keine Kontrolle des erzeugten Codes
- Folgekosten, da der Kaufpreis eine 1-Jahres-Lizenz bedeutet

Ein Oberon-Compiler für ARM7 ist nutzlos, da kann man genausogut
den GCC verwenden. Für die Cortex-M3 sieht die Sache schon anders
aus. Es wäre sicher möglich meinen Compiler darauf zu portieren.
Ich glaube aber nicht, dass ich das leisten werde. Mir reichen die
C16x, sofern ich die Nachfolger einbeziehe. Wenn aber jemand anders
dies in Angriff nehmen möchte bin ich gerne bereit dabei zu helfen.

Meine Roadmap sieht folgendermaßen aus: Zunächst werde ich den Typ
INTEGER in WORD umbenennen, damit INTEGER für signed 16-Bit-Typen
verfügbar wird. Wenn das läuft gibt es eine neue Dokumentation.
Dann möchte ich die SFR-Deklaration in den Compiler übernehmen, Dies
wird für die Controller von Infineon einfach, da ich die entsprechenden
Definitionen von DAVE übernehmen kann. Für die STM-Controler wird das
schwieriger, von STM gibt es keinerlei Support. Natürlich könnte man die
Hedaerfiles von Keil benutzen, das wäre aber Klauen. Also werde ich 
diese
für die meinerseits vorhandenen Typen händisch erstellen müssen.

Später soll dann natürlich die Unterstützung für INTEGER realisiert
werden,die manches Programmierproblem vereinfachen kann.

Grüße, Guido

Falls jemand mitspielen, d.h. probieren, möchte: Hier

Beitrag "Phytec KC167 board, suche Handbuch und verschenke 4 Stück"

verschenkt der Hans gut geeignete, gebrauchte Dev-Boards.

Für die könnte ich eine komplette Startumgebung (vorzugsweise
unter Linux) mit Schnellstartanleitung zusammenstellen.

Hallo,

die ersten Schritte von den Natürlichen zu den Ganzen Zahlen ist
vollbracht. Ist für so einen jungen Burschen ja nicht ganz einfach.;-)

Jetzt gibt es also INTEGER für vorzeichenbehaftete und WORD für
vorzeichenlose 16-Bit-Zahlen. Wie für pascaloide Sprachen üblich
müssen Werte der Typen über Trunc bzw. Abs ineinander umgewandelt
werden, die als Inline-Funktionsprozeduren hinzugekommen sind wie
auch Odd. Die einfachen Optimierungen des Compilers, wie z.B. Schieben
statt Multiplizieren oder Dividieren, greifen für INTEGER natürlich
nicht, so dass der Overhead damit etwas zunimmt. Kann ich mit leben.

Zusätzlich habe ich die verknüpften Bedingungen umstrukturiert, weil mir
Odd einige Fehler darin aufgewiesen hat. Irgendwie waren die logischen
Verknüpfungen verloren gegangen, sind jetzt wieder im Spiel.

Have Fun, Guido

P.S.: Executables sind wie immer im trunk.tgz.

Wieder einen Schritt weiter,

ich habe die Registerdefinitionen in den Compiler übernommem,
so dass der Assembler kein Includefile mehr benötigt. Der bekommt
einfach die Registeradressen übermittelt und ist, Dank der Arbeit
Alfred Arnolds, damit zufrieden. Damit habe ich Alles in eigener Hand,
was vor allem für die moderneren Derivate interessant ist.
Eine Deklaration der SFR ist dementsprechend nicht mehr nötig und
auch nicht mehr möglich.

Als Standard sind die Register des C167CR in Form einer Unit in das
Steuerprogramm obcc eingebunden. Diese Definition kann durch den
Kommandozeilenparameter -ir überschrieben werden, ein paar Beispiele für
andere Controller liegen den Sourcen bei. Das Vorgehen hierzu ist in der
Dokumentation beschrieben.

Als nächstes möchte ich Pointer implementieren, dank Abdul ist klar,
wie NIL zu handhaben ist, der Heap ergibt sich auch fast von selbst.

Viel Spaß, Guido

Hallo,

die Pointer sind implementiert. Ich bin über deren Sinn
noch etwas unschlüssig aber die Möglichkeit verkettete
Listen anzulegen ist im Vergleich zu Assembler schon nett.

Die Pointer werden vom Laufzeitsystem nicht initialisiert,
das muss der Nutzer (also ich) selbst übernehmen. Es lohnt
aber, da ein mit NIL initialiserter Pointer beim Zugriff
einen BTRAP-Interrupt auslöst, ein Fehler sich also mit einer
zugehörigen ISR leicht abfangen lässt. Ich hänge mal mein
Testmodul (ptest.txt) zur Demonstration an.

Es gibt keine Garbage-Collection, schon die Freigabe eines
Pointerelementes mittels dispose würde nach meinem Geschmack
zuviel Overhead und Ressourcenbedarf produzieren. Die Verwaltung
des Heaps obliegt also dem Nutzer, im Testmodul ist auch diese
demonstriert (sein Output ist als Kommentar daran angehängt).

Wie im Testmodul zu sehen ist, können für ISRs jetzt auch die
Vektornamen anstelle ihrer Nummern angegeben werden. Da der
Compiler sie eh kennt, war es mir zu mühselig immer die Nummern
nachzuschlagen. Dabei ist mir aufgefallen, dass noch immer die
Vektoren des C167CR fest im Generator vorgegeben sind. als nächsten
Schritt werde ich diese an die Registerdefinitionen anhängen, so dass
sie für andere Controllertypen leicht angepasst werden können.
Leider gibt es hierfür keine schönen Dateien in DAVE, da ist wohl
Handarbeit angesagt.

Viel Spaß, Guido

Hallo,

hier die nächste Version mit folgenden Erweiterungen
und Änderungen:

Arrays und Records können jetzt am Block zugewiesen
werden. Bis zu 5 Words kopiert der Compiler direkt,
für größere Strukturen legt er eine Kopierschleife
an. Bei dieser Gelegenheit habe ich mir gleich die
lokalen Strukturen in "langen" Prozeduren vorgeknöpft,
die jetzt auch benutzbar sind. Diese werden temporär auf
dem Frame angelegt.

Die Interruptvektoren können jetzt an das jeweilige
Derivat angepasst werden. Dazu werden ihre Definitionen
an die SFR-Definitionen angehängt und mit diesen
geladen. Beispiele für den C164CI und den ST10F276 habe
ich den Quellen zugefügt.

Alle Systemprozeduren habe ich jetzt konsequent auf
Großschreibung umgestellt. Damit wird alles was der
Compiler kennt komplett groß geschrieben, was den
Zusatznutzen bringt, dass sein Scanner beim Einlesen
eine Umwandlung vornehmen kann. Wenn sich jemand an
der Großschreibung stört, kann er jetzt mit der Option
"-uu1" (UseUpper) seinen Quellcode komplett in
Großbuchstaben umwandeln lassen, so dass keine
Fehlermeldungen entstehen. Zur Annäherung an N.Wirths
Modul System habe ich PEEkW in GET, POKEW in PUT und
BREAKPOINT in HALT umbenannt. ADR und GET muss ich bei
Gelegenheit zum selben Zweck noch in funktional
umschreiben.

Viel Spaß, Guido

P.S.: Executables sind wie immer im trunk dabei.

Grmmpf,

vor lauter Rumhantieren mit lokalen Arrays und
Pointerlementen habe ich einen Bug für globale
Arrays mit konstantem Index eingebaut. Eine kurze
Zeile in der Prozedur Index im Generator behebt
das Problem. deshalb hierzu nur einen Patch.

Wenn es jemand probieren möchte: obcc.diff in das
Verzeichnis trunk schieben und von dort aus mit

1

 patch -p0 -i ./obcc.diff

patchen.

Viel Spaß, Guido

Hallo,

heute mal eine Frage zur Codeerzeugung.

Eigentlich ist relozierbarer (relocatable) Code für den C167
erstmal nicht erstellbar, weil ein Lesen des Instruction-Pointers
durch das Programm nicht möglich ist. Andererseits behauptet Keil,
dass ihr Compiler genau dieses schafft. Übersehe ich da einen Trick?
Stackfummeleien scheiden aus. ;-)

Wenn das möglich wäre, und ich war bisher felsenfest davon überzeugt,
dass die Siemensianer hier an alle Eventualitäten gedacht haben,
würde mir dies eine Linkliste für alle Sprünge ersparen.

Hat jemand eine Idee?

Grüße, Guido

Danke Locator, für die Blumen und die Bestätigung.
Dann muss wohl wirklich ein Linkprozess die Adressen
auflösen. Naja, für die globalen Variabken ist das ja
auch notwendig.

Hallo,

nach halbjähriger Umzugs-Schockstarre geht es hier wieder
weiter. Ich habe Lookup-Tables (als TABLE) implementiert,
zusätzlich Bytetransfers via GETB und PUTB. Ein paar kurze
Spezialitäten kommen noch dazu (SRST, EINIT und DUMMIJMP),
so dass ich in meinen Programmen nicht mehr auf Assembler
zurückgreifen muss.

Als Beispiel hänge ich eine zweite Stufe des Bootstraploaders
an, die einen AM29F040B am 8-Bit-Bus eines C167 ohne Multiplex
mit Daten versorgt. Es muss mit der Compileroption
"-ps\$0E000" compiliert werden, da es von der 1. BSL-Stufe an
die Startadresse des XRAMs geladen wird und die Initialisierung
nicht vom Compiler erstellt wird.

Der Hintergrund ist, dass ich die Codeerzeugung mit in den
Compiler übernehmen möchte. Das erleichtert größere
Erweiterungen enorm, ist aber zunächst mal sehr viel Arbeit.
Die direkte Einbindung von Assemblercode bleibt dabei natürlich
auf der Strecke, aber nach meinem Gefühl ist sie mittlerweile
sowieso unnötig. Falls noch etwas fehlt, kann es ja schnell
implementiert werden.

Executables sind wie immer im trunk.tgz, viel Spaß, Guido

Hallo,

die Codeerzeugung ist erstmal abgeschlossen, der Compiler
funktioniert jetzt standalone. Vor allem im Generator waren
hierzu einige Umbauarbeiten notwendig, hoffentlich ist dabei
nicht zu viel kaputt gegangen. Allerdings ist die
Wartbarkeit dadurch deutlich verbessert worden, so dass
Fehler leichter eingegrenzt werden können.

Ich habe auch die Dokumentation überarbeitet, eine Übersicht
an den Anfang gestellt, überholte Abschnitte gelöscht und
die Details in einem eigenen Kapitel gesammelt. Dieses wird
zukünftig sicher noch wachsen, da ich keine Lust nehr habe,
für jede Kleinigkeit im Quelltext rumzuscrollen. Wozu hat man
schließlich ein EBook!

Als Beispiel hänge ich die überarbeitete Version meines
Miniwebservers auf dem MCB167-NET an. Mit der Option -uw0
compiliert liegt seine Länge immer noch bei knapp 5.7 kiB. Die
ausgelieferte Webseite ist jetzt, völlig unlesbar, als Tabelle
eingebunden (weil das jetzt geht!), für eine echte Anwendung
würde ich diese in ein anderes Speichersegment schreiben und
mit GET darauf zugreifen (in CopyPage). Zum Compilieren muss
enet.txt in enet.mod umbenannt werden, das Resultat erscheint
dann als Enet_0.bin.

Executables sind wie immer im trunk, viel Spaß, Guido

Hallo Joern,

im Prinzip wäre das schon möglich. Es gibt aber für die M3
Cortex bereits den Oberoncompiler Astrobe von CFB-Software.
Der Autor Chris Burrows ist viel weiter als ich, den Vorsprung
werde ich wohl nicht aufholen können.

Gruß, Guido

Hallo,

es hat etwas länger gedauert aber hier ist die nächste
Version. Mittlerweile ist der Modulimport realisiert
und funktioniert grundlegend. Auch das Linken übernimmt
hierbei der Compiler, alle nötigen Informationen erhält
er aus einer Symboldatei, einer reinen Textdatei,
die er beim Export erstellt. An strukturierten
Typen können bisher Arrays und Records skalarer
Elemente importiert werden, komplexere Strukturen
werde ich nach Bedarf implementieren.

Die Einzelheiten habe ich in der Dokumentation erläutert
der ich auch ein kurzes Kapitel über den Bootstraploader
hinzugefügt habe.

Eine ganze Menge Fehler habe ich wieder korrigiert, aber
das sind sicher nicht die letzten. Als Beispiel hänge ich
das frische Modul zum Lesen von SD-Karten im FAT16-
Format an. Zum Testen muss das in "sdc.mod" umbenannt
und mit der Option "-im1" compiliert werden.

Executables sind wie immer im trunk, viel Spaß, Guido