BigEndian/LittleEndian (mal wieder)

[JamesTKirk]

In der Tat macht es in den allermeisten Fällen keinen Unterschied, ob ein Programm nun auf Little oder Big Endian läuft, da sich der Compiler darum kümmert, dass alles richtig läuft. Die einzigen Ausnahmen sind Binärdatenaustausch mit anderen Systemen oder der Zugriff auf Werte größer 1 Byte mit Hilfe von kleineren Werten.

In FPC gibt es (da dieser im Gegensatz zu Delphi durchaus Big Endian Systeme wie Power PC (mit Mac OS X, Linux, Amiga, GameCube, Wii, etc.), M68k (Linux, Amiga, etc.), ARM Big Endian (Linux) und MIPS Big Endian (Linux) unterstützt) daher öfters mal Code wie diesen hier:

Delphi-Quellcode:

{$ifdef ENDIAN_LITTLE}
  float64 = record
    case byte of
      1: (low,high : bits32);
      // force the record to be aligned like a double
      // else *_to_double will fail for cpus like sparc
      // and avoid expensive unpacking/packing operations
      2: (dummy : double);
  end;
{$else}
  float64 = record
      case byte of
        1: (high,low : bits32);
        // force the record to be aligned like a double
        // else *_to_double will fail for cpus like sparc
        2: (dummy : double);
  end;
{$endif}

Der Code stammt in diesem Fall aus der SoftFPU-Unit, zeigt aber, dass beim Aufbrechen eines Double in High und Low Teil darauf geachtet werden muss, dass man die beiden Teile richtig herum hat. Ähnliches gilt, wenn man mit nem PByte über einen Speicherbereich von z. B. LongInt wandert.

Und nochmal: Delphi unterstützt nur arm-android in Little Endian.

Gruß,
Sven

[Furtbichler]

Zitat von JamesTKirk:

...oder der Zugriff auf Werte größer 1 Byte mit Hilfe von kleineren Werten.

Stimmt.

[himitsu]

Oder auch ganz einfache Casts ... Beim Rumpointern sollte man da aufpassen.

Beim Little-Endian liegen die niedrigsten Teila am anfang, also ein Byte gelesen an der Adresse eines Word, ergibt den selben Wert, wenn im Word eine Zahl mit dem Wertebereichs eines Bytes drin ist.
Beim Big-Endin würde man dort dann 0 auslesen, weil man das höherwertigere Byte erwischt.

[KFAF]

himitsu, ich glaube du hast da was verkehrt.

Bei einen Little-Endian ist das niederwertigste Byte doch am Ende, bei einem Big-Endian am Anfang. D.h., dein Beispiel müsste genau anders herum sein: lese ich auf einem LE System das erste Byte von 48879 ($BEEF) bekomme ich BE, auf BE bekomm' ich EF.

Aber um wieder zum Thema zu kommen: Der Code funktioniert trotzdem, weil ...? Der Compiler die bitwise-Operationen sowiese auf jedem System nur auf eine Art ausführt?!

Folgendes Beispiel:
Zahl X liegt in einem WORD im Speicher.
Dann gilt : LE_X shr 8 = BE_X shr 8, weil die CPU die Werte sowieso in der selben Reihenfolge schieben muss (sonst wäre es ja kein shift sondern ein shift and rotate), und nur der Speicher anders ist, oder?

[gammatester]

Zitat von KFAF:

himitsu, ich glaube du hast da was verkehrt.

Bei einen Little-Endian ist das niederwertigste Byte doch am Ende, bei einem Big-Endian am Anfang. D.h., dein Beispiel müsste genau anders herum sein: lese ich auf einem LE System das erste Byte von 48879 ($BEEF) bekomme ich BE, auf BE bekomm' ich EF.

Was hast Du denn für ein komisches LE-System? Auf allen meinen LE-Windows/Intel-Systemen mit FPC und Delphi erhalte ich mit

Delphi-Quellcode:

var
  w: word;
  b: byte absolute w;
begin
  w := $BEEF;
  writeln(b);
end.

die Ausgabe 239 = $EF.

[JamesTKirk]

Um mal das Testprogramm von gammatester aufzugreifen:

Delphi-Quellcode:

program tendiantest;

var
  w: Word = $BEEF;
  b: Byte absolute w;
begin
  (* Hinweis: hexstr ist bei FPC eine Funktion in System, welche das 
   *          gleiche macht wie IntToHex. Da SysUtils unter M68k noch
   *          bockt, konnte ich die jedoch nicht verwenden...
   *)
  Writeln(hexstr(b, 2));
  Writeln(hexstr(w shl 4, 4));
  Writeln(hexstr(w shr 4, 4));
end.

Ergebnis i386:

EF
EEF0
0BEE

Ergebnis m68k:

BE
EEF0
0BEE

Gruß,
Sven