BASCOM-AVR Demo Version 2.0.7.5 auf ATTiny25

Es ist kein unmittelbarer Fehler, den ich in BASCOM-AVR Version 2.0.7.5 festgestellt habe, aber doch ein Verhalten, daß eine intensive Fehlersuche zur Folge hatte.

Zum schnellen Datenaustausch hatte ich eine Interruptserviceroutine in Assembler mit auch noch einem timingkritischen Abschnitt darin ohne Sichern der Prozessorregister (bzw manuellem Sichern, Stichwort: nosave) geschrieben.

Da es zu Problemen kam, nahm ich das Programm mittels Disassembler unter die Lupe und fand heraus, daß Bascom ohne Meldung Assemblerbefehle austauscht, anstatt eine Fehlermeldung oder zumindest eine Warnung zu erzeugen. Außerdem wird dabei ein Register benutzt, daß man in einer "nosave ISR" möglicherweise nicht gesichert hat. Siehe Kommentare im Code:
Code:
'### Verkürztes kompilierbares Demo zur Problembeschreibung
'### BASCOM-AVR Demo Version 2.0.7.5 (Compiler Version 2.0.7.5)
'
$regfile = "ATtiny25.DAT"
$framesize = 32
$swstack = 32
$hwstack = 34
$crystal = 16000000

Pcmsk = Bits(pcint3 , Pcint4)
On Pcint0 Isr_receive_data_compelled Nosave                 'keine Register sichern
Enable Pcint0
Enable Interrupts

Do
Loop

End                                                         'end program


Isr_receive_data_compelled:

  sbi gifr, pcif                                            'löschen Interrupt Flag

'### Mit Bascom assembliert und dann mit ReAVR von ja-tools zum Überprüfen
'### disassembliert zeigte, daß aus der SBI Zeile ohne Warnung Folgendes entstand
'### und dabei r23 verändert wurde.
'###
'###   lds        r23,(p3A+0x20)        ; io register
'###   ori        r23,k20
'###   sts        (p3A+0x20),r23        ; io register
'###
'### OK, SBI kann nicht auf das GIFR im ATTiny25 zugreifen, da das Register außerhalb
'### des Adressbereiches von SBI liegt.
'###
'### In einer ISR, die keine Register sichert kann die Änderung von r23 OHNE Warnung
'### aber fatal werden. Bei zeitkritischen Routinen können außerdem die zusätzlichen
'### Takte des Ersatzcodes noch graue Haare wachsen lassen wenn man von dem Austausch
'### zunächst nichts mitbekommt - Programm läuft ja eigentlich.

Return
In der gleichen "nosave ISR" verwendete ich folgendes Kommando:
Loadadr Flash_data(write_block_array_pointer) , X
Hier wird das Register r10 verändert. (Das X für r26, r27 steht, ist normalerweise bekannt)

Problem ist nicht weitergemeldet und vielleicht ist das ja auch irgendwo dokumentiert.