unsigned - wofür eigentlich? < Sonstiges < Hochschule < Informatik < Vorhilfe
|
| Status: |
(Frage) beantwortet  | | Datum: | 15:19 Fr 13.05.2011 | | Autor: | GK13 |
| Aufgabe | Warum werden für die Ladebefehle load byte (lb) und load half (lh) unsigned Versionen load unsigned byte (lbu) und load unsigned half (lhu) benötigt??
Warum werden keine unsigned-Versionen der Speicherbefehle store byte (sb) und store half (sh) gebraucht? |
Hey!!
Wir beschäftigen uns an der Uni gerade mit Assemblercode, meine Frage hat zwar mit der Vorlesung zutun, allerdings eher oberflächlich - d.h. man braucht ja unsigned und signed nicht nur im Assemblercode, deswegen hab ich es unter sonstiges gepostet. Hoffe das ist korrekt.
So, die Frage steht oben, aber ich würde gerne erklären, was ich mir dazu überlegt hab:
Erstmal hab ich die Frage so verstanden: wozu brauche ich zusätzlich zu lb und lh noch unsigned-versionen (...)?!
Ich brauche ja nicht für lb und lh tatsächlich eine unsigned version, sondern für mich im Prinzip. die gehören nur zusammen und deswegen steht es da so, richtig?! So hab ich es mir überlegt, aber ich bin nicht sicher, deswegen wollte ich das hier noch nachfragen. Sonst hab ich es nämlich ganz falsch verstanden.
So wenn meine Zahlen also als vorzeichenlos betrachtet werden sollen, dann benutze ich unsigned - vielleicht habe ich dann insgesamt einen größeren Wertebereich? Ich brauche ja den negativen Bereich gar nicht, habe aber genausoviel Speicher zur Verfügung.
Ist die überlegung korrekt?
Sonst verstehe ich nicht, wozu ich signed und unsigend überhaupt benötige (anders als im code klarzustellen dass ich damit wirklich nur positive zahlen aufnehmen will..).
Warum ich sie nicht brauche, wenn ich sie speichern will, weiß ich allerdings nicht so recht und mir kommt meine erste Erklärung auch ein bisschen suspekt aber trotzdem irgendwie ansatweise logisch vor.
Weiß jemand Rat?
Lieben Gruß!!
Ich habe diese Frage in keinem Forum auf anderen Internetseiten gestellt.
|
|
| |
|
Hallo!
Wenn ich das richtig verstehe, ist das wie folgt:
Die Register wissen, was negative Zahlen sind, und würden das bei irgendwelchen Rechnungen berücksichtigen. (Ich gehe davon mal aus)
Aber das RAM ist ziemlich doof, es speichert irgendwelche Nullen und Einsen, ohne überhaupt irgendeine Ahnung zu haben, ob das jetzt ganze Zahlen oder Fließkommazahlen, oder evtl sogar Zeichen sind.
Wenn du also eine Zahl ins RAM schiebst, schiebst du nur die 8 (16, 32) Bit ins RAM, und das wars.
Wenn du eine Zahl ins Register holst, willst du dem Register noch mitteilen, ob das höchste Bit ein Vorzeichen ist, oder nicht, damit es korrekt rechnet.
Ansonsten gibt es Anwendungen, bei denen eben nur positive Zahlen Sinn machen, und dann benutzt man unsigned-Datentypen. So kann ein 32Bit-Recher eben maximal 4GB RAM ansprechen... Man könnte die Speicheradressierung natürlich auch mit signed-Datentypen durchführen, aber das wäre schon ziemlich... gewöhnungsbedüftig, und hätte vermutlich allerlei merkwüdige Nebeneffekte.
|
|
|
| |
|
| Status: |
(Mitteilung) Reaktion unnötig  | | Datum: | 22:07 Fr 13.05.2011 | | Autor: | felixf |
Moin,
> Wenn ich das richtig verstehe, ist das wie folgt:
>
> Die Register wissen, was negative Zahlen sind, und würden
> das bei irgendwelchen Rechnungen berücksichtigen. (Ich
> gehe davon mal aus)
bei welchen Architekturen ist das der Fall? Bei der Intel-x86-Architektur ist es zumindest nicht der Fall, ein Register weiss nicht ob der Inhalt ein Vorzeichen hat oder nicht, man muss halt die entsprechenden Befehle benutzen (IMUL anstelle MUL, IDIV anstelle DIV, wobei die I-Variante mit Vorzeichen arbeitet).
> Ansonsten gibt es Anwendungen, bei denen eben nur positive
> Zahlen Sinn machen, und dann benutzt man
> unsigned-Datentypen. So kann ein 32Bit-Recher eben maximal
> 4GB RAM ansprechen... Man könnte die Speicheradressierung
> natürlich auch mit signed-Datentypen durchführen, aber
> das wäre schon ziemlich... gewöhnungsbedüftig, und
> hätte vermutlich allerlei merkwüdige Nebeneffekte.
Vor allem muss man viel mehr Sicherheitsabfragen einbauen, so dass man z.B. nicht auf negative Adressen zugreifen kann.
Ein weiter Vorteil ist noch: mit unsigned-Typen kann man groessere Zahlen darstellen als mit signed-Typen.
LG Felix
|
|
|
| |
|
Moin!
diese Befehle gibt es z.B. bei der MIPS-Architektur. Auf der ![[]](/images/popup.gif) Wiki-Seite sind auch die Befehle aufgelistet. Sparcs und Alphas besitzen diese, und neben diesen heute etwas exotischen Prozessoren findet man das häufiger bei Microcontrollern, zum Beispiel beim Microchip PIC32.
Allerdings hast du recht, das hat mit dem Rechnen nix zu tun, auch MIPS haben spezielle Befehle zum berücksichtigen des Vorzeichens.
Ich hab mal nachgeguckt: Diese Unterscheidung lb und lbu gibt es nur für Datentypen, die weniger Bits als die Architektur haben, also 16bit und 8bit bei 32bit-Architekturen. Da die Register in dem Fall auch 32 Bit haben, bestimmen diese Funktionen, ob das höchste Bit des Datenwertes auf alle höheren Bits im Register übertragen werden soll, oder nicht.
Aus nem Byte 10101010 wird dann in nem 16bit-Register mit nem LBU 00000000.10101010 und mit nem LB 11111111.10101010 .
Da Rechenoperationen wie ein ADD beziehen sich aber immer auf ganze Register, und würden bei dem per LBU geladenen Byte immer eine positive Zahl sehen, während die andere Zahl je nach Rechenoperation auch als negativ angesehen werden kann.
Somit hatte meine Antwort oben sogar ein Fünkchen Wahrheit 
Und was das Speichern angeht, bleibts auch dabei: wenn man ein Byte speichert, speichert man nur die unteren 8 Bit, und schert sich nicht um die oberen. Es gibt also keinen Grund für entsprechende Befehle.
|
|
|
| |
|
| Status: |
(Mitteilung) Reaktion unnötig | | Datum: | 13:53 Sa 14.05.2011 | | Autor: | felixf |
Moin,
> diese Befehle gibt es z.B. bei der MIPS-Architektur. Auf
> der
> Wiki-Seite
> sind auch die Befehle aufgelistet. Sparcs und Alphas
> besitzen diese, und neben diesen heute etwas exotischen
> Prozessoren findet man das häufiger bei Microcontrollern,
> zum Beispiel beim Microchip PIC32.
ah, das ist interessant zu wissen 
> Allerdings hast du recht, das hat mit dem Rechnen nix zu
> tun, auch MIPS haben spezielle Befehle zum berücksichtigen
> des Vorzeichens.
>
> Ich hab mal nachgeguckt: Diese Unterscheidung lb und lbu
> gibt es nur für Datentypen, die weniger Bits als die
> Architektur haben, also 16bit und 8bit bei
> 32bit-Architekturen. Da die Register in dem Fall auch 32
> Bit haben, bestimmen diese Funktionen, ob das höchste Bit
> des Datenwertes auf alle höheren Bits im Register
> übertragen werden soll, oder nicht.
> Aus nem Byte 10101010 wird dann in nem 16bit-Register mit
> nem LBU 00000000.10101010 und mit nem LB 11111111.10101010
Ok, das macht auch viel mehr Sinn. Im x86-Befehlssatz kann man Rechenoperationen auch auf halbe Register anwenden: EAX ist z.B. der volle 32-Bit-Akkumulator, AX die unteren 16 Bit davon, AL die unteren 8 Bit, und AH die oberen 8 Bit von AX. Wenn man dann etwa IMUL AL, BL schreibt, werden die unteren 8 Bit von EAX mit den unteren 8 Bit von EBX multipliziert unter Beachtung des Vorzeichens.
Dieser Haufen verschiedener Interpretationsmoeglichkeiten fuer ein Register ist ein Zugestaendnis an die Abwaertskompatiblitaet, um Assembler-Code von 8-Bit-Intel-Systemen auf 16-Bit-Intel-Systemen nutzen zu koennen ohne grosse Aenderungen, und schliesslich um 16-Bit-Programme auch auf einer 32-Bit-CPU ohne Aenderungen laufen lassen zu koennen.
Intel hat mal mit IA-64 versucht, den ganzen Kompatiblitaetsmist loszuwerden, allerdings hat AMD dann mit x86-64 etwas Abwaertskompatibles vorgeschlagen was sich schliesslich auch durchgesetzt hat...
> Da Rechenoperationen wie ein ADD beziehen sich aber immer
> auf ganze Register, und würden bei dem per LBU geladenen
> Byte immer eine positive Zahl sehen, während die andere
> Zahl je nach Rechenoperation auch als negativ angesehen
> werden kann.
>
>
> Somit hatte meine Antwort oben sogar ein Fünkchen Wahrheit
>
Ja :)
> Und was das Speichern angeht, bleibts auch dabei: wenn man
> ein Byte speichert, speichert man nur die unteren 8 Bit,
> und schert sich nicht um die oberen. Es gibt also keinen
> Grund für entsprechende Befehle.
Genau.
LG Felix
|
|
|
| |
|
| Status: |
(Frage) beantwortet | | Datum: | 14:38 Sa 14.05.2011 | | Autor: | GK13 |
erstmal vielen Dank!=)
Ich hab aber noch eine Frage:
Wenn ich nur die untersten 8 Bit speicher und die Zahl dann irgendwann benutzen möchte, dann weiß ich doch nur den Betragswert und nicht ob positiv oder negativ? Das interessiert mich doch aber?!
Irgendwas muss ich noch falsch verstanden haben.
Was ich auch nicht ganz verstehe:
wenn durch lb immer 11111111.bla gemacht wird, dann ist ja gar nichts darüber ausgesagt, obs jetzt positiv oder negativ ist. es ist nur gesagt es könnte negativ sein.
wie genau komm ich dann an diese information? du sagtest "je nach Rechneroperation", wie meinst du das?
Ich meine, eine Zahl wird ja nicht als negativ angesehen, weil ich sie von einer anderen abziehe, sonst gäbe es ja gar keine möglcihkeit für -(-a) und man könnte doch wieder nur unsigend benutzen, und da muss ich also was falsch verstanden haben.
lg
|
|
|
| |
|
| Status: |
(Antwort) fertig  | | Datum: | 14:54 Sa 14.05.2011 | | Autor: | felixf |
Moin!
> erstmal vielen Dank!=)
>
> Ich hab aber noch eine Frage:
>
> Wenn ich nur die untersten 8 Bit speicher und die Zahl dann
> irgendwann benutzen möchte, dann weiß ich doch nur den
> Betragswert und nicht ob positiv oder negativ? Das
> interessiert mich doch aber?!
Nein, du hast schon den richtigen Wert (solange er nicht zu gross/klein war). Das liegt daran, dass eine ganze Zahl nicht einfach in Form von $(Vorzeichen, Betrag)$ gespeichert wird (wie bei Fliesskommazahlen), sondern als Zweierkomplement.
So ist -1 auf in 16 Bit etwa 11111111.11111111, in 8 Bit 11111111. Abschneiden der oberen 8 Bit der 16-Bit-Variante liefert also die 8-Bit-Variante.
Genauso kannst du eine negative 8-Bit-Zahl, sagen wir 11001010, zu einer 16-Bit-Zahl mit dem gleichen Wert machen, indem du die oberen 8 Bit auf 11111111 setzt. Aus einer vorzeichenbehafteten 8-Bit-Zahl eine 16-Bit-Zahl zu machen bedeutet also das oberste Bit der 8-Bit-Zahl achtmal davorzuschreiben.
> Irgendwas muss ich noch falsch verstanden haben.
>
> Was ich auch nicht ganz verstehe:
> wenn durch lb immer 11111111.bla gemacht wird, dann ist ja
Nein, dsa wird nur gemacht wenn bla negativ ist. Wenn bla positiv ist, wird daraus 00000000.bla.
Macht das jetzt mehr Sinn?
LG Felix
|
|
|
| |
|
| Status: |
(Mitteilung) Reaktion unnötig | | Datum: | 22:04 Fr 13.05.2011 | | Autor: | felixf |
Moin!
> Warum werden für die Ladebefehle load byte (lb) und load
> half (lh) unsigned Versionen load unsigned byte (lbu) und
> load unsigned half (lhu) benötigt??
> Warum werden keine unsigned-Versionen der Speicherbefehle
> store byte (sb) und store half (sh) gebraucht?
Darf ich fragen, um was fuer eine CPU(-Architektur) es sich handelt?
Bei den Intel-x86-CPUs ist mir eine Unterscheidung zwischen signed und unsigned Load-Befehlen nicht bekannt.
LG Felix
|
|
|
|
