Assemblerprogramm mit Mips-Simulator SPIM-Hilfe

Hallo erstmal,
hätte an euch ne Frage in Bezug auf diesem Assembler-Code:

.text		
       	.globl __start	
__start:
	la $a0,prompt	# print prompt on terminal
	li $v0,4
	syscall

	li $v0,5	# syscall 5 reads an integer
	syscall
	move $t2,$v0	# $t2 holds hex number

	la $a0,ans1	# print string before result
	li $v0,4
	syscall

	li $t0,8	# eight hex digits in word
	la $t3,result	# answer string set up here

loop:	rol $t2,$t2,4	# start with leftmost digit
	and $t1,$t2,0xf	# mask one digit
	ble $t1,9,print	# check if 0 to 9
	add $t1,$t1,7	# 7 chars between '9' and 'A'
print:	add $t1,$t1,48	# ASCII '0' is 48
	sb $t1,($t3)	# save in string
	add $t3,$t3,1	# advance destination pointer
	add $t0,$t0,-1	# decrement counter
	bnez $t0,loop	# and continue if counter>0

	la $a0,result	# print result on terminal
	li $v0,4
	syscall

	li $v0,10
	syscall		# exit

	.data
result:	.space 8
	.asciiz "\n"
prompt:	.asciiz "Enter decimal number: "
ans1:	.asciiz "Hexadecimal is "

Also dieser Code soll ein Prog sein, dass eine Dezimale Zahl in eine Hexadezimale Zahl umwandelt.
Ich verstehe den oberen Code bis zur Zeile 16. Ab Zeile 16 fang ich an den Code nicht zu verstehen. Zum Beispiel wieso wird beim "loop:" 4 Stellen nach links rotiert, da man sowieso 8 Zeicehn(Strings) eingibt.
Ich bitte um jede Hilfe!

Kann keiner mir helfen???
Habt Ihr keine Erfahrung mit dem Mips-Simulator??

Christoph

Eine hexadezimal-Ziffer steht für 4 Bits. Deswegen wird in jedem Schleifendurchlauf um diese Anzahl rotiert, um jeweils die nächsten 4 Bits zu bekommen. Dann wird abgefragt, ob diese 4 Bits eine Zahl im Bereich 0 bis 9 darstellen oder eine Zahl im Bereich 10-15. Im ersten Fall wird auf die ASCII-Zeichen '0'-'9' abgebildet, im zweiten auf 'A' bis 'F'. An der Stelle sind einige Magic numbers enthalten, die sich mit einer ASCII-Tabelle erklären lassen.

Es sind übrigens 8 Hexadezimal-Ziffern, weil ein word beim MIPS aus 4 Bytes besteht. Jedes Byte hat 8 Bit, ergibt also zwei Hexadezimal-Ziffern.

Ich danke dir sehr für deine Antwort Christoph. Du hast mich schon viel weitergebracht. Aber ich hab das noch nicht ganz verstanden.
Also wenn das prog jeweils abfragt ob diese 4 Bits eine Zahl im Bereich 0 bis 9 oder im Bereich 10-15 darstellen, dann wird ja die Zahl die ich eingebe (also die dezimale Zahl) garnicht durch 16 geteilt, sondern es wird ja nur von links zu rechts jeweils zwei Ziffern zu Hexadezimale-Ziffer umgewandelt. Zum Beispiel wenn ich die Zahl 315(dezimal) zu X(hexadezimal) umwandeln will, wird dann das prog die zahl 3(dezimal) zu hexadezimal umgewandelt und dann die zahl 15(dezimal) zu hexadezimal umgewandelt. Ich weiss dass ich das total falsch verstande, deshalb freage ich dich wo mein gedankenfehler ist, also wie funktioniert es.
Wie kann irgendendeine Zahl zu hexadezimal umwandeln, wenn er nciht die normale Formel benutz, also durch 16 teilen und immer den Rest behalten.
Wäre nett wenn du mir das erklären würdest.
Und was bewirkt eigentlich diese Zeile?

and $t1,$t2,0xf    # mask one digit

Ich danke dir schon im voraus für deine hoffentliche Antwort!

Christoph

Unknow schrieb:

Ich danke dir sehr für deine Antwort Christoph. Du hast mich schon viel weitergebracht. Aber ich hab das noch nicht ganz verstanden.
Also wenn das prog jeweils abfragt ob diese 4 Bits eine Zahl im Bereich 0 bis 9 oder im Bereich 10-15 darstellen, dann wird ja die Zahl die ich eingebe (also die dezimale Zahl) garnicht durch 16 geteilt, sondern es wird ja nur von links zu rechts jeweils zwei Ziffern zu Hexadezimale-Ziffer umgewandelt. Zum Beispiel wenn ich die Zahl 315(dezimal) zu X(hexadezimal) umwandeln will, wird dann das prog die zahl 3(dezimal) zu hexadezimal umgewandelt und dann die zahl 15(dezimal) zu hexadezimal umgewandelt. Ich weiss dass ich das total falsch verstande, deshalb freage ich dich wo mein gedankenfehler ist, also wie funktioniert es.

