LowLevelMahn
Level-1
- Beiträge
- 766
- Reaktionspunkte
- 90
-> Hier kostenlos registrieren
Hintergrund:
Ich arbeite an einem (C/C++) Tool mit dem man Absolut-Offsets zu DB-Schema-Beschreibungen erstellen kann
und stütze mich dabei auf Tests mit Step7, TIA V11/12/13, MHJ etc.
mein Tool basiert auf sehr viele manuellen und automatischen Tests und ich kenne das
(nicht unbedingt triviale) Padding und Alignment-Verhalten von Typen in DBs sehr genau
Jetzt habe ich aber doch mal eine komische Ausnahme entdeckt die ich mir aus
Kompiler/Codegenerierung/Hardware-Sicht nicht wirklich erklären kann
Software: V12 SP1 Update 4
Standard: Alle Struktur-Typen wie Struct, UDT, STDs werden in unoptimierten DBs auf 16Bit ausgerichtet (aligned)
Es gibt den SDT "IP_V4" der die Daten einer IPv4-Addresse vorhalten/speichern kann:
1. Es ist eine Struktur und SDT -> 16Bit Ausrichtung
2. Er besteht aus einem Array[1..4] of Byte und ist daher (mit/ohne Padding) genau 4 Bytes lang
ein frei stehender "IP_V4" Typ (siehe Bild) wird so in einem Datenblock eingebaut wie in 1. und 2. beschrieben
und das Verhalten gilt für alle Struct-Artigen die ich je (sehr viele) gesehen habe
Jetzt wird es komisch:
Wenn man jetzt aber den Typ "TCON_IP_RFC" verwendet - der einen "IP_V4" beinhaltet wird
dieser "IP_V4" nicht auf eine 16Bit- sondern auf 32Bit-Grenze ausgerichtet - und zwar nur in diesem SDT
wenn ich das gleiche "TCON_IP_RFC"-Layout mit einem normalen Struct bauen kommt wieder
das Standardausrichtung auf 16Bit
Ich hab keine Ahnung ob es den "TCON_IP_RFC" auch in Step7 Classic gibt wenn ja - kann den einer mal benutzten und das Layout zeigen?
Ideen dazu?
Kann mir irgendjemand erklären was der Sinn dahinter sein soll - oder hat Siemens einfach mal das Alignment für
"IP_V4" in dem "TCON_IP_RFC"-Typ unnötig hart von Hand eingestellt? Technisch ist der Unterschied aus Performance-Sicht
unbedeutend, verbraucht (manchmal) einfach ein wenig mehr Speicher, aber warum dann diese Spezialisierung für diese EINE kleine Kombination
Bitte keine Erklärungen wie Alignment/Padding funktioniert oder was Kompiler können/dürfen - das ist mir alles
zu (100+x)% klar - und ja symbolische DBs sind an dieser Stelle nicht komisch - aber um die geht es hier nicht
Ich arbeite an einem (C/C++) Tool mit dem man Absolut-Offsets zu DB-Schema-Beschreibungen erstellen kann
und stütze mich dabei auf Tests mit Step7, TIA V11/12/13, MHJ etc.
mein Tool basiert auf sehr viele manuellen und automatischen Tests und ich kenne das
(nicht unbedingt triviale) Padding und Alignment-Verhalten von Typen in DBs sehr genau
Jetzt habe ich aber doch mal eine komische Ausnahme entdeckt die ich mir aus
Kompiler/Codegenerierung/Hardware-Sicht nicht wirklich erklären kann
Software: V12 SP1 Update 4
Standard: Alle Struktur-Typen wie Struct, UDT, STDs werden in unoptimierten DBs auf 16Bit ausgerichtet (aligned)
Es gibt den SDT "IP_V4" der die Daten einer IPv4-Addresse vorhalten/speichern kann:
1. Es ist eine Struktur und SDT -> 16Bit Ausrichtung
2. Er besteht aus einem Array[1..4] of Byte und ist daher (mit/ohne Padding) genau 4 Bytes lang
ein frei stehender "IP_V4" Typ (siehe Bild) wird so in einem Datenblock eingebaut wie in 1. und 2. beschrieben
und das Verhalten gilt für alle Struct-Artigen die ich je (sehr viele) gesehen habe
Jetzt wird es komisch:
Wenn man jetzt aber den Typ "TCON_IP_RFC" verwendet - der einen "IP_V4" beinhaltet wird
dieser "IP_V4" nicht auf eine 16Bit- sondern auf 32Bit-Grenze ausgerichtet - und zwar nur in diesem SDT
wenn ich das gleiche "TCON_IP_RFC"-Layout mit einem normalen Struct bauen kommt wieder
das Standardausrichtung auf 16Bit
Ich hab keine Ahnung ob es den "TCON_IP_RFC" auch in Step7 Classic gibt wenn ja - kann den einer mal benutzten und das Layout zeigen?
Ideen dazu?
Kann mir irgendjemand erklären was der Sinn dahinter sein soll - oder hat Siemens einfach mal das Alignment für
"IP_V4" in dem "TCON_IP_RFC"-Typ unnötig hart von Hand eingestellt? Technisch ist der Unterschied aus Performance-Sicht
unbedeutend, verbraucht (manchmal) einfach ein wenig mehr Speicher, aber warum dann diese Spezialisierung für diese EINE kleine Kombination
Bitte keine Erklärungen wie Alignment/Padding funktioniert oder was Kompiler können/dürfen - das ist mir alles
zu (100+x)% klar - und ja symbolische DBs sind an dieser Stelle nicht komisch - aber um die geht es hier nicht