Microchip Frust

[Siro]

Hallo Klebwax
Der Satz von Dir trifft es wahrscheinlich:

"Mächtige Werkzeuge haben eine Lernkurve"

Da liegt wohl mein Hauptproblem, oder es liegt am Alter
Es gibt derart viel Neues, dass man erstmal völlig überfordert da steht.

Das mit dem Datenblatt "kopieren"... hatte ich ja schon korrigiert..
Das scheint "nur" unglücklicherweise auf mein Dokument vom PIC12F1840 zuzutreffen.
Wenn schon Probleme, dann alle Gleichzeitig....

Die 400 Prozent habe ich mir nicht ausgedacht, sondern das ist eine offizielle Meldung von der IDE

Zudem habe ich mir den erzeugten Assembler Code angesehen.
Da wird tatsächlich wild im Code rumgesprungen um unnützen Code und Laufzeiten zu erzeugen.
Hier wird also nicht nur "nicht optimiert", sondern Code bewust vergrößert.
Ich glaube nicht, das dies ein Compiler automatisch macht.

Ich will das ja auch nicht alles schlecht machen.
Aber bissle Luft machen, musste schon mal sein

Mit der automatischen Codevervollständigung nütz oft leider nichts.
Wenn man zum Beispiel das WPUEN Bit ändern möchte,
musst man erstmal wissen, das dies im Header File als nWPEUN declariert wurde.
Also zunächst auf die Suche nach der Headerdatei gehen.
C:\Programme (X86)\Microchip\xc8\v1.36\include
p12lf1840.h

das ich es dort finde, musste ich auch erstmal erforschen, denn es wird ja nur "htc.h" includiert.

Die Konstanten für die "config" Einstellungen sind übrigens in eine .html Datei versteckt.
habe ich nun auch gefunden.
C:\Programme (X86)\Microchip\xc8\v1.36\docs\chips\12f1840.html

Ich fummle mich da schon rein. Aber das kost echt VIEL Zeit.

So, nun gehts weiter.
Siro

[Peter(TOO)]

Hallo Siro,

Zudem habe ich mir den erzeugten Assembler Code angesehen.
Da wird tatsächlich wild im Code rumgesprungen um unnützen Code und Laufzeiten zu erzeugen.
Hier wird also nicht nur "nicht optimiert", sondern Code bewust vergrößert.
Ich glaube nicht, das dies ein Compiler automatisch macht.

Je nach Compilertechnologie ist das aber so.

Die alten Compiler verwendeten im Prinzip einfach Macros.
Damit die Macros zusammen passen, braucht es eine Konvention, z.B. dass der Parameter in B steht und das Resultat des Macros auch in Register B übergeben wird.
Jetzt kann aber die CPU mit Reg B nicht rechnen.
Das Macro für i++; sieht dann so aus:

MOV B, A
INC A
MOV A, B

Das nächste Macro beginnt dann wieder mit

MOV B, A
....

Das Andere ist dann, ab welchem Punkt man nicht mehr inline Code erzeugt, sondern Funktionen in einer Laufzeitbibliothek aufruft.

Beide Verfahren vereinfachen den Compiler ganz enorm, ergeben aber nicht sehr effizienten Code.
Diese Compiler funktionieren eigentlich wie Interpreter, es wird einfach Statement für Statement in Code übersetzt.


Moderne Compiler erzeugen nach der Lexikalischen und Syntaktischen Analyse einen Baum in einem Pseudocode.
Dieser Baum wird dann auf logischer Ebene analysiert und optimiert. Hier kann man unwirksamen Code entfernen, Speicherzugriffe auf Variablen optimieren und Schleifen optimieren.
Dann erst wird Maschinencode erzeugt und die Registernutzung optimiert.
Solche Compiler sind natürlich etwas aufwendiger.

Neben dem besseren Code bringt das ganze noch einen weiteren Vorteil:
Der Compiler besteht aus 3 Teilen, dem Frontend, dieses ist Sprachspezifisch und erzeugt den Baum, der Optimierer, welcher Sprachunabhängig ist und dem Backend oder Codegenerator, welches CPU-Spezifisch aber Sprachunabhängig ist.

Für unterschiedliche Sprachen muss man dann nur das Frontend neu entwickeln und für eine spezielle CPU nur ein neues Backend.

MfG Peter(TOO)

[Klebwax]

Die 400 Prozent habe ich mir nicht ausgedacht, sondern das ist eine offizielle Meldung von der IDE

Zudem habe ich mir den erzeugten Assembler Code angesehen.
Da wird tatsächlich wild im Code rumgesprungen um unnützen Code und Laufzeiten zu erzeugen.
Hier wird also nicht nur "nicht optimiert", sondern Code bewust vergrößert.
Ich glaube nicht, das dies ein Compiler automatisch macht.

Ich sehe mir eigentlich nie den Assemblercode meines C-Programms an, weder auf dem PC, dem Tablett noch einem µC. Ich würde mir aber auch nicht zutrauen, zu entscheiden, ob der erzeugte Code sinnlos ist. Die standardgerechte Umsetzung von C auf einer Harvardachitektur ohne Datenstack und mit einem sehr begrenzten Returnstack ist nicht trivial. Da geht es um Sequencepoints, die Rekursivität von Funktionen, die jederzeitige Unterbrechbarkeit durch Interrupte und vieles mehr. Nicht zuletzt ist die Wortbreite des Prozessors mit 8 Bit kleiner als ein C-int, daß mindestens 16 Bit haben muß. Den Vorwurf "Code bewust vergrößert" halte ich für vermessen. Wer das begründet äußert, weil er einen guten standardkonformen C-Compiler programmieren kann, diskutiert hier nicht über die Schwächen einer IDE.

