Microchip Frust

[Siro]

Irgendwie schafft es Micriochip den Entwicklern Knüppel zwischen die Beine zu werfen.
Ich hab mal mit den PIC's vor Jahren angefangen, weil es freie Tools gab. MBLAB-IDE
Das war auch Jahrelang mein Lieblingsspielzeug.
In Windeseile hatte man mal eben einen Assemblercode "ohne Projekt" und den ganzen Schnickschnack geschriebnen.
Einfach eine Datei, assemblieren und fertig.

Das geht anscheinend überhaupt nicht mehr.

Mal abgesehn von der jetzigen äußert ...... IDE MPLAB-X
die Wochen benötigt um da halbwegs mit zu arbeiten.

Nun musste ich eben feststellen,
dass die Datenblätter, also die PDF Dokumente von Microchip gesperrt wurden.
Von wegen mal einen Registernahmen aus dem Datenblatt mit CTRL-C zu kopieren geht nicht mehr.

Dann schaute ich mal nach den Compilern.
Hitex bietet anscheinend keine Compiler mehr an für die PICs
Microchip hat nur noch Monatscompiler ????
Wenn ich das richtig verstehe soll ich dann jeden Monat dafür Geld bezahlen.....

Übrigens eine Code zu erzeugen, der bewusst 400 Prozent langsamer ist,
kann doch wohl nicht deren ernst sein.
Wie soll ich denn eine Qualität bewerten um dieses Produkt evtl. auch zu kaufen.

Dann hab ich mühsam meine Einstellungen in der Firma getätigt.
Und hab die IDE nun zu Hause auf dem Privatrechner draufgespielt.
Jetzt fang ich wieder an, alles neu einzustellen.

Wo sind eigentlich die Menüs für den Programmer geblieben ?
Keine Ahnung. Gibts nicht mnehr.

Und was soll das mit dem MPLAB Switcher ?

Ich wollte doch nur mal eben ein kleines Progrämmchen schreiben
und nun sitze ich seit Tagen daran um überhaupt etwas zum Laufen zu bringen.

Sorry, aber auch den Frust muss man mal loswerden.....

Eine LED blinkt aber inzwischen schon, hätt ich mal lieber nen astabilen Multivibrator genommen......

Siro

PS. Ich hab mich ja auch mit den LPCXpresso beschäftigt.
Sicher ist es auch dort schwerfällig sich reinzuarbeiten. Aber von den Funktionen und Bedienung her und das als "FREE" bis 256 K-Byte
kann sich Microchip mal wirklich eine Scheibe abschneiden.


- - - Aktualisiert - - -

wer schon meckert, darf auch revidieren:

Ich hatte anscheinend das "GLÜCK", dass nur mein Datenblatt geschützt ist. Das betrifft den PIC12(L)F1840
Ich hab das grad mal bei anderen Datenblättern von den PIC's probiert. Dort kann man Texte markieren und kopieren.

Also gehe ich mal von einem "Versehen" seitens Michrochip aus:
es betrifft das Datenblatt: DS40001441F

[Klebwax]

Irgendwie schafft es Micriochip den Entwicklern Knüppel zwischen die Beine zu werfen.
Ich hab mal mit den PIC's vor Jahren angefangen, weil es freie Tools gab. MBLAB-IDE
Das war auch Jahrelang mein Lieblingsspielzeug.

Sorry, aber ich muß dir eigentlich in allen Punkten widersprechen.
Die alte MPLAB IDE lief nur auf Windows, war für mich eigentlich unbrauchbar.

In Windeseile hatte man mal eben einen Assemblercode "ohne Projekt" und den ganzen Schnickschnack geschriebnen.
Einfach eine Datei, assemblieren und fertig.
Als der erste brauchbare C-Compiler verfügbar war, hab ich mir Assembler nicht mehr angetan.
Nun bin ich eigentlich ein Fan der Commandline, heutzutage kommt man aber um eine IDE nicht mehr herum. Und wenn man mal damit angefangen hat, will man eigentlich auch nicht mehr zurück. Die Unterstützung beim Programmieren, die eine IDE bietet, kann man sicher auch auf der Commandline haben. Wer mit find, grep, diff, patch und zur not auch sed virtuos umgehen kann und auch noch make richtig einsetzt, kann da schon etwas erreichen. Zeitgemäß ist das aber nicht mehr.


Das geht anscheinend überhaupt nicht mehr.

Mal abgesehn von der jetzigen äußert ...... IDE MPLAB-X
die Wochen benötigt um da halbwegs mit zu arbeiten.

Mächtige Werkzeuge haben eine Lernkurve. MPLABX basiert ja auf netbeans, und netbeans ünterstützt viele Sprachen. Nachdem ich mich an die Funktionen und Tastenkürzel etwas gewöhnt habe, hab ich mir netbeans als IDE auch für meinen PC installiert und bearbeite C und Javascript-Code für den PC auch damit. Und man wird viel produktiver dabei. Syntaxfehler werden gleich beim Schreiben des Programms angezeigt, wenn man sich von der IDE helfen läßt, kommen Tippfehler kaum noch vor.

