Adressregister retten, wozu ?

Outrider

Level-1
Beiträge
745
Reaktionspunkte
5
Zuviel Werbung?
-> Hier kostenlos registrieren
Häufig sehe ich den Befehl TAR1 oder TAR2 am Beginn eines Bausteins.
Der Befehl bedeutet Transferiere Adressregister 1 oder 2 in Akku 1.
und am Ende dan LAR1 oder LAR2

Warum das Ganze ?

Häufig wird der Begriff "retten" benutzt, das assoziiert dass etwas nachher wieder zurückgebracht wird.
Wenn ich aber zwischendurch Akkuoperation durchgeführt habe, wie kann ich dann etwas "retten", im Akku steht dann nicht mehr das Alte !
Gruß und Danke für Infos
 
Hallo Outrider,
da hast du die Hälfte der Befehle weggelassen. Es geht:
TAR1
T save_AR1
und dann
L save_AR1
LAR1

Das macht man, damit man das Adressregister innerhalb des Bausteins zur Pointerberechnung verwenden kann.

Gruß Kaulquappe
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Re Adressregister

Mir ist schon klar dass die Register intern zur Pointerberechnung genutzt werden, aber warum wird am Anfang der Inhalt gerettet !
Der Inhalt wird in den Akku geschrieben, wenn ich inder FC aber AKKU operationen verwende dann ist das gerettete verloren oder...?
Oder darf ich nach dem Retten keine Akkuoperationen ausführen ?
Müsste eigentlich nicht vom System zwangsläufig am Ende eines FC oder FBs eine Rettung stattfinden damit das Register im nächsten FC oder FB frei für den Gebrauch ist ?

Viele Fragen sind da.
Gruß
 
Dann war ich wohl etwas zu kurz angebunden: Das Adressregister lässt sich nicht direkt in eine statische Variable transferieren. Deshalb lädt man es erst in den Akku und dann überträgt man den Wert des Akkus in die statische Variable (in meinem Beispiel save_AR1). Und dann kann mal sowohl mit dem Adressregister als auch mit dem Akku machen was man möchte und stellt sicher, dass bei Verlassen des Bausteins wieder alles ist wie vorher.

Noch ein Nachtrag:
Wenn ein FB in einem zeitgesteuerten OB aufgerufen wird, schlägt er ja beliebig im OB1 ein. Und da sind AR1 und AR2 die Pointer auf einen Daten-DB und einen Instanz-DB. Und die sollen ja bei verlassen wiederhergestellt werden.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Der Nachtrag ist so nicht richtig. Beim Aufruf eines höherprioren OBs (z.B. ein Zeit-OB der den OB1 unterbricht) werden alle Register gerettet und zum Abschluß wiederhergestellt, so dass der unterbrochene OB hiervon nichts bemerkt. Das macht das Betriebssystenm der CPU, der Anwender muss sich darum nicht kümmern.
Das Sichern von insbesondere AR2 ist bei multiinstanzfähigen FBs notwendig, da AR2 auf den Anfang des Datenbereichs des jeweils aktiven FBs zeigt. Würde dieses überschrieben, so führten anschließend alle IN/OUT/INOUT/STAT Zugriffe innerhalb des FBs auf eine falsche Adresse im verwendeten Multiinstanz-DB.
 
Das Sichern von insbesondere AR2 ist bei multiinstanzfähigen FBs notwendig, da AR2 auf den Anfang des Datenbereichs des jeweils aktiven FBs zeigt. Würde dieses überschrieben, so führten anschließend alle IN/OUT/INOUT/STAT Zugriffe innerhalb des FBs auf eine falsche Adresse im verwendeten Multiinstanz-DB.

Das verstehe ich jetzt nicht. Ich habe jetzt glaub ich schon viele MultiinstanzFBs gebaut. Und diese auch in FBs als Multiinstanzen aufgerufen, teilweise 40 mal. Die haben alle einwandfrei funktioniert ohne das ich mich um Adressregisterrettung gekümmert habe? Was habe ich denn da automatisch richtig gemacht, dass es trotzdem funktioniert hat?

mfG René
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Scheint er nicht zu machen. Codeschnipsel eines SCL bausteins von Anfang an.

Code:
      SET   
      SAVE  
      =     L      0.1
      L     DID [AR2,P#10.0]
      SLD   8
      SAVE  
      SRD   11
      SAVE  
      PUSH  
      UD    DW#16#FFFF0000
      TAK   
      SPZ   I007
      CLR   
      =     L      0.1
I007: T     #DB_ACT_Byte
      CLR   
      U     L      0.1
      SAVE  
      L     DID [AR2,P#16.0]
 
Dieser hier gezeigte SCL-Baustein verändert aber nichts am AR2, deshalb ist ein sichern oder auch retten, ganz wie man mag nicht notwendig.
Er verwendet das AR2 hier nur also Offset um auf Daten der Instanz zuzugreifen, hier also z.B. AR2 + 8 Byte der Instanz.

Im AR2 steht standardmäßig der Offset des übergeordneten Instanz-DB.
d.h. Wenn du einen Multiinstanz-FB aufrufst, und die Instanz im Stat-Bereich startet z.B. bei DBB100, dann steht im AR2 hier also 100.0 drin.

Sollte durch den SCL-Baustein ein sichern oder ähnliches notwendig sein, dann kann man also davon ausgehen, das der Compiler das schon einbauen wird,
falls nicht ist es ein Bug im Compiler, aber nichts was man selbst beheben könnte.

Mfg
Manuel
 
Zuletzt bearbeitet:
Zurück
Oben