Welches Register für was?

[wer]

Ich bin mir noch immer etwas unsicher, welche Register für welchen Zweck geeignet sind.
Bisher habe ich gelernt, daß die 6 letzten als 16-Bit Zeiger X,Y und Z benutzt werden können. R0/R1 kann als implizites Ergebnis von mul herhalten. Außerdem gibt es einen Unterschied zwischen den ersten und letzten 16 Registern. Warum nimmt man z.B. so gerne R16 als temporäres Register und nicht R25?

Ich habe auch schon gesehen, daß manche Befehle nicht mit den unteren Registern funktionieren, z.B. cpi.

In diesem Beispiel von Oldmax

.Def	mSek_2= R4	; Register 4 zählt bis 100msek.
.Def	zehntel= R5 	; Register 5 zählt Zehntelsekunden
.Def	Sekunde=R6 	; Register 6 zählt Sekunden
.Def 	Minuten= R7	; Register 7 zählt Minuten
.Def 	Temp = r16	; Allzweckregister
.....
Timer0_ISR:
             Push 	Temp		; Register sichern
             In 	Temp, Sreg
             Push 	Temp        	
             INC	mSek_2
             LDI	Temp, 100
             CP	mSek, Temp
             BRLO	End_Timer0_ISR
             CLR 	mSek_2
   	INC 	zehntel
             LDI	Temp, 10
             CP	zehntel, Temp
             BRLO	End_Timer0_ISR
   	Clr	zehntel
	Inc	Sekunde
	LDI	Temp, 60
	CP	Sekunde, Temp
	BRLO	End_Timer0_ISR
	Clr	Sekunde
             Inc	Minute
             CP	Minute, Temp
             BRLO	End_Timer0_ISR
             CLR	Minute
End_Timer0_ISR:
	POP	Temp
	Out	SReg, Temp
	POP	Temp
RETI

aus diesem Thema könnte man doch einfach

.Def	zehntel= R17 	; Register 17 zählt Zehntelsekunden
.Def  ; entsprechend für die anderen Zähler
...
   cpi zehntel, 10

schreiben. Die ISR wäre dadurch kürzer und Temp bräuchte man nur noch um die Flags zu sichern. Ist das falsch? Also warum wurden hier die Register R4 .. R7 benutzt?

 

[Dirk]

Hallo,

du hast ja die Eigenschaften der Register eigentlich schon beschrieben. Bei den unteren 16 Registern r0..r15 ist keine Immediate-Adressierung (ldi, cpi) möglich. Bit-Adressierung ist auch nicht möglich (sbr, cbr).

Dadurch sind die Register ab r16 "wertvoller". r16 wird oft als erstes Arbeitsregister verwendet, weil es das erste Register im oberen Bereich ist, mit dem Immediate- und Bitadressierung möglich ist. Man könnte auch jedes andere Register im oberen Bereich verwenden, möglichst nicht die Register, die X, Y und Z zugeordnet sind, da diese ja auch andere Aufgaben übernehmen können (indirekte Adressierung).

Ich vermute, Oldmax hat trotz CPI Register im unteren Bereich verwendet, weil so eine "Uhr" muss ja nicht oft umgestellt werden, das Ereignis tritt nicht so oft ein und viel Code "kostet" es nicht. Wichtiger ist es hier vielleicht, nicht die Register im oberen Bereich durch so eine Uhr zu belegen. Man könnte die Uhr auch ins SRAM verlegen.

Dirk

 

[oldmax]

Hi
Dino hat recht, ich hab selten feste Register im Programm und arbeite viel mit Variablen. Der Mehraufwand durch die Lade- und Speicherbefehle ist selten zeitrelevant. Der Vorteil, ich kann mir die Inhalte der Variablen mit OpenEye ansehen und so Fehler erkennen. Mit Registern ist das nicht ganz so einfach...
Außerdem, welche Register verwendet werden, ist Sache des Programmierers unter Beachtung der speziellen Eigenschaften. Gut ist es aber, wenn man sich eine Regel angewöhnt. So ist es überhaupt kein Problem,
LDI R16, 0b11001100 zu schreiben. Ist aber ein Register für spezielle Aufgaben vorgesehen, macht es Sinn, einen Namen zu definieren. So ist "Temp" ein Hinweis, das es ein Register ist, welches nur in kleinen Programmsequenzen gültige Inhalte trägt. Eben ein temporäres Register. Ob es nötig tut ? Nö. Trotzdem gewöhnt sich wohl jeder irgendein Schema an und hat dafür auch sicherlich gute Gründe.
Gruß oldmax

 

