Kein LPM Z+ über avr-gcc?

[Philipp Sªsse (Gast)]

Hallo zusammen,

es wir eng im Flash bei meinem aktuellen Projekt. Ein Blick in den
Disassembler offenbart mir das ganze Drama: all meine

pgm_read_byte(Code++)

werden zu einer ADIW-LPM-MOV-Orgie, so als hätte der tiny13 keinen
zauberhaften LPM Z+ Befehl. (Zum Verständnis: der Kram im Flash wird
geparst und in Abhängigkeit von einem gelesenen Byte passieren
bestimmte Sachen mit den folgenden; es wird also byteweise gelesen,
aber an vielen verschiedenen Stellen im Code. Die wordweisen und
dwordweisen Routinen, die ja LPM Z+ offenbar nutzen, kann ich hier also
leider nicht nutzen.)

Okay, zugegeben, ein Compiler müßte den Code schon gut durchforsten, um
sich durchzuringen, die Adresse "Code" in der ganzen Routine im Z zu
lassen. Aber gibt es vielleicht händische Lösungen, ohne daß ich die
ganze Routine in Assembler schreiben muß (da passiert nämlich noch
zuviel anderes)? Sollte ja nicht so selten sein, die Anforderung,
oder?

Falls es noch nichts gibt, werde ich wohl versuchen, selbst etwas zu
basteln, habe aber leider fürchterlich wenig Erfahrung mit Assembler in
C. Kann ich dem Compiler in einem bestimmten Bereich verbieten, mein
Z-Register anzufassen, damit ich nicht irgendwann eine Überraschung
erlebe? Dann wäre es ja mit zwei einfachen Assembler-Makros zu machen,
denke ich.

[Philipp Sªsse (Gast)]

So, das gute Stück schnuckelt nur so, wenn ich vorneweg ein

    asm (
      "movw r30, %A0"  "\n\t"  \
      : : "w" (Code));

schreibe, um die Variable Code ins Z zu laden, und dann jedes

    x = pgm_read_byte(Code++)

durch

    asm ("lpm %0, Z+" "\n\t" : : "r" (x) );

ersetze. Bringt 10 wertvolle Bytes pro Aufruf.

Glücklicherweise will das Z hier sonst keiner haben, deshalb geht es
noch gut. Aber wohler wäre mir schon, wenn ich garantieren könnte, daß
das meins ist in diesem Bereich (global reservieren kann ich es nicht
-- andernorts wird es gebraucht).

[Jörg W. (dl8dtl) (Moderator)]

> ADIW-LPM-MOV-Orgie, so als hätte der tiny13 keinen
> zauberhaften LPM Z+ Befehl.

Hat er aus Sicht des derzeitigen GCC auch nicht. :-(

Der Prozessorkern mit LPM Z+ hatte typischerweise noch einen anderen
Befehl, den tiny13/2313 aber nicht haben.  Der ursprüngliche GCC-
Patch hatte diese dann damit in die falsche Kategorie sortiert und
ihnen einen Befehl übergeholfen, den sie gar nicht haben.  Die
schnelle Abhilfe dagegen war dann erstmal nur, ihn komplett
zurückzubremsen und für diese beiden auch kein LPM Z+ zu generieren.

Ob das inzwischen ausanderklamüsert worden ist (in den aktuellen
Versionen, also 4.x), kann ich dir nicht sagen.  Frag auf der
avr-gcc-list mal nach, wenn du's genau wissen willst.

[Philipp Sªsse (Gast)]

Ah! Vielen Dank für die Insiderinformation! Das ist dann wohl auch der
Grund, weshalb z.B. bei einer for(int i;i;i--) Schleife kein SBWI,
sondern SBI+SBIC benutzt wird?

Aber hast Du nicht eigentlich maßgeblichen Einfluß, wie die Kategorien
festgelegt werden?

[Jörg W. (dl8dtl) (Moderator)]

> Das ist dann wohl auch der Grund, weshalb z.B. bei einer for(int
> i;i;i--) Schleife kein SBWI, sondern SBI+SBIC benutzt wird?

Ja, vermutlich.

> Aber hast Du nicht eigentlich maßgeblichen Einfluß, wie die
> Kategorien festgelegt werden?

Nein, wie kommst du darauf?  Ich habe bislang keinerlei Zugriff auf
den GCC-Code.  Das macht Marek Michalkiewicz.

Da ich mir durch den 0b-Konstanten-Patch aber gerade im Begriff bin,
bei den GCC-Leuten ein wenig bekannt zu werden, schau ich mal, ob mich
Marek hernach eventuell zum Co-Maintainer für den AVR-Teil machen
kann/darf/will.  Zwar würde ich mich am eigentlichen Compiler eher
wenig vergreifen wollen, aber zumindest simple Patches wie das
Einbringen neuer AVRs könnte ich dann ja vielleicht gleich selbst
erledigen.

[Philipp Sªsse (Gast)]

> Nein, wie kommst du darauf?

Och, das ist die vielleicht naive Vorstellung daß zwischen Compiler und
Lib eine Schnittstelle ist, die auch einer Schnittstelle zwischen den
jeweils beteiligten Leuten bedürfte.

[Jörg W. (dl8dtl) (Moderator)]

> Och, das ist die vielleicht naive Vorstellung daß zwischen Compiler
> und Lib eine Schnittstelle ist, die auch einer Schnittstelle
> zwischen den jeweils beteiligten Leuten bedürfte.

Die gibt es, aber es ist keine Personalunion.