mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Assemblerbefehlslänge


Autor: stke0006 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich habe folgendes Problem.

Ich müsste für die Uni wissen wie Lange ein Assemblerbefehl (haben ja 
immer verschieden Längen) ist. Also es heißt in einer Aufgabe:

Während des Befehls:

Adresse     Label      Befehl
70240H      START:     AND.L #$00000001,D7;

wird ein Interrupt aktiv.

Füllen sie die Stacktabelle aus.

und hier bräuchte ich eine Tabelle wie lang so ein Befehl ist.

hier noch verschiedene Befehle:

BSR $71280

MOVE.L D0,(-A7)

ADD.L #$12345678,D7;

BRA.W ADR1; ADR1 = 10830H

und so weiter wie man da am besten vorgeht.


Danke im voraus....

: Verschoben durch User
Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stke0006 schrieb:

> und so weiter wie man da am besten vorgeht.

Ganz einfach.
Besorg dir die Befehlssatzbeschreibung des Prozessors und sieh nach.

Autor: stke0006 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht leider nicht das Datenblatt hab ich da stehen nur die allgeime 
Befehle drin.

Das ist der Knackpunkt bei dieser Aufgabe rauszufinden wie Lang ein 
solcher Befehl ist.

z.B. BSR.W Gesamtbefehlslänge: 4 Byte (2 Byte Opcode+ 2 Byte Distanz)


das ist als Beispiel angegeben.

Kommt aber leider in der klausur nicht dran.

Autor: kruemeltee (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal, welcher Prozessor ist es?

Dann such dir die Befehlstabelle und nicht das Datenblatt.

Autor: ^ö^ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stke0006 schrieb:
> Das geht leider nicht das Datenblatt hab ich da stehen nur die allgeime
> Befehle drin.

Oh doch, das geht. Zu jedem Prozessor findest du eine Dokumentation, die 
genau solche Fragen klärt oder zumindest zu klären hilft. Vielleicht 
nicht im allgemeinen Datenblatt, dann aber sicher in irgend einer 
Dokumentation über den Instruktionssatz.

Allgemein wäre es noch hilfreich, die Prozessorarchitektur anzugeben ;-) 
(Diejenigen Prozessoren, die ich bisher gesehen habe, kennen keine 
unterschiedlich langen Befehle.)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stke0006 schrieb:

> Das geht leider nicht das Datenblatt hab ich da stehen nur die allgeime
> Befehle drin.

Sorry, aber wenn du im Netz zur 68000 (oder Nachfolger) keine präzise 
Befehlssatzbeschreibung mitsamt Codierung findest, dann fällst du mit 
Recht durch.

> Das ist der Knackpunkt bei dieser Aufgabe rauszufinden wie Lang ein
> solcher Befehl ist.

Jo. Zumal dies aus deiner obigen Beschreibung heraus nicht bei jedem 
Befehl eindeutig zu beantworten ist. Tip: Bei manchen Befehlen kann sich 
der Assembler je nach Operanden eine von mehreren Codierungen raussuchen 
- und wird sich hoffentlich die kürzere aussuchen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Jo. Zumal dies aus deiner obigen Beschreibung heraus nicht bei
> jedem Befehl eindeutig zu beantworten ist. Tip: Bei manchen
> Befehlen kann sich der Assembler je nach Operanden eine von
> mehreren Codierungen raussuchen


und als Ergänzung:
Wieviele Bytes der Opcode (also der Teil ohne irgendwelche Register oder 
Adressangaben) ist, ist zum Teil auch relativ willkürlich und von 
Prozessor zu Prozessor verschieden.
Zum Teil hat das auch mit Entwicklungsgeschichten von Prozessoren bzw. 
Prozessorfamilien zu tun, bei denen man zwar neue Befehle eingebaut hat 
aber aus Kompatibilitätsgründen die alten OpCodes nicht einfach ändern 
konnte oder wollte. So kommt es dann, dass zb bei 2 Befehlen, bei denen 
augenscheinlich der eine die Verallgmeinerung oder eine Erweiterung des 
anderen ist und von denen man daher landläufig annehmen könnte, dass sie 
sich zumindest sehr ähnlich sind, der eine einen 1 Byte OpCode hat und 
der andere deren 2. Einfach deswegen, weil es keinen 1 Byte OpCode mehr 
gab, den man benutzen hätte können.

