liegt mein Array "verkehrt herum" im Ram?

Integers werden auf dem von dir benutzten Prozessor little-endian, d.h.
beginnend mit dem niederwertigsten Byte im Speicher abgelegt. 0x01 wird
somit als das niedrigstwertige und 0x50 als das höchstwertige Byte
betrachtet, so das die gelesene uint32_t-Wert 0x50000001 ist.

Danny schrieb im Beitrag #3367193:
> Ich bin grad völlig verblüfft, bislang war für mich "big-endian" die
> einzig denkbarer Art und ich bin jahrelang damit in kein Problem
> gelaufen...

Was für Exoten-Prozessoren hast du denn jahrelang benutzt?

Oliver

Oliver S. schrieb:
> Was für Exoten-Prozessoren hast du denn jahrelang benutzt?

Sehr gebräuchliche Prozessoren mit Big Endian sind:

- 68000
- PowerPC
- SPARC

Viele ARM-Prozessorkerne lassen sich wahlweise als Big oder Little 
Endian konfigurieren, teilweise per externem Endianess-Pin. Beispiel 
Alcatel MTC-20285. Auch StrongARM- und Xscale-Prozessoren werden oft in 
Big Endian verwendet, gerade in Netzwerkkomponenten, da die Header von 
TCP/IP-Paketen auch in Big Endian (sog. Network Byte Order) spezifiziert 
sind.

Bei einigen MIPS-Prozessoren kann die Endianess sogar für jeden Prozess 
separat eingestellt werden, z.B. Toshiba TX39.

Nachtrag: Auch aktuelle ARM-Kerne beherrschen beide Betriebsarten, 
exemplarisch für den Cortex-A9:
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0407e/BABCIEHF.html

DirkB schrieb:

1

> uint32_t test;

2

> test = *(uint32_t*)(&data[0]);

Weil noch keiner darauf eingegangen ist: DirkB hat hier völlig recht. 
Ganz unabhängig davon ob der TE einen kleinen oder großen Indianer 
programmiert, hat er auch Daten und Adressen durcheinandergewürfelt.

So hat er z.B. hier:

Danny schrieb:
> uint32_t* ptr = data[1];
> test = *prt

den Inhalt von data[1] (also vermutlich ein uint_8t) als Adresse 
eines uint32_t interpretiert. Und das geht in jedem Fall in die Hose. 
Wenn es das erwartete Ergebnis geliefert hat, dann auf jeden Fall nur 
zufällig.


XL

Danny schrieb:
> uint32_t* ptr = &data[0];

Welchen Datentyps ist denn das Array jetzt?

Danny schrieb:
> uint8_t

Dann wirst du wohl mindestens ein Warning bekommen. Und dann wird sich 
das ganze nicht so verhalten, wie du dir das (wahrscheinlich) 
vorstellst. Benutze doch einen Pointer vom selben Typ.

Danny schrieb:
> dann liest er aber kein 32bit-Wert aus 4 hintereinander liegenden
> 8bit-Werten

Ah ja, mein Fehler. Klar, deshalb ja auch die Frage nach Endianess. 
Ziehe meinen Klugschiss zurück :)

Ro B. schrieb:
> Danny schrieb:
>> dann liest er aber kein 32bit-Wert aus 4 hintereinander liegenden
>> 8bit-Werten
>
> Ah ja, mein Fehler. Klar, deshalb ja auch die Frage nach Endianess.
> Ziehe meinen Klugschiss zurück :)

Würds dann aber eher sauber coden und dann shiften/adden. Oder siehst du 
deine Vorgehensweise als optimiert?

Sonst halt einfach das Array "rückwärts" benutzen.