C30-Compiler von Microchip

dsPIC30, PIC24,PIC33 C30 Compiler
PIC18 C18 Compiler

Bis auf diversen Optimierungen, lohnt es sich schon diese Compiler zu 
nutzen.

Gruß Sascha

Wenn du einen Compiler für PIC18 und PIC30 suchst, wirst du Pech 
haben. Das sind zwei sehr verschiedene Architekturen mit entsprechend 
verschiedenen Compilern. Der C30 ist übrigens nichts anderes als ein um 
eine spezielle Optimierung bereicherter GNU-Compiler.

Ich hatte mir den C30 Mitte letzten Jahres mal angesehen und war 
ziemlich prompt über einen bösen Bug gestolpert. Anfang diesen Jahres 
gab es dann eine verbesserte Version.

Wobei der C18er Compiler recht eigenartige Verhaltensweisen an den Tag 
legt, wenn nicht sogar Bugs.

Nennen möchte ich mal:

1.
Wenn man bei einer Funktion mit Rückgabewert die Rückgabe mit return (x) 
vergisst gibt es keine Warnung geschweige denn einen Fehler. Da wird 
einfach mal irgendwas zurückgegeben.

2.
Bei Zuweisung einer int-Zahl in eine long-Variable werden die 
höherwertigen Bytes mit FF beschrieben. Seltsam... Das wird dann ein 
ganz anderer Wert.
Beispiel: b=0x1234, long a=b -> a=0xFFFF1234

3.
printf: Zuweisung einer signed(!) int-Variable z.B. mit x=-100
-> Ausgabe per printf(%d) liefert 65436!

4.
Diese Zuweisung funktioniert NICHT!: int = (int)char[0]<<8 + char[1];
Diese funktioniert: int = (int)char[0]<<8 | char[1];

Die erste Variante geht normalerweise bei anderen Compilern.

Im Gegensatz zum Keil-Compiler sind das Welten.

Steffen

@Gerhard

Aber schon der erste Punkt ein ein gravierender Fehler!

Das wurde in keinem Update bisher behoben und führt zu ärgerlichen 
Fehlersuch-Runden, die nicht sein müssten. Auch die anderen Sachen sind 
nicht ohne.

Es gibt Eigenheiten des Compilers, dass eher an unwichtigen statt an 
wichtigen Stellen gewarnt wird. Von fehlenden Fehlern mal abgesehen.

Aber egal, muss man sich halt durchwurschteln. :-)

Steffen

Tim wrote:

> Wenn du den GCC gewohnt bist wirst du enttaeuscht sein.

Vom C30 Compiler?

Ich fragte deshalb, weil der C30 ja letztlich auch nur eine GCC Version 
ist, mit zusätzlich eingebauten proprietärem Optimizer.

Die MPlab kannst du dir auch ersparen, der Compiler lässt sich von der 
Command Line nutzen, also auch beispielsweise in PN einbauen.

Selbstbau-Programmierer für PICs gibt's grad so wie für AVR, angefangen 
vom Parallelport bis zum ICD2-Nachbau. Nur dass der ICD2 auch debuggen 
kann, was bei Atmel für etliche Devices nur mit dem 300€ Teil geht.

Den C30-Compiler kenne ich nicht.

Ihr verwechselt das jetzt nicht mit dem PIC32-Compiler? Das ist ein GCC 
für den MIPS mit Microchip-Optimierungen.

Ich hab gerade nochwas zum C18 gefunden...

printf kann z.B. kein float. Okay, muss auch nicht sein, kann man auch 
eine selbtsgeschriebene Funktion zur Ausgabe hernehmen.
Der Compiler hält es aber nichtmal für nötig eine Warnung auszugeben, 
wenn man %f in printf verwendet -> seltsam. Muss man erstmal ins Messer 
laufen.

Okay, wenn man einige dieser Sachen dann kennt geht es schon, andere 
Compiler haben halt andere Macken.
Aber mein Lieblingsconplier ist er nicht wirklich ;-).

Steffen

Steffen Hildebrandt wrote:

> Ihr verwechselt das jetzt nicht mit dem PIC32-Compiler?

Definitiv nicht.

> Das ist ein GCC für den MIPS mit Microchip-Optimierungen.

Der C30 auch. Nicht jedoch der C18.

> printf kann z.B. kein float.

Das wiederum interessiert den Compiler selbst rein garnicht, sondern ist 
Bestandteil der Bibliothek.

Eine Newlib für C30 wäre wohl auch kein Hexenwerk, nur vielleicht 
grösser als den PIC30 Kunden lieb ist.

> wenn man %f in printf verwendet -> seltsam.

Eigentlich geht es den Compiler einen Sch..dreck an, was der Anwender in 
den Formatstring von printf reinschreibt. Da gilt genau genommen Schrott 
rein Schrott raus, und bei vielen Compilern ist es auch exakt so. GCC 
ist immerhin so freundlich, den Formatstring auf offensichtliche 
Inkonsistenzen zu überprüfen.

Aber das geschieht ohne Wissen über die konkrete Implementierung von 
printf, in der Annahme, die entspräche dem in C Libraries üblichen.
Und zwar erfolgt dies im maschinenunabhängen Teil von GCC. Dessen 
Entwickler können beim besten Willen nicht wissen, dass Microchips 
Implementierung von printf() unvollständig ist.

PS: Fehlt dem printf wirklich die Ausgabe von Fliesskommadaten, oder 
muss man nur die richtige Version der Library an Land ziehen? Vom C30 
habe ich das nicht im Kopf, bei AVR muss man sich einfach die richtige 
Library suchen, sonst kriegt man den gleichen Effekt.

Okay, so bewandert bin ich mit den Internas von Compilern nicht.

Wenn das erst mal kein grundsätzlicher Fehler ist ists okay, aber eine 
Warnung wäre zumindest angebracht. Compiler und Lib stammen von 
Microchip, da sollten sie ihren Kram doch ganz gut kennen.

printf kann kein %f bzw. floating-point, steht in der Doku auch so drin.
Wenn man es weiss ists kein Problem, aber gerechnet hab ich damit 
erstmal nicht.

Steffen

Steffen Hildebrandt wrote:

> Wenn das erst mal kein grundsätzlicher Fehler ist ists okay, aber eine
> Warnung wäre zumindest angebracht. Compiler und Lib stammen von
> Microchip, da sollten sie ihren Kram doch ganz gut kennen.

Nicht der ganze Compiler ist von Microchip, nur der Codegenerator. Das 
ist im GCC organisatorisch getrennt und der maschinenabhängige Teil ist 
vergleichsweise klein. Und ist der einzige Teil, der für eine neues 
Zielsystem neu geschrieben wird (vermutlich: man kopiert sich Teile von 
von einem möglichst vergleichbaren bestehenden Target und ferkelt darin 
herum). Allzu viel Ahnung vom maschinenunabhängigen Löwenanteil des 
Compilers muss man dafür wahrscheinlich garnicht haben.

Beim Compiler für den PIC32 war es einfacher: Da dieser einen MIPS Kern 
hat, war die GCC Version dafür schon 2 Jahrzehnte vor dem Controller da.

Aha, interessant.

Klar, beim neuen MIPS-Compiler (PIC32) ists etwas einfacher. Der ist 
sicher schon recht ausgefeilt.

Naja, was solls. Muss ich mich weiter mit dem C18-Compiler rumärgern.

Steffen

Geht auch anders. Es gibt andere Compiler (€€€) oder Assembler. Das 
einzige was mich am C30 ziemlich stört ist der fehlende Support für C++, 
aber das ist eher eine Marotte von mir als ein ernstes Kriterium für die 
Praxis.