Daher nochmal:
Befehlsreferenz besorgen und bei jedem Befehl nachsehen.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AND(I).L #imm,Dx-Befehl müsste 6 Bytes haben (2 Bytes Basis-Opcode, 
4Bytes imm-Wert).

ABER: Ich kann mir ehrlich gesagt schwer vorstellen, dass man das in der 
Klausur wissen muss, erst recht, weil der 68k ja schon etwas abgehangen 
ist und das ohne weitere Hilfen ziemlich nutzloses Wissen wäre. Meine 
Klausuren haben jedenfalls solche Fragen nicht :)

Ich habe den 68k zwar auch in-und-auswendig programmiert und jetzt auch 
noch etwas gegoogelt, aber ob er beim Eintreffen des Interrupts den 
Befehl vor dem Writeback abbricht oder danach, ist auf die Schnelle 
nicht zu finden (aber dafür Massen von 
IPL-Masken/IACK/Vector-Gelaber...). Damit ist es auch denkbar, dass der 
Befehl einfach wieder aufgesetzt wird, damit wäre der Return-PC auf dem 
Stack klar...

Autor: stke0006 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind zwar nützliche Tipps aber das Hauptproblem besteht weiter. Ich 
erkläre es mal ausführlich:

Aufgabe:

Der Befehl wird durch einen Interrupt Prirität 7 unterbrochen. Der 
Stackpointer zeigt auf die Adresse 0x30000000H. Geben sie den 
Stackinhalt mit Adresse nach beenden des jeweiligen Befehls an.


Adresse     Label      Befehl
20040H      Start:     sub.l d0,d0;

Dann muss man die Tabelle ausfüllen. Hier braucht man die Länge des 
Befehls.

A. K. schrieb:
> Jo. Zumal dies aus deiner obigen Beschreibung heraus nicht bei jedem
> Befehl eindeutig zu beantworten ist.

Das war z.B. auch ein Trick des Professors das ist eine orginal 
Klausuraufgabe gewessen hier musste man herausfinden ob man mit 2 Byte 
es realisieren kann oder ob man 4 Bytes braucht.

Dann was auch immer schwer ist z.b.

cmp.L   D0,D7 kann 2 Byte groß sein aber auch 6 Byte je nachdem ob D0,D7 
Konstanten sind oder nicht. usw.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stke0006 schrieb:
> Sind zwar nützliche Tipps aber das Hauptproblem besteht weiter. Ich
> erkläre es mal ausführlich:

Brauchst du nicht.
Du hast letzten Endes nur 1 Wahl:
Wenn du keine Unterlagen verwenden darfst, wie zb die komplette 
Instruction Set Beschreibung, dann bleibt dir nichts anderes übrig, als 
dieses auswendig zu lernen.

>
> Das war z.B. auch ein Trick des Professors das ist eine orginal
> Klausuraufgabe gewessen hier musste man herausfinden ob man mit 2 Byte
> es realisieren kann oder ob man 4 Bytes braucht.

Darf man fragen was das für eine Vorlesung ist, die solch sinnlose 
Klausurfragen stellt?
Das ist doch fern jeglicher Praxis.
Ich meine jetzt nicht den Aufbau des Stackframes sondern das rausfinden, 
wieviele Bytes ein Befehl umfasst. So etwas, sofern man es nicht 
auswendig weiß, sieht man im Instruction Set Manual nach, sollte man 
wirklich irgendwann in die Verlegenheit kommen, die Angabe tatsächlich 
zu benötigen.
Aber alle, die nicht gerade System Tools auf der Ebene Compiler, 
Assembler oder Debugger schreiben, dürften diese Information ihr Leben 
lang nie benötigen.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Hier braucht man die Länge des Befehls.