[wer]

Hi
Dino hat recht, ich hab selten feste Register im Programm und arbeite viel mit Variablen. Der Mehraufwand durch die Lade- und Speicherbefehle ist selten zeitrelevant. Der Vorteil, ich kann mir die Inhalte der Variablen mit OpenEye ansehen und so Fehler erkennen. Mit Registern ist das nicht ganz so einfach...
Außerdem, welche Register verwendet werden, ist Sache des Programmierers unter Beachtung der speziellen Eigenschaften. Gut ist es aber, wenn man sich eine Regel angewöhnt. So ist es überhaupt kein Problem,
LDI R16, 0b11001100 zu schreiben. Ist aber ein Register für spezielle Aufgaben vorgesehen, macht es Sinn, einen Namen zu definieren. So ist "Temp" ein Hinweis, das es ein Register ist, welches nur in kleinen Programmsequenzen gültige Inhalte trägt. Eben ein temporäres Register. Ob es nötig tut ? Nö. Trotzdem gewöhnt sich wohl jeder irgendein Schema an und hat dafür auch sicherlich gute Gründe.
Gruß oldmax

Mit anderen Worten, der geringe zeitliche Vorteil in der ISR ist Dir weniger wichtig als das Freihalten von vier 'wertvollen' oberen Registern.

 

[oldmax]

Hi

Mit anderen Worten, der geringe zeitliche Vorteil in der ISR ist Dir weniger wichtig als das Freihalten von vier 'wertvollen' oberen Registern

Nun, ich glaub nicht, das dies die Message war, aber wenn du es so auffaßt....
Grundsätzlich gilt: Zeit sparen da wo nötig und informativ da wo auch nötig... also immer so ein kleines bischen mal von diesem und jenem. register sparen... hmmm. also oft brauch ich gar nicht alle...
Gruß oldmax

 

[wer]

Nun, ich glaub nicht, das dies die Message war, aber wenn du es so auffaßt....

Sorry, aber mir geht es nicht darum irgend etwas irgendwie aufzufassen, sondern zu verstehen, warum Leute, die sich mit diesen Mikrocontrollern auskennen so und nicht anders programmieren. Nur so kann man schließlich lernen. Wenn Du meinst, daß mein Resume nicht den Punkt trifft, dann bessere bitte noch mal nach.

 

[dino03]

Hallo,

Dino hat recht, ich hab selten feste Register im Programm und arbeite viel mit Variablen.

ich schreib zwar schon verdammt viel aber noch (zum Glück) nicht alles
Das Geschreibsel war von Dirk Ich will mich ja nicht mit fremden Federn schmücken lassen

Gruß
Dino

 

[oldmax]

Hi
@Dino
Sorry, ich sollte mir doch langsam eine Lesebrille aufsetzen
@wer
OK; also, programmieren, ein Buch schreiben, kochen, das sind Tätigkeiten, die schon nach ein paar grundsätzlichen Regeln durchgeführt werden, aber einen großen Freiraum der persönlichen Geschmacksrichtung lassen. Dies ist eben die sogenannte "persönliche Note".
Wenn es schnell gehen muß und Register ausreichend sind, dann verwende ich auch ein "Zero"- Register für den Null-Wert (BSPW. bei indirekter Adressierung) oder ein "sechzig", "24" etc. um Register im unteren Bereich als Zähler laufen zu lassen und dann mit einem anderen Register statt mit einer Konstanten zu vergleichen. Wie gesagt, dies ist abhängig vom Programm und der Anwendung. So gibt es viele Programmierer, die den SRAM meiden und sehr viel in den Registern erledigen. Dadurch wird aber ein Controller nicht billiger, weil der SRAM nur zu 10% genutzt wird. Auch werden auch völlig komplizierte Endlosprogramme geschrieben, weil Aufrufe kleinerer Programmsequenzen unnötiges Herumgehüpfe ist. Dem Anwender ist es später egal, hauptsache der Controller macht seinen Job. Ob er ein paar tausendstel scheller die Programmschleife durchläuft, merkt eh keiner. Wenn ein fürchterlicher Spaghetti-Code den Job macht, wen juckt's. Wenn du allerdings in einem Team an einem gemeinsamen Projekt arbeitest oder der Nachwelt ein pflegbares Programm hinterlassen möchtest, dann kommt es auf klare Strukturen an. Nur so hat ein Kollege die Chance, durchzublicken.
Gruß oldmax

 