Mit der automatischen Codevervollständigung nütz oft leider nichts.
Wenn man zum Beispiel das WPUEN Bit ändern möchte,
musst man erstmal wissen, das dies im Header File als nWPEUN declariert wurde.

Eigentlich nicht. Zuerst OPTION_REG eingeben, WPUEN ist ja Teil diese Registers, dann solange der Cursor noch auf diesem Fragmet ist, Ctrl-Space. Jetzt bietet einem die IDE unter anderem OPTION_REGbits an. Da es ja um ein Bit in diesem Register geht, ist das schon mal richtig. Steht jetzt OPTION_REGbits. da, werden einem alle vorhandenen Bits in diesem Register angeboten. Als letztes in der Auswahlliste findet sich nWPUEN, also markieren, return fertig. Da WPUEN im Datenblatt mit einem Überstrich markiert ist, ist das n am Anfang nicht ungewöhnlich.

Wenn man doch in den Headerfile schauen will, in dem die Register definiert sind, Cursor z.B. auf OPTION_REGbits setzen und Ctrl-linke Maustaste und der File, aus dem das Symbol kommt, öffnet sich (und der volle Pfad ist natürlich in Tooltip sichtbar). Das funtioniert natürlich auch bei eigenen Symbolen und Headerfiles.

Als kurze Lektüre, was die IDE so alles kann, empfehle ich die "Keyboard Shortcuts Card" unter Help.

@Peter Der XC8, vormals HI-TECH C, ist schon einer der besten Compiler für die 8 Bit PICs. Und C für einen Prozessor ohne Datenstack ist zusammen mit einer brauchbaren libc schon eine Herausforderung.

MfG Klebwax

[Siro]

Guten Abend, ihr Fleißigen,
erstmal vielen Dank für Euren vielen Informationen:
Bin grad erst dazu gekommen, einiges auszuprobieren.

Mit der Tastenkombination CTRL Space geht so einiges, ich bin echt erstaunt.
Muss man einfach mal bischen rumprobieren.

Rechte Maustaste "Navigate" dann "Go to Declaration" führt zum Programmcode

super G E I L das gefällt mir wirklich.

Mit den Configuration Bits hab ich jetzt auch verstanden.
Man stellt sie im Configuration Fenster ein,
dann "Generate Source Code to Output und kopiert es in den Programmcode rein
Da brauche ich garnicht zu wissen, was in der .html Datei steht.

Das wirft doch schon einen ganz anderen Blick auf die IDE.

Was würde ich nur ohne Euch tun ?
wahrscheinlich noch mehr meckern.....

Also vielen Dank euch Beiden Peter + Klebwax
Siro

Mit dem erzeugten vermeintlich 400 Prozent langsameren Code kommt vielleicht doch vom Compiler selbst ?
Könnte natürlich sein. Sieht aber wirklich SEHR umständlich aus.
Das ist natürlich problematisch bei den 8 Bittern und dazu das Banking bei den PICs.
Hab selbst mal etliche Macros in Assembler geschrieben um mir das Leben zu erleichtern
und muste feststellen, das dies nicht wirklich einfach ist bei dieser Prozessorarchitektur.

Irgendwie hat der Compiler bei Verzweigungen Doppelsprünge eingebaut, welche natürlich unnötig sind.
Aber da die freie Version halt nicht optimiert, bleibt das anscheinend dann so stehen.

Auf jeden Fall habt ihr mir sehr gute Informationen gegeben und ich kann mit der IDE jetzt
anfangen vernünftig zu arbeiten.

Hab auch grad gelesen, dass man die freie Version wohl 60 Tage als Pro Version testen kann.
Nennt sich dann "Evaluation License"


Fällt mir doch grad noch was ein.
Die vielen Einstellungen, alleine vom Editor. Farben, Fonts......
kann man das irgendwie exportieren und auf einen anderen Rechner importieren ?

[Peter(TOO)]

Hallo Siro,
[QUOTE=Siro;623797Mit dem erzeugten vermeintlich 400 Prozent langsameren Code kommt vielleicht doch vom Compiler selbst ?
Könnte natürlich sein. Sieht aber wirklich SEHR umständlich aus.
Das ist natürlich problematisch bei den 8 Bittern und dazu das Banking bei den PICs.[/QUOTE]

Wie Klebwax schon geschrieben hat:

C arbeitet hauptsächlich mit dem Stack: lokale Variablen und die Parameter bei Funktions-Aufrufen werden über den Stack übergeben.
Nun haben die 8-Bit PIC aber keinen Stack
Also muss man den Stack emulieren. Was andere CPUs mit einem einzigen Maschinenbefehl erledigen, muss man beim PIC aus mehreren Befehlen zusammenwürfeln.
Ein älterer BASIC-Dialekt, mit nur globalen Variablen. wäre da wesentlich effizienter umzusetzen.

Die Speicherarchitektur ist auch nicht gerade optimal. Durch das 12-Bit ROM wird beim Speichern von ASCII-Text Konstanten 1/3 verschwendet. Im Prinzip könnte man ASCII packen, was aber mehr Code für den Zugriff erzeugt.

Ein Freund, C Compilerentwickler bei IAR, bezeichnet solche CPUs als "brain demaged", dazu zählt er auch die 8051-Architektur.

MfG Peter(TOO)

[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