BigEndian-Dateien und Intel-CPUs?

[dpauw]

Hallo zusammen!

Was mir gerade brandheiß durch den Kopf schoss: Was passiert eigentlich, wenn auf einem Intel-Mac mein Fat-Binary meine BigEndian-Datei öffnen will? Chaos, oder?
Denn dabei dürfte auch Rosetta nicht einspringen können...

 

[-Nuke-]

http://developer.apple.com/document...ary/index.html#//apple_ref/doc/uid/TP40002217

links "Swapping Bytes"

 

[thomastr]

Hallo,
was soll denn eine "BigEndian Datei" sein? Es dürfte nur ganz wenige Anwendungen geben, die Daten direkt im Format, wie sie im Prozessor abgelegt werden schreiben. Und selbst falls dies der Fall wäre, muss Rosetta das abkönnen (es emuliert ja einen PowerPc). Probleme kann es höchstens mit schlecht portierten/programmierten nativen Intelanwendungen geben.

Sauber programierte Anwendungen verwenden die entsprechenden Funktionen und haben kein Problem mit der Behandlung der verschiedenen Datstellungen.


Gruß

Thomas

 

[dpauw]

Eine "BigEndian-Datei" ist für mich eine Datei, die, wie üblicherweise so durchgeführt, einen bestimmten Datenbereich aus dem RAM per fwrite in eine Datei schreibt.

Diverse Formate(bmp(=LE), tga(=BE)) machen das so und übertragen damit die Endianness ihres Prozessors auch in die entstehende Datei.

Also kein Grund für altkluge Belehrungen...

 

[dpauw]

http://developer.apple.com/document...ary/index.html#//apple_ref/doc/uid/TP40002217

links "Swapping Bytes"

Danke für den Link, der ist hilfreich!

 

[below]

s dürfte nur ganz wenige Anwendungen geben, die Daten direkt im Format, wie sie im Prozessor abgelegt werden schreiben.

Das zwar nicht, aber die Byteorder ist bei den meisten Binärformaten klar als little oder big endian definiert. Beispiel aus der Praxis:

"The bitorder in ID3v2 is most significant bit first (MSB). The
byteorder in multibyte numbers is most significant byte first (e.g.
$12345678 would be encoded $12 34 56 78), also known as big endian
and network byte order."

Also ist das ID3 Tag immer Big Endian, ob auf Intel oder PPC Rechnern. Die müssen entweder entsprechend eingelesen, oder geswapped werden.

Das ganze ist natürlich kein Problem mit Rosetta, sondern nur wenn aus der Applikation ein Fat Binary werden soll.

Nuke hat den Link ja schon geposted.

Alex

 

[Happy Bytes]

Das beste ist wenn man sich einen Wrapper um solches Lesen/Schreiben bildet.

ala

open
GetDW (DWORD)
GetW (WORD)
etc
Close

diese Funktionen GetDW kann man dann komplett CPU unabhaengig gestalten und mit #ifdef etc richtig zuorden.

Hier mal paar Beispiele von mir auf Lowlevel Shifting wie das aussehen kann:

else if (GETDW(&Header[0])==0x464C457F)

{

// =======================================================================

// ELF (Linux Executeble)

// =======================================================================

*WhatFile = ELF;

ELF_EP = GETDW(&Header[0x18]);

AVDEBUG("[Kernel32] ELF EP: %x (%d)\n",ELF_EP, ELF_EP);

}


und hier die defination:

#define GETDW1(p) (((AV_BYTE*)p)[0]| \

((AV_BYTE*)p)[1]<<8| \

((AV_BYTE*)p)[2]<<16| \

((AV_BYTE*)p)[3]<<24)



#define GETW1(p) (((AV_BYTE*)p)[0]| \

((AV_BYTE*)p)[1]<<8)

#define GETB(p) (*(AV_BYTE*)(p))



#define GETW2(p) (((AV_BYTE*)p)[1]| \

((AV_BYTE*)p)[0]<<8)



#define GETDW2(p) (((AV_BYTE*)p)[3]| \

((AV_BYTE*)p)[2]<<8| \

((AV_BYTE*)p)[1]<<16| \

((AV_BYTE*)p)[0]<<24)





Hier jetzt richtig setzen! (Beispiel fuer PPC CPU um FileHeader richtig zu lesen) wenn Du hier Intel hast dann nutze #define GETDW GETDW2

#define GETDW GETDW1

#define GETW GETW1