[wer]

Namen

Ich möchte mal noch was zu diesem Thema fragen. Vielleicht gibt es den ein oder anderen Tipp, der mir da weiterhilft.

Ich habe grundsätzlich drei verschiedene Gruppen von Variablen, die ich alle in Registern halten will:
1.) Globale Variablen
2.) Temporäre Register
3.) Lokale Variablen

Die Variablen bekommen mit z.B.

.DEF counter = R20

möglichst sinnvolle Namen.

Für die lokalen Variablen, kann man ja Register recyclen, so daß man in einem Unterprogramm

.DEF counter = R20

im nächsten

.DEF flag = R20

und in einem dritten vielleicht

.DEF reminder = R20

definiert. (Entsprechendes für andere Register).

Der Assembler quittiert solches Vorgehen mit einer Wahrnung. Das ist ein Punkt, den ich gerne vermieden hätte.
Mir scheint es ein wenig aufwändig, alle .DEF's durch entsprechende .UNDEF's wieder aufzuheben. Gibt es da einen anderen Trick?
Wie geht Ihr da vor?

Weiter hätte ich gerne gewußt, wo Ihr diese .DEF's für lokale Variablen unterbringt, alle im Hauptprogramm oder bei den Unterprogrammen?

Ich tendiere zu letzterem, da ich ohnehin funktionell zusammenhängende Routinen in eigenen Dateien unterbringe und dort dann auch die lokalen Variablen definieren kann. Nur dort würde die .DEF ... .UNDEF Geschichte funktionieren. Andererseits hat man nur im Hauptprogramm den Überblick, welche Register überhaupt noch frei sind für den einen oder anderen Zweck.

 

[dino03]

Hallo,

Für die lokalen Variablen, kann man ja Register recyclen, so daß man in einem Unterprogramm

.DEF counter = R20

im nächsten

.DEF flag = R20

und in einem dritten vielleicht

.DEF reminder = R20

definiert. (Entsprechendes für andere Register).

Der Assembler quittiert solches Vorgehen mit einer Wahrnung. Das ist ein Punkt, den ich gerne vermieden hätte.
Mir scheint es ein wenig aufwändig, alle .DEF's durch entsprechende .UNDEF's wieder aufzuheben. Gibt es da einen anderen Trick?
Wie geht Ihr da vor?

so einen Kram fange ich garnicht erst an weil man damit spätestens bei InterruptServiceRoutinen den Überblick vollständig verliert. Ist aber wohl Geschmackssache

Meiner Meinung nach wird es sehr unübersichtlich wenn man ein Register im Projekt mit 20 verschiedenen Namen anspricht.

Gruß
Dino

 

[Dirk]

Hallo zusammen,

... so einen Kram fange ich garnicht erst an weil man damit spätestens bei InterruptServiceRoutinen den Überblick vollständig verliert. Ist aber wohl Geschmackssache

Meiner Meinung nach wird es sehr unübersichtlich wenn man ein Register im Projekt mit 20 verschiedenen Namen anspricht.

Dinos Meinung teile ich auch.

Ich würde es möglichst vermeiden, für ein Register unterschiedliche Namen zu verwenden. ... ist aber sicherlich - wie Dino schon sagte - Geschmacksache.

Dirk

 

[wer]

Hallo zusammen,


Dinos Meinung teile ich auch.

Ich würde es möglichst vermeiden, für ein Register unterschiedliche Namen zu verwenden. ... ist aber sicherlich - wie Dino schon sagte - Geschmacksache.

Dirk

Gut, diese Problematik ist mir klar. Aber was ist die Alternative?
Irgendwann hat man ja eine Sammlung von Unterprogrammen mit spezifischen Namen für die verwendeten Register. Diese Unterprogramme will man ja möglichst einfach einsetzen und nicht erst alle Register zuordnen.

 

[LotadaC]