Wenn ihr anscheinend schon so auf dem 68k rumreiten dürft, habt ihr 
sicherlich auch über das Befehlsformat gesprochen. Das ist zwar etwas 
aufwendiger als bei RISC, aber für die meisten Befehle trotzdem noch 
überschaubar. Basisopcodes immer zwei Bytes, zzgl. Konstanten (bis auf 
die Quick-Befehle) 2/4 Bytes, zzgl. Offsets zwei Bytes. Ab dem 68020 
wäre es schon umständlicher, mit doppelt indirekt&Co.

> cmp.L   D0,D7 kann 2 Byte groß sein aber auch 6 Byte
> je nachdem ob D0,D7 Konstanten sind oder nicht

Hm? Den 68k-Assembler will ich sehen, mit dem du Konstanten mit Namen 
von Registern definieren kannst...

> Darf man fragen was das für eine Vorlesung ist, die solch sinnlose
> Klausurfragen stellt?

Wollte ich auch grad fragen ;)

Autor: schnarch68k (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich hoffe nur, dass für einen solchen Dummfug nicht auch noch 
Studiengebühren kassiert werden!

Autor: stke0006 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also die Klausur Heißt Mikroprozessoren. Im labor wird mit dem 
Coldfireprozzesor gearbeitet.

Was mir das bringt weis ich nicht. muss es halt lernen.

Georg A. schrieb:
>> cmp.L   D0,D7 kann 2 Byte groß sein aber auch 6 Byte
>> je nachdem ob D0,D7 Konstanten sind oder nicht
>
> Hm? Den 68k-Assembler will ich sehen, mit dem du Konstanten mit Namen
> von Registern definieren kannst...


Das problem so steht es in meinen Unterlagen. Ich mach lieber sachen wie 
Reglungstechnik oder so. -> also nicht wirklich die ahnung :-)

und in der Klausur kommen dann so Fragen immer wieder auf. Und ich habe 
das Internet ziemlich lange durchforstet die reine Opcodelänge hab ich 
gefunden aber das andere bringt immer wieder die Fragen auf.

z.b.
Adresse     Label      Befehl
10000H      Start:     BSR.W ADR1; ADR1 = 60020H

das war letztes Jahr in der Klausur dran. Hab da zum ersten mal diese 
zeile gesehen und dann steht man da...

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich müsste für die Uni wissen wie Lange ein Assemblerbefehl (haben ja
>immer verschieden Längen) ist. Also es heißt in einer Aufgabe:
Frage ist Kappes, wenn nicht konkr. CPU genannt wird. (und wegen 
AND.L... kann man weder sagen dass es 68K, Coldfire, R8C ,M16C,R32C.. 
oder sonst was ist)

>AND.L #$00000001,D7;
bei Coldfire wird da ANDI.L draus, weil Immediate
ANDI.L #$00000001,D7; (bzw ANDI.L #imm,Dx);
hat 6 Byte Länge (2 f Bef, 4 f. imm)
(dumm gelaufen, Coldfire kennt für viele Befehle nur Size=longword)
(aber wenn .L angegeben muss er ja sowiso schonmal die 4 Byte imm 
nehmen)

>cmp.L   D0,D7 kann 2 Byte groß sein aber auch 6 Byte je nachdem ob D0,D7
>Konstanten sind oder nicht. usw.
Unsinn. Dx sind keine Konstanten.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> kann man weder sagen dass es 68K,...

Doch, erschliesst sich eindeutig aus dem Uni-Kontext ;) Der 68k war da 
eine sehr beliebte Lehr-Architektur, weil deutlich regelmässiger als die 
x86-Krankheit. Dass er immer noch benutzt wird, ist erstaunlich. So 
häufig wird der Coldfire ja auch nicht benutzt...

> bei Coldfire wird da ANDI.L draus, weil Immediate

Beim 68k gibts sowohl AND.L #imm,Dx als auch ANDI.L #imm,Dx, und das 
sind unterschiedliche Opcodes. Aber die Länge ändert sich nicht...

