Big Endian - amiga-news.de Forum

amiga-news.de Forum > Programmierung > Big Endian

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

02.06.2002, 15:53 Uhr

Festus
Posts: 537
Nutzer

Servus,

in letzter Zeit bin ich schon häufig über o.g. Begriff gestolpert. Kann mir wer sagen, um welche Problematik es da geht???

Dankeschön im voraus!
--
Gruß,
Festus

[ - Antworten - Zitieren - Direktlink - ]

02.06.2002, 16:20 Uhr

AC-FoX
Posts: 35
Nutzer

Bezeichnet die Art und Weise, wie Zahlenwerte, die größer als ein Byte sind, im Speicher abgelegt werden.
Neben Bytes (8-bit breit) gibt es noch Words (16-bit breit) und Longs (32-bit breit) als grundlegende Datentypen.
Im Rechner ist der Speicher jedoch nur in Bytes adressiert. Wenn man jetzt ein Word oder Long aus dem Prozessor in den Speicher legt, gibt es zwei Möglichkeiten, in welcher Reihenfolge die 2 oder 4 Bytes, aus denen das Word oder Long besteht, geschrieben werden.
Beim Big Endian Mode oder auch MSB (most significant byte first) wird das höchste Byte in die unterste Speicherstelle gelegt. Beim Little Endian Mode oder LSB (least significant byte first) wird das unterste Byte zuerst geschrieben.
Stell dir vor, du hast die Zahl 12345678. Und es passen nur jeweils zwei Ziffern in eine Speicherstelle im RAM. Im Big Endian Mode würde dann im Speicher stehen (beim untersten Byte angefangen zu lesen) "12345678". Im Little Endian Mode würde da "78563412" stehen - die am wenigsten wichtigen Ziffern "78" sind hier also zuerst in den Speicher geschrieben worden.
Das IMHO viel intuitivere Big Endian wird von den 68k, den PowerPC und weiteren Prozessoren als normaler Arbeitsmodus benutzt.
Little Endian wird vor allem bei der x86 Prozessor-Linie benutzt - aber die sind ja sowieso nicht ganz dicht

Die Probleme mit dem Endian-Mode treten vor allem bei Dateiformaten auf, bzw beim Konvertieren von binären Dateien eines anderen Rechnersystems auf. Das Umwandeln von einem Typ in den anderen kostet nicht viel Rechenzeit. Allerdings ist die Frage, wann und wie man konvertiert meist eine willkommene Quelle für Bugs.

Gruß

[ - Antworten - Zitieren - Direktlink - ]

03.06.2002, 15:33 Uhr

Festus
Posts: 537
Nutzer

@ AC-FoX

Herzlichen Dank für Deine Erläuterungen. Jetzt bin ich schon wieder schlauer

--
Gruß,
Festus

[ - Antworten - Zitieren - Direktlink - ]

03.06.2002, 16:29 Uhr

Beeblebrox
Posts: 723
Nutzer

Also ich war eigentlich der Meinung es ist genau andersrum:
Intel macht BigEndian und so ziemlich alles andere ist
LittldeEndian. Letzendlich ist das nur Definitionssache und
es ist wirklich vollkommen egal wierum was im Speicher liegt.
Es macht allerdings scheinbar gelegentlich größere Probleme
bei der Portierung von Programmen einem auf das andere System.

[ - Antworten - Zitieren - Direktlink - ]

04.06.2002, 04:55 Uhr

Andreas_Wolf
Posts: 2980
Nutzer

@ Beeblebrox:

> Intel macht BigEndian und so ziemlich alles andere ist LittldeEndian.

Nein. BigEndian heißt ja nicht umsonst auch MotorolaByteOrder und LittleEndian IntelByteOrder.

> Letzendlich ist das nur Definitionssache und es ist wirklich
> vollkommen egal wierum was im Speicher liegt.

Wie AC-FoX schon schrieb, ist BigEndian i.A. intuitiver für den Programmierer, da das Ablageformat der Zahlen dem entspricht, das wir außerhalb des Computers auch nutzen. Bei weniger schnellen CPUs sollte man darauf achten, daß die benutzten Datenformate bzgl. der Endianess der CPU entsprechen, also z.B. auf dem 68k lieber AIFF als WAVE zu benutzen, da die Umwandlung umso stärker ins Gewicht fällt, je langsamer die CPU ist.
Übrigens: Das Internet ist BigEndian, ebenso wie Audio-CDs (wenngleich die meisten CD-Laufwerke und Brenner die Daten als LittleEndian liefern/erwarten, da dort die Wandlung in Hardware implementiert ist).

[ - Antworten - Zitieren - Direktlink - ]

04.06.2002, 21:52 Uhr

Beeblebrox
Posts: 723
Nutzer

