Microchip Frust

[Peter(TOO)]

Hallo Siro,

NACHTRAG

Vor so 30 Jahren, hatte ich einen C-Compiler für den 6301 (CMOS-Derivat des 6801, ein Singlechip von Hitachi) mit genau dem selben Problem. Allerdings gab es damals noch keine besseren Compiler für diesen Chip.

Ich habe mit dann in AWK einen Optimierer geschrieben, welcher den Assembler-Source bearbeitet hat und diesen dann mit dem Assembler übersetzt.
AWK ist eine Skriptsprache zum bearbeiten strukturierter Textdateien und unter Unix/Linux standardmässig vorhanden, ist aber auch auf andere Betriebssysteme portiert worden.

C war vom Konzept schon immer sehr flexibel, nicht nur weil die Standart-Bibliothek problemlos mit eigenen Versionen ersetzt werden kann, was bei den meisten Programmiersprachen nicht möglich ist.
Ein C-Compiler bestand ursprünglich aus mehreren Teilen, welche heute oft in einem Programm zusammengefasst sind. Die einzelnen Programmteile waren aber auch einzeln benutzbar:
preprozessor: Löst die #includes und #defines auf und erzeugt eine einzelne Datei.
lint: Kam erst später hinzu und macht die genaue Typenprüfung. Musste früher oft separat erworben werden, ist heute aber in jedem Compiler fest drin.
cc: Der eigentlich Compiler, welcher als Ausgabe ein Assembler-Listing erzeugt. Oft auch als zwei Programme implementiert (Parser und Codegenerator)
asm: Der normale Assembler
link: der Linker

Unter Unix gab es auch einen Pascal-Compiler, welcher Pascal in einen C-Source übersetzt hat.

Aus diesen historischen Gründen, können heutige C-Compiler meist immer noch als nur Preprozessor verwendet werden oder nur das Assembler-Listing erzeugen, welches dann mit dem Assembler übersetzt werden kann.

Übrigens PL/M, 1973 von Garry Killdall für Intel entwickelt, hatte auch so einen Macro-Codegenerator
Da gab es an den Macro-Grenzen auch diese unnötigen Register-Tauschereien.
PL/M lief unter ISIS, einem Betriebssystem von Intel. Dies bewegte Killdall dazu CP/M zu entwickeln, welches hauptsächlich in PL/M geschrieben war. CP/M war eigentlich ein Klone von RTS, welches von DEC stammte.

MfG Peter(TOO)

[Siro]

Hallo Peter,
PL/M*80 kenne ich von Damals. Das war ähnlich dem Pascal,
meine ersten Programmiererfahrungen auf einen Tektronix System mit 8 Zoll Disketten. 8085 Emulator
Compiliert wurde in der Mittagspasue, weil das dauerte halt.......
C hab ich erst 25 Jahre später kennen gelernt.

Achja Klebwax, Du hast natürlich recht bei der Zuweisung a = 3;
Die 3 ist in "C" ein Integer, was dann schon problematisch werden könnte bei dem 8 Bitter.
Hab das mal geändert und folgender Code hat sich ergeben:
volatile ist erforderlich, damit mir der Compiler den offensichtich unnötigen Code nicht wegoptimiert....
hier nochmal ein Ausschnitt vom erzeugten Code.

volatile char a,b,c;

a = (char)(3);
0x89: MOVLW 0x3
0x8A: MOVLB 0x0
0x8B: MOVWF __pcstackBANK0
0x8C: MOVF __pcstackBANK0, W
0x8D: MOVWF a
b = '3';
0x8E: MOVLW 0x33
0x8F: MOVWF __pcstackBANK0
0x90: MOVF __pcstackBANK0, W
0x91: MOVWF b
c = a+b;
0x92: MOVF a, W
0x93: ADDWF b, W
0x94: MOVWF __pcstackBANK0
0x95: MOVF __pcstackBANK0, W
0x96: MOVWF c


Das sind schon erstaunliche Umwege,
er packt immer die Werte irgendwo hin
und holt sie wieder zurück.
Keine Ahnung wofür das gut sein sein.
---------------
so würd ich das machen, bin aber auch kein Compiler
movlb 0
movlw 3
movwf a
movlw '3'
movwf b
addwf a,W
movwf c
-------------------

- - - Aktualisiert - - -

hab das mal mit einem Array ausprobiert:

volatile char a[3];

a[0]=(char)(3);
0x8C: MOVLW 0x3
0x8D: MOVLB 0x0
0x8E: MOVWF __pcstackBANK0
0x8F: MOVF __pcstackBANK0, W
0x90: MOVWF a
a[1]=5;
0x91: MOVLW 0x5
0x92: MOVWF __pcstackBANK0
0x93: MOVF __pcstackBANK0, W
0x94: MOVWF 0x21
a[2]=a[1]+a[2];
0x95: MOVF 0x21, W
0x96: ADDWF 0x22, W
0x97: MOVWF __pcstackBANK0
0x98: MOVF __pcstackBANK0, W
0x99: MOVWF 0x22

[Siro]

im Prinzip können die beiden Zwischenzeilen jeweils einfach weggetrichen werden. So wie Du den Assemblercode damals bereinigt hast.
Das liesse sich recht einfach mit einem extra Programmchen ändern.
Das macht aber ja dann auch die Freigeschaltete Version, vermute ich.

[Peter(TOO)]

Hallo,

im Prinzip können die beiden Zwischenzeilen jeweils einfach weggetrichen werden. So wie Du den Assemblercode damals bereinigt hast.
Das liesse sich recht einfach mit einem extra Programmchen ändern.
Das macht aber ja dann auch die Freigeschaltete Version, vermute ich.

Du hast die Wahl zwischen freischalten, selber was machen oder es so zu lassen.
Die hatte ich damals leider nicht. Zudem hatte der 6301 auch nicht viel ROM.

MfG Peter(TOO)

[Klebwax]

im Prinzip können die beiden Zwischenzeilen jeweils einfach weggetrichen werden. So wie Du den Assemblercode damals bereinigt hast.
Das liesse sich recht einfach mit einem extra Programmchen ändern.
Das macht aber ja dann auch die Freigeschaltete Version, vermute ich.

Mit Sicherheit nicht einfach so. Ein Optimizer analysiert einen größeren Programmkontext und entscheidet dann, was er streichen kann. Möglicherweise macht es mehr Sinn, den Code so zu lassen, ihn aber mehrfach zu verwenden. Schreib mal ein paar tausend Zeilen C-Code und schau dir das dann mal an.

Die eigentliche Fragen sind aber: ist dein Code zu langsam für deine Aufgabe oder ist er zu groß für deinen Prozessor?

Und solltest du eine Frage mit Ja beantworten: Ist es, bezogen auf deine Stückzahl, billiger einen größeren bzw. schnelleren Prozessor einzusetzen oder den optimierenden Compiler zu kaufen.

Ich selbst bin mit dem, was man heute für kleines Geld kaufen kann, noch nicht an die Grenze gestoßen. Die neuen PIC24E sind kaum teurer, wenn überhaupt, als die alten PIC16 und lassen sich mit der gleichen IDE bearbeiten. Beim Umstieg auf die XC-Compiler hat Microchip vieles vereinheitlicht. Es ist inzwischen nicht mehr leicht, am C-Code zu erkennen, für welchen Prozessor er geschrieben wurde.

MfG Klebwax