Autor: Eckhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich kann aus der Aufgabe nicht lesen wieso Du die Befehlslänge brauchst.
Die Frage ist doch einfach wie der Stack vor und nach dem Auftreten des 
Interrups aussieht. Da keine Angabe ist um welchen Coldfire Core es sich 
handelt ist das jetzt nicht so einfach zu behandeln. Was Du brauchst ( 
Steht im Datenblatt ) ist der Exeption Stack Frame.

Normalerweise 16 Bit für format/vektor, 16 Bit für das Status Register 
und 32 Bit für den Program Counter. Was vorher auf dem Stack lag ergibt 
sich entweder aus dem Programm oder Du denkst Dir einfach was nettes 
aus.

Eckhard

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Doch, erschliesst sich eindeutig aus dem Uni-Kontext ;) Der 68k war da
>eine sehr beliebte Lehr-Architektur,
blablabla   ... hätte...sollte...könnte...
Im 1. Post stand nichts über konkr Archi. drin, also ist alles andere 
reine Spekulation. Und wenn in seiner Klausur-Aufgabe ebenfalls nichts 
drüber drin stand, hat der Prof. eine unsinnige Frage gestellt (ie. Wie 
lange braucht man, um von A nach B zu fahren)

Autor: SF (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Normalerweise ist das keine unsinnige Frage. Typischerweise gibt es in 
der Uni Übungen, Praktika oder Seminare (manchmal auch in den 
Vorlesungen) in denen dann entweder ein realer µC mit realem Befehlssatz 
vorgestellt wird oder irgendein "erfundener" abstrakter Typ.

Bei der Klausur wird dann vorausgesetzt, das man an den 
Übungen/Seminaren/Praktika teilgenommen hat, den Prozessortyp kennt und 
auch die entsprechenden Unterlagen dabei hat. Ist also kein Problem wenn 
man als Student aufgepasst hat und die Übungen/Seminare/Praktika besucht 
hat.

Der TS hat uns leider nicht alle Informationen, die er eigentlich haben 
müsste, mitgeteilt.

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das jetzt nur mal kurz überflogen, aber wird im Stack nicht nur 
die Rückkehradresse, also quasi der Programmcounter, bevor er auf einen 
neuen Wert gesetzt wird, abgelegt? Damit ist doch die Frage nach der 
Befehlslänge völlig irrelevant, da nicht der Befehl sondern der PC im 
Stack abgelegt wird. Oder sehe ich das falsch?

Gruß
Sven

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stepp64 schrieb:
> Ich hab das jetzt nur mal kurz überflogen, aber wird im Stack nicht nur
> die Rückkehradresse, also quasi der Programmcounter, bevor er auf einen
> neuen Wert gesetzt wird, abgelegt?

Nein.
Der PC hat schon die Adresse des nächsten Befehls.
Ist ja auch logisch. Wenn der Return kommt, möchtest du mit dem nächsten 
Befehl weitermachen und nicht den Befehl, während dessen Abarbeitung der 
Interrupt auftrat, erneut ausführen.

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist schon klar. Mir ging es auch eher darum, dass im Stack der Wert 
des PC+1 gespeichert wird, und nicht der Befehl selbst. Und mir scheint, 
das der Threaderöffner der Meinung ist, er müsste die Befehlsbytes im 
Stack abspeichern, deshalb auch immer wieder seine Überlegungen über die 
Länge des Befehls. Da der PC aber immer die selbe Länge hat, ist es 
irrelevant, aus wie vielen Bytes der Befehl besteht.

Wollte ich halt nur noch mal klarstellen.

Autor: Guido Körber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn die Dokumentation noch ähnlich strukturiert ist wie früher, 
dann brauchst Du das "Programmers Reference Manual" zum Coldfire. Da 
sollte alles drin stehen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stepp64 schrieb:

> Länge des Befehls. Da der PC aber immer die selbe Länge hat, ist es
> irrelevant, aus wie vielen Bytes der Befehl besteht.

Wenn du nur die Startadresse eines Befehls hast und wissen willst, 
welchen Wert der PC haben wird, wenn er nach Abarbeitung des Befehls auf 
den Stack gepusht wird, dann ist die Länge des Befehls keineswegs 
irrelevant.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> blablabla   ... hätte...sollte...könnte...
> Im 1. Post stand nichts über konkr Archi. drin, also ist alles andere
> reine Spekulation

Bevor du hier blöd rumnölst (scheinst du ja häufiger zu machen), lies 
einfach nochmal den ersten Post GANZ. Wo du da bei der Befehlsliste am 
Ende einen M8/16/32 raussehen willst (insb. wg. dem bsr und movE), 
erschliesst sich mir nicht. Bleibt also 68k/CF. Und da gibts keine hier 
relevanten Unterschiede.

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, jetzt macht es klick (mein 46 Jahre altes Gehirn rechnet halt nicht 
mehr so schnell ;-). Stimmt ja, er muss die Adresse des nächsten Befehls 
erst ausrechnen und da bräuchte er natürlich die Länge des aktuellen 
Befehls.

Ich leg mich dann wieder hin.....

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bleibt also 68k/CF
1. kann man nicht ausschliessen, dass es weitere CPU-Archit. gibt, auf
   die die Befehls-Syntax zutrifft (oder ist das Ziel der Aufgabe zuerst
   alle auf der Welt verfügbaren CPUs "abzuklappern" ?)
2. ist 68k <> CF , wenn auch ähnlich

Also, Vermutungen sind blablabla.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MCUA schrieb:
> 1. kann man nicht ausschliessen, dass es weitere CPU-Archit. gibt, auf
>    die die Befehls-Syntax zutrifft ...

Es ist ausdrücklich die Uni erwähnt. Damit ist schonmal klar, dass nur 
ausgestorbene oder mindestens 25 Jahre alte CPUs in Frage kommen, neuere 
sind da noch nicht bekannt. Das reduziert die Möglichkeiten schon ganz 
erheblich. Immerhin wird man nicht mehr wie ich mit der Barkhausenschen 
Röhrenformel traktiert, hoffe ich jedenfalls.

Gruss Reinhard

Autor: Reiner Zufall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Die Länge ist in der Tat irrellevant.

Der Befehl wird eingelesen, ausgewertet, und dann der PC um die Anzahl 
der Bytes weiter gestellt das er auf den nächsten Befehl zeigt. Dann 
wird der Befehl abgearbeitet. Diese Abarbeitung kann nicht unterbrochen 
werden!

Ist jetzt ein Interrupt aufgetreten, wird Standardmäßig nur Der PC auf 
dem Stack gespeichert (gilt nicht für alle Architekturen). Welche 
Register gesichert werden müssen hängt von der Architektur und dem 
Compiler ab.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es heißt aber ausdrücklich "Während des Befehls". Der aktuelle Befehl 
wird also noch abgearbeiten und dann wird in die INT-Routine gesprungen. 
Auf dem Stack müsste also tatsächlich die Adresse des folgenden Befehls 
liegen.
Dafür braucht man die Befehlslänge, da wir ja nur die Adresse des 
genannten Befehls kennen.

Obwohl Stacktabelle schon recht hochgeriffen ist; denn es steht ja 
wirklich nur der PC drin. Außer, der CF sichert automatisch noch andere 
Dinge.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reiner Zufall schrieb:
> Hallo,
>
> Die Länge ist in der Tat irrellevant.
>
> Der Befehl wird eingelesen, ausgewertet, und dann der PC um die Anzahl
> der Bytes weiter gestellt das er auf den nächsten Befehl zeigt. Dann
> wird der Befehl abgearbeitet. Diese Abarbeitung kann nicht unterbrochen
> werden!

OK.
Na denn. Dieser Befehl ist gerade in Arbeit

70240H      START:     AND.L #$00000001,D7;

er steht an genau der genannten Adresse im Speicher (70240H).
Während der Befehl arbeitet kommt ein Interrupt.
Welcher Wert wird jetzt als Rücksprungadresse auf den Stack geschrieben? 
Die Lösung bitte als Hexzahl angeben und auch wie du auf sie kommst, 
ohne die Befehlslänge zu kennen.

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, ich weiß es jetzt nicht, wie es hier aussieht.
Ich dachte immer dass die Befehlsverarbeitung von einem INT nicht 
unterbrochen wird (da atomar). Die Unterbrechung kommt immer direkt nach 
dem laufenden Befehl. Jedenfalls kenne ich nichts anderes, bin aber auch 
nicht so weit herumgekommen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:
> Hmm, ich weiß es jetzt nicht, wie es hier aussieht.
> Ich dachte immer dass die Befehlsverarbeitung von einem INT nicht
> unterbrochen wird (da atomar). Die Unterbrechung kommt immer direkt nach
> dem laufenden Befehl.

Normalerweise ist es auch so.
Ansonsten müsste man ja den kompletten CPU Zustand sichern. Das würde 
höchst wahrscheinlich länger dauern, als den angelaufenen Befehl zu Ende 
zu führen.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian H. schrieb:
> Hmm, ich weiß es jetzt nicht, wie es hier aussieht.
> Ich dachte immer dass die Befehlsverarbeitung von einem INT nicht
> unterbrochen wird (da atomar).

Der Interrupt als Signal an einem Prozessorpin kann jederzeit auftreten, 
je nach Architektur sogar asynchron.

> Die Unterbrechung kommt immer direkt nach
> dem laufenden Befehl.

Die Bearbeitung erfolgt nach dem laufenden Befehl (wobei es in Punkto 
CPU-Design auch denkbar ist, den Befehl abzubrechen und nach dem 
Interrupt neu zu starten, solange noch keine Teilergebnisse 
zurückgespeichert wurden). Trotzdem muss in der Aufgabenstellung die 
Länge des Befehls, während dem das Interruptsignal auftrat, bekannt 
sein, um den auf den Stack gesicherten PC-Wert zu bestimmen.

Andreas

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das erinnert mich an meine Anfänge mit CPUs (Z80), da habe ich mit 
Papier und Bleistift erst die Mnemoniks hingeschrieben, dann aus der 
Befehlsreferenz die Codebytes und dann die Sprungdistanzen abgezählt und 
eingetragen.
Das ist aber schon über 20 Jahre her.

Heutzutage interessiert es niemanden mehr, wie lang ein Befehl ist.
Man tippt einfach die Befehle, Argumente und Labels ein und der 
Assembler macht dann das richtige Hex daraus.

Man muß als Professor nicht so tun, als sei man auf ner einsamen Insel 
und der Nootebook-Akku ist leer.
Man sollte besser mal sinnvolle Aufgaben stellen.


Peter

Autor: Reiner Zufall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> OK.
> Na denn. Dieser Befehl ist gerade in Arbeit
>
> 70240H      START:     AND.L #$00000001,D7;
>
> er steht an genau der genannten Adresse im Speicher (70240H).
> Während der Befehl arbeitet kommt ein Interrupt.
> Welcher Wert wird jetzt als Rücksprungadresse auf den Stack geschrieben?
> Die Lösung bitte als Hexzahl angeben und auch wie du auf sie kommst,
> ohne die Befehlslänge zu kennen.

Dann nimmt man die Befehl Referenz des MC her und schaut wie viele Byte 
der Befehl braucht. Da aber zur Aufgabe wahrscheinlich ein komplettes 
Listig ist (und nicht nur ein Befehl) wird vor dem nächsten Befehl ja 
die Richtige Adresse stehen.
Ohne Listing und ohne Datenblatt geht das nicht (außer man hat es 
auswendig gelernt) Da es sich bei dem Coldfire um ein RISC Architektur 
handelt Tippe ich auf 70244H. Aber da kann der Fragesteller sich mit 
beschäftigen. Mit den Prozessoren kenne ich mich nicht aus.

Autor: Reiner Zufall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mist, ich habe mal gerade Google angeworfen es sind nur 2Byte.
Seite 176:
http://sca.uwaterloo.ca/coldfire/5200PRM.pdf

Autor: Reiner Zufall (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ab Seite 179 und folgende wird das Exeption handling im Detail 
beschrieben.

Ich fasse es immer noch nicht das ich überhaupt gesucht habe. Als ob ich 
nix besseres zu tun hätte. Ich bin dann mal weg.

Erster Link!:

http://lmgtfy.com/?q=coldfire+instuction+set

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Normalerweise ist es auch so.
> Ansonsten müsste man ja den kompletten CPU Zustand sichern. Das würde
> höchst wahrscheinlich länger dauern, als den angelaufenen Befehl zu Ende
> zu führen.

Dann bin ich ja beruhigt.
Ich hatte Deinen anderen Beitrag 
(Beitrag "Re: Assemblerbefehlslänge") anders gedeutet.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es ist ausdrücklich die Uni erwähnt. Damit ist schonmal klar, dass nur
>ausgestorbene oder mindestens 25 Jahre alte CPUs in Frage kommen,
..weil manche Profs hinterm Mond leben

>Die Länge ist in der Tat irrellevant.
Ist es nicht. Eine CPU ist ja umsomehr effizienter, je besser die 
Befehle im OP-code verpackt sind. Ausserdem muss das ganze ja auch aus 
dem Mem geladen werden, und da ist es ein Unterschied ob zB nur 1 Byte 
oder viele Bytes  geladen werden müssen, und das wirkt sich nat. auch 
auf die Taktcyclen aus. --Diskuss. läuft auf CISC <> RISC hinaus--
(Ja, für den Programmierer ist es das egal, aber nicht für'n 
CPU-Designer)


>Die Bearbeitung erfolgt nach dem laufenden Befehl (wobei es in Punkto
>CPU-Design auch denkbar ist, den Befehl abzubrechen und nach dem
>Interrupt neu zu starten..
Es kann auch sein, dass der INT im Cycle-Steal-Mode (**) ausgeführt wird 
(ist schneller als auf das Ende des mom. aktuellen Befehls zu warten)
(**)wobei da nochmal die Frage ist, wieviele Cycles "gestealt" werden

>Da es sich bei dem Coldfire um ein RISC Architektur handelt
Coldfire ist keine reine RISC Architektur , sondern VL-RISC 
(VariableLenghRISC), hat also zT Befehlssatz wie CISC, nicht wie RISC.
Ausserdem ist Coldfire als Nachfolger des 68k gedacht, und der Bef.satz 
ist an 68k angelehnt (und 68k ist alles andere als RISC-Architektur)

>Mist, ich habe mal gerade Google angeworfen es sind nur 2Byte.
Falsch geguggt. Es sind 6 Byte, da ANDI genommen wird (werden muss). 
(ausserdem können es niemals 2 Byte sein, da bereits alleine #imm 4 Byte 
hat)

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mich hier sehr wundert, daß "stke0006" nicht endlich damit 
rausrückt, welcher Prozessor es eigentlich ist.
Da Uni, denke ich auch eher 68xxx als CF.
Die Frage danach tauchte schon am 09.06.2010 23:15 auf und ist immer 
noch unbeantwortet.
Beitrag "Re: Assemblerbefehlslänge"

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was mich hier sehr wundert, daß "stke0006" nicht endlich damit
>rausrückt, welcher Prozessor es eigentlich ist.
"stke0006" hat keinen blassen Schimmer, nach was er sucht!
siehe hier:

>Ganz einfach.
>Besorg dir die Befehlssatzbeschreibung des Prozessors und sieh nach.

darauf "stke0006" :
>Das geht leider nicht das Datenblatt hab ich da stehen nur die allgeime
>Befehle drin.

Er hat also ein "Datenblatt", in dem nur "allgemeine Befehle" stehen....
So ein Quatsch. (Er ist sich wahrscheinlich nichtmal der Tatsache 
bewusst, dass es zig verschiedene CPU-Architekt. gibt)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.