Unterschied in Codegröße zwischen CodeVision und WinAVR

Steffen Graap wrote:

> Ist der Compiler beim optimieren einfach schlechter oder warum kommt es
> zu diesem  Ergebnis?

Kann man, ohne den Code zu sehen, nichts dazu sagen.

Kannst du mal die Codegrößen der einzelnen Funktionen von Codevision
aufschreiben?  Die größte Funktion ist INT0_vect, aber wenn ich mir
den generierten Assemblercode ansehe, finde ich da kaum noch
Optimierungspotenzial.  Gerade in Bereichen wie dem Aufblähen von
8-bit-Zahlen auf 16 bits (integer promotion) ist der GCC hier besser,
als ich erwartet hätte (das ist sonst seine schwache Seite).

Wenn man es mit -mint8 compiliert, passt es gerade so in die 2 KiB
rein.  Das könnte für eine derartige Applikation sogar legal sein,
aber schick ist es nicht.  Mich würde mal interessieren, wo CV hier
so viel besser ist, dann guck ich nochmal weiter.

Achte bitte auf eine einheitliche Groß-/Kleinschreibung.  Wenn die
Datei boot.h heißt, sollte dann nicht #include "Boot.h" stehen.  Zum
Glück war's nur eine Stelle.

Es könnte hilfreich sein, in der ISR einige der "static" Vars vorneweg 
zu laden und hinten wieder wegzuspeichern. Ziemlich viel Platz wird mit 
den vielen LDS/STS verbraten, Register sind billiger.

Oder: Die statischen und externen Variablen alle miteinander in eine 
struct packen und per Pointer adressieren. LDD ist nämlich kürzer als 
LDS.

In welchem Anhang?

Richtig, es ging mir nur um die ISR. Aber das ist der mit Abstand 
grösste Brocken.

Er sollte es alleine machen, ja, aber manchmal hilft es, dem Compiler 
entgegenzukommen. Ausprobieren. Mit Registern meinte ich eher, Variablen 
die von der Arbeitsweise her "static" sein müssen, vorneweg in "auto" 
Variablen zu laden, nicht in explizite Register.

Wäre es nicht ausgerechnet ein schon angestaubter Tiny26, liessen sich 
auch die bei neueren AVRs vorhandenen 3 GIOR Bytes im I/O-Space 
platzsparend einsetzen. Atmel dürfte die als Analogon zum Bitspace der 
8051 verstanden haben, für überwiegend bitadressierten Kram sind Bytes 
im I/O-Bereich ideal.

Was die Optimierung von in Speicher plazierten Variablen sehr effektiv 
aushebeln kann ist, ist die Gefahr von Aliasing. Vielleicht ist etwas 
gewonnen, wenn du GCC davon überzeugen kann, dass diesbezüglich von 
pu8Bytezeiger keine Gefahr ausgeht.

Grund für den bei CV erheblich kürzeren Code ist eine 
Optimierungstechnik, die im GCC mangels Sinn (Speed) auf 
Workstations/Servern nicht enthalten ist: Auslagerung kurzer 
Codesequenzen in kleinste Unterprogramme (bm8.lst: OPTIMIZER ADDED 
SUBROUTINE).

Im Zusammenhang mit GCC ist mir dieser Schritt beim Microchip C30 
begegnet (Procedural Abstraction), dort aber als proprietäre Erweiterung 
in einem separaten Compiler-Pass realisiert.

Beispiel:

  ...
  variable += 1;  // 5 Worte
  ...
  variable += 1;
  ...
  variable += 1;
  ...
  variable += 1;
  ...

ist kürzer, wenn realisert als

  void incr(void) { variable += 1; }

  ...
  incr(); // 1 Wort
  ...
  incr();
  ...
  incr();
  ...
  incr();
  ...

Steffen Graap wrote:

