16bit in 2*8bit umwandeln

[Dshing]

Hi,
ich stehe grad auf dem Schlauch.
Ich will eine 16Bit unsigned int in zwei 8Bit unsigned int's umwandeln, das ganze in C und möglichst speicherplatz- und rechenzeitsparend.

Ich komm einfach nicht auf eine gute Lösung.
Könnt ihr mir ein paar Tipps geben, wie ihr das machen würdet?

 

[kinglouy]

unsigned short s = 0xffff;
unsigned char x1 = (unsigned char) s;
unsigned char x2 = (unsigned char) (s >> 8);

 

[AP Nova]

An #2: Gibt es in C kein "byte" als Datentyp, der auch für Zahlen gedacht ist?

 

[DaysShadow]

@AP Nova: Nein, es gibt keinen byte Datentyp, char ist der kleinste primitive Datentyp in C und in C++ auch.

 

[kinglouy]

Nein, char ist der kleinste Datentyp, hinter dem aber auch nur ein Zahlenwert steckt. Für diesen Datentyp gibt es halt im Gegensatz zu anderen Datentypen eben noch Literale für Buchstaben, die aber ebenfalls nur als Zahlen gespeichert werden. Char ist also prinzipiell ein Zahlentyp.

Es steht aber jedem offen ein "typedef char byte;" hinzuzufügen.

 

[asdfman]

Buchstabenliterale sind aber leider vom typ int.

Spoiler

Zumindest in C. In C++ nicht. Wieder ein Punkt, in dem die Sprachen inkompatibel sind, aber auf mich hört ja keiner. Meckermecker.

 

[4cc]

union{
short a;
unsigned char b[2];
}

so vielleicht?

 

[zwobot]

Eine Union ist gut, aber auf Big- und Little-Endian achten.

 

[eisdealer]

die 16-bit-zahl durch 256 teilen ( mit Rest)... das ergebnis dann die vordere 8-bit-zahl, und der rest die hinteren 8 bit ...


wäre so mein gedanke

 

[kinglouy]

@eisdealer
Die Bitverschiebung um 8 Bit aus meiner Lösung entspricht deiner Division durch 256 (2^8). Ich denke aber, dass eine Division teurer ist als eine Bitverschiebung.

 

[blackst0rm]

Könnte man das nicht auch so lösen:

unsigned short a = 0x0;
char* b = &a;

Dann sollte b auf die 1. Byte zeigen und b+1 auf das 2. Byte zeigen.
Ich weiß gerade nicht ob da nicht noch gecastet werden muss, da ich schon eine Weile kein C(++) mehr verwendet habe.

 

[ice-breaker]

@kinglouy: ein guter Compiler sollte dies aber eigentlich erkennen und daraus auch einen Bitshift machen. Immerhin ist der Dividend fest.

 

[Dshing]

Ahh so viele gute Ideen. Danke
Die Variante von kinglouy mit dem Bitshift gefällt mir am besten.

Super Dank euch

 

[maxwell-cs]

@kinglouy: ein guter Compiler sollte dies aber eigentlich erkennen und daraus auch einen Bitshift machen. Immerhin ist der Dividend fest.

klar. aber um mal jemanden hier im forum zu zitieren: man sollte das schreiben, was man meint, und nicht das, was man von der compileroptimierung erwartet.

 

[Krik]

Ich denke aber, dass eine Division teurer ist als eine Bitverschiebung.

Sollte das bei heutigen Prozessoren nicht schon egal sein? Zumindest bei diesen einfachen Operationen?
Die sollten das doch alle in einem Takt machen können; also Befehle dekodieren, Speicher lesen, Befehle ausführen, Speicher schreiben und das für mehrere verschiedene einfache Befehle (Bitshift und Kram) auf einen Schlag.

 

[ice-breaker]

@maxwell-cs: DAS Zitat ist gut, passt aber nicht ganz Beides sind ja Operationen die zum korrekten Ergebnis führen, das eine high-level (Division), das andere low-lvel (Bitshift). Ich würde natürlich auch den Bitshift bevorzugen, wollte nur mal anmerken, dass es eben nicht langsamer ist.

@e-Laurin: Befehle werden in mehreren Takten ausgeführt und dabei benötigt jede Operation eine unterschiedliche Anzahl an Takten. Diese Eintakt-Variante hat man schon lange über Bord geworfen, findet man imho nur noch bei AVR-Mikrocontrollern.

 

[Funart]

Heutigen Prozessoren ist es so oder so egal was ihr da treibt.

Wenn ihr nicht gerade für kleinere Prozessoren entwickelt welche eine 8 / 16 bit architektur besitzen, lohnt sich die Arbeit nicht das überhaupt zu zerlegen .
Vermutlichgehts dabei um eine Schulaufgabe.
Prozessoren verwalten das so oder so auf die gleiche weise. Relevant wirds erst bei breiteren Datentypen.

 

[Krik]

@ice-breaker
Afaik können heutige CPUs doch mehrere Befehle gleichzeitig pro Takt und Core ausführen. Greift das in diesem Fall nicht?

zB bei AMD: Die K10-Architektur (Phenom II & Co.) kann zB 4 Gleitkommaoperationen pro Takt ausführen, da sollte es doch auch was vergleichbares bei boolschen Operationen und Integerarithmetik geben.
Deswegen frage ich.

 

[maxwell-cs]

@ice-breaker: wenn man mal von einer korrekten optimierung ausgeht (was ja auch nicht immer gegeben ist), ist der unterschied zwischen dem, was man schreibt, und dem, was die compileroptimierung draus macht, eben nur der effizienzunterschied.

das zitat war ursprünglich darauf bezogen, präinkrement dem postinkrement vorzuziehen, wo es möglich ist.

ein

for(int i = 0; i < size; i++)

ist genauso korrekt wie ein

for(int i = 0; i < size; ++i)

 

[ice-breaker]

Doch, aber das sind Äpfel und Birnen Mehrere Befehle pro Takt ausführen ist nicht das gleiche wie ein Befehl pro Takt auszuführen, also dass ein Befehl in einem Takt komplett fertig ausgeführt wird.