BigEndian/LittleEndian (mal wieder)

[KFAF]

Hallo DelphiPraxis!

Ich habe vorhin die Testversion der XE5 heruntergeladen, spiele mit dem Gedanken sie mir zu kaufen. Das mit den neuen Compilern für Android lohnt sich wirklich und funktioniert auch blendend. Um ein paar Dinge zu testen habe ich da älteren Quelltext aus XE3 durchgejagt. Dabei bin ich neben dem Problem, dass es dort keine AnsiStrings mehr gibt, auch noch auf ein anderes gestoßen:

Bekanntlicherweise sind ARM-CPUs ja Big-Endian, wohingegen IA-64 u. 32 Modelle Little-Endian sind. Ich habe erst kürzlich eine eigene Library für Kryptographie mangels funktionierender (XE3...), weniger überladener Units geschrieben. Dabei habe ich z.B. SHA-1 und SHA-256 implementiert.

Benutzt habe ich dafür die offizielle Spezifikation, festgelegt im FIPS 180-2. Daraus habe ich auch die Konstanten übernommen und alle Testvektoren durchprobiert. Sie funktioniert einwandfrei. Das dürfte doch aber garnicht möglich sein, da mir erst jetzt auffällt, das alle Konstanten im FIPS laut Dokument in BigEndian angegeben wurden, bei mir also die Byte-Order komplett verkehrtherum sein sollte. Aber es klappt trotzdem! Auf dem ARM geht es jedoch nicht. Deshalb bin ich in erster Linie auch drauf gekommen.

Habe ich etwas übersehen? Die ganzen Shift und Rot Befehle müssten doch da kompletten Schwachsinn erzeugen!

[mkinzler]

Neuere ARM-Prozessoren ( ab ARMv7) unterstützen beides, d.h. das OS bestimmt die Byteorder: Bei iOS, Android und Windows Phone ist das little-endian.

[himitsu]

War der MAC (PowerPC) nicht mal BigEndian?
Ich frag mich grade, so ein wenig, was der jetzt nutzt, nachdem die auf Intel umgestiegen sind. (wobei IA64 wohl auch Beides kann) ... muß man da nun beim OSX aufpassen?


Es wäre ja auch blöd, wenn in einem OS je nach System dieses plötzlich umschalten würde, dan liefen die Programme ja nicht mehr überall.
Und für die Wiederverwendbarkeit von Code wäre es auch besser, wenn wie überall das Selbe nutzen würden.

PS: Auch für die Datenübertragung und Speicherung ist es einfacher, wenn überall nur ein System verwendet würde. (also vorallem bei unseren Delphi-Programmen, egal für welches System)

[Furtbichler]

Also ich glaube, das es innerhalb eines Systems keine Rolle spielt, denn was als $1,$2,$3,$4 abgelegt ist, wird auch so gelesen.

Das einzige Problem ist der Austausch von Strukturen, also Datentypen, die aus mehreren Bytes bestehen, zwischen zwei Endian-Systemen, denn da schicke ich z.B. [$1,$2],[$3,$4] (2 WORD) los und empfange [$2,$1],[$4,$3].

Oder habe ich die rosarote Brille auf?

[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.