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
Und welcher Prozessor? Bei 8 Bit ist ein "word" 1 Byte, bei 16 bit 2 byte, bei 32 bit 4 byte, ...
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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"...
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.
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!
Larry schrieb: > Da braucht man nicht mal schieben! Und du hast die originale Post des TO gelesen? leo
> 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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.