Wie kann man bitte rechnerisch aus 1 Byte ein Hi-Word erstellen ? $23 ist das Byte und es soll dann $2300 werden ? $01 soll $0100 werden usw. Danke. Gruss
$23 um 16 Bit nach links schieben. Platz sollte da sein.
Gast
#6055361
left shiften mit 8 bit.
Gast
#6055367
Und welcher Prozessor? Bei 8 Bit ist ein "word" 1 Byte, bei 16 bit 2 byte, bei 32 bit 4 byte, ...
Gast
#6055368
Joachim D. schrieb: > $23 um 16 Bit nach links schieben. oooch neeeeeeeeee!
Joachim D. schrieb: > 16 Bit nach links schieben echt? rechne noch mal nach!
Überraschung ;)
Gast
#6055372
oder y = x * 256;
Die Bezeichnug "word" wurde im Lauf der Jahre viel zu unscharf, Mißverständnisse sind quasi vorprogrammiert. Ich versuche diese Gummi-Typen nicht nur im Code sondern auch in begleitendem Text zu vermeiden so gut es geht. Selbst in Pascal (obwohl es dort als Datentyp sauber definiert ist) benutze ich es nicht mehr sondern stattdessen UInt16/Int16 um Nicht-Pascalern beim Lesen keine unnötigen Fragezeichen oder gar falsche Vorstellungen in den Kopf zu pflanzen.
Bernd K. schrieb: > UInt16/Int16 um Nicht-Pascalern beim Lesen keine unnötigen Fragezeichen > oder gar falsche Vorstellungen in den Kopf zu pflanzen. Dafür wird dich ein "Pascaler" fragen ob ..... > in Pascal (obwohl es dort als Datentyp > sauber definiert ist)
Max M. schrieb: > Dafür wird dich ein "Pascaler" fragen ob ..... > >> in Pascal (obwohl es dort als Datentyp >> sauber definiert ist) In FPC ist word immer 16 bit. Delphi auch. Das sind die beiden Dialekte die heute noch am weitesten verbreitet sind, alles andere was heute noch lebt sind Nischenerscheinungen. Kennst Du einen bei dem word breiter ist als 16 Bit? Und selbst wenn: Genau aus dem Grund weil dann wieder einer kommt und zweifelt nehm ich NICHT word und stattdessen lieber Datentypen mit unmißverständlcihen Namen wo ich kann, mir gehts ja gerade auch um Leser die nicht auswendig wissen wie breit das jetzt hier und heute zufällig ist, ein Datentyp mit der Zahl 16 im Namen wird im Lauf der Zeit nicht stillschweigend anfangen zu mutieren.
Bernd K. schrieb: > Die Bezeichnug "word" wurde im Lauf der Jahre viel zu unscharf, > Mißverständnisse sind quasi vorprogrammiert. Eigentlich bezeichnet man damit die native Breite des Systems. Viele kennen es als 16 Bit, weil x86 ursprünglich mal eine 16-Bit-Architektur war und man das dort aus Kompatibilitätsgründen bis heute gleich gelassen hat. Wenn man aber z.B. das Datenblatt eines ARM liest, ist ein Word dort 32 Bit breit. 16 Bit ist ein Halfword.
Gast
#6055622
Rolf M. schrieb: > Bernd K. schrieb: >> Die Bezeichnug "word" wurde im Lauf der Jahre viel zu unscharf, >> Mißverständnisse sind quasi vorprogrammiert. > > Eigentlich bezeichnet man damit die native Breite des Systems. Viele > kennen es als 16 Bit, weil x86 ursprünglich mal eine 16-Bit-Architektur > war und man das dort aus Kompatibilitätsgründen bis heute gleich > gelassen hat. Wenn man aber z.B. das Datenblatt eines ARM liest, ist ein > Word dort 32 Bit breit. 16 Bit ist ein Halfword. ...und 8-bit dann ein Quarter-Worder mit Käse. :D Zurück zum TO: "Rechnerisch" würde bedeuten (steht auch schon weiter oben), den Wert mit 256 (0xff) zu multiplizieren. In der Praxis löst man das aber nicht rechnerisch, sondern schiebt den Wert um 8 bit nach links, weil es effizienter ist.
Gast
#6055637
FS schrieb: > Zurück zum TO: "Rechnerisch" würde bedeuten (steht auch schon weiter > oben), den Wert mit 256 (0xff) zu multiplizieren. In der Praxis löst man > das aber nicht rechnerisch, sondern schiebt den Wert um 8 bit nach > links, weil es effizienter ist. ..."rechnerisch" sind $FF jedoch "255" und nicht "256", in hexadezimaler Entsprechung "$100"...
Gast
#6055640
FS schrieb: > In der Praxis löst man das aber nicht rechnerisch, sondern > schiebt den Wert um 8 bit nach links, weil es effizienter ist. Die allermeisten Compiler (wenn nicht sogar alle) machen in diesem Falle sowieso ein Shift draus. Eine Multiplikation wird es höchstens dann bleiben, wenn man explizit keinerlei Optimierung möchte...
FS schrieb: > Zurück zum TO: "Rechnerisch" würde bedeuten (steht auch schon weiter > oben), den Wert mit 256 (0xff) zu multiplizieren. In der Praxis löst man > das aber nicht rechnerisch, sondern schiebt den Wert um 8 bit nach > links, weil es effizienter ist. Auf jedem halbwegs optimierenden Compiler sollten diese Operationen zu identischem Code führen. Ich würde dennoch den Shift nehmen, weil es die Intention besser ausdrückt. Und auf dem PC macht das sowieso selten einen signifikanten Unterschied.
Danke für die Info. Ich werde schieben rechts und links. Gruss
Gast
#6055941
Da Hi-Word, also das "most significant byte" des Wortes, wird wohl wenn es einem Byte entschluepft, immer Null sein. Da braucht man nicht mal schieben!
Gast
#6055945
Larry schrieb: > Da braucht man nicht mal schieben! Und du hast die originale Post des TO gelesen? leo
Gast
#6055971
> Und du hast die originale Post des TO gelesen? Bis auf den Lapsus, dass nicht das Hi-Word null werden soll, sondern das Lo-Word, bleibt es dabei. > Da braucht man nicht mal schieben! C-Programmierer koennen scheinbar nur Ramsch spielen. Sie schieben. Und auf den Optimierer ihres Compilers vertrauen.
Peter B. schrieb: > Danke für die Info. > > Ich werde schieben rechts und links. > Nur links! ;-)
Nick M. schrieb: > Und welcher Prozessor? > Bei 8 Bit ist ein "word" 1 Byte, > bei 16 bit 2 byte, > bei 32 bit 4 byte, > ... Prozessor ist wurscht, und bzgl Wortlänge: Lies noch mal die Frage ...
Larry schrieb: >> Und du hast die originale Post des TO gelesen? > > Bis auf den Lapsus, dass nicht das Hi-Word null werden soll, > sondern das Lo-Word, bleibt es dabei. Wo meinst du, das gelesen zu haben? >> Da braucht man nicht mal schieben! Also hast du es nicht gelesen. Solltest du mal, damit du die Aufgabenstellung verstehst. Larry schrieb: > C-Programmierer koennen scheinbar nur Ramsch spielen. Sie schieben. Was hat das denn mit C zu tun? Ich würde da in jeder Sprache schieben. > Und auf den Optimierer ihres Compilers vertrauen. Wenn man dem Optimizer nicht trauen darf, dann ist der Compiler Mist. Das ist ebenfalls unabhgängig von der Sprache.