Statische Variablen funktionieren nicht mehr nach LOOP

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

TAR2 #temp_AR2
ist diese TEMP oder STAT? Ich gehe von STAT aus....

TEMP reicht.
Warum wohl hat Züttu die Variable #temp_AR2 genannt?

Harald

 

[trinkiwinki]

TEMP reicht.
Warum wohl hat Züttu die Variable #temp_AR2 genannt?

Harald

OK hast recht....Entschuldigung

ABer so kann ich es nicht schreiben:

TAR2 #temp_AR2 'Temp_AR2 wird ROT

Muß das evtl. so heißen:

L #temp_AR2
TAR2

?

Gruß

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hast Du eine TEMP-Variable "temp_AR2" als DWORD angelegt?

Harald

 

[trinkiwinki]

Hast Du eine TEMP-Variable "temp_AR2" als DWORD angelegt?

Harald

Ja. Halt noch im STAT Bereich, aber das sollte ja eigentlich keine ROlle spielen....
Gruß

 

[Züttu]

Das spielt sehr wohl eine Rolle, denn du weisst nicht mehr wo dein STAT-Register liegt, das steht ja in temp_AR2. Wenn du temp_AR2 im TEMP anlegst wird auch der Aufruf nicht mehr rot

 

[trinkiwinki]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das spielt sehr wohl eine Rolle, denn du weisst nicht mehr wo dein STAT-Register liegt, das steht ja in temp_AR2. Wenn du temp_AR2 im TEMP anlegst wird auch der Aufruf nicht mehr rot

Alles klar. Ist nun in Ordnung.


DANKE vielmals an alle, die mir geholfen haben, das zu verstehen.......


Gruß

Marco

 

[PN/DP]

Doch, das spielt eine Rolle. Es darf nicht STAT sein.
LAR2 #temp_AR2 wäre sogar gar nicht möglich, wenn temp_AR2 in STAT liegen würde.

Was sagt die Fehlermeldung zur rot markierten Zeile?: "Anweisung nicht erlaubt für AR1/AR2-Befehls-Operanden"

Auch wichtig:

...
LAR2 #Offset_adress_DB40
...
[COLOR="Red"]// hier kann nicht auf STAT-Variablen zugegriffen werden![/COLOR]
...
LAR2 #temp_AR2
// erst wieder ab hier

Harald

 

[SPSKILLER]

Kannste nicht ganz eindeutig schreiben, daß Dein Beitrag #10 ein Witz war?
Der Beitrag wird wohl von einigen Lesern für bare Münze genommen werden.

Harald

Hey Harald,

was soll die scheiss Anmache?

Nicht mal du als "push" User (wird ja immer als besonders nützlich hervorgerufen *ROFL*) kannst leugnen, dass mein Beitrag #10 richtig ist ist.

Du bist nur der gleiche Depp wie ich, der da niemals drauf gekommen wäre.
Es funktioniert so, und es ist ohne Multiinstanz einfach kürzer als das AR2 zu retten.

Du legst du ja immer wert drauf den kürzesten Code zu posten.

Alle weiterne Einschränkungen hatte ich bereits geschildert.

Ich hoffe mal, dass dein Image des besten Programmierers unter der Sonne dadurch nicht allzu sehr leidet...

Micha

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kannste nicht ganz eindeutig schreiben, daß Dein Beitrag #10 ein Witz war?
Der Beitrag wird wohl von einigen Lesern für bare Münze genommen werden.

Harald

Hey Harald,

was soll die scheiss Anmache?

Nicht mal du als "push" User (wird ja immer als besonders nützlich hervorgerufen *ROFL*) kannst leugnen, dass mein Beitrag #10 richtig ist ist.

Du bist nur der gleiche Depp wie ich, der da niemals drauf gekommen wäre.
Es funktioniert so, und es ist ohne Multiinstanz einfach kürzer als das AR2 zu retten.

Du legst du ja immer wert drauf den kürzesten Code zu posten.

Alle weiterne Einschränkungen hatte ich bereits geschildert.

Ich hoffe mal, dass dein Image des besten Programmierers unter der Sonne dadurch nicht allzu sehr leidet...

Micha

Hallo Micha,

was soll denn jetzt Deine echte "scheiss Anmache"?
Ich war ehrlich davon überzeugt, daß Dein Beitrag #10 nur ein Witz sein kann.

(ich geh davon aus, dass hinter TAR1 und TAR2 noch ne variable steht ...)

nee. sicher net.

Das mit dem Beschreiben der ARs hinter dem Loop ist eigentlich genial, solange der Baustein nicht als Multiinstanz verwendet wird.

Da bin ich in 15 Jahren nicht drauf gekommen...

Mit Programmiererfahrung kann man doch nicht wirklich glauben, daß LAR1 + LAR2 hinter LOOP irgendwas sinnvolles bewirkt, außer
die ARs auf 0 zu schreiben. Mit retten und und wieder herstellen hat das überhaupt nichts zu tun ... es ist noch nicht mal besonders
kurz, weil komplett überflüssig. Also ich leugne ausdrücklich, daß an solchem Code irgend etwas richtig ist und funktioniert.

4L hat ja versucht, Dir diplomatisch und schonend beizubringen, daß Du auf dem Holzweg bist, falls Dein Beitrag ernst gemeint war.

Es ging trinkiwinki im Übrigen gerade darum, wegen Multiinstanz die Adressregister zu retten und wieder herzustellen.

Weil kürzlich in einem anderen Thread ein User (angeblich mit vollem Wissen) einen nicht richtig funktionierenden Beispielcode postete,
der zum STOP der CPU führen kann, habe ich Dich einfach gebeten, Deinen vermeintlichen Witz aufzuklären.

Und was Deine weiteren Ausflüsse angeht:
Willst Du nicht am Freitag zum Forum-Stammtisch nach Bielefeld kommen? Da könnten wir schön ein Bier zusammen trinken und Du sagst
mir mal ins Gesicht, was Dir an mir nicht passt (gut programmieren können ist doch kein Übel).
Vielleicht kann ich ja mein Auftreten hier noch verbessern.

:sm24:
Prost
Harald

 

[Perfektionist]

Damit auch ich das nun endlich begreife ...

Ich dachte, es ist so, dass AR1 zur freien Verfügung steht. Wenn ich also garnicht erst mit AR2 rumhantiere, dann ich auch keine Falle stelle, wo vorübergehend der Zugriff auf die Lokaldaten fehl geht, da man ja AR2 in einem multiinstanzfähigen Baustein verbogen hat. Fazit: wenn man mit einem Quell- und Zielzeiger arbeiten muss, läd man die, wenn auch laufzeituneffektiver, wechselseitig in AR1. Und lässt die Codeakrobatik mit AR2 bleiben, um nicht in die Falle zu treten, dass während verbogenem AR2 der Zugriff auf Lokaldaten in die Hose geht.

... und irgendwie ist das dann doch sinnvoll, in AR2 eine Null zu laden, wenn, ich will es mal Root-Instanz nennen, wenn also der Baustein wie in dem gezeigten Fall auf eine Root-Instanz zugreift. Sowie in AR2 ein Offset steht, weil der gerade bearbeitete Baustein mit einer Multiinstanz aufgerufen wurde, ist es natürlich nicht mehr sinnvoll, dann AR2 mit Null zu füttern. Gut - der Beispielcode, der da die Null in AR2 läd, ist nicht mit voller Absicht entstanden.

 

[Perfektionist]

zur multiinstanzfähigkeit muß noch gesagt werden, dass das AR1 um das AR2 zum bausteinstart erhöht werden muß.

Dafür Danke. Den Aspekt habe ich zwar irgendwo schonmal gelesen, wäre aber sicher erstmal drüber gestolpert, hätte ichs dann selbst machen sollen. Bislang hab ich halt nur in Nicht-Multiinstanzen rumgepointert. (Vielleicht sollte ich mal wieder die FAQ des Forums durchgehen.)

 

[SPSKILLER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Und was Deine weiteren Ausflüsse angeht:
Willst Du nicht am Freitag zum Forum-Stammtisch nach Bielefeld kommen? Da könnten wir schön ein Bier zusammen trinken und Du sagst
mir mal ins Gesicht, was Dir an mir nicht passt (gut programmieren können ist doch kein Übel).
Vielleicht kann ich ja mein Auftreten hier noch verbessern.

ich bin grad in Polen zur IBN.
Deshalb scheidet der Vorschlag leider aus.
Ausserdem habe ich nix gegen dich, ich kenn dich doch überhaupt nicht.

Es kommt bei deinen Beiträgen halt oft der Klugscheisser rüber.
Das ist meine Meinung.
Wem das nicht passt, sorry.

Ich meine hier NIX persönlich.

Jetzt noch mal fachlich:

Mit Programmiererfahrung kann man doch nicht wirklich glauben, daß LAR1 + LAR2 hinter LOOP irgendwas sinnvolles bewirkt, außer
die ARs auf 0 zu schreiben. Mit retten und und wieder herstellen hat das überhaupt nichts zu tun ... es ist noch nicht mal besonders
kurz, weil komplett überflüssig. Also ich leugne ausdrücklich, daß an solchem Code irgend etwas richtig ist und funktioniert.

Das hat sehr wohl was mit "wieder herstellen" zu tun.
In einem FB, der nicht als Multiinstanz aufgerufen wird ist AR2 beim Aufruf 0.
Wenn das AR2 während der Bearbeitung des FBs verändert wird (im Beispiel hier in der Schleife), dann muss es mit P#0.0 restauriert werden - wenn danach noch auf Instanzdaten zugegriffen werden soll.
P#0.0 ist auch nur ne 0 im Akku 1, deshalb kann man direkt nach der Schleife einfach LAR2 schreiben um AR2 wieder auf 0 zu setzen.
AR1 zu retten ist Quatsch. Brauchts nicht.

Was soll jetzt daran nicht funktionieren

Es ist nur so wie der Perfektionist geschrieben hat:

Gut - der Beispielcode, der da die Null in AR2 läd, ist nicht mit voller Absicht entstanden.

Ich wollte eigentlich nur sagen, dass ich nicht auf die Idee gekommen wäre mein AR2 so zu "nullen". Dazu muss man anders denken.

Bevor jetzt wieder jemand draufhaut: Klar kann eine Schleife durch einen Sprung verlassen werden, wodurch der Zähler nicht auf 0 runterläuft, aber das interessiert in dem Beispiel nicht.

@Perfektionist

Du hast das schon verstanden!
Aber das Verbiegen des AR2 ermöglicht trotzdem Lokaldatenzugriffe, man kann die Variablen der Instanz aber nur noch indirekt ansprechen...

Micha

 

[vierlagig]

*räusper* ... man muß natürlich sicherstellen, dass der AKKU auch wirlich 0 ist ...

 

[SPSKILLER]

was soll da in dem Beispiel denn sonst drin stehen?

 

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

was soll da in dem Beispiel denn sonst drin stehen?

in dem beispiel nicht viel, aber soll auch fälle geben, in denen man eine schleife vorzeitig bedingt verlässt ...

mir ist das ja sowieso alles wurscht, ich schreib FBs grundsätzlich MI-fähig...

 

[SPSKILLER]

mann, ich hab gewusst, dass das kommt
Lies mal #32 richtig!

 

[vierlagig]

mann, ich hab gewusst, dass das kommt
Lies mal #32 richtig!

ja, da ist der verweis auf die 0 nach der schleife drin, aber es ist eben nicht nach jeder schleife 0

 

[SPSKILLER]

Zuviel Werbung?
-> Hier kostenlos registrieren

noch mal für dich:

Bevor jetzt wieder jemand draufhaut: Klar kann eine Schleife durch einen Sprung verlassen werden, wodurch der Zähler nicht auf 0 runterläuft, aber das interessiert in dem Beispiel nicht.

 

[PN/DP]

ich bin grad in Polen zur IBN.
Deshalb scheidet der Vorschlag leider aus.

Das ist schade. Vielleicht laufen wir uns irgendwann mal über den Weg, dann steht mein Angebot mit dem Bier und dem Unterhalten.

Es kommt bei deinen Beiträgen halt oft der Klugscheisser rüber.

Tja, das ist schon seit meiner Schulzeit mein Problem, daß andere Leute mein Besser-Wissen und meinen Hang zur Perfektion als Klugscheisserei empfinden.
Deshalb korrigiere ich andere Leute normalerweise nur noch, wenn ich direkt gefragt werde. Hier im Forum fühle ich mich direkt gefragt.
Ich war bisher der Meinung, daß meine Beiträge überwiegend nützlich waren und oft neues nicht allgemein vorhandenes Wissen und Knowhow rüberbringen.

Das ist meine Meinung.
Wem das nicht passt, sorry.

Ich habe nicht gesagt, daß mir Deine Meinung nicht passt. Ich habe eher gefragt, was Dir an mir nicht passt. Was Du ja nun beantwortet hast.
Hier im Forum kann zum Glück jeder seine Meinung schreiben - wenn er das Echo verträgt.

Ich meine hier NIX persönlich.

Dies hier klingt aber doch ein bißchen persönlich:

Ich hoffe mal, dass dein Image des besten Programmierers unter der Sonne dadurch nicht allzu sehr leidet...

Jetzt noch mal fachlich:

Das hat sehr wohl was mit "wieder herstellen" zu tun.
In einem FB, der nicht als Multiinstanz aufgerufen wird ist AR2 beim Aufruf 0.
Wenn das AR2 während der Bearbeitung des FBs verändert wird (im Beispiel hier in der Schleife), dann muss es mit P#0.0 restauriert werden - wenn danach noch auf Instanzdaten zugegriffen werden soll.

Das ist nicht ganz richtig.
Das AR2 ist beim FB-Aufruf DW#16#84000000 = P#DBX0.0 . Später P#0.0 in AR2 schreiben ist genau genommen keine korrekte Restauration.
Doch zum Glück wird beim Zugriff auf Multi-Instanzdaten die Bereichskennung im AR2 ignoriert und immer durch DIB (16#85..) ersetzt.

In einem Nicht-Multiinstanz-fähigen FB wird das AR2 gar nicht für den Zugriff auf die Instanzdaten verwendet.
AR2 kann beliebig manipuliert werden und ein wieder-Herstellen wegen Zugriff auf Instanzdaten ist folglich überflüssig.

Der Code in einem Multiinstanz-fähigen FB muß imho immer Multiinstanz-verträglich programmiert sein (auch wenn er momentan nicht als
Multiinstanz verwendet wird), was bei Benutzung des AR2 ein korrektes wieder-Herstellen erfordert.
Einfach P#0.0 (oder P#DBX0.0) in AR2 schreiben ("ich weiß ja, daß ich diesen Multiinstanz-fähigen Baustein NIE als Multiinstanz benutze") ist
imho nicht korrekt, auch wenn es in dem speziellen Fall funktioniert.

Wenn man einen FB schreibt, der nicht als Multiinstanz verwendet werden soll, dann sollte man den auch als "nicht Multiinstanz-fähig" anlegen.
Netter Nebeneffekt: der MC7-Code des Bausteins wird dann kürzer.

AR1 zu retten ist Quatsch. Brauchts nicht.

Das will ich nicht so allgemein stehen lassen.
Das AR2 wird beim Aufruf eines anderen FB automatisch gesichert und wieder hergestellt, das AR1 aber nicht.
Wird nun in einem Baustein A, der AR1 benutzt, ein weiterer Baustein B aufgerufen, der ebenfalls das AR1 benutzt, dann erwarte ich, daß der
Baustein B das AR1 unverändert an Baustein A zurückgibt - das AR1 also ggf. sichert und restauriert.

Es kann nicht schaden, Bausteine immer so zu programmieren, daß man bei Nutzung dieser Bausteine nicht erst deren Code durchlesen muß,
um zu sehen, ob diese mit dem aufrufenden Baustein verträglich sind.

Ich wollte eigentlich nur sagen, dass ich nicht auf die Idee gekommen wäre mein AR2 so zu "nullen". Dazu muss man anders denken.

Bevor jetzt wieder jemand draufhaut: Klar kann eine Schleife durch einen Sprung verlassen werden, wodurch der Zähler nicht auf 0 runterläuft, aber das interessiert in dem Beispiel nicht.

Wenn ich tatsächlich mal das AR2 nach einer Schleife "nullen" wollte oder ganz allgemein an irgendeiner Programmstelle einen bestimmten Wert
im AKKU1 brauche, aber nicht extra laden will, weil dieser Wert glücklicherweise schon drin steht, dann schreibe ich das Laden dieses Wertes
als auskommentierte Zeile dazu. Dann beachte ich diese Bedingung, wenn ich später mal den Code ändern muß:

      ...
      LOOP  lop1
[COLOR="DarkGreen"]//      L     P#0.0       //P#0.0 steht schon im AKKU1[/COLOR]
      LAR2

So, nun aber auf nach Bielefeld.
Harald

 

[Perfektionist]

Vorweg: es regt sich bei mir der Widerspruchsgeist, obwohl ich 99% von dem Geschriebenen für richtig befinde.

Das will ich nicht so allgemein stehen lassen.
Das AR2 wird beim Aufruf eines anderen FB automatisch gesichert und wieder hergestellt, das AR1 aber nicht.
Wird nun in einem Baustein A, der AR1 benutzt, ein weiterer Baustein B aufgerufen, der ebenfalls das AR1 benutzt, dann erwarte ich, daß der
Baustein B das AR1 unverändert an Baustein A zurückgibt - das AR1 also ggf. sichert und restauriert.

Werden die Flags automatisch gesichert? Die Akkus werden jedenfalls nicht automatisch gesichert. Das ist sicherlich ein schöner Dienst, den ein FB einem erweisen kann, indem er das AR1 unangetastet lässt. Da mir aber als aufrufender Baustein bewusst sein muss, dass auch dem aufgerufenen Baustein das AR1 zur Verfügung steht und ich als Aufrufender weiss, dass der Aufgerufene mit Akku, Flags und AR1 tun und lassen darf, was er will, muss ich mich selbst vor Aufruf drum kümmern, dass ich meine Werte rette.

Dass das AR2 automatisch gesichert wird ist dem Umstand geschuldet, dass das AR2 dem Anwenderprogramm nicht wirklich zur Verfügung steht. Wenn jemand das AR2 sichert, dann damit hantiert und es danach restauriert, dann hat er sich das AR2 nur vorübergehend vom System ausgeliehen.