Und last but not least: wer heute auf dem Markt bestehen will, muß eine moderne IDE anbieten. Heutige Programmierer kennen diff und patch meißt garnicht mehr, sie brauchen soetwas wie Visual Studio.


Nun musste ich eben feststellen,
dass die Datenblätter, also die PDF Dokumente von Microchip gesperrt wurden.
Kann ich nicht nachvollziehen. Hab gerade probeweise ein Datanblatt runtergeladen.


Von wegen mal einen Registernahmen aus dem Datenblatt mit CTRL-C zu kopieren geht nicht mehr.
Da geh ich anders vor, den Anfang des Namens eintippen und von der IDE Vorschläge machen lassen, wie es weiter geht. Da kann es einem auch nicht passieren, daß es diese Register oder diesen Pin bei diesem speziellen Chip nicht gibt.


Dann schaute ich mal nach den Compilern.
Hitex bietet anscheinend keine Compiler mehr an für die PICs
Microchip hat nur noch Monatscompiler ????
Wenn ich das richtig verstehe soll ich dann jeden Monat dafür Geld bezahlen.....
Kann ich nicht nachvollziehen. Wenn ich den Copmpiler kaufe, habe ich ihn und bekomme IMHO auch noch Zugriff auf die Hotline für ein Jahr.


Übrigens eine Code zu erzeugen, der bewusst 400 Prozent langsamer ist,
kann doch wohl nicht deren ernst sein.

Das ist sicher Quatsch, im guten Fall Unsinn, im schlechten Verleumdung. Gerade die kleinen PIC ( XC8 ) haben aus architektuellen Gründen Mühe mit einem vollen ANSI-C. Sie bieten daher viel Raum für Optimierungen und die muß man bezahlen. Mir hat das aber bisher nicht gefehlt. Mein Lieblings-PIC für kleine Aufgaben ist der PIC12F1840 mit 8 Pin. In 4K Code bringe ich in nicht optimiertem C mehr unter, als ich mit mit den paar I/Os sinnvoll anfangen kann. Und mit bis zu 8MHz Befehlstakt hab ich auch keine Geschwindigkeitsprobleme. Sollte da mal ne Grenze zu sehen sein, kann ich entweder für 30 Tage kostenfrei den Compiler mit Optimierung mal ausprobieren, oder ich nehme sowieso einen mächtigeren µC.

Beim XC16, der der gcc ist, sind die Unterschiede in der Optimierung nicht so groß. Die erste Optimierungsstufe ist auch in der freien Version möglich. Der PIC24EP256GP202 mit 28 Pins, den ich auch gerne nutze, kann man mit einem Befehlstakt bis zu 70 MHz betreiben. Und beim Füllen der 256K Flash mit Code ist man dankbar für jede Unterstützung einer modernen IDE.


Dann hab ich mühsam meine Einstellungen in der Firma getätigt.
Und hab die IDE nun zu Hause auf dem Privatrechner draufgespielt.
Jetzt fang ich wieder an, alles neu einzustellen.

Wo sind eigentlich die Menüs für den Programmer geblieben ?
Keine Ahnung. Gibts nicht mnehr.
Was soll in den Menüs denn drin sein? Es gibt einen Knopf für Debug, da wird der Code zum Debuggen gebrannt, und einen für Programm. Das reicht doch.


Und was soll das mit dem MPLAB Switcher ?
Das ist IMHO ein Workaround für Windows. Sind noch USB-Treiber für eine alte MPLAB-Version installiert, kümmert sich der Switcher darum. Wer nur MPLABX hat, braucht das nicht.


Ich wollte doch nur mal eben ein kleines Progrämmchen schreiben
und nun sitze ich seit Tagen daran um überhaupt etwas zum Laufen zu bringen.

Nun, ja, eine halbe Stunde zum Runterladen und installieren. Sich automatisch ein Projekt und ein Sourcefiletemplate zu erzeugen ist auch schnell gemacht. 5 Zeilen Pinwackeln ebenso. Dann einen Chip aufs Steckbrett, 5 Drähte an einen PICKIT3 und los gehts mit Debuggen. Schmerzfreier gehts kaum noch.


.. Sicher ist es auch dort schwerfällig sich reinzuarbeiten. Aber von den Funktionen und Bedienung her und das als "FREE" bis 256 K-Byte
kann sich Microchip mal wirklich eine Scheibe abschneiden.
Ich stelle das "FREE" mal gegen "Code zu erzeugen, der bewusst 400 Prozent langsamer ist,". Bevor du das nicht überprüfbar nachweisen kannst, ...

MfG Klebwax

[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. :p

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

[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