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
stke0006 schrieb: > und so weiter wie man da am besten vorgeht. Ganz einfach. Besorg dir die Befehlssatzbeschreibung des Prozessors und sieh nach.
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.
Erstmal, welcher Prozessor ist es? Dann such dir die Befehlstabelle und nicht das Datenblatt.
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 ;)
ich hoffe nur, dass für einen solchen Dummfug nicht auch noch Studiengebühren kassiert werden!
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.
Mist, ich habe mal gerade Google angeworfen es sind nur 2Byte. Seite 176: http://sca.uwaterloo.ca/coldfire/5200PRM.pdf
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)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.