Frage zu Little Endian/Big Endian

Mechanics schrieb:

Ja, es gibt Big Endian Systeme, z.B. Mainframes und sicher auch was von ARM, aber mit ARM hatte ich schon lang nichts mehr zu tun. Auf Mainframes laufen ganz sicher keine Spiele Und überhaupt stellt sich das Problem in der Form wie du es beschreibst, nicht. Es gibt keine "portablen" Programme wie du dir das vorstellst. Die Endianess ist völlig egal. Wenn ein Programm kompiliert wird, muss sich der Compiler drum kümmern. Wenn das Programm in einer Laufzeitumgebung läuft, wie Java, muss sich die Laufzeitumgebung drum kümmern.
Wenn dein Programm jetzt irgendwelche Daten liest, dann muss es halt wissen, was es tut. Entweder ist es bei dem Dateiformat definiert, oder wenn es dein eigenes Format ist, musst du es es halt selber definieren.

ok, mal folgendes beispiel:
ich schreib folgendes programm

#include <stdio.h>

int main()
{
     FILE *fp=fopen("testdatei.dat","wb");
     if(fp==NULL)
     {
          printf("Datei konnte nicht erstellt werden.\n");
          return 1;
     }
     int variable=50;  // int hat auf meinem system 4 bytes.
                       // dezimal 50 = hexadezimal 0x32
     fwrite(&variable,sizeof(int),1,fp);
     fclose(fp);
     printf("Datei erstellt.\n");
     return 0;
}

die datei "testdatei.dat" wird erfolgreich erstellt.
so sieht das mit einem hexeditor aus (nur noch vorneweg: mein system hat little endian):

32 00 00 00

nun lese ich den wert wieder aus der "testdatei.dat":

#include <stdio.h>

int main()
{
     FILE *fp=fopen("testdatei.dat","rb");
     if(fp==NULL)
     {
          printf("Datei konnte nicht geoeffnet werden.\n");
          return 1;
     }

     int variable;
     fread(&variable,sizeof(int),1,fp);
     printf("variable = %d\n",variable);
     fclose(fp);
     return 0;
}

output:

variable = 50

das stimmt also alles.
nun nehmen wir mal an, ich habe ein big endian system und starte das untere programm. die "testdatei.dat" ist die selbe wie oben.
jetzt müsste, wenn ich alles richtig verstanden habe, der wert "838860800" ausgegeben werden (das ist der dezimalwert von 0x32000000).

stimmt das so?

Mechanics

Wie ich geschrieben habe, entweder ist das Format definiert oder du musst es selber definieren. Wenn es dein eigenes Format ist, sagst du einfach, du schreibst grundsätzlich little endian und auf einem big endian System musst du konvertieren.

Mechanics schrieb:

Wie ich geschrieben habe, entweder ist das Format definiert oder du musst es selber definieren. Wenn es dein eigenes Format ist, sagst du einfach, du schreibst grundsätzlich little endian und auf einem big endian System musst du konvertieren.

"konvertieren"? ich finde, dass ist ziemlich mühsam, besonders wenn man ein programm schreibt, dass viel mit zahlenwerten aus dateien arbeitet.

ja, aber das müsste doch dann ein generelles problem sein, oder? ich meine, wer baut sich schon sein eigenes linux (von win wollen wir mal nicht sprechen).

einige ausführahre dateien liegen ja in so einer linux-iso ja schon vorkompiliert vor (wie z.b. die binutils o.ä.), und ich glaub nicht, dass die das konvertieren?

ich verstehe auch nicht ganz, WARUM man big und little endian systeme hat, und nicht ein universelles endian format (entweder little oder big endian).

Mechanics

Ja, aber eine Linux ISO besorgst du dir für die passende Architektur. Selbstverständlich kriegst du kein für ein x86 System kompilierstes Linux auf einem Big Endian System zum Laufen. Genausowenig wie auf einem little endian 64 Bit System
So schlimm ist das Problem nicht. Es gibt tatsächlich Fälle, wo das im Protokoll oder Format nicht definiert ist, aber das sind Ausnahmen und die kriegt man meist auch in den Griff. Und so umständlich das konvertieren jetzt nicht. Wenn du die Performance meinst, ist es auch kein Problem, weil das Lesen von der Festplatte (oder Netzwerk) immer noch um einiges langsamer ist, als die paar Daten gleich in ein anderes Format zu konvertieren.