Ich habe mich wirklich geirrt was big- und littleendian angeht, also
nehme ich alles zurück und behaupte ab jetzt das gegenteil: Intel ist
Littleendian. Das Bigendian intuitivier ist mag sein, aber der Source
wird dadurch kaum anders aussehen, nur z.B. halt ein -- hinter einer
Zeigervariablen statt eines ++. Von der Performance ist das auch egal,
den Unterschied merkt man erst bei der Emulation/Konvertierung oder
auch bei der Verwendung von den angesprochenen .wav Dateien. Auf irgend-
einer Amigaseite stand auch das das TAO-Dingens Littleendian ist aber
die Geschwindigkeitseinbußen, wenn AmigaDE auf einem PPC läuft nur
max 5% betragen. Das kann ich natürlich nicht beurteilen.

[ - Antworten - Zitieren - Direktlink - ]

04.06.2002, 22:38 Uhr

thomas
Posts: 7716
Nutzer

Dann versuch mal ein auf dem Amiga geschriebenes Programm, das IFF-Dateien liest, auf den PC zu portieren. Kompilieren geht noch, aber laufen wird es erst, wenn du reichlich BigEndian->LittleEndian Konvertierungen einbaust. Und du kannst mir nicht erzählen, daß das keine Performance kostet.

Gruß Thomas

--
Email: thomas-rapp@web.de

Home: home.t-online.de/home/thomas-rapp/

[ - Antworten - Zitieren - Direktlink - ]

05.06.2002, 09:18 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von Beeblebrox:
Auf irgendeiner Amigaseite stand auch das das TAO-Dingens Littleendian ist aber die Geschwindigkeitseinbußen, wenn AmigaDE auf einem PPC läuft nur max 5% betragen. Das kann ich natürlich nicht beurteilen.

Das kann niemand, solange es keine vergleichbare Konfiguration für ein Big-Endian System gibt, mit der man das vergleichen kann. Die 5% wirken somit so ziemlich aus der Luft gegriffen.
Ich weiß nicht, ob diese 5% von AInc stammen oder ob sie nur von "einem sehr kleinen" Overhead sprachen, aber zumindest versuchen sie zu argumentieren, daß dieser kleine Performance-Verlust niemanden stören würde, wogegen der wohl deutlich kleinere Verlust durch z.B. Memory-Protection absolut indiskutabel sei.
Damit zeigt sich, daß jegliche technische Diskussion mit AInc zu solchen Details eigentlich nur in dem Versuch von AInc, Alibis für den unveränderlichen Status von Taos Technik zu schaffen, ausartet.

Java ist übrigends konsequent BigEndian, was sich aber auf die meisten Operationen nicht störend auswirkt, weil Zugriffe mit unterschiedlichen Pointertypen auf dieselben Daten generell ausgeschlossen sind. Somit ist die tatsächliche Byteorder im Speicher egal, aber für I/O Operationen eindeutig definiert.

mfg

--

Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.06.2002, 17:10 Uhr

AC-FoX
Posts: 35
Nutzer

Eine Endian-Konvertierung braucht auf einem 68k Prozessor drei Taktzyklen für eine 32 bit Zahl und nur einen Taktzyklus für eine 16 bit Zahl. Der PPC hat extra eine Option, schon beim Laden einer Zahl aus dem RAM, innerhalb des Ladebefehls, eine Endian-Umwandlung durchzuführen. Gilt natürlich nur, wenn man auf Assembler-Ebene programmiert. In einer C-Implementation können da schon 4-12 CPU Befehle allein durch eine Konverter-Funktion ausgelöst werden - nicht gerechnet den Funktions-Overhead, falls man den Code nicht als inline einbindet.
Die 5%, die der PPC also langsamer sein soll sind also höchstens ein
Mittelwert und durch "angepaßte" Programmierung fast vermeidbar. Wenn jedoch durchgängig alle Systemstrukturen Little-Endian sein müssen, dann sollte man dem C-Compiler eine extra Direktive spendieren, damit er schon auf CPU-Ebene eine Endian-Konvertierung durchführen kann. Evtl geht da aber auch ein prozessorspezifisches "inline __asm LONG EndianConvertLONG(LONG value __asm("d0"))".

My 2 bits

[ - Antworten - Zitieren - Direktlink - ]

24.06.2002, 11:25 Uhr

Solar
Posts: 3680
Nutzer

Es sei noch erwähnt, das "LittleEndian" seinen Ursprung in der 8/16-Bitter-Zeit hatte - zu diesem Entwicklungszeitpunkt bot LittleEndian bei der Verarbeitung größerer Zahlen irgendwelche Vorteile (weiß nicht mehr genau welche). War zu seiner Zeit also gar nicht dumm - nur inzwischen durch die Technik überholt.

IIRC sind z.B. StrongARM und XScale ebenfalls LittleEndian.

[ - Antworten - Zitieren - Direktlink - ]

24.06.2002, 19:23 Uhr

Andreas_Wolf
Posts: 2980
Nutzer

@ Solar:

> IIRC sind z.B. StrongARM und XScale ebenfalls LittleEndian.

Beide CPUs sind, ebenso wie der PowerPC, umschaltbar. Nur werden sie fast ausschließlich im LittleEndian-Modus genutzt, so wie beim PowerPC der BigEndian-Modus bevorzugt wird.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Big Endian

[ - Suche - Neue Beiträge - Registrieren - Login - ]