Hallo,
ich habe mal eine Frage zu folgendem DLX Code:
1
LHI R7,adr_y>>16
2
ORI R7,R7,adr_y&0xFFFF
3
SW 0(R7),R5
4
5
.data 0x10000
6
adr_y: .word 0
Es geht wohl um das Problem, dass in DLX nur mit 16 Bit Konstanten
Adressiert werden kann.
Noch mal eine Allgemeine Frage zur DLX Architektur. Anscheinend ist ja
das Bit 0 das MSB. Ist das nur intern so, oder muss das auch bei er
Programmierung beachtet werden?
1
LHI R7,adr_y>>16
Hier werden ja die Highbits geladen. Das geht ja indem bei einer 32Bit
Zahl 16 Stellen nach rechts geschoben wird. Also anscheinend scheint
beim Programmieren Bit 0 das LSB zu sein.
1
ORI R7,R7,adr_y&0xFFFF
Hier werden die Low Bits mit der Bisherigen Adresse verodert, was
natürlich voraussetzt, das die Low Bits in R7 0 sind. Ist das so?
nur was soll das:
1
adr_y&0xFFFF
bringen eine Verundung mit 11 ist doch sinnlos, oder da bleibt ja alles
erhalten. Ich fände eine Verundung von R7 mit 0en Sinnvoll, um die Low
Bit 0 zu setzten. Das weis ich eben nicht, ob das schon automatisch beim
laden der High Bits geschieht.
Vielen Dank
Assembler schrieb:
ich will ja nicht behaupten, das ich mich mit DLX auskenne aber ich
verstehe das so ...
> LHI R7,adr_y>>16
lädt die 16 höherwertigen Bits der Adresse in den H-Teil (Bit 31..16)
von R7
> ORI R7,R7,adr_y&0xFFFF
adr_y&0xFFFF liefert die 16 niederwertigen Bits und fügt sie damit in
den L-Teil (Bit 15..0) von R7 ein, sodaß anschl. die komplette 32Bit
Adresse in R7 steht.
Sascha
Das verodern verstehe ich ja noch. Aber was macht dann das:
adr_y&0xFFFF. Wieso liefert das die Low Bits? Nimmt es sonst nicht
automatisch die Lowbits? Macht es ja nach dem schieben quasi auch, oder?
Geh dochmal auf die Webseite des Herstellers Deiner CPU und lade Dir das
Instruction-Set runter und schau dort einfach mal nach.
Das geht bestimmte schneller als rumzuraten.
Sieht auch nicht so aus, als ob viele Deine CPU kennen.
Ist ja kein AVR oder 8051, da würde schnell jemand antworten können.
Peter
Hallo,
Ich haben vom DLX eigentlich keine Ahnung. Aber mit einer einfachen
Internet-Recherche lässt sich das doch erklären. In dem Wikipedial
Artikel zum DLX gibt es im ersten Weblink ein PDF
(http://www.mr.inf.tu-dresden.de/lehre_ws/infet1/docs/Kapitel4-Rechner-Teil2.pdf).
Und da ist doch alles drinnen:
Auf der Folie 22 (DLX-Tricks (2)), da heisst es:
Wie lädt man eine 32Bit Konstante?
Sequenz aus zwei Befehlen
LHI R9,0xCAFE
ORI R9,R9,0xBABE
R9 hat jetzt den Wert 0xCAFEBABE
Auf der Folie 15 wird "ORI" als I-Typ Instruktion beschrieben. Es sind
also nur 16 Bit für einen Operanden reserviert. Wenn du nur "adr_y"
angibt, dann wir der Assembler nörgeln, weil das ein 32 Bit Wert ist.
Mit "adr_y&0xFFFF" bekommt er aber einen 16 Bit Wert.
Auf der Folie 17 wird der "LHI" Befehl beschrieben. Und wenn ich die
Notation richtig verstehe, dann werden die unteren 16 bit dabei
ge-nullt.
Jetzt würde mich mal interessieren, warum du dich mit dem DLX eigentlich
rumplagst ohne Handbuch etc...?
Axel
Ja die Seite habe ich auch schon gelesen. Mir ist das auch alles relativ
verständlich. Nur mich wundert eben das:
> LHI R7,adr_y>>16
das Dürfte auch ein I-Typ sein. Und ich lade quasi auch eine 32 Bit
Konstante. Und zwar den Highteil in den Lowteil geschrieben und der Rest
0en. Aber wieso muss da nciht noch ein (adr_y>>16)&0xFFFF dran. Um von
dem Geschobenen wieder nur den Lowteil zu nehmen?
Die LHI Instruktion lädt einen 16 bit Wert in die oben 16 Bit eines
Registers und füllt die unteren 16 Bit mit Nullen.
Und wenn 0xCAFEBABE um 16 Bits nach links verschiebe, dann kommt das
0xCAFE
raus - was ein 16 Bit Wert ist, der sich in einer I-Typ Instuktion
nutzen
lässt. Die Oben 16 Bits sind dann Null, das bitweise verunden mit
0x0000FFFF kannst du dir sparen.
Axel
Wenn ich den Wert
10110110010101101101101001101101
habe.
Dann lade ich doch mit
>LHI R7,adr_y>>16
00000000000000001011011001010110
mit > ORI R7,R7,adr_y&0xFFFF
lade ich
10110110010101101101101001101101
&
00000000000000001111111111111111
=
0000000000000000110110100110110
Das kommt doch genau auf Gleiche, als wenn ich gleich
10110110010101101101101001101101
laden würde und er nach den 16Bit abbricht, was er ja wohl auch macht,
da er eh nur 16 Bit laden kann.
Hallo,
technisch ja. Aber ich vermute, dass der Assembler das nicht automatisch
macht, sondern da einen Fehler bzw. eine Warnung auswirft. Das geht
einfach nach dem Motto "avoid excessive cleverness". Der Programmierer
hat gefälligst so genau wir möglich anzugeben, was er machen will. Dafür
ist dann aber auch beim Durchsehen des Codes klar, was passiert. Und der
erzeuge Code sowieso der gleiche, also kostet das nichts.
Das Ausnutzen von irgendwelchen impliziten Regeln erscheint zwar clever,
macht den Code aber meisten nicht wartbarer und am Ende zieht sich die
Fehlersuche in die Länge.
Axel
Eine eigene Frage?
Dieser Thread ist über 16 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