Dein Denkfehler ist, dass die Zahl 315 so im Rechner steht. Der Rechner speichert die Zahl binär: 100111011.

Ein Rechts-Shift um vier Stellen ist bei Binärzahlen dasselbe wie eine Division durch 16. Deine Rechts-Rotation kannst du in diesem Algorithmus als Rechts-Shift lesen.

Unknow schrieb:

Wie kann irgendendeine Zahl zu hexadezimal umwandeln, wenn er nciht die normale Formel benutz, also durch 16 teilen und immer den Rest behalten.
Wäre nett wenn du mir das erklären würdest.

Der Algorithmus benutzt die normale Formel, denn Rechts-shift um 4 ist Division durch 16. Der Schritt "Rest behalten" wird von der nächsten Zeile erledigt:

Unknow schrieb:

Und was bewirkt eigentlich diese Zeile?
and $t1,$t2,0xf    # mask one digit

Das ist eine bitweise UND-Verknüpfung des Registers $t2 mit der Zahl 0x0F. Das bewirkt effektiv, dass alle bis auf die letzten 4 Bits von $t2 auf 0 gesetzt werden. Die letzten 4 Bits behalten ihre Werte. Das ist also die "Rest behalten"-Operation.

Danke dir wieder für deine Antwort.
Also damit ich das jetzt 100 prozentig verstehe.
Bei dem Beispiel mit der Zahl 135(dezimal)--->100111011(binär)
ist der erste Schritt eine Rechts-Rotation um vier Stellen also
101110011(binär), dann ist der zweite Schritt die UND Verknüpfung mit der Zahl 0x0F(aber wieso benutzt man 0x0F???), das heisst alle bis auf die letzten 4 Bits von $t2 werden auf 0 gesetzt --->000000011(binär) ---> 3(dezimal). Obwohl hier eigentlich 11 rauskommen sollte(weil 16*19+11=315 ist) kommt hier 3 raus. Wieso, was hab ich wieder falsch gemacht?
Und noch was ist der Befehl rol eigentlich nicht nach Links-Rotieren?

Könntest du mir BITTE helfen es zu verstehen Christoph???
Ist wichtig!!!

Hilfe mir PLEASE!!!

Nobuo T

...

Unknow schrieb:

Und noch was ist der Befehl rol eigentlich nicht nach Links-Rotieren?

Richtig. Und nach links zu rotieren macht idR. auch mehr Sinn, zuerst (dh. links) kommt schliesslich die hoechste Stelle der Zahl.

Unknow schrieb:

Bei dem Beispiel mit der Zahl 135(dezimal)--->100111011(binär)

Aehm, ja. Du meinst wohl 315 dezimal (13B hex).
Zudem darfst du nicht vergessen, dass es sich hierbei praktisch um einen 32Bit-Wert handelt. Dh. da kleben eigentlich links noch 23 0en mehr dran!
Das ganze funktioniert mit der Rotation auch nur, wenn du mit einem Vielfachen von 4 Binaerstellen rechnest. Dh. damit du ueberhaupt zu etwas Sinnvollem kommst, musst du mindestens 3 0en links ergaenzen: 0001 0011 1011

Unknow schrieb:

ist der erste Schritt eine Rechts-Rotation um vier Stellen also
101110011(binär)

so. Wir rotieren also links. Das gibt 0011 1011 0001 (Nochmal: Wir rechnen hier mit nur 12 Binaerstellen statt 32!).

Unknow schrieb:

, dann ist der zweite Schritt die UND Verknüpfung mit der Zahl 0x0F(aber wieso benutzt man 0x0F???),

0F ist binaer ...0000 1111. Damit werden die untersten 4Bit (mit 4Bit lassen sich 16Zahlen darstellen) der Zahl maskiert und so bekommt man pronto einen Wert zwischen 0 und 15 (also modulo 16). Einleuchtend?

Unknow schrieb:

das heisst alle bis auf die letzten 4 Bits von $t2 werden auf 0 gesetzt --->000000011(binär) ---> 3(dezimal).

Erstmal zaehlt man die Bits normalerweise von rechts aus => Es wird alles bis auf die ersten 4Bit auf 0 gesetzt.
Das ergibt also 0001 --->1(hexadezimal) und das passt auch (hoechste Stelle der Zahl 13B).

Unknow schrieb:

Obwohl hier eigentlich 11 rauskommen sollte(weil 16*19+11=315 ist) kommt hier 3 raus. Wieso, was hab ich wieder falsch gemacht?

Diese konfuse Rechnerei muss man nicht verstehen, hoffe ich.