Fehler wegen Optimierungsniveaus

[Owen S. (senmeis)]

Servus,

ich habe eine Fehlermeldung

C:/WinAVR/avr/include/avr/eeprom.h:233: error: can't find a register in 
class `BASE_POINTER_REGS' while reloading `asm'

bekommen wenn das Optimierungsniveau im AVR Studio auf "-Os" gesetzt 
wird. Der betroffene Code sieht wie folgt aus:

asm volatile ( 
            ".%=_start:" CR_TAB
            "sbiw %2,1" CR_TAB
            "brlt .%=_finished" CR_TAB
             XCALL " __eeprom_read_byte_" _REG_LOCATION_SUFFIX CR_TAB
            "st z+,__tmp_reg__" CR_TAB
            "rjmp .%=_start" CR_TAB
            ".%=_finished:" 
          : "=x" (pointer_eeprom),
            "=z" (pointer_ram),
            "+w" (size)
           : "x" (pointer_eeprom), 
             "z" (pointer_ram)
           : "memory");

Was soll ich jetzt machen?

MfG
Senmeis

[Johann L. (gjlayde)]

Gibt's ein übersetzbares d.h. compilerbares Beispiel? Muss nicht 
linkfähig sein zum Testen.

In Zeile 233 der eeprom.h steht lediglich ein normales Define.

[Johann L. (gjlayde)]

Offenbar verwendest du eine nicht sonderlich aktuelle Version von WinAVR 
bzw. avr-libc. Wäre nett, darauf hinzuweisen...

Das Problem ist, daß das asm-Schnippel in einer Inline-Funktion steht 
und der Fehler ohne Kontext nicht reproduzierbar ist.

Vermutlich tritt er nur zusammen mit hoher Registerlast auf, da der 
Schnippel viele obere Register verwendet.

Du kannst versuchen die Registerlast auf die obereg GPRs etwas zu 
reduzieren, indem du folgendes inline Asm verwendest:

      asm volatile (
            ".%=_start:" CR_TAB
            "subi %A2,1" CR_TAB
            "sbci %B2,0" CR_TAB
            "brlt .%=_finished" CR_TAB
            "%~call __eeprom_read_byte_" _REG_LOCATION_SUFFIX CR_TAB
            "st z+,__tmp_reg__" CR_TAB
            "rjmp .%=_start" CR_TAB
            ".%=_finished:"
          : "+x" (pointer_eeprom),
            "+z" (pointer_ram),
            "+d" (size)
           :: "memory");

[Owen S. (senmeis)]

vielen Dank.

Ich habe diesen Assembler Code entsprechend verändert. Nun lässt der 
Code kompilieren, aber der Arbeitsspeicher (RAM) wird nicht damit 
gespart. Bei mir beträgt dies immer 93,2%. Wieviel kann das eingespart 
werden in normalen Fällen?

MfG
Senmeis

[(prx) A. K. (prx)]

Wenn das RAM voll ist, dann wirft man einen Blick in das Mapfile um 
rauszufinden, womit es belegt ist.

> Wieviel kann das eingespart werden in normalen Fällen?

Zwischen 0 und 77,48%, je nach Einzelfall.

[Johann L. (gjlayde)]

Owen Senmeis schrieb:

> Ich habe diesen Assembler Code entsprechend verändert. Nun lässt der
> Code kompilieren, aber der Arbeitsspeicher (RAM) wird nicht damit
> gespart. Bei mir beträgt dies immer 93,2%. Wieviel kann das eingespart
> werden in normalen Fällen?

Es gibt keine "normalen" Fälle. Es gibt einzig und allein konkrete 
Fälle.

Wie bitte soll man Einsparpotential beurteilen, ohne irgendwas über 
die Quelle, die verwendete Toolchain-Version oder die Build-Optionen zu 
wissen???

Der Code ober behebt ein Compilerproblem bei hoher Registerlast, es ist 
keine Optimierung. Das gleiche Problem ist übrigens bei 
eeprom_write_block zu erwarten.