Warum es zwei Formate gibt, ist eine andere Frage. Natürlich ist es aus heutiger Sicht Quatsch. Aber früher hat man nicht so sehr an die Standardisierung gedacht. Gab halt Firmen, die haben das auf die Weise gelöst, und andere Firmen haben das auf eine andere Weise gelöst. Und beides hat sich irgendwie etabliert und deswegen muss man sich heute auch damit rumschlagen. Allein schon der Name "endianess" drückt aus, dass es keinen Sinn hat Googel mal, woher dieser Name kommt.

man braucht doch extra-betriebssysteme und extra programme... das war eigentlich meine frage.

auf deutsch also: so ein big-endian system kannste in die tonne treten.

p.s.: habe nix gefunden, weder den ursprung des namens noch dessen wortgenaue übersetzung. ich glaub aber, dass "Endianess" von "Endian" kommt (wer hätte es gedacht...)

Mechanics

Was den Ursprung des Namen angeht:

http://en.wikipedia.org/wiki/Endianness#Etymology

Du brauchst keine extra Betriebssysteme oder Programme, du musst sie nur neu kompilieren und an ein paar ganz wenigen Stellen die Endianess beachten. Genauso wie mit jeder anderen Architektur auch. Wenn man eine Software von x86 auf ARM portiert, gibt es sicher tausend mal größere Hürden als die Endianess.

gut, dann wäre wohl alles geklärt.

danke.

tntnet

Also die Endianess hängt vom Prozessor ab. PowerPC ist ein Big-Endian-Prozessor. Und wenn ich Linux auf einem PowerPC laufen lasse, dann läuft das halt Big-Endian. Das ist auch kein Problem.

Probleme gibt es erst, wenn man mit der Aussenwelt kommunizieren möchte. Sei es über Dateien oder das Netzwerk. Da definiert man halt ein Format bzw. ein Protokoll. Und da muss man genau definieren, wie man Zahlenwerte ablegen möchte. Und da reicht es noch nicht einmal einfach Little- oder Big-Endian zu spezifizieren, sondern auch die Länge. Also einfach ein sizeof(int) ist nicht korrekt.

Bei Netzwerkprotokollen wird häufig ASCII verwendet. Und da spielt die Endianess keine Rolle. Das Programm muss die Zahlen halt richtig parsen. So steht im http-Protokoll beispielsweise:

Content-Length: 1234

Und das funktioniert dann einfach so.

Binärprotokolle müssen halt einfach exakt spezifiziert werden. Und wenn ich so ein Binärprotokoll (oder Datei) lese, dann muss ich letzten Endes die Daten dann halt auch parsen.

Bei deinem so einfachen Beispiel gibt es ja schon das Problem, dass sizeof(int) nicht eindeutig definiert ist.
Auch nicht auf Systemen mit der selben Endianess.

DirkB schrieb:

Bei deinem so einfachen Beispiel gibt es ja schon das Problem, dass sizeof(int) nicht eindeutig definiert ist.
Auch nicht auf Systemen mit der selben Endianess.

gut, dann ersetzt bitte (im geiste) das sizeof(int) durch 4.

noch eine frage:
läuft jetzt windows auf big endian?

hustbaer

?!? schrieb:

noch eine frage:
läuft jetzt windows auf big endian?

Nö.

Die Windows Versionen die es bereits gibt bzw. mal gab (x86, AMD64, Alpha, PowerPC, MIPS, Itanium) liefel alle auf Little Endian.

Und da ARM Little Endian kann (sogar per Default Little Endian verwendet), wird wohl auch das kommende Windows für ARM mit Little Endian arbeiten.

Soweit ich weiss läuft nichtmal Windows CE mit Big Endian CPUs.