Assembler Befehl LDA

[Thomas (Gast)]

Hallo,
wir haben heute in Informatik die Befehlsverarbeitung begonnen. Der 
Ablauf des Befehls LDA <ADR> wurde so erklärt:

BR erhält Befehlscode für LDA
PC inkrementieren
Adresse an Speicher anlegen (Adressierung des Arguments)
Wert aus Speicher wird in AR übernommen
Speicher mit AR adressieren
Wert aus Speicher in HR übernehmen.

LDA...load accumulator
BR....Befehlsregister
PC...Programmcounter
AR...Adressregister
HR...Hilfsregister

Ich stelle mir den Speicher so vor:

0: LDA
1: 7
2: x
3: x
4: x
5: x
6: x
7: 20

Also zuerst ist der PC bei 0. Dort steht der Befehlscode für LDA. Als 
nächstes wird dieser inkrementiert. Dort steht die Adresse 7. Diese wird 
jetzt an den Speicher angelegt. Raus kommt der Wert 20. Wieso wird 
dieser jetzt in das AR übernommen, und damit der Speicher nochmal 
adressiert? Kann mir das bitte jemand erklären?

Viele Grüße

[Thomas (Gast)]

Ok ich glaub jetzt hab ichs kapiert. Es bewirkt manchmal wunder, wenn 
man das geschriebene nochmals durchliest :-). Der Speicher wird erst mit 
der Adresse 1 adressiert, heraus kommt die 7 und damit wird der Speicher 
dann nochmal adressiert. Ist das so richtig?

[Michael U. (amiga)]

Hallo,

im Prinzip ja, aber... ;)

Hängt vom konreten Prozessortyp ab, dem Dein LDA gehört.
Der Hersteller hat ja die Struktur des "LDA" in Siliziom gegossen.
Man müßte also z.B. wissen, ob der Speicher und CPU 8 oder 16Bit breit 
sind.

Wenn es 8Bit sind und der Befehl das macht, was Du schreibst, kann er 
nur maximal 256 Byte adressieren (eben Adresse 0...255).
Auch eine 8Bit CPU hat aber normalerweise megr Speicher und damit einen 
Adressbus, der z.B. 16Bit breit ist.
Wenn der LDA da auf den ganzen Bereich zugreifen will, muß er ein 3 Byte 
Befehl sein, 1. Byte Befehl (LDA), 2.+3.Byte Speicherdresse.

Dann sähe es z.B. so aus:

0000: LDA
0001: 7 (untere 8 Bit der Adresse)
0002: 3 (obere 8 Bit der Adresse)
0003: x
...
0307: 20

PC auf 0000 und ins AR
Befehl holen und dekodieren. PC+1
"LDA" sagr der Logik jetzt, daß noch eine 16 Bit Adresse dazugehört. 
Also
Also PC ins AR und 2. Byte holen und merken, PC+1
PC ins AR, 3. Byte holen und merken, PC+1

2. und 3. Byte in das 16Bit Adressregister schieben und den Speicher 
adressieren.
Inhalt von Adresse 0e07 in den Akku holen.

Der PC zeigt jetzt auf das nächste Befehlsbyte im Speicher.

Ich binn jetzt mal bei Deinen Bezeichnungen geblieben, soweit habe ich 
eine CPU noch nicht "zerlegt" ;-)

Gruß aus Berlin
Michael

[Thomas (Gast)]

Gut danke. Naja ich bin 1. Semester ET und in Info zerlegen wir alles 
bis ins kleinste Detail. Aktuell haben wir Van Neumann Rechner. Davor 
sämtliche ALU Speicher etc. auf Gater Ebene.

[Jürgen W. (juergen_w)]

Hallo,

ich kenne den Befehl "LDA" (Lade Akkumulator) noch vom alten 6502.
Falls es für diese CPU sein sollte ist die Adressierungsart oben wohl
für die sogenannte ZP (Zero-Page). Das hatte den Vorteil das eben nur 2 
anstatt 3 Bytes für den kompletten Befehl gebraucht wurden.

Grüsse

[Thomas (Gast)]

Naja wir behandeln keine konkrete CPU, sondern die vermutlich einfachste 
Architektur:

http://de.wikipedia.org/wiki/Von-Neumann-Architektur

[Hannes L. (hannes)]

> Naja wir behandeln keine konkrete CPU, ...

Das ist ohne Verrenkungen nicht möglich, da jede CPU ihre Eigenarten 
hat. Da wirst Du wohl keine konkrete(re)n Aussagen bekommen und vorerst 
etwas "herumeiern" müssen.

...

[Thomas (Gast)]

Wieso wird Speicher denn eigentlich in der Praxis hexadezimal 
adressiert?

[Michael U. (amiga)]

Hallo,

Thomas schrieb:
> Wieso wird Speicher denn eigentlich in der Praxis hexadezimal
> adressiert?

Der Speicher wird nicht hexadezimal adressiert, der wird wie auch alle 
Register usw. binär angesprochen, eben mit 0 oder 1 auf den Leitungen.

Die lesbare Darstellung um z.B. das Bitmuster 0000001100000111 des 
Adressregisters für den Menschen einfacher zu machen, ist da meist die 
hexadezimale Darstellung.
00000011000001111 in 4er-Gruppen aufgeteilt 0000 0011 0000 0111 und die 
dann als hex aufgeschrieben, also 0307 ist auch im Kopf in beide 
Richtungen kein Problem.
0000001100000111 in dezimal 775 ist ohne Aufwand schon schwierig.

Gruß aus Berlin
Michael