Forum: Mikrocontroller und Digitale Elektronik RISC oder CISC


von Иван S. (ivan)


Lesenswert?

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

von Michael H. (morph1)


Lesenswert?

>>Zur Erleuchterung und Hilfe zur Fragestellung habe ich ein Assembler
>>Quick Referencd Guide beigelegt.

hast du leider nicht :|

von Klaus W. (mfgkw)


Lesenswert?

Иван S. schrieb:
> ...
> Zur Erleuchterung und Hilfe zur Fragestellung habe ich ein Assembler
> Quick Referencd Guide beigelegt.
> ...

nö.
Oder es hat schon jemand weggenommen.

von Klaus W. (mfgkw)


Lesenswert?

2 Deppen, ein Gedanke.

von Иван S. (ivan)


Angehängte Dateien:

Lesenswert?

Shitt, Sorry, mein menschliches Versagen.

von Klaus W. (mfgkw)


Lesenswert?

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

von Klaus W. (mfgkw)


Lesenswert?

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. :-)

von (prx) A. K. (prx)


Lesenswert?

Иван 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.

von Klaus W. (mfgkw)


Lesenswert?

also bisher 2:1 für CISC...

Netter Nebeneffekt: "Erleuchterung" habe ich in meine Liste
der schönen Wörter aufgenommen.

von Иван S. (ivan)


Angehängte Dateien:

Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Иван S. (ivan)


Lesenswert?

Danke, ihr habt mich überzeugt, daß es kein RISC ist. Andererseits nur 
63 Befehle, das hat schon was. Da macht programmieren sicher Spaß.

von Klaus W. (mfgkw)


Lesenswert?

Иван 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...

von Reinhard Kern (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

@  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

von Reinhard Kern (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

von Tobias P. (hubertus)


Lesenswert?

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...

von (prx) A. K. (prx)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

@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.

von Purzel H. (hacky)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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...

von (prx) A. K. (prx)


Lesenswert?

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.

von Tobias P. (hubertus)


Lesenswert?

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...

von (prx) A. K. (prx)


Lesenswert?

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.

von Иван S. (ivan)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Иван S. (ivan)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

Иван 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 ;-).

von Иван S. (ivan)


Lesenswert?

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.

von Иван S. (ivan)


Lesenswert?

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
Noch kein Account? Hier anmelden.