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....
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.
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.)
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.
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.
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...
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.
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.
> 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 ;)
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...
>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.
> 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...
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
>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)
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.
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
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.
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.
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.
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.
> 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.
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.....
>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.
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
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.
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.
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.
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.
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.
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
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
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.
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
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.
>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)
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"
>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)
