Hallo linux,
genau das wollte ich doch vermeiden: PUSHen/POPen von Registern ist völlig sinnlos, wenn niemand diese - außer ich selbst - verändert.
Offensichtlich werden aber Register verändert und der Entwickler von Bascom kann nicht sagen (!?) welche Reg. für das angebotene und beworbene "Mixed ASM" nun zur Verfügung stehen. Zumindest habe ich dazu keine Info gefunden. Der Entwickler aber sollte das doch wissen und klar dokumentieren können -oder?

Wozu habe ich denn 32 Reg. wenn ich diese interaktiv aus (Un-)Sicherheitsgründen übers SRAM retten soll? Dann reichen doch auch 3 od. 2 Register. Das ging früher auch, ja, aber die AVR bieten nunmal 32 Reg. und da sollte ich nicht ständig (zumal OHNE IRQs) Kopien erstellen müssen. Abgesehen davon würde die RISK-Controller-Philosophie in Frage gestellt werden.

Außerdem: wo endet den diese Register-Retterei? Ab einen best. Punkt muß ich dann vielleicht Teile der I/O-Register ins SRAM verschieben? Nein.
Schlußendlich bleibt dann die Ungewißheit, ob nicht Bascom vielleicht seine Pointer über meine Register-SRAM-Kopie verlegt - die Vermutung/Möglichkeit ist ja leider nicht unbegründet, schließlich müßte ich mich darauf verlassen das Bascom alle SRAM-Pointer korrekt verwaltet. Soll ich dann die Register vielleicht sicherheitshalber in EXTERNES RAM auslagern?

Ich habe auch erlebt das Bascom - ohne Fehlermeldung - über ein SRAM-Array hinauslief und munter SRAM-Zellen (außerhalb der eindeutigen Deklaration) vollgeschrieben hat.

linux, vielen Dank für den Hinweis, in den einen od. anderen Fall habe ich das auch so gemacht (PUSH/POP). Das ist aber ein rumdoktern an den Symtomen ohne die Ursache zu ermitteln. Für professionelle Programme - vielleicht (wie bei mir) im Fahrzeug- oder Sicherheitsbereich - ist das unakzeptabel! Ein Programmierer MUß wissen was in seinen Registern vor sich geht...

Mir wäre geholfen wenn jemand ähnliche Erfahrungen hat und ein Liste der Register veröffentlicht, welche ich zuverlässig nutzen kann.
Grüße,
Mega128.