Was meinst Du mit "Sammlung von Unterprogrammen"? Innerhalb eines Programmes, oder als Bibliothek etc. für verschiedene Programme?
Beim ersten vergebe ich Namen für global festgelegte Register, wenn ein Register in unterschiedlichen Unterprogrammen unterschiedliche Funktionen hat, ist das halt ein universelles Register, und bekommt keinen spezifischen Namen.
Beim zweiten bleibe ich bei den nativen Registernamen (R0 - R31), und im Kopf des Unterprogrammes wird ordentlich dokumentiert, welche Register für was verwendet werden.
P.S.: Wenn Du einem Register mit .def einen Namen gegeben hast, kannst Du es trotzdem noch mit Rxx ansprechen.

 

[dino03]

Hallo,

Beim ersten vergebe ich Namen für global festgelegte Register, wenn ein Register in unterschiedlichen Unterprogrammen unterschiedliche Funktionen hat, ist das halt ein universelles Register, und bekommt keinen spezifischen Namen.

So in der Art mache ich das auch.

Beim zweiten bleibe ich bei den nativen Registernamen (R0 - R31), und im Kopf des Unterprogrammes wird ordentlich dokumentiert, welche Register für was verwendet werden.
P.S.: Wenn Du einem Register mit .def einen Namen gegeben hast, kannst Du es trotzdem noch mit Rxx ansprechen.

Beim Einsprung in das Unterprogramm sollte man sowieso alle lokal verwendeten Register vorher auf dem Stack retten und danach wieder zurückschreiben. Damit ist es sowieso recht egal was für einen Zweitnamen man dem Register gibt. Man könnte es also gleich komplett lassen und die normalen Registernamen verwenden.

Grundsätzlich halte ich es so das ich mir mal ausgedacht habe wofür ich bestimmte Register verwenden will. Das halte ich dann in allen Programmen und Schnipseln durch. Temporäre Register muß man wie gesagt sowieso sichern wenn man ins Unterprogramm springt. Ganz wichtig ist das bei ISRs. Da muß zusätzlich noch das Statusregister gesichert werden.

Alle Werte die im Programm global verwendet werden und länger Bestand haben sollen lager ich in SRAM-Zellen. Den Zellen habe ich dann bestimmte Aliase verpaßt. Wenn dann in Routinen diese Werte benötigt werden dann werden die aus den SRAM-Zellen in die Register geladen. Also so wie bei Variablen.

Alles in den Registern zu halten ist eigentlich nicht wirklich sinnvoll. Benötigen tut man sowas eigentlich nur bei sehr zeitkritischen Routinen oder wenn man sehr kleine Tinys verwendet die sowieso kaum SRAM haben und wo es grade so für den Stack ausreicht.

Gruß
Dino

 

[Dirk]

Irgendwann hat man ja eine Sammlung von Unterprogrammen mit spezifischen Namen für die verwendeten Register. Diese Unterprogramme will man ja möglichst einfach einsetzen und nicht erst alle Register zuordnen.

Also es ist durchaus sinnvoll, für komplexere Unterprogramme symbolische Namen für die Register zu definieren. Diese würde ich direkt über der entsprechenden Routine mit .DEF festlegen.

Direkt zu deiner Frage: Leider kenne ich selber keine Lösung (ausser vielleicht mit UNDEF), wie man die Warnung des Assemblers unterdrücken kann. Wenn das bei mir vorkommt, ignoriere ich diese Warnung.

Wenn ich Unterprogramme schreibe, versuche ich bei meinen einmal festgelegten symbolischen Namen zu bleiben. Symbolische Namen nutze ich grundsätzlich, ich arbeite nie mit den originalen Registernamen. In der Regel sind diese bei mir dann auch bei unterschiedlichen Programmen gleich. Die DEF befinden sich bei Programmstart (ich habe hier also so eine Art Template, ein Grundgerüst).

Dirk

 

[oldmax]

Hi
So wirklich verstehe ich diese Vorgangsweise nicht. Immerhin reden wir hier von Assembler. Was nützt es mir, wenn ein Register unter verschiedenen Namen aufrufbar ist, ich dennoch die gleiche Speiceradresse verändere. Bei einer Hochsprache, klar, da ist eine lokale Variable keine globale Varaiable und hat ihren eigenen, wenn auch nur temporären Speicherplatz. In einem Assembler ist mir nicht bekannt, das es wirkliche "Lokale" Variablen gibt. Klar, kann ich machen, wenn ich Aufrufe in Unterprogramme lokale Variablen mit auf den Stack packe. Dann hab ich wirklich Speicherzellen, die nur für den Moment des Unterprogrammes gültig sind. Doch diese Mechanismen sind nicht grad einfach und auch nicht erforderlich. Zumindest sehe ich keine Notwendigkeit, einem Mikrocontroller solch eine Struktur aufzuzwingen

CALL UP
  LD  x, Sp      X-Register mit Stackpointer laden
  Push rx        4 Bytes für lokale Variablen reservieren
  Push rx
  push rx
  push rx


 
  ....
  POP rx
  POP rx
  pop rx
  pop rx
ret

Das ist jetzt nich ausführbarer Code, aber so in etwa funktioniert die Reservierung lokaler Variablen einer Hochsprach. Für Assembler macht das keinen Sinn.
Oder hab ich da etwas mißverstanden. Wenn es nur darum geht, innerhalb einer Sub ein Register anders zu benennen, wozu. Die Adresse eines Register ist fest "verdrahtet" und wird duch eine lokale "Umbenennung" nicht nochmal irgendwo im Speicher erzeugt.
Gruß oldmax

 

[Dirk]

Hallo Oldmax,

... Was nützt es mir, wenn ein Register unter verschiedenen Namen aufrufbar ist, ich dennoch die gleiche Speiceradresse verändere...

wenn du eine komplexe Routine hast, ist es eventuell sinnvoll, symbolische Namen für Register zu verwenden, um eher die Übersicht zu behalten. Du kannst natürlich auch bei den Registernamen bleiben, genauso wie du in C folgendermaßen Variablen benennen kannst: a1, a2, a3 usw. anstellen von TemperaturKanal1, Motordrehzahl usw.

Es kommt eben auf das Unterprogramm drauf an. Wenn man symbolische Namen verwendet, hat man zudem die Möglichkeit, einfach die Registerzuordnung zu den Namen zu ändern. Das kann u. U. vorteilhaft sein.

Es macht schon Sinn, symbolische Namen zu verwenden! Bei kleineren Programmen, die übersichtlicher sind und keine "fremden Routinen" enthalten, macht es sicherlich weniger Sinn.

Dirk

 

[wer]

Hi
So wirklich verstehe ich diese Vorgangsweise nicht. Immerhin reden wir hier von Assembler. Was nützt es mir, wenn ein Register unter verschiedenen Namen aufrufbar ist, ich dennoch die gleiche Speiceradresse verändere. Bei einer Hochsprache, klar, da ist eine lokale Variable keine globale Varaiable und hat ihren eigenen, wenn auch nur temporären Speicherplatz. In einem Assembler ist mir nicht bekannt, das es wirkliche "Lokale" Variablen gibt. Klar, kann ich machen, wenn ich Aufrufe in Unterprogramme lokale Variablen mit auf den Stack packe. Dann hab ich wirklich Speicherzellen, die nur für den Moment des Unterprogrammes gültig sind. Doch diese Mechanismen sind nicht grad einfach und auch nicht erforderlich. Zumindest sehe ich keine Notwendigkeit, einem Mikrocontroller solch eine Struktur aufzuzwingen

CALL UP
  LD  x, Sp      X-Register mit Stackpointer laden
  Push rx        4 Bytes für lokale Variablen reservieren
  Push rx
  push rx
  push rx


 
  ....
  POP rx
  POP rx
  pop rx
  pop rx
ret

Das ist jetzt nich ausführbarer Code, aber so in etwa funktioniert die Reservierung lokaler Variablen einer Hochsprach. Für Assembler macht das keinen Sinn.
Oder hab ich da etwas mißverstanden. Wenn es nur darum geht, innerhalb einer Sub ein Register anders zu benennen, wozu. Die Adresse eines Register ist fest "verdrahtet" und wird duch eine lokale "Umbenennung" nicht nochmal irgendwo im Speicher erzeugt.
Gruß oldmax

Nein! Mir geht es jetzt nicht darum lokale Variablen auf dem Stack zu erzeugen.
Ich suche nur einen Weg, meine Register je nach Unterprogramm passend zu benennen und dabei nicht die Übersicht zu verlieren.
Sicher kann ich grundsätzlich alle lokal genutzten Register über den Stack sichern. Falls ich jedoch immer eine bestimmte Gruppe von Registern (z.B. R20 - R25) für diesen Zweck reserviere, dann brauch ich noch nicht einmal das. Ich kann das dann machen, wenn ich kein lokales Register mehr frei habe und ich doch auf ein global genutztes zurückgreifen muß, aber ich muß das nicht grundsätzlich tun. In jedem Falle hätte ich aber gerne die Möglichkeit, diese Register je nach Unterprogramm anders zu benennen.

Ähnlich ist das mit einer Gruppe von Registern, die für die Parameterübergabe an die Unterprogramme benötigt werden. Im Moment denke ich, daß diese Register (z.B R16 - R19) auch im Hauptprogramm als temporäre Register genutzt werden können. Dort heißen sie dann vielleicht temp1 .. temp4. Wenn ich sie dann z.B. zur Parameterübergabe an eine Divisionsroutine nutzen will, dann würde ich sie gerne Divisor, DividentHigh und DividentLow nennen. In einem anderen Unterprogramm z.B. zur Ausgabe von Texten über die serielle Schnittstelle sollten sie dann StringHigh und StringLow heißen, usw. Bei dieser Gruppe ist ein Warning des Assemblers auch mittels .UNDEF nicht vermeidbar, weil die entsprechenden Namen ja auch dem aufrufenden Programmteil bekannt sein müßten.

Ich hoffe, meine Frage ist jetzt verständlicher.

 

[oldmax]

Hi Dirk
Nicht, das ich Registern keine Namen gebe. Natürlich halte ich das für sehr sinnvoll, aber das ist auch nicht der Punkt. So wie ich dieses Thema verstanden habe, will WER ein Register temporär lokal in einer Sub-Routine einen anderen Namen geben.
Ich habe grundsätzlich drei verschiedene Gruppen von Variablen, die ich alle in Registern halten will:

Ich habe grundsätzlich drei verschiedene Gruppen von Variablen, die ich alle in Registern halten will:
1.) Globale Variablen
2.) Temporäre Register
3.) Lokale Variablen

Wozu? Die Adresse bleibt ein und dieselbe und es ist trügerisch zu glauben es handelt sich dann um ein lokal gültiges Register.

Die Variablen bekommen mit z.B.

.DEF counter = R20

möglichst sinnvolle Namen.

Für die lokalen Variablen, kann man ja Register recyclen, so daß man in einem Unterprogramm

.DEF counter = R20

im nächsten

.DEF flag = R20

und in einem dritten vielleicht

.DEF reminder = R20

Es sind doch nicht wirkliche Variablen, es sind Register ! Ein Register ist eine Speicherzelle, die Funktionen durchführen kann und deshalb nur temporär gültige Inhalte hat. Es sei denn, man "verschwendet" diese intelligenten Speicherzellen direkt für Variablen. Eine Variable ist in der Regel eine "dumme" Speicherzelle und deren Wert ist für ihren Namen gültig. Das brauch ich den Experten hier nicht zu erzählen, aber korrigiert mich wenn ich da falsch liege. Im Programm wird lediglich mit
LDS Counter, Real_Variable
eine Speicherzelle in das Register R20 kopiert. Ich sehe da kein neues Register R20. Auch Flag und Remeiner überschreiben sich gnadenlos gegenseitig ihre Werte. Aber vielleicht hab ich dedn Zusammenhang auch falsch verstanden und liege daneben. Ehrlich gesagt, wie ein Programmierer sein Programm aufsetzt ist seine Handschrift und persönliche Note. Darauf wird er irgendwann einmal sehr stolz sein. (oder auch nicht ...) Dem Anwender ist es egal, er will ein funktionierendes preiswertes Programm. Welchte Tricks, Kniffe und auch welcher Stil im Programm enthalten ist, können bestenfalls Kollegen erkennen und sich dafür interessieren.

Gruß oldmax

 

[wer]

Ich sehe da kein neues Register R20. Auch Flag und Remeiner überschreiben sich gnadenlos gegenseitig ihre Werte.

Natürlich ist da kein neues Register.

Ich betrachte ein ganz einfaches Szenario: Ein Hauptprogramm, viele Unterprogramme, keine verschachtelten Aufrufe, keine Rekursionen.

In dieser Situation kann Flag Reminder gerne überschreiben und umgekehrt, denn sie sind nie zur gleichen Zeit aktiv.

Aber oldmax, ich hab immer noch nicht verstanden, wie Du das machst. Stell Dir vor, Du merkst, daß Du irgendwann während eines laufenden Projektes ein Unterprogramm brauchst, daß Du schon mal geschrieben hast. Was tust Du dann? Du kopierst den Code in Dein laufendes Projekt und paßt alle Register so an, daß sie nicht mit den bisher verwendeten kollidieren, oder was?