Hallo, ich will ja keinen Thread zu Glaubenskriegen hier aufreissen, es geht eher um etwas konkreteres. Und zwar bin ich am Überlegen, ob eine Bestimmte uC-Familie nun eher zu den RISs oder den CISCs gehört. Ganz konkret handelt es sich um die ST7 von ST. Das ist eine von Neumann'sche Maschine mit Akkumulatorarchitektur. Zur Erleuchterung und Hilfe zur Fragestellung habe ich ein Assembler Quick Referencd Guide beigelegt. Ich persönlich würde ja eher sagen, daß es sich um einen RISC handelt. Aber das muß ja nichts heißen. Mit Dank und Gruß, Iwan
>>Zur Erleuchterung und Hilfe zur Fragestellung habe ich ein Assembler >>Quick Referencd Guide beigelegt. hast du leider nicht :|
Иван S. schrieb: > ... > Zur Erleuchterung und Hilfe zur Fragestellung habe ich ein Assembler > Quick Referencd Guide beigelegt. > ... nö. Oder es hat schon jemand weggenommen.
Mehr als die Assemblerbefehle würden mich dazu die Ausführungszeiten der einzelnen Maschinenbefehle interessieren. Wenn die ziemlich durchweg gleich 1 Takt sind, ist es klar RISC. Wenn nicht, CISC. Noch interessanter wäre aber für mich, ob es einen ordentlichen C-Compiler gibt. Dann ist mir RISC oder CISC egal. (Wenn Assembler sein muß, geht sowieso nicht über 68k. nicht weil er CISIC ist, das wäre die 80...-Schiene auch, aber die ist vollkommen krank zu programmieren.)
Bei den address modes und unterschiedlichen Befehlslängen: CISC Nachtrag: Daß ein Prozessor eher schlicht veranlagt ist und z.B. alles über Akkumulator macht, macht ihn noch nicht zu einem RISC-Prozessor, sondern erstmal nur zu einem Primitivling. :-)
Иван S. schrieb: > Ich persönlich würde ja eher sagen, daß es sich um einen RISC handelt. > Aber das muß ja nichts heißen. Ein recht klares Indiz für CISC sind Befehle, die mehr als eine Operation verknüpfen. Operationen wie "addiere", "lade", ... Nun sollte man da nicht päpstlicher sein als der Papst, denn wenn man das streng auslegt bleibt kein RISC mehr übrig, aber eine Architektur, in der ein Grossteil der Operationen eine Ladeoperation und einer Rechenoperation in einem Befehl verknüpfen, kann man demzufolge kaum als RISC bezeichnen. Dass AVR ein paar sehr RISC-untypische Befehle der load-op-store Klasse kennt (setzen/löschen von I/O Bits) ist der Optimierung auf Controller-Anwendungen geschuldet und als Ausnahme anzusehen, die ablaufmässig entsprechenden INC/DEC memory Befehle des ST7 hingegen eher als Regel. Ein definitiver Indikator für CISC ist aber die speicherindirekte Adressierung.
also bisher 2:1 für CISC... Netter Nebeneffekt: "Erleuchterung" habe ich in meine Liste der schönen Wörter aufgenommen.
Klaus Wachtler schrieb: > Mehr als die Assemblerbefehle würden mich dazu die Ausführungszeiten > der einzelnen Maschinenbefehle interessieren. Sorry für die Wartezeit, ich hab mal schnell eben das Assembler Manual unddas Family user guide nach "cycles" durchsucht. Recht viel hab' ich in der kuren Zeit nicht zusammenbekommen, aber das Beispiel (siehe Anhang) könnte DIr vielleicht helfen um zu einer Entscheidung zu kommen. > Wenn die ziemlich durchweg gleich 1 Takt sind, ist es klar RISC. > Wenn nicht, CISC. Hier eher viele zwei-Takter. > Noch interessanter wäre aber für mich, ob es einen ordentlichen > C-Compiler gibt. Dann ist mir RISC oder CISC egal. Klar, mehrere. Ride7 zum Beispiel oder Cosmic C. Eventuell gibts auch was von Keil, aber da bin ich mir nicht sicher > (Wenn Assembler sein muß, geht sowieso nicht über 68k. 68k hab' ich noch nie programmiert. Was ist so schön dran?
Wobei man wohl eher von non-RISC sprechen sollte als von CISC, denn das C passt nicht so sehr. Die RISC/CISC Debatte hatte eher Kisten wie die VAX oder NS32000 im Gegensatz zu MIPS oder Alpha im Auge, als eine Architektur die mehr an die ersten Schritte der Rechentechnik in den 50ern und beginnenden 60ern erinnert, in der Akkumulator-Architekturen des geringen Aufwands wegen recht verbreitet waren.
Klaus Wachtler schrieb: > Wenn die ziemlich durchweg gleich 1 Takt sind, ist es klar RISC. > Wenn nicht, CISC. Nach der Logik bleibt kaum ein RISC übrig. RISC vs. CISC ist eine strukturelle Frage, eine Beurteilung der ISA (Instruction Set Architecture), nicht der Implementierung. Wird denn aus einer prototypischen RISC wie der MISP Architektur eine CISC, wenn sich jemand entschliessen sollte, sie mit einer 8-Bit ALU zu implementieren? Es ist also nicht so entscheidend, wie lang ein Befehl braucht, sondern wie komplex er ist, aus wieviel noch sinnvoll trennbaren Teilschritten er besteht. Besteht der Befehlssatz in hohem Masse aus load-operate und load-operate-store Befehlen, kann man kaum von RISC sprechen, auch wenn's nur 20 Befehle sein sollten.
Danke, ihr habt mich überzeugt, daß es kein RISC ist. Andererseits nur 63 Befehle, das hat schon was. Da macht programmieren sicher Spaß.
Иван S. schrieb: > ... > Hier eher viele zwei-Takter. Nicht RISC. > >> Noch interessanter wäre aber für mich, ob es einen ordentlichen >> C-Compiler gibt. Dann ist mir RISC oder CISC egal. > > Klar, mehrere. Ride7 zum Beispiel oder Cosmic C. Eventuell gibts auch > was von Keil, aber da bin ich mir nicht sicher ok, dann ist mir egal, welcher Prozessor drunter ist :-) > >> (Wenn Assembler sein muß, geht sowieso nicht über 68k. > > 68k hab' ich noch nie programmiert. Was ist so schön dran? Bei Intel-Gegurke und eigentlich selbst bei AVR muß ich dauernd nachblättern, was genau jetzt bei welchem Befehl passiert. Es ist in keinster Weise intuitiv. Das mag großteils dran liegen, daß ich ein schlechtes Gedächtnis habe und vielleicht auch sonst irgendwie unterbelichtet. Kann auch daran liegen, daß ich in meiner zarten Jugend einfach damit geprägt wurde. Aber mit 68000-Assembler schaut man einmal an, wie es gemeint ist, versteht es und programmiert los. Alles ist sauber durchdacht, logisch (manche sagen dazu: orthogonaler Befehlssatz), und irgendwie einprägsam. ADD addiert, MOVE bewegt und SUB subtrahiert. Alles, was daran noch variabel ist, schreibt man in den Befehl rein: ADD.L addiert long-Werte, ADD.W addiert Words, etc.. ADD.L D0,D1 addiert D0 zu D1, Ergebnis nach D1. ADD.W #12,D1 addiert den Wert 12 zu D1 usw.. Es gibt ein paar Datenregister, die sind alle gleichwertig. Ebenso ein paar Adreßregister, alle gleichwertig, außer daß D7 auch SP heißen kann und der Stackpointer ist. Fertig. Das macht man einmal und hat es verstanden; ich kann das herunter beten, auch wenn ich 10 Jahre nicht damit gearbeitet habe. So würde ein Ingenieur einen Prozessor machen. Es entspricht meinem schlichten Gemüt :-) Wenn ich dagegen ein Buch zu Intel-Assembler aufschlage, wird mir schlecht. So etwas einfaches wie ADD oder MOVE gibt es da gar nicht. Jeder Befehl ist über etliche Seiten beschrieben, die liest man durch und schaut erst mal nach, welchen Prozessor man momentan gerade hat, liest nochmal und hat es immer noch nicht verstanden. Es gibt etliche Register, aber jedes ist anders. In den letzten Jahren musste ich gelegentlich Assembler auf Pentium und AVR anfassen. Trotzdem muß ich für jeden Pups ein Handbuch holen und nachschlagen. Gelegentlich taucht hier im Forum jemand auf und will unbedingt mit irgendwas 68000-mäßigem spielen. Alle schreien dann, wozu das gut sein soll, ist doch total veraltet etc.; ich denke mir: "ach wäre das schön, wenn es eine nette Entwicklungsumgebung mit 68k-Controller gäbe". Seufz...
Klaus Wachtler schrieb: > Wenn die ziemlich durchweg gleich 1 Takt sind, ist es klar RISC. > Wenn nicht, CISC. So einfach ist das nicht - es gibt heute Nachkömmlinge von alten Architekturen wie Z80 oder 8051 (ziemlich RISC-unverdächtig, das war noch nicht erfunden), die fast alle Befehle in einem Takt erledigen. Aber deswegen mutieren die ja nicht bei gleichem Befehlssatz plötzlich zum RISC-Prozessor. RISC war nur eine damals neue Strategie, die Prozessorleistung zu erhöhen aufgrund der Erkenntnis, dass Befehle mit der Komplexität von Unterprogrammen nur einem Menschen was nützen, nicht aber einem Compiler, der sowieso alles in kleinste Schritte zerlegt. Ich würde das daher nur als historischen Übergang sehen, den Befehlssatz auf die weitgehende Verwendung höherer Programmiersprachen zu optimieren. Kurz gesagt RISC = Menschen raus. Ist aber dadurch wieder überholt, dass in Hardware gegossene Befehlserweiterungen für Vektorrechnung usw. eben doch schneller sind und daher von einem optimierenden Compiler verwendet werden sollten, egal wie aufwendig der Compiler dadurch wird. Vielleicht kommt ja auch mal wieder ein Verschlankungszyklus, Abwechslung muss sein. Gruss Reinhard
CISC erzeugt weniger Code, da viele Operation im RAM möglich sind, z.B.: CISC: inc adresse RISC: mov register, adresse inc register mov adresse, register Peter
@ Peter Dannegger (peda) >CISC erzeugt weniger Code, da viele Operation im RAM möglich sind, z.B.: Das ist auch nur eine Legende. Denn der Mikrocode muss die Daten genauso aus dem RAM laden, Opertation ausführen, zurückschreiben. Ob das nun selbst vor dem ASM-Programmierer verborgen passiert oder nicht ist egal. >CISC: >inc adresse 8051, olle Gurke >RISC: >mov register, adresse >inc register >mov adresse, register AVR! YEAH! MfG Falk
Klaus Wachtler schrieb: > Gelegentlich taucht hier im Forum jemand auf und will > unbedingt mit irgendwas 68000-mäßigem spielen. > Alle schreien dann, wozu das gut sein soll, ist doch total > veraltet etc.; ich denke mir: "ach wäre das schön, wenn es > eine nette Entwicklungsumgebung mit 68k-Controller gäbe". Hallo, 68er waren vor allem geniale Vermarktung: man lässt einen ganzen Adressraum (I/O) und die zugehörigen Befehle einfach weg und verkauft das Fehlen von Etwas als fortschrittliche Architektur - als ob man nicht mit jedem anderen Prozessor auch memory mapped io machen könnte, wenn es denn so toll wäre. Könnte von Microsoft sein. Erinnert mich an den grossen Fortschritt, Autos ohne Ersatzrad zu liefern. Oder die tolle Idee mit dem 400g-Blähkaffee in grösseren Tüten. Gruss Reinhard
Klaus Wachtler schrieb: > Es ist in keinster Weise intuitiv. Neue formale Definition von "intuitiv": Klaus Waechter versteht es, ohne ins Handbuch gucken zu müssen ;-). > Kann auch daran liegen, daß ich in meiner zarten Jugend > einfach damit geprägt wurde. Über solche Prägungen kann man drüber weg kommen, jedenfalls ich kann das. Ich habe mich schon mit derart vielen Architekturen abgegeben, 68000 inklusive, dass mir das solange egal ist, wie dahinter noch eine gewisse Logik steckt (nur die der 8-Bit PICs hat sich mir noch nicht recht erschlossen). > So würde ein Ingenieur einen Prozessor machen. Aber nur, wenn er das Teil nicht selbst implementieren muss. Eine 68000 ohne Mikroprogrammierung zu implementieren ist der Weg in den Wahnsinn. Und so richtig orthogonal ist das nur, solange man sich nicht auflistet, welcher Befehl welche Adressierungsart zulässt und wie er codiert ist. Motorola hatte sorgsam drauf geachtet, dass nur sinnvoll erscheinende Adressierungsarten zulässig sind (also beispielsweise kein PCrel als Ziel), und solcherlei nicht verwendete Codierungen fröhlich für die Codierung anderer Befehle verwendet. Von allen mir bekannten ISAs (und das sind schon ein paar) hat die 68000 unter den Zeitgenossen die mit Abstand komplexeste Codierung. > Es entspricht meinem schlichten Gemüt :-) Wie gesagt, die Schlichtheit lässt deutlich nach wenn man genauer hinschaut. > beschrieben, die liest man durch und schaut erst mal nach, > welchen Prozessor man momentan gerade hat, Wenn du fair bist, dann schliesst du in diesen Vergleich auch noch sämtliche Nachfolger der 68000 mit ein, also 020,040,060 bis hin zu Coldfire. Und stellt dest, dass du spätestens bei effizienter Programmierung mit 060 sehr genau hinsehen musst, um effiziente und ineffiziente Programmierung unterscheiden zu können, da sich ein Teil der Befehle und Adressierungen der mit der 020 hinzugekommenen Architektur praktisch nicht effizient implementieren lässt. Oder du vergleichst 68000 mit 8086, und lässt die Nachfolger beider Linien weg. Zwar ist dann 68000 mit Abstand besser, aber so arg komplex mit vielen Seiten pro Befehl ist 8086 nicht. PS: Ich habe nichts gegen 68000 und habe mich lang genug damit befasst. Aber ich mache aus einer persönlichen Geschichte kein Dogma, und halte die Entwicklung ab 68020 für einen katastrophalen Fehler.
Etwas OT: Klaus, dann sind wir schon mindestens 2 grosse 68k-Fans hier ;-) Ich habe meine ersten Mikroprozessor-Schritte auf den Dingern gemacht. Und in der Firma hatten wir Mikrocontroller eingesetzt, die auf dem 68k basierten - der 68332 war das hauptsächlich. Dazu gab es einen Debugger und eine tolle C-Programmierumgebung; das Zeug war zwar nicht das neuste vom neusten, aber sehr genial. Insbesondere, wenn ich es mit meiner aktuellen Entwicklungsumgebung für ARM vergleiche... (z.B. hab ich mir extra einen J-Link von Segger gekauft, damit ich ordentlich debuggen kann - die IDE unterstützt den J-Link zwar, aber das Debuggen damit ist ein Krampf - langsam, Breakpoints funktionieren nicht zuverlässig... Ich hätt gern die IAR-Umgebung, aber das dauert dann wieder so lange, bis ich mich da eingearbeitet habe -_-) Wenn du übrigens was mit einer 68k-ähnlichen Architektur machen willst, wäre vielleicht Coldfire was. Sind RISC-Controller, die irgendwie auf 68k basieren, und z.T. dasselbe instruction set haben - sprich beim Programmieren fühlt sich das Ding wie ein echter 68k an. Ich hab mir ein paar solche Chips zugelegt, ich will irgendwann auch mal mit denen was anfangen...
Reinhard Kern schrieb: > Adressraum (I/O) und die zugehörigen Befehle einfach weg und verkauft > das Fehlen von Etwas als fortschrittliche Architektur Ist es auch. Bei einer Architektur (ISA) mit 32-Bit Adressraum und Fokus auf Programmierung in Hochsprachen sind separate Adressräume überflüssig und ekelhaft umständlich. Eine Architektur mit 16-Bit Adressraum aber weit mehr vorgesehenem Speicher (die Zeitgenossen 8086 und Z8000) geht das nicht. Ausserdem steckte in beiden die Tradition 8080/Z80 drin. Motorola musste das nicht. Schon 6800 kam sehr gut ohne aus.
@Reinhard Kern: Ich habe ja auch nicht gesagt, daß aus "alles in 1 Takt" RISC folgt, sondern umgekehrt: wenn viele Befehle nicht in einem Takt erledigt sind, sondern in 1-6, dann ist es eher kein RISC. Und selbst das nur als ein Indiz. Daß sich die das mit (Nach-?) Implementierungen auch ändern kann, ist klar; hier geht es aber um einen Originalprozessor. Es war übrigens nun nicht so, daß nur RISC geschaffen wurde, um den Compilerbauern entgegen zu kommen. Gerade die Adressierungsarten des MC68000 waren 1:1 so gebaut, daß man sie in einem C-Compiler nutzen kann:
1 | struct { int i; int j; } *p; |
2 | ...
|
3 | p->j += 5; |
kann direkt umgesetzt werden in
1 | p: |
2 | DC.l 1 |
3 | ... |
4 | LEA p,A0 |
5 | ADD.L #5,4(A0) |
(oder so ähnlich, ist schon etwas her). Es gibt dazu noch die Steigerung, daß zu einer Basisadresse wie hier A0 noch ein Datenregister addiert wird (z.B. D4) und dazu dann noch wie hier ein fester Wert. Das entspricht dann einem Feldzugriff über die Anfangsadresse, plus aus dem Index berechneten Offset im Feld in D4 als Anfangsadresse einer struct in einem Feld, plus einem konstanten Offset zum Zugriff auf ein bestimmtes Element der struct. Also:
1 | p[i].j += 5; |
resultiert in nur zwei Maschinenbefehlen: 1. Aus i und der struct-Größe einen Offset berechnen (z.B. in D4 speichern), und dann 2. aus diesem Wert, der Anfangsadresse des Feldes und dem Offset von j im Feld eine Stelle im Speicher greifen und 5 addieren. Auf einem RISC-Prozessor ist das mal schnell eine Folge von 20 Befehlen oder mehr. Der langen Rede kurzer Sinn: beides hatte die Intention, Compiler zu unterstützen. Aber die eine Variante kann man auch manuell schön nutzen, die andere ist wohl leichter in Hardware zu gießen.. @A. K.: ja, hast ja auch Recht. Da sehe ich aber keinen Widerspruch zu mir. Die interne Struktur hat hier niemand; als Indizien bleiben nur Äußerlichkeiten.
Die RISC/CISC Diskussion war in den 80-ern aktuell. Eine CISC maschine hat eine Mikrocode Maschine, die zusammengesetzte Befehle nach aussen als einfach darstellt. Toll war zB der Loop_CX Befehl der x86 Serie. Dieser ASM Befehl hat einen Zahler decrementiert, auf null getestet und ist an die bedingte Stelle gesprungen. In diesen 30 Jahren hat sich einiges geaendert. Auch ein einfacher Controller kann schon den MAC (multiply-add) Befehl. Ganz moderne Controller haben nun Events, damit kann man Interrupts in Hardware bearbeiten, und so auch bei hohen Interruptraten die CPU entlasten.
Tobias Plüss schrieb:
> wäre vielleicht Coldfire was. Sind RISC-Controller,
Naja, sagen wir mal Freescale nennt sie RISC, weil das irgendwoe
moderner klingt und die einfacher sind als 68020 oder CPU32. Nix gegen
Coldfire, die sind durchaus ok, jedenfalls in der korrigierten Version
der Architektur, aber die als RISC zu sehen fällt mir verdammt schwer.
Tobias Plüss schrieb: > Etwas OT: > > Klaus, > dann sind wir schon mindestens 2 grosse 68k-Fans hier ;-) > Ich habe meine ersten Mikroprozessor-Schritte auf den Dingern gemacht. > Und in der Firma hatten wir Mikrocontroller eingesetzt, die auf dem 68k > basierten - der 68332 war das hauptsächlich. Dazu gab es einen Debugger > und eine tolle C-Programmierumgebung; das Zeug war zwar nicht das neuste > vom neusten, aber sehr genial. Insbesondere, wenn ich es mit meiner > aktuellen Entwicklungsumgebung für ARM vergleiche... (z.B. hab ich mir > extra einen J-Link von Segger gekauft, damit ich ordentlich debuggen > kann - die IDE unterstützt den J-Link zwar, aber das Debuggen damit ist > ein Krampf - langsam, Breakpoints funktionieren nicht zuverlässig... Ich > hätt gern die IAR-Umgebung, aber das dauert dann wieder so lange, bis > ich mich da eingearbeitet habe -_-) > > Wenn du übrigens was mit einer 68k-ähnlichen Architektur machen willst, > wäre vielleicht Coldfire was. Sind RISC-Controller, die irgendwie auf > 68k basieren, und z.T. dasselbe instruction set haben - sprich beim > Programmieren fühlt sich das Ding wie ein echter 68k an. > Ich hab mir ein paar solche Chips zugelegt, ich will irgendwann auch mal > mit denen was anfangen... Ich habe ja momentan keinen Bedarf dafür, leider. Aber gerade über deine Mails u.a. in letzter Zeit wurde ich schon wieder gierig und habe erst realisiert, daß es mit Coldfire und CPU32 ja auch noch sinnvolle Relikte gibt. Irgendwie macht mich das etwas nervös...
No Way schrieb: > Die RISC/CISC Diskussion war in den 80-ern aktuell. Eine CISC maschine > hat eine Mikrocode Maschine, die zusammengesetzte Befehle nach aussen > als einfach darstellt. Oder auch ohne Mikrocode, wenn man masochistisch genug veranlagt ist. So wie Zilog, die sich ohne dessen Hilfe mit der Z8000 abkämpften (und dadurch verzögerten). > In diesen 30 Jahren hat sich einiges geaendert. Auch ein einfacher > Controller kann schon den MAC (multiply-add) Befehl. Das hängt auch damit zusammen, dass eine zusätzliche Addition in einem MAC Befehl bei einem kombinatorischen Multiplizierer keine zusätzliche Zeit und zumindest in der Recheneinheit nur wenig zusätzlichen Aufwand kostet, so dass MAC viel schneller ist als MUL+ADD. Aufwendiger ist da eher der zusätzliche Port beim Registerzugriff. ARM hatte an dieser Stelle ins Klo gegriffen, als sie die dynamischen Shifts mit einem zusätzlichen Register implementierten, dafür aber den Befehlsablauf durcheinander brachten.
Jau, CPU32 ist ziemlich gut. Der 68332 ist ein schöner Prozessor; schade daran ist, dass das interne RAM nur 2k gross ist. Irgendwo habe ich hier noch einen Tray '332er.... man könnte ja mal ein Board dafür anfertigen. Allerdings bin ich im Moment noch mit einem ARM-Board befasst, anschliessend könnte man aber darüber nachdenken. Der 332er wird sogar noch hergestellt, aber ich hab mal aus zuverlässiger Quelle gehört, dass er in circa 2 Jahren abgekündigt wird...
Falk Brunner schrieb: >>CISC erzeugt weniger Code, da viele Operation im RAM möglich sind, z.B.: > > Das ist auch nur eine Legende. Denn der Mikrocode muss die Daten genauso > aus dem RAM laden, Opertation ausführen, zurückschreiben. Dynamisch weniger Code (Zeit): nein. Statisch weniger Code (Platz): u.U. ja. Und bei Controllern zählt der Platz oft mehr als die Zeit.
Kann zum ST7 noch jemand etwas sagen? 63 Befehle ist ja nicht gerade viel, IMO. Warum geht das eben nicht als Reduced Instruction-Set Computing durch? Siehe auch nochmal das Codebeispiel oben.
IBM hatte anno POWER das Akronym RISC ebenfalls beansprucht, aber etwas kreativ anders interpretiert. Denn von wenig Befehlen konnte da schon anfangs keine Rede sein. Trotzdem ist die Einstufung RISC korrekt. Daher kann man IBM recht geben, die Bedeutung RISC = Reduced Instruction Set Complexity trifft es genauer. M.a.W: Die Anzahl der Befehle ist irrelevant, es ist die Simplifizierung des Ablaufs die zählt, also die Komplexität der einzelnen Befehle.
A. K. schrieb: > Daher kann man IBM recht geben, die Bedeutung RISC = Reduced Instruction > Set Complexity trifft es genauer. Danke, dieser Meinung kann ich mich ddurchaus anschließen > M.a.W: Die Anzahl der Befehle ist irrelevant, es ist die Simplifizierung > des Ablaufs die zählt, also die Komplexität der einzelnen Befehle. Im Fred hat sich so herausgestellt, daß der ST7 ein non-RISC ist, aber eventueller Weise auch nicht unbeding tein CISC. Wie könnte Man(n) sowas nennen? FARN - Fine Aritekture Reduced Nomenclatura?
Иван S. schrieb:
> Wie könnte Man(n) sowas nennen?
Typische Akkumulator-orientierte Architektur.
Älteren Semestern beschreibt man sie am einfachsten als modernisiertes
6502-Pendant die sich Ivan zuliebe mit Zilogs Mnemotechnik tarnt ;-).
A. K. schrieb: > Älteren Semestern beschreibt man sie am einfachsten als modernisierte > 6502 die sich Ivan zuliebe mit Zilogs Mnemotechnik tarnt ;-). You Made My Day. Thank you for that! Your're welcome.
A. K. schrieb: > > Älteren Semestern beschreibt man sie am einfachsten als modernisiertes > 6502-Pendant die sich Ivan zuliebe mit Zilogs Mnemotechnik tarnt ;-). Artikel ST7 aktualisiert.
Bitte 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.