Reverse Engineering der NLT II

[HenneNWH]

ohne die Info von dir mit "Die Originalimplementierung dieser Funktion hat mit GCC/Clang falsche Werte geliefert." war einfach nicht klar warum dich diese kleine Routine so interessiert

d.h. du hast das für 32/64bit gefixt aber weils im BCC eh ohne Optimierung gebaut wurde hatte der Fehler in der DOS Exe nie Auswirkungen?

zu deinem Benchmark

...

aber es zeigt auf jeden Fall wie gut die Optimizer arbeiten können

Ziel des Tests war herauszufinden wie gut die Compiler optimieren. Wenn die Schleife aus der main()-Funktion wegoptimiert wird, passt es.

Die Funktion swap_u32() ist mir im Charaktergenerator schon aufgefallen.
Damals hatte ich diese Idee für den Test. Gestern gab's dann auch einen echten Grund das zu fixen.
Performance steht da nicht im Vordergrund, dafür wird diese Funktion zu selten aufgerufen.

Hab am Wochenende auf Debian 13 aktualisiert: GCC 14.2.0, Clang 19.1.7 läuft hervorragend.

Aber eigentlich will man hier ja doch, dass der Compiler am Ende wieder ein bswap im Assembler erzeugt, oder?
__builtin_bswap32 (GCC/Clang) bzw. _byteswap_ulong (MSVC) dürften daher die schnellste und, im Gegensatz zu Inline-Asm, plattformunabhängigere Variante sein.

Nicht ganz. Mir geht es bei BrightEyes darum möglichst nah am Original zu bleiben und portablen und korrekten Code zu erzeugen.
Die builtins halte ich bei performancekritischer Software für das Mittel der Wahl, aber es zieht im Nachgang für mehrere Compiler Präprozessor-ifdef-Orgien nach sich.
Das muss nicht sein.

wäre interessant ob der "-fsanitize=undefined" das aufzeigt - ich denke ein Coverity hätte das auch bemängelt

Nur zur Info: Der Address-Sanitizer funktioniert bei mir mit GCC auf dem Raspi2 nicht. Da fehlen scheinbar hardwareseitig atomic_load/store und compare_exchange Instruktionen.