Microchip Frust

[Siro]

Moin Peter,

ich hab grad mal ein ganz simples Progrämmchen geschrieben und extra nur ein char genommen.
Ich weise lediglich einem char einen konstanten Wert zu

char a;

a = 3;

Das macht der Compiler daraus:

MOVLW 0x3     ; lade den Wert 3 ins W-Register
MOVWF 0x72    ; speichere den Wert aus W im RAM an der Speicherstelle 0x72
MOVF  0x72,W  ; lade das W-Register mit dem Wert aus Speicherstelle 0x72
MOVWF a       ; speichere den Wert in "a"  a hat die Speicherstelle 0x77

Warum packt der Compiler den Wert erstmal in die Speicherstelle 72 um ihn dort wieder zu laden ?
Das sieht schon sehr merkwürdig aus.

Dazu muss gesagt werden, dass der Compiler die gespiegelten Speicherstellen benutzt hat,
Was er also in der Hinsicht sehr gut gelöst hat.
Es gibt bei meinem verwendeten 12F1840 nämlich genau 16 Speicherstellen, die ohne BANKSELECT direkt addressierbar sind.

Aber der Zwischenschritt über die zusätzliche Speicherstelle macht mich stutzig.

Siro


"brain demaged" ==> Hirngeschädigt. Das trifft es wohl SEHR gut für die PIC Architektur
und trotzdem mag ich diese kleinen Käfer.



Hab eben noch einen Versuch gestartet:
Der Compiler nimmt für die 2te Variable auch die Spoeicherstelle 0x72 als Zwischenspeicher.

[Peter(TOO)]

Hallo Siro,

char a;

a = 3;

Das macht der Compiler daraus:

MOVLW 0x3     ; lade den Wert 3 ins W-Register
MOVWF 0x72    ; speichere den Wert aus W im RAM an der Speicherstelle 0x72
MOVF  0x72,W  ; lade das W-Register mit dem Wert aus Speicherstelle 0x72
MOVWF a       ; speichere den Wert in "a"  a hat die Speicherstelle 0x77

Warum packt der Compiler den Wert erstmal in die Speicherstelle 72 um ihn dort wieder zu laden ?
Das sieht schon sehr merkwürdig aus.

Ich denke ich kann nachvollziehen, was die Entwickler da gemacht haben:
Die 16 direkt ansprechbaren Speicherstellen, werden quasi als CPU-Register verwendet.
Bei den PICs dreht sich alles um das temporäre W-Register

Die meisten CPUs würden dies umsetzen als:

LDA #0x03, R1
STA R1, a

Da der PIC dies nicht kann, gibt es zwei Macros für STA und LDA...


Mach mal etwas komplizierteres, wie

a[i] = 3;

MfG Peter(TOO)

[Klebwax]

ich hab grad mal ein ganz simples Progrämmchen geschrieben und extra nur ein char genommen.
Ich weise lediglich einem char einen konstanten Wert zu

char a;

a = 3;

Nicht ganz richtig. Der Teil rechts vom Gleichheitszeichen Ist ein int. Alle mathematischen Ausdrücke, auch so einfache wie die Konstante "3", sind in C erstmal ein int. Erst bei der Zuweisung an ein char castet das der Compiler auf ein char. Eine Character-Konstante sieht so aus: 'a'

MfG Klebwax

[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