> Das zweite was ich gefunden habe ist so etwas:
>
> lds r24,u8Adresse
> cpi r24,lo8(4)
> brsh .L57
> lds r24,u8Adresse         (nicht nötig, kostet 4 Byte)
> clr r25
> subi r24,lo8(-(au8Prog))
> sbci r25,hi8(-(au8Prog))

Das hast du ihm aber extra so gesagt, indem du einen ganzen Haufen
Variablen als volatile deklariert hast.  Damit zwingst du den
Compiler, sie immer aus dem Speicher zu lesen und sie jedesmal
wieder zurück zu schreiben.

Ich überblicke die ganze state machine da nicht, aber ich vermute
mal ganz stark, dass keine einzige davon volatile sein muss.  Wenn
überhaupt, dann würde wahrscheinlich ein Synchronisationsflag als
volatile genügen.  Leider ist das alles recht unübersichtlich, wenn
man nur mal so draufguckt.

Ich sehe gerade, dass der CV einige der Variablen in globale Register
gepackt hat.  Das kann er, da er ja immer alle Dateien zusammen als
eine einzige C-Datei compiliert und daher nie von externen Moduln
ausgehen muss.  Das könnte man dem GCC natürlich auch noch nahelegen.
Allerdings sind deine Headerdateien ziemlich durcheinander und nicht
sauber nach Definition und Deklaration getrennt, daher gelingt mir
das jetzt nicht auf Anhieb.

Deine EEPROM-Zugriffe stimmen für den GCC übrigens so noch nicht,
da musst du explizit eeprom_write_...() aufrufen.

Yep, die volatiles hatte ich glatt übersehen. Aber da passt der Trick 
mit dem pointer-to-struct rein. Denn damit lässt sich diese 
optimierungsunfreundliche Eigenschaft recht elegant innerhalb der ISR 
umgehen, und da ist das ja ohnehin nicht relevant. D.h. wenn der Pointer 
auf die Daten nicht volatile ist, kann optimiert werden. Und ausserhalb 
der ISR ist es weiterhin volatile.

Steffen Graap wrote:

> In CV brauchte ich dies nicht machen.

Mag sein, aber GCC ist nicht für Microcontroller optimiert, sondern für 
High-End Maschinen in denen zeilen/blockübergreifende Optimierung 
wichtig ist. Und es ist auch nicht GCC oder Jörg, der "volatile" 
fordert, sondern der C Standard seit 20 Jahren.

> Das GCC mit den Prozessorregistern recht sparsam umgeht

Er hat bei "volatile" einfach keine Chance, denn das ist letztlich 
nichts anderes also die Aussage "führe bitte keine Registeroptimierung 
durch". Er tut damit nur was du ihm sagst.

Also:

  volatile struct S {
     int var1;
     int var2;
  } globale_variablen;

und dann in der ISR:

  struct S *gvars = (struct S *) &globale_variablen;
  ... gvars->var ...

und der Spuk dürfte vorbei sein. In der ISR selbst besteht für 
"volatile" kein Grund, solange du auf nested interrupts verzichtest.

Naja, ist ziemlich unsauber.  Ich würde eher dafür plädieren, volatile
nur dort zu benutzen, wo es wirklich notwendig ist.  Allerdings ist
diese Abwägung zuweilen ziemlich schwierig.  Normalerweise sollte es
komplett genügen, eine Art Semaphore volatile zu haben und den Rest
nicht.

> Naja, ist ziemlich unsauber.

Es ist geringfügig umständlich in der Handhabung und vielleicht nicht 
allzu schön, aber m.E. durchaus sauber, was den Standard angeht.

> Normalerweise sollte es komplett genügen, eine Art Semaphore volatile
> zu haben und den Rest nicht.

Hilft in diesem Fall rein garnicht. Denn an der Optimierung von 
Variablen ändert keine Semaphore irgendwas. Nur die Problematik bei 
nicht-atomarem Zugriff lässt sich per Sema erledigen.

Und was ISRs angeht, hilft sie auch da nicht, denn was machst du in der 
ISR wenn die Sema grad blockiert ist?

Andreas Kaiser wrote:

>> Naja, ist ziemlich unsauber.

> Es ist geringfügig umständlich in der Handhabung und vielleicht nicht
> allzu schön, aber m.E. durchaus sauber, was den Standard angeht.

Meine Lesart des Standards ist, dass das Ergebnis des ,,Wegcastens''
eines type qualifiers nicht definiert ist.

>> Normalerweise sollte es komplett genügen, eine Art Semaphore volatile
>> zu haben und den Rest nicht.

> Und was ISRs angeht, hilft sie auch da nicht, denn was machst du in der
> ISR wenn die Sema grad blockiert ist?

Ich meinte mehr so eine Art Flag, das im main context gepollt werden
kann und sicherstellt, dass man auf konsistente Daten zugreift.
Eigentlich braucht man volatile doch nur für Dinge, bei denen kein
sequence point dazwischen liegt, also das typische Flag, auf das man
in main() pollt.

U. U. ist gerade für so eine einfache Applikation eine "memory barrier"
sinnvoller zu handhaben als eine Unmenge an volatile-Variablen.  Die
"memory barrier" wird implementiert mit:

1

asm volatile(:::"memory");

Sie zwingt den Compiler, danach alle Werte, die aus dem Speicher
gelesen worden sind, neu zu evaluieren.  Leider kann man sie
meiner Meinung nach nicht auf Register anwenden (falls man globale
Registervariablen benutzt).  Ich bin mir nicht ganz sicher, ob ein
vergleichbarer Trick für solche Variablen benutzbar wäre:

1

asm volatile(:::"r2");

>

1

asm volatile(:::"memory");

Das ist nun aber sehr compilerspezifisch. Und für Ersatz von "volatile" 
Vars einigermassen umständlich und fehlerträchtig, denn das muss man 
dann im gesamten Hauptprogramm an den Zugriffen auf solche Variablen 
unterbringen und es setzt gewissen Vorstellungen von der Arbeitsweise 
von Compilern voraus. Zudem wirft es alle speicherbezogenen 
Optimierungen über Bord, also auch die harmlosen Variablen.

Wenn wegcasten von qualifiern nicht definiert ist, wie gibt man dann 
einen String aus (d.h. übergibt ihn an eine Funktion, die "char *" 
erwartet)? Immer erst in eine lokale Variable umkopieren? Ist mir noch 
nirgends begegnet. Dafür aber jede Menge casts, um "const" loszuwerden 
weil die aufgerufene Funktion irgendwann in grauer Vorzeit ohne "const" 
deklariert wurde.

Andreas Kaiser wrote:

> Wenn wegcasten von qualifiern nicht definiert ist, wie gibt man dann
> einen String aus (d.h. übergibt ihn an eine Funktion, die "char *"
> erwartet)? Immer erst in eine lokale Variable umkopieren?

Ja, das ist der einzig saubere Weg, den ich im Standard sehe.  Das
ist auch nicht verwunderlich, ist ja schließlich ein Standard, und
der soll die Eckpunkte markieren.  Letztlich deutet die Situation,
die du beschreibst, ja auf einen Designfehler hin (gerufene Funktion
ändert zwar die Daten nicht, wurde aber nicht sauber dahingehend
deklariert, sodass man mit einem Hack arbeiten muss).  Dein Cast
tötet den Compilertest aber auch für die Fälle, in denen es wirklich
kracht, d. h. die gerufene Funktion ist als non-const char * deklariert,
wird mittels typecast aus einem const char * gefüttert, hackt aber
anschließend tatsächlich auf dem String herum (wozu sie gemäß ihrer
Deklaration berechtigt ist) -> peng!

Da das ,,Wegcasten'' des qualifiers aber ein Designfehler ist, würde
ich dies niemandem für ein Neudesign empfehlen.