Darf ein Compiler Structs umsortieren?

Das ist das Problem, diese Texte sind so mindestens so verquast wie EU- Richtlinien oder schlimmer noch deutsche Steuergesetzestexte.

Finde ich auch.
Bin schon stolz, wenn ich ein halbswegs passendes Kapitel finde...

Aber es läuft wohl darauf hinaus, daß es wohl erlaubt ist, umzusortieren.

Glaube ich auch.
Aber besser erstmal ein paar Tage abwarten, ob das nicht doch
jemand besser weiß.

das nennt sich padding und kann normalerweise abgeschaltet werden, global und lokal. umsortiert wird garantiert nichts.

wenn ich mich recht erinnere, darf ein compiler zwar füllbytes einbauen, aber nicht die member umsortieren.

wenn ich mich recht erinnere, darf ein compiler zwar füllbytes einbauen, aber nicht die member umsortieren.

Und wenn du mir jetzt noch sagst, wo das im Standard steht,
halt ich den Mund.

supertux

~fricky schrieb:

wenn ich mich recht erinnere, darf ein compiler zwar füllbytes einbauen, aber nicht die member umsortieren.

genau, GTK+s Vererbung basiert z.B. darauf, dass das erste Element des structs stets die Parent Klasse darstellt.

namespace invader

Das erste Element muss immer "am Anfang" stehen. Vor allen weiteren Elementen dürfen noch Stopfbytes eingefügt werden, aber durcheinandergebracht dürfen sie nicht werden:

ISO/IEC 9899:TC3, 6.7.2.1 schrieb:

Within a structure object, the non-bit-field members and the units in which bit-fields
reside have addresses that increase in the order in which they are declared. A pointer to a
structure object, suitably converted, points to its initial member (or if that member is a
bit-field, then to the unit in which it resides), and vice versa. There may be unnamed
padding within a structure object, but not at its beginning.

Wenn man haben will, dass die ersten paar Elemente verschiedener structs gleich sind, muss man eben diese gemeinsamen Elemente in ein Struct zusammenfassen und das dann jeweils als erstes Element verwenden.

flamer schrieb:

wenn ich mich recht erinnere, darf ein compiler zwar füllbytes einbauen, aber nicht die member umsortieren.

Und wenn du mir jetzt noch sagst, wo das im Standard steht,
halt ich den Mund.

ich weiß nicht, wo es im es standard steht. dürfte ein compiler die member aber nach belieben umsortieren, wäre binärkompatibilität zwischen verschiedenen kompilaten nicht mehr möglich. damit wäre das konzept des dynamischen linkens (oder jede andere binäre schnittstelle) hinfällig.

pointercrash**

Hey Leute,

ganz lustig:
Wenn ich 8 Bit als Byte nehme, word als 16 Bit, passiert beim Umlegen der struct auf full optimization (speed) folgendes:

byte0 // ab hier Header
word0
byte1
word1
byte2
// ab hier Daten
word2
byte3
word3
byte4

wird zu

byte0
byte1
byte2
byte4
byte3
stuffbyte
word0
word1
word2
word3

Hoffe, beim Debugger- Abpinseln keinen Fehler gemacht zu haben.
Der Hase liegt im Pfeffer, weil Header und Nutzdaten gemischt werden könnten (habe das Datenfeld übrigens gekürzt).

namespace invader schrieb:

Das erste Element muss immer "am Anfang" stehen. Vor allen weiteren Elementen dürfen noch Stopfbytes eingefügt werden, aber durcheinandergebracht dürfen sie nicht werden:

Also ist das da oben eigentlich nicht zulässig? Ich habe zum Compiler noch eine ganze Latte "force- dies, force- das pairing, write combine"- Parameter gefunden, die werde ich mal testweise nacheinander lahmlegen.

namespace invader schrieb:

Wenn man haben will, dass die ersten paar Elemente verschiedener structs gleich sind, muss man eben diese gemeinsamen Elemente in ein Struct zusammenfassen und das dann jeweils als erstes Element verwenden.

Jahahaa, so scheint es! Ich bin da schon am Rumtippeln, muß aber leider einen Haufen Zugriffe entsprechend anpassen. Genau darum habe ich mich nicht gerissen, aber wat mutt, dat mutt

EDIT: Hatte natürlich die Reihenfolge heillos durcheinandergebracht, weil ich da schon mit den switches gepielt habe und immer der gleiche Speicherbereich angesprochen wurde.

^^welcher compiler macht sowas verbotenes? das muss ein billiger bis kostenloser sein (icc vielleicht?). normalerweise sollte das so aussehen

byte0
stuffing-byte
word0
byte1
stuffing-byte
word1
byte2
stuffing-byte
word2
...

ach ja, wenn du's ihm abgewöhnen willst, dann mach aus den 'bytes' in der struct auch 'words'. dann sollte er eigentlich keinen grund zum umsortieren haben.

pointercrash**

~fricky schrieb:

^^welcher compiler macht sowas verbotenes? das muss ein billiger bis kostenloser sein (icc vielleicht?) ... ach ja, wenn du's ihm abgewöhnen willst, dann mach aus den 'bytes' in der struct auch 'words'. dann sollte er eigentlich keinen grund zum umsortieren haben.

Ja, ist ein kostenloser GCC- Ableger. Aus den Bytes Words zu machen, hätte geholfen, aber ich habe noch einen (natürlich undokumentierten) Switch gefunden, der ihm das austreibt, auch, wenn ich die Optimierung auf den Wert für höchste Geschwindigkeit setze. Eine Lösung ganz ohne Tipperei!

Ein Gutes hatte die Sache aber doch: Die eigenmächtige Umsortierung hat tatsächlich speed gebracht. Wenn ich dem Compiler helfe, indem ich selbst umsortiere (tut ja nicht weh), kriege ich tatsächlich zwei Word- Zugriffe (read/write) statt vier Byte- Zugriffen, was ich bei dieser zeitkritischen Sache gut gebrauchen kann.
Einziger Nachteil: Die Debug- Informationen zerbröselt's dabei, was mich bei der Release ja nicht stört.