the_muck
Danke für die Bestätigung, the_muck – deckt sich exakt mit unseren Tests. Ich habe das zusammen mit Claude (KI-Unterstützung bei Testaufbau und Auswertung) durchgetestet. Kurze Zusammenfassung, was wir jetzt sauber (mit echten Signalen, ohne Force, mehrfach gegengeprüft) herausgefunden haben:
SHL_BLK adressiert S_DATA und D_DATA grundsätzlich byteweise, nicht bitweise. Der angegebene Bit-Index innerhalb des Bytes wird komplett ignoriert – egal ob S_DATA und D_DATA im selben oder in unterschiedlichen Speicherbereichen liegen (%M, %V, ...). Effektiv wird immer Bit .0 des adressierten Bytes verwendet, ohne jede Fehlermeldung. Der Compiler lässt jede Bit-Adresse durch, zur Laufzeit tut sie aber nur bei .0 das Erwartete.


Wir haben das über viele A/B-Tests durchprobiert: gleicher Bereich/unterschiedlicher Bereich, mit/ohne Force, verschiedene S_N-Werte – das Muster ist immer dasselbe. .0 funktioniert, .1–.7 werden stillschweigend als .0 desselben Bytes behandelt.
Im Handbuch steht dazu nichts Konkretes, nur der Hinweis "S_DATA, D_DATA is the starting address of a memory block... must be in the legal memory area, otherwise the consequences may be terrible" – und das einzige offizielle Beispiel nutzt ausschließlich .0-Adressen.
Workaround: S_DATA und D_DATA immer auf Bit .0 legen (z. B. per Selbstreferenz-Trick S_DATA = D_DATA), den eigentlichen Wert danach über ein separates Network reinschreiben.