Wieso spricht man bei den 8 Bit-AVRs von RISC?

Das Takt-Argument stammt aus grauer Vorzeit, als die damaligen CISC 
Architekturen durchweg viele Takte pro Befehl benötigten.

Ein besseres Kriterium als die Anzahl Taktzyklen ist die Trennung in 
Load/Store-Operationen einerseits und vergleichsweise einfache 
Operationen auf eher vielen Registern andererseits.

Damit in Zusammenhang ist auch die Komplexität der Operationen zu sehen. 
Sowas wie Additionen zum Speicher hin, also load-execute-store, finden 
sich bei RISCs selten - Ausnahme ist hier AVR, weil dessen Einsatzgebiet 
diese Methode bei manchen I/O-Operationen wirklich nahe legt.

Um im Bereich AVR zu bleiben, kann man sie mit Architekturen wie den 
68HC11/12 und STM8 vergleichen, oder den teilweise überbordend komplexen 
Renesas R8C..M32C (16-Bitter).

1 Punkt für Gryffindor schrieb:
> Wenn ich es richtig verstehe brauchen RISC meistens nur 1 Zyklus je
> Befehl im Gegensatz zu den CISC die je nach Komplexität des Befehls
> mehrere Taktzyklen brauchen.

So in etwa.

> Wenn man sich bspw. die Instruktion von
> einem beliebigen Atmega anschaut fällt einem doch auf das viele Befehle
> deutlich mehr als nur 1 Taktzyklus brauchen.

Reine Fake News! Schau einfach mal das Instruction Set Summary an, da 
sieht das bei MIR anders aus! Fast alle Logisch/Arithmetischen Befehle 
brauchen nur 1 Takt. Sprich fast alles, Was mit Registern arbeitet. 
Load/Store zum SRAM dauert halt 2-3 Takte, Sprungbefehle 2-4, 
Multiplikationen 2. Das ist schon SEHR nah am Lehrbuch von RISC! Siehe 
Anhang.

Die wesentliche Entscheidung ist, ob du Befehle mit (mehr oder minder) 
beliebig langer Ausführungszeit dabei hast, weil da irgendein 
Mikroprogramm in der CPU abläuft (DJNZ beim Z80, REP xxx beim 80x86), 
oder ob die Ausführungszeit der Befehle von vornherein feststeht und 
unabhängig von den Operanden ist.

Beim "klassischen" RISC hattest du halt nur 1-Zyklus-Befehle, dafür ließ 
sich nie die ganze Busbreite in einem Befehl als Adresse laden. Man muss 
dann low- und high-Teil separat laden, oder sie indirekt aus 
PC-relativen Daten laden.

Der AVR braucht für den RAM-Zugriff ohnehin immer (mindestens) einen 
zweiten Taktzyklus, aber wieviel er braucht, ist definiert und hängt 
nicht von den Operanden ab. Insofern ist das schon noch "irgendwie" 
RISC. Wenn du eine Schleife brauchst (äquivalent zu den genannten 
CISC-Befehlen, musst du sie dort immer separat programmieren.

1 Punkt für Gryffindor schrieb:
> je nach Komplexität des Befehls

Wie sieht's aus mit der Orthogonalität?
Ich sehe da eine Tendenz und auch Zusammenhang.

Auf RISC-Prozessoren sind oft Operatoren als Maschinenbefehl nicht mit 
allen Adressierungsarten und/oder Adressbereichen möglich.

Bei CISC-Maschinen gibt es eine Tendenz zu voller Orthogonalität. Kann 
man auch mit Microcode machen.

Mit Microcode kann man daher einen RISC-Kern auch zu einem CISC 
aufpusten und nebenher volle Orthogonalität bereitstellen.

Oder sehe ich das falsch?

mfg mf

1 Punkt für Gryffindor schrieb:
> Danke für die Übersicht. Mir war nicht klar dass man Branches und
> Load/Store Instruktionen bei diesem Vergleich nicht mitzählt. Dachte
> wenn auch nur 1 Befehl mehr als 1 Zyklus dauert spricht man nicht mehr
> von RISC.

Ein ausgeführter Sprungbefehl braucht auch bei anderen RISC mehr als 
einen Takt. Aber die sind tiefer gepipelined als beim AVR, um das 
möglichst zu verbergen.

Die frühen MIPS beispielsweise arbeiten zweigleisig, um den zweiten Takt 
zu verstecken. Der Befehl direkt nach dem Sprungbefehl, im sogenannten 
Delay Slot, wird in jedem Fall noch ausgeführt, während parallel dazu 
der erste Befehl des Sprungziels aus dem Speicher gezogen wird.

Bei Loads läuft bei denen das ähnlich. Auch die brauchen einen Takt 
länger, können das aber im Idealfall verbergen. Bei denen darf man im 
nachfolgenden Befehl nicht auf das Zielregister des Loads zugreifen, 
weil die Daten zu diesem Zeitpunkt noch nicht vorliegen. Andere RISC 
erkennen einen Ressourcenkonflikt und blockieren die Pipeline, bis die 
Daten vorliegen. Diese alten MIPS hingegen liefern dann einfach Mist ab.

michael_ schrieb:
> Ein 4-MHz AVR ist etwa ganz grob mit einem 12MHz 8051 zu vergleichen

Guter Durchschnitt und gutes Augenmaß, wenn der ROM und auch der RAM mit 
der Geschwindigkeit mithalten.

Hässlich wird's, wenn der Flash so lahm ist, dass es Waitstates ohne 
Ende gibt.

Auf Arbeit war eine von MotoFreescaleNXP 16bitter auf Cortex-M3 
portierte Applikation plötzlich alles andere als Echtzeit-fähig. Viele 
32bit-Operationen; Core-Takt war vegleichbar schnell eingestellt.
Die Kollegen haben viel geflucht
und Wochenendstunden viel gebucht.

mfg mf

michael_ schrieb:
> Ein 4-MHz AVR ist etwa ganz grob mit einem 12MHz 8051 zu vergleichen.
> Für ähnliche Operationen.

Das wage ich geflegt zu bezweifeln. ;-) Vor allem, da es vom 8051 
mittlerweile Dutzende Versionen mit überaus unterschiedlicher Leistung 
gibt. Das Original braucht 12 Oszillatortakte/Maschinentakt, die meisten 
neueren nur 6, einige SuperDuper Varianten nur 2! Und für die Bewertung 
REALER CPU-Leitung reicht es nicht, einzelne Operationen zu vergleichen, 
da braucht man eher ganze Funktionen bzw. Algorithmen. Und da kann der 
AVR u.a. mit seinen schier endlosen Registern (32!) massiv punkten. Der 
olle 8051 hat nur Akku, B und sonst fast nix. EIN Pointer Register. Der 
AVR hat drei! Jaja, ich weiß daß der RAM relativ "schnell" und direkt 
adressiert werden kann. Soll keine sinnlose Diskussion zum Thema AVG 
gegen 8051 werden.

P S Insomnia

Falk B. schrieb:
> Und da kann der
> AVR u.a. mit seinen schier endlosen Registern (32!) massiv punkten. Der
> olle 8051 hat nur Akku, B und sonst fast nix.

Naja, Neben A und B hat er auch R0 bis R7. Diese kann man in 4 Banken 
umschalten -> 32 Register. Außerdem können Additionen, Subtraktionen, 
Vergleiche und logische Operationen direkt in den 256 Bytes RAM 
ausgeführt werden.

> EIN Pointer Register.

Du meinst R0+R1 (8-Bit)(x4 Banken) oder DPTR (16-Bit)?
Einige Derivate haben sogar zwei DPTR.

> Der AVR hat drei!

Aber nur Z für Flash (LPM)

Der 8051 kann teilen! In 4  Systemzyklen bzw. 48 Takte.
Ein mit 4 MHz getakteter AVR hätte 16 Takte um das in der selben Zeit zu 
erledigen.
Er braucht etwas länger.

Ich halte 4 MHz AVR zu 12 MHz Standard-MCS51 schon für passend.

Natürlich gibt es auch 100MHz single-cycle 8051. Die basieren dann aber 
auch auf Risc-Techniken. Aber die werden wohl kaum gemeint gewesen sein.

Achim M. schrieb:
> Hässlich wird's, wenn der Flash so lahm ist, dass es Waitstates ohne
> Ende gibt.

Das gibt es bei den Controllern mit integriertem Flash eigentlich nicht 
(beim AVR auf gar keinen Fall) und beim Std. 8051 mit ext. ROM ist das 
auch kein Thema, weil es da sowieso gemütlich abläuft.
Wenn man natürlich so eine 100MHz single-cycle Rakete mit einem externen 
EPROM mit 250ns verbinden möchte, dann ist man selbst Schuld.

Was mir noch bei 8051 gefällt: Bitadressierbares RAM und SFR
Und nur einen Kopierbefehl: MOV - was beim AVR MOV, LD(I), ST, IN und 
OUT ist ...


Ich habe im übrigen letztens betrübt feststellen müssen, dass ein AVR 
mit 20 MHz ein 16-Bit Businterface in SW schneller bedienen kann, als 
der M68k nativ mit 8 MHz Takt. Ich hätte den M68k gerne nochmal 
eingebaut.


Gruß
Jobst

Achim M. schrieb:
> Hässlich wird's, wenn der Flash so lahm ist, dass es Waitstates ohne
> Ende gibt.

Ist vei Flash halt das generelle Problem. Wird beim AVR noch dadurch 
verschärft, dass man eben nicht als Workaround mal zeitkritischen Code 
aus dem RAM ausführen kann, wie man das bspw. beim ARM macht. Außerdem 
kann man bei dem (thumb mode) oft zwei Befehle mit einem flash read 
bekommen.

Jörg W. schrieb:
> Wird beim AVR noch dadurch
> verschärft, dass man eben nicht als Workaround mal zeitkritischen Code
> aus dem RAM ausführen kann,

Der führt sein Programm aus dem Flash mit 1 Cycle/Befehl aus.
Was genau soll da bei einer hypothetischen Ausführung aus dem Ram noch 
schneller werden?
(Ok, eigentlich sind es ja schon 2 Cycles/Befehl, aber dank einstufiger 
Pipeline werden es dann effektiv nur einer).

Oliver

> Die frühen MIPS beispielsweise arbeiten zweigleisig, um den zweiten
> Takt zu verstecken. Der Befehl direkt nach dem Sprungbefehl, im
> sogenannten Delay Slot, wird in jedem Fall noch ausgeführt,
> während parallel dazu der erste Befehl des Sprungziels aus dem
> Speicher gezogen wird.
So ein ähnliches Prefetching macht der 80486 auch. Das kann merkwürdige 
Effekte erzeugen, etwa wenn man Code im Hauptspeicher dynamisch 
modifiziert. Wenn die geänderte(n) Adresse(n) bereits von der CPU in die 
Pipeline eingelesen wurden (und diese nicht durch bspw. einen Sprung neu 
geladen wird), führt die CPU den "alten" Code aus und nicht das, was 
nach der Änderung im Hauptspeicher steht. Obs der Pentium-1 (P55C) noch 
macht, weiß ich nicht, ich weiß nur noch, daß ich mit einer der beiden 
CPUs mit diesem Effekt herumgespielt habe.

Falk B. schrieb:
> olle 8051 hat nur Akku, B und sonst fast nix. EIN Pointer Register

Möchtest du noch einmal in das Datenblatt sehen? Wozu hat er bloss die 
"Select Registerbank" Befehle? Und Register 0 und 1 als Index Register?
Mit dem Keil Compiler ist das Ding recht leistungsfähig, vor allem wenn 
man das Alter bedenkt. Wenn das Ding so grottig wäre, wie oft und gern 
dargestellt, würde es heute doch nicht mehr gebaut werden.

Oliver S. schrieb:
> Jörg W. schrieb:
>> Wird beim AVR noch dadurch
>> verschärft, dass man eben nicht als Workaround mal zeitkritischen Code
>> aus dem RAM ausführen kann,
>
> Der führt sein Programm aus dem Flash mit 1 Cycle/Befehl aus.
> Was genau soll da bei einer hypothetischen Ausführung aus dem Ram noch
> schneller werden?

Die Digitallogik der CPU könnte man halt problemlos schneller bekommen, 
die Flash-Zugriffe nicht. Das limitiert die erreichbare 
Gesamtgeschwindigkeit deutlich nach oben.

Naja, es limitiert den Takt, mit dem die Flash-gefütterte CPU arbeiten 
kann, aber nicht die Geschwindigkeit der CPU bei vorgegebenen Takt. Mir 
fallen auch nicht viele Dinge ein, wo ein AVR heute sinnvoll eingesetzt 
werden kann und wo der dabei an seine Leistungsgrenze kommt. Ich weiß 
nicht wer ernsthaft sowas wie eine FFT auf dem Ding rechnen will oder 
was auch immer.

Ben B. schrieb:
> Mir fallen auch nicht viele Dinge ein, wo ein AVR heute sinnvoll
> eingesetzt werden kann und wo der dabei an seine Leistungsgrenze kommt.
> Ich weiß nicht wer ernsthaft sowas wie eine FFT auf dem Ding rechnen
> will oder was auch immer.

Immerhin so ernsthaft, dass Funkamateure mittlerweile auf ATmega328 ein 
komplettes SDR (Sende- und Empfangsseitig inklusive 
SSB-Modulation/Demodulation, wenngleich auch mit nicht sehr toller 
Sprachqualität) damit implementiert haben. Da habe ich selbst gestaunt, 
ich mag die AVRs, aber das hätte ich ihnen nicht zugetraut.

Aber ja, ich gebe dir Recht, wenn man compute power braucht, nimmt man 
eher was anderes.

Max M. schrieb:
> Alles ein Kind seiner Zeit

Wer sagt, daß diese Zeiten nicht noch viel länger andauern?

Jörg W. schrieb:
> mittlerweile auf ATmega328 ein komplettes SDR (Sende- und Empfangsseitig
> inklusive SSB-Modulation/Demodulation, wenngleich auch mit nicht sehr
> toller Sprachqualität) damit implementiert haben. Da habe ich selbst
> gestaunt, ich mag die AVRs, aber das hätte ich ihnen nicht zugetraut.

Ben B. schrieb:
> Mir fallen auch nicht viele Dinge ein, wo ein AVR heute sinnvoll
> eingesetzt werden kann und wo der dabei an seine Leistungsgrenze kommt.

Mir langen für fast alle Anwendungen 2 bis 4, maximal 8 MHz. Das Teil 
hat genügend Leistung verfügbar wenn man diese nicht ungeschickt 
programmtechnisch verbrät.

CISC wurde auf möglichst kleinen Programmcode optimiert, RISC auf kurze 
Befehlszeit.
Den Unterschied habe ich sehr deutlich gesehen, als ich versucht habe, 
Anwendungen vom AT89C2051 auf den ATtiny2313 zu portieren. Da ging mir 
regelmäßig der Flash aus. Und der ATtiny4313 kam leider erst viel zu 
spät.

Der 8051 ist darauf optimiert, möglichst viel in den 128 Bytes direct 
RAM zu verarbeiten und XDATA nur für große Puffer zu benutzen. Dann 
erhält man auch sehr kompakten und schnellen Code.

Ich find eben auch, daß ein AVR für sein Einsatzgebiet mehr als genug 
Bumms hat, vor allem wenn man das Potential seiner integrieren 
Hardware-Module zusammen mit dem breiten Interrupt-Spektrum nutzt und 
nicht z.B. SPI oder FastPWM in Software macht.

Klar gibt's immer Freaks, die mit sowas Dinge möglich machen, die vorher 
komplett unmöglich erscheinen. (Ich erinnere mal an den C64 mit seinen 
Demos, was mit der Kiste in ihren späten Jahren veranstaltet wurde, 
hatten Yannes (SID), Charpentier (VIC-II), und Tramiel (Commodore) 1982 
bestimmt nicht auf dem Schirm.) Solchen Leuten möchte ich auch auf 
keinen Fall ihre Fähigkeiten oder die Sinnhaftigkeit ihres Projekts 
absprechen, aber da würde jeder verstehen, wenn man für sowas heutzutage 
einen dickeren ARM-Controller nimmt.

Das für mich relevanteste Limit insbesondere bei den kleinen AVRs ist 
die RAM-Größe. Da wünscht man sich schon ab und an etwas mehr bzw. muß 
sein Programm so auslegen, daß es mit dem was da ist klarkommt.

Ben B. schrieb:
> Das für mich relevanteste Limit insbesondere bei den kleinen AVRs ist
> die RAM-Größe. Da wünscht man sich schon ab und an etwas mehr bzw. muß
> sein Programm so auslegen, daß es mit dem was da ist klarkommt.

Die neueren AVR128Dx kommen nun mit 16kB. Welche Deiner AVR Anwendungen 
braucht warum wirklich mehr? Mir fällt keine ein. Datenintensivere Dinge 
wie Grafikdisplay, Datenbank, hochbittige analoge Signalverarbeitung 
usw. macht man sowieso nicht mit AVR...

Stefan ⛄ F. schrieb:
> RISC ist ein Marketing Begriff.

Heute vielleicht. Als der Begriff geprägt wurde, nicht. Der Rest dazu 
steht in der Wikipedia.

Oliver

> Das Interrupt-Systerm beim AVR ist katastrophal.
Erläutere Deine Meinung bitte mal. Ich finde es für einen 8Bit-µC 
ziemlich gelungen und hatte noch nie ein größeres Problem damit.

> Die neueren AVR128Dx kommen nun mit 16kB.
16kB bekommt man auch im bastelfreundlichen ATMega1284.

> Welche Deiner AVR Anwendungen braucht warum wirklich mehr?
Es gab z.B. Entwicklungen eines Webservers auf Basis eines ATMega644. 
Der hat nur 4kB RAM und das wird knapp wenn man eine größere dynamische 
HTML-Seite z.B. in einen Sendepuffer laden möchte. Man erreicht schnell 
den Punkt wo das nicht geht und einige Teile der Seite direkt aus dem 
Flash gesendet werden müssen.

> Grafikdisplay
Das kann man mit einem AVR von der Rechenleistung her locker machen, vor 
allem wenn das Display mittels SPI angebunden wird. Aber stimmt 
natürlich, bei kleinen AVRs wird das aufgrund der RAM-Größe ein 
ziemliches Gebastel im Programm, vor allem wenn man irgendwas zeichnen 
will, was sich für sich alleine schon nicht im RAM ablegen lässt. Wenn 
der Datenbus schnell genug ist, kann man komplett im Grafik-RAM des 
Displays arbeiten... aber schön ist was anderes.

MCUA schrieb:
>>> Das Interrupt-Systerm beim AVR ist katastrophal.
>>Erläutere Deine Meinung bitte mal. Ich finde es für einen 8Bit-µC
>>ziemlich gelungen und hatte noch nie ein größeres Problem damit.
> Das hat nicht unbedingt was mit der Grösse/Breite der CPU zu tun.
> Der AVR unterstützt nicht mehrere indiv. schaltbare/zuweisbare
> INT-Prioritäten!

Stimmt. Aber das hat ihn nicht davon abgehalten, millionenfach sehr 
erfolgreich zu sein. Diese Entscheidung gegen Interruptprioritäten für 
einen einfacheren Interruptcontroller wurde bewußt getroffen und scheint 
in der Praxis auch selten ein Problem zu sein. Außer für Leute wie dich.

Hallo,
Stefan ⛄ F. schrieb:
> RISC ist ein Marketing Begriff. Irgendwann hat mal eine Firma einen
> Prozessor mit ungewöhnlich simplen Befehlssatz auf den Markt geworfen
> und brauchte dazu Verkaufsargumente...

Das ist kompletter Quatsch! Mach dich mal schlau wo das RISC-Konzept 
entwickelt wurde und warum.

Stefan ⛄ F. schrieb:
> Ich wetter es gibt inzwischen mehr Prozessoren, die ein bisschen CISC
> und ein bisschen RISC sind, als eindeutig einer der beiden Kategorien
> zuweisbar.

Das trifft auf alle modernen Hochleistungsprozessoren zu.

rhf

MCUA schrieb:
> Der AVR unterstützt nicht mehrere indiv. schaltbare/zuweisbare
> INT-Prioritäten!

Das habe ich auch nicht verstanden, warum man damals diesen Rückschritt 
gemacht hat. Schon die alten 8051 hatten mindestens 2 oder 4 Level, die 
ich auch fleißig benutzt habe. Es macht das Programmieren sehr bequem, 
wenn man mehrere Ausführungsebenen hat, wo die jeweils anderen keinerlei 
Rücksichten nehmen müssen.
In einem älteren Gerät wurde z.B. ein Ton per Timerinterrupt erzeugt. 
Durch die anderen Interruptquellen klang der Ton unsauber. Einfach das 
PT0-Bit gesetzt und schon war der Ton klar.

Beim AVR war das ein riesen Heckmeck, in jedem unteren Interrupt alle 
unteren Interrupts zu sperren, um per SEI nur die höheren wieder 
freizugeben und am Schluß alles wieder rückwärts. Das war nicht nur 
aufwendig, sondern auch fehlerträchtig.

Bei den ARM sind ja 16 oder 256 Interruptlevel Standard.

Ben B. schrieb:
> So ein ähnliches Prefetching macht der 80486 auch

Prefetching und Delay Slot sind wirklich verschieden.

> In einem älteren Gerät wurde z.B. ein Ton per Timerinterrupt erzeugt.
Ja sorry, wer macht denn so einen Mist auch. Dafür kann man besser einen 
Timer im PWM-Modus nehmen oder einen Piepser, der mit nackten 5 bzw. 
3,3V leben kann.

Was ich mit den Interrupts beim AVR mache sind alles kurz gehaltene 
Routinen, keine langen Rattenschwänze.

Also entweder schiebt man der seriellen Kommunikation ein neues Byte in 
den Sendepuffer oder holt eines aus dem Empfangspuffer ab und speichert 
es weg oder ich stelle mir eine stabile Zeitbasis damit hin (z.B. 10 
oder 100Hz), setze mir ein "Taste X gedrückt"-Flag wenn man das 
interruptbasiert haben will...

Die möglicherweise zeitintensiveren Aufgaben laufen alle in der 
Hauptschleife.

Äh... nein. Die Zeitbasis stellt mir nur ein Flag, daß ein Zeitabschnitt 
durchlaufen wurde und wenn ich es ganz genau brauche (z.B. für eine Uhr) 
dann wird diese ebenfalls im Interrupt berechnet (oder zumindest ein 
Zähler inkrementiert), damit durch ein "doppelt gesetztes" Flag nichts 
verlorengeht wenn in der Hauptschleife mal was länger dauern sollte.

Wenn man regelmäßig was im µs-Bereich braucht, dann wirds Zeit für einen 
schnelleren Controller. Meine, man kann sich auch beim AVR Interrupts 
mit 300..500kHz reinballern lassen, aber irgendwann geht ein 
beträchtlicher Teil der Rechenzeit nur für die Bearbeitung dieser 
Interrupts drauf. 20MHz/500kHz sind nur 40 CPU-Takte zwischen den 
Interrupts.

Max M. schrieb:
> Aber was ist der Sinn

Der Sinn ist: Sie sind viel einfacher zu programmieren und kommen mit 
sehr netten bastlerfreundlichen Details wie 5V, DIL Gehäusen und 
besonderer Robustheit :)

> Ja, ich habe mal auf dem Dreirad angefangen,

Schlechter Vergleich!

Ben B. schrieb:
> 16kB bekommt man auch im bastelfreundlichen ATMega1284.

... der vom Gehäuse allerdings viel größer ist und dem auch sonst viele 
interessante Features der Neuen fehlen.

Ben B. schrieb:
> Es gab z.B. Entwicklungen eines Webservers auf Basis eines ATMega644.
> Der hat nur 4kB RAM und das wird knapp

Sowas hab ich auch noch auf AVR Basis am Laufen. Mit dem 4fachen schauts 
für ein paar statische Seiten schon deutlich besser aus, für viel mehr 
ist so ein AVR aber nun wirklich ungeeignet.

Hehe. Ich wollte immer ein Minimal-System mit dem 68000 in seinem 
DIP-Gehäuse auf Lochraster basteln, einfach weil's ein so gigantisch 
großer Schaltkreis ist. Allerdings ist da nie was draus geworden. Ich 
habe nicht mal so eine CPU für die Sammlung bekommen und die 
Minimalbeschaltung von dem Ding, damit der evtl. nur ein paar LEDs 
betreiben oder sowas wie eine Uhr anzeigen kann, ist gar nicht so wenig 
wenn ich mich da korrekt erinnere.

Max M. schrieb:
> für einen Arduino nano mit IDE hätte man 1990

Die IDE hätte man aber auch schon damals der Oma gleich 
hinterhergeworfen...

Oliver

Stefan ⛄ F. schrieb:
> RISC ist ein Marketing Begriff.

Nö.

RISC entstand einerseits öffentlich als Reaktion auf Prozessoren wie der 
VAX, die den Höhepunkt überbordender aber nachweislich sinnarmer 
Komplexität darstellten. Andererseits insgeheim im IBM Labor, in John 
Cocke festgestellte, dass man den Aufwand für die Implementierung 
komplexer Maschinen in anderer Form sinnvoller investiert.

Die Situation heute ist etwas anders. Dir RISCs sind komplexer geworden. 
Die überlebenden CISC haben durch eine radikale veränderte 
Mikroarchitektur und massenhaft Transistoren die Probleme in den Griff 
bekommen.

Stefan ⛄ F. schrieb:
> Lust L. schrieb:
>
>> der vom Gehäuse allerdings viel größer ist
>
> Was ich gerade als Vorteil empfinde. Mit dem 2,54mm Raster komme ich
> viel besser zurecht. Miniaturisierung überlasse ich der Industrie, das
> ist nicht keine Welt.

Ich glaube Du weißt gerade nicht wovon Du redest. Die AVR128Dx28 haben 
ein SmallDIP Gehäuse mit ebendiesem Raster 😉

Die winzigen 1614er Tiny möchte ich hier auch ausdrücklich empfehlen. 
Zwar SMD aber mit äußerst bastler-lötfreundlichem Pinabstand!

MCUA schrieb:
> Das wäre nicht so, gäbe es mehrer Prio-Ebenen!

Die neueren AVRs haben derer zwei.

> [Interrupts]
> Dann wird das nämlich vom AVR verschlafen.
Normalerweise "merkt" sich der AVR den zweiten Interrupt, der wird dann 
ausgeführt wenn das Programm vom ersten Interrupt in die Hauptschleife 
zurückkehrt. Wirklich einziger Nachteil dabei, man kann sich ins Bein 
schießen wenn z.B. die Interruptfreigabe beim letzten über eine serielle 
Schnittstelle übertragenen Byte nicht zurückgenommen wird. Dann kann man 
es schaffen, daß dauerhaft Interrupts ausgelöst werden weil der 
Sendepuffer dauerhaft leer bleibt und der Controller an dieser Stelle 
klebenbleibt.

Was natürlich schwierig ist, wenn die Interruptroutinen voneinander 
abhängig sind. Also eine schafft die Vorbedindungen für eine andere und 
beide werden zeitgleich ausgelöst. Dann hat man keine echte Garantie, 
daß die für die Vorbedingungen zuerst ausgeführt wird. Allerdings hab 
ich sowas noch nie wirklich gebaut.

Idiotengriller schrieb:
> Es ist halt die Frage ... ob pipelines
> im Spiel sind

Noch ein Punkt für AVR.
Berechenbarer Determinismus in der Code-Abarbeitung. Mangels Pipeline.

Anders ausgedrückt: Ein Lob der Langsamkeit. Geht nämlich nur, so lange 
der Takt langsamer ist als das Flash, will man den Code nicht in RAM 
kopieren.

(prx) A. K. schrieb:
> Ein Lob der Langsamkeit.

Was reicht das reicht doch.
Was langt das langt doch.

Lust L. schrieb:
> Mir langen für fast alle Anwendungen 2 bis 4, maximal 8 MHz. Das Teil
> hat genügend Leistung verfügbar wenn man diese nicht ungeschickt
> programmtechnisch verbrät.

...

Ben B. schrieb:
> Wirklich einziger Nachteil dabei, man kann sich ins Bein schießen wenn
> z.B. die Interruptfreigabe beim letzten über eine serielle Schnittstelle
> übertragenen Byte nicht zurückgenommen wird.

Oder man schießt sich ins gleiche Bein wenn das Datenblatt neuerer AVRs 
zu wörtlich genommen wird. Da ist die Rede davon daß der 
Interrupt-Eintritt das auslösende Interruptflag automatisch zurücksetzt. 
Das ist mitnichten der Fall- man muß das z.B. über gezielte 
Register-Auslesung (SPI) oder manuell (RTC) veranlassen.

MCUA schrieb:
>> Berechenbarer Determinismus in der Code-Abarbeitung. Mangels
> Pipeline.
>> Der AVR hat eine Pipeline, wenn auch eine sehr kurze.

Wenn ich richtig im Bilde bin reicht es für garantierte 
Ausführungszeiten.

> Oder man schießt sich ins gleiche Bein wenn das Datenblatt
> neuerer AVRs zu wörtlich genommen wird. Da ist die Rede davon
> daß der Interrupt-Eintritt das auslösende Interruptflag
> automatisch zurücksetzt. Das ist mitnichten der Fall- man muß
> das z.B. über gezielte Register-Auslesung (SPI) oder
> manuell (RTC) veranlassen.
Das ist bei den alten AVRs aber auch schon immer so gewesen. Wenn man 
den Zustand nicht ändert (durch Register auslesen oder manuell), dann 
bleibt der so. Schlecht wenn das im Datenblatt anders beschrieben wird, 
das sorgt für Frust.

(prx) A. K. schrieb:
> Anders ausgedrückt: Ein Lob der Langsamkeit. Geht nämlich nur, so lange
> der Takt langsamer ist als das Flash, will man den Code nicht in RAM
> kopieren.

"Wenn du es eilig hast, gehe langsam."

Konfuzius

;-)

Falk B. schrieb:
> "Wenn du es eilig hast, gehe langsam."
>
> Konfuzius

Nicht alles aus dem Osten ist von Konfuzius.

Japan: „Wenn du es eilig hast, geh langsam. Wenn du es noch eiliger 
hast, mach einen Umweg.“

Ben B. schrieb:
> Das ist bei den alten AVRs aber auch schon immer so gewesen

Nö. Da gab es öfter den Fall daß Interrupt-Flags mit dem 
Intvektor-Sprung automatisch rückgesetzt wurden. Was dann 
fälschlicherweise in die Datenblätter der Neuen übernommen wurde wo das 
aber grundsätzlich nicht mehr so ist (Bsp. SPI).

Falk B. schrieb:
> "Wenn du es eilig hast, gehe langsam."

Ich nehme an um die nötige Zeit zu haben erst nachzudenken und dann zu 
handeln :)
Andere Variante: "Hektik macht langsam"

AMD K6-2 schrieb:
> Da die ursprüngliche Frage hinreichend geklärt ist, gibt es noch eines,
> was ich seit einem Jahrzehnt nicht verstanden habe: Wie können ein CISC-
> und ein RISC-Prozessor den gleichen Befehlssatz haben?

Ein Meisterwerk des Sinn umkehrenden Marketings lieferte Motorola ab, 
indem sie das eingedampfte 68020-Derivat Coldfire als "variable length 
RISC" verkauften.

Man kann ab NexGen-586, AMD-K5 und Intel-P6 viele x86 als RISC 
Prozessoren verkaufen, die einen CISC Prozessor emulieren. Was beim 
nicht mit dem K6 (=NexGen) verwandten K5 sogar irgendwie stimmte, den 
dessen Kern entstammte eigentlich der AMD 29000 RISC Schiene, die aber 
zwischenzeitlich eingestellt wurde und um den dann ein x86 gestrickt 
wurde.

Allerdings hat man dann zwar erfolgreich den Begriff RISC in einen CISC 
reinoperiert, hat aber nicht den gleichen Befehlssatz.

Ron T. schrieb:
> Ich nehme an um die nötige Zeit zu haben erst nachzudenken und dann zu
> handeln :)

https://www.iec.co.jp/kojijyukugo/vo26.htm

(prx) A. K. schrieb:
> Falk B. schrieb:
>> "Wenn du es eilig hast, gehe langsam."
>>
>> Konfuzius
>
> Nicht alles aus dem Osten ist von Konfuzius.
>
> Japan: „Wenn du es eilig hast, geh langsam. Wenn du es noch eiliger
> hast, mach einen Umweg.“

Konfuzius war doch ein Westjapaner, oder? ;-)

DPA schrieb:
> "variable length RISC" ist ein oxymoron.

Wieso? Die Anzahl der Instruktionen sagt nix über deren Länge aus. ABer 
das ist so oder so reine Wortklauberei.

DPA schrieb:
> Für mich sind Fixe länge der Instruktionen das, was RISC architekturen
> überhaupt erst interessant macht.

Also ist ein ARM im Thumb-Modus für dich kein RISC mehr? Im Thumb-Modus 
sind viele Befehle nur 16 bit breit (sodass zwei Befehle in ein 
Speicherwort passen), aber es gibt auch 32-bittige.

MCUA schrieb:
> Auch bei CISC weiss man wo eine Instruktion anfängt.

Wenn du mehrere Befehle pro Takt dekodieren willst, dann stimmt das nur 
beim ersten davon. Ein Ansatz, dieses Problem zu lösen, ist ein brute 
force Verfahren: Man fängt damit an, alle Bytes eines 16 Byte Fensters 
so zu behandeln, als ob da ein Befehl anfängt, ermittelt daraus deren 
Länge, und sucht sich dann jene aus, bei denen es zufällig stimmte.

Jörg W. schrieb:
> Also ist ein ARM im Thumb-Modus für dich kein RISC mehr? Im Thumb-Modus
> sind viele Befehle nur 16 bit breit (sodass zwei Befehle in ein
> Speicherwort passen), aber es gibt auch 32-bittige.

Erst bei Thumb2.

MCUA schrieb:
> (Telefunken hatte mal eine CPU mit glaubich 56-Bit-Befehlssatz)

Ich weiss nur von deren Mainframe, der TR 440. Der verarbeitete zwar 
Daten in 48 Bits, zusammen mit Dreierprobe und Typenkennung waren es 
dann 52 Bits. Aber codiert wurde in 24 Bits. Eine RISC war es trotz der 
fixen Befehlslänge nicht.

MCUA schrieb:
> lso weis sie auch, dass da ein Befehl steht.

Sagen wir mal, sie tut so, als wäre da einer. ;-)

DPA schrieb:
> Für mich sind Fixe länge der Instruktionen das, was RISC architekturen
> überhaupt erst interessant macht. Nicht zu wissen, wo eine Instruktion
> anfängt oder endet, ist doch ziemlicher mist. Aber OK, ist wohl eher ein
> Nebeneffekt und nicht ein muss.

Es gibt viele mögliche Definitionen von RISC. Das übliche Akronym 
"Reduced Instruction Set Computer" gibt dahingehend wenig vor. Und IBM 
nannte die RS/6000 gerne auch "Reduced Instruction Set Cycles", weil man 
bei POWER wahrlich nicht von einem reduzierten Befehlssatz sprechen 
konnte. Ich selber bezeichne es lieber als "Reduced Instruction Set 
Complexity", weil man damit der Sache weit näher kommt.

Bei der Längenerkennung gibts einfache und weniger einfache Fälle. 
Einfach war es beispielsweise bei 68000. Obwohl die einen ziemlich 
komplexen Befehssatz hatte, ging die Länge eindeutig aus dem ersten 
Befehlswort hervor. Damit war es dann allerdings bei 68020 sowas von 
vorbei. Da ergab das zweite Wort die Länge des ersten Operanden und 
damit die Position der Codierung des zweiten Operanden. Und erst dessen 
Codierung zeigte, wo der nächste Befehl begann. Es war also wesentlich 
aufwändiger, in einem Takt die Position des nächsten Befehls 
rauszufinden.

Es ging aber noch weit krasser. Bei der VAX ging aus den ersten 1-2 
Bytes nur die Anzahl Operanden hervor, und das konnten weit mehr als 3 
Stück sein. Jeder Operand codierte seine eigene Länge. Wenn man genug 
Zeit hat, die in aller Ruhe einen nach dem anderen zu dekodieren, ist 
das sehr einfach. Will man das aber schneller angehen, wird es zum 
Alptraum². Das war eine Architektur, die schon aufgrund sowohl der 
Komplexität der Codierung eine recht begrenzte Lebensdauer hatte.

DPA schrieb:
> Aber man kann nicht im vornherein sagen, da fängt ne
> instruktion an oder nicht, man kann nur der CPU sagen, fang mal dort an.
Na und? Nenn mir mal einen Fall, in dem es sinnvoll wäre, eine CPU 
greift völlig zufällig auf irgend eine Stelle im Speicher zu und 
versucht deren Inhalt dann auszuführen!
(Ausser vielleicht in irgend einer künstlerischen Installation...)

Jörg W. schrieb:
> Also ist ein ARM im Thumb-Modus für dich kein RISC mehr?

Pi mal DAUMEN schon ;-)

Falk B. schrieb:
> Jörg W. schrieb:
>> Also ist ein ARM im Thumb-Modus für dich kein RISC mehr?
>
> Pi mal DAUMEN schon ;-)

ARM mal DAUMEN :)

Fahrradkette schrieb:
> Autoaufkleber mit "No RISC, No Fun" finde ich jedenfalls komplett
> daneben.

Den klebt man besser auf ein paar alte ASUS Smartphones. Aus der Ära, 
als Intel ziemlich freudlos versuchte, in diesem Markt Atoms 
unterzubringen.

AMD K6-2 schrieb:
> was ich seit einem Jahrzehnt nicht verstanden habe: Wie können
> ein CISC- und ein RISC-Prozessor den gleichen Befehlssatz haben?

Haben sie nicht. Abgesehen davon - reine RISC- und CISC-Architekturen 
gibt es nicht (mehr). Vielleicht mal, als sie neu (RISC) eingeführt 
wurden. Das war aber deutlich vor dem K6.

> Der AMD K6 wurde damals als "RISC" beworben, führte aber natürlich,
> da für IBM-kompatible PCs, x86-Code aus.

Nicht wirklich. Er emuliert eine x86 CPU. Unter der Haube ist er eine 
superscalare RISC-artige Architektur. Stichwort µOP.

→ https://en.wikipedia.org/wiki/Micro-operation

> Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören?

Äpfel und Birnen.

Fahrradkette schrieb:
> Also ich frage mich schon lange, was dieses RISC eingentlich sein soll.
> Autoaufkleber mit "No RISC, No Fun" finde ich jedenfalls komplett
> daneben.

Ne, voll 90er!!!! ;-)

IT Archäologe schrieb:
> Axel S. schrieb:
>>> Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören?
>>
>> Äpfel und Birnen.
>
> Nö, NOP ist bspw.  CISC wie RISC.

Nö. Das ist bloss der gleiche Assemblerbefehl. RISC und CISC mit 
gleichem Maschinenbefehl zu finden, also gleicher Codierung, ist nicht 
ausgeschlossen, aber deutlich schwieriger. ;-)

IT Archäologe schrieb:
> Ob der Code dazu in Hex 0xDEADBEEF oder
> 0x15926536 lautet, ist grad egal.

Dir schon, aber nicht der Maschine. Erst recht nicht, wenn es genau 
genommen keinen NOP gibt, sondern nur Codes, die eigentlich einem 
normalen Befehl entsprechen, der aber so genutzt nichts ändert. Das war 
schon beim 8086 so und ist beim ARM nicht anders.

hex-fan schrieb:
> Ein Befehl, der nichts ändert, ist ein NOP. Wie der intern abläuft,
> ist doch völlig egal (bis auf die Zyklenzahl natürlich).

Nur auf abstrakter Ebene, aber eben nicht auf Maschinenebene.

Es ging darum:

AMD K6-2 schrieb:
> Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören?

Sitze gerade mit Bier im Garten und wollte die Diskussion um die 
folgende Frage erweitern: "Warum ist ein ARMv8 eigentlich noch ein 
RISC?" Schließlich gibt es doch etwa (ab v8.3-A) eine 
FJCVTZS-Instruktion; im Klartext: "Floating-point Javascript Convert to 
Signed fixed-point, rounding toward Zero"

Christopher J. schrieb:
> Sitze gerade mit Bier im Garten und wollte die Diskussion um die
> folgende Frage erweitern: "Warum ist ein ARMv8 eigentlich noch ein
> RISC?" Schließlich gibt es doch etwa (ab v8.3-A) eine
> FJCVTZS-Instruktion; im Klartext: "Floating-point Javascript Convert to
> Signed fixed-point, rounding toward Zero"

Es geht um die Komplexität der Maschinenoperationen, nicht um die 
Komplexität der Namen der Maschinenoperationen. ;-)

W.S. schrieb:
> Sie hätten ihn auch Ottokar nennen können.

Auf dass man hier dann tagelang über den Unterschied zum Bobbycar 
diskutiert. Prost!

W.S. schrieb:
> Und warum irgend ein "man" bei den 8 Bit-AVRs von RISC spricht, gehört
> in die PR-Abteilung.

Keineswegs, aber das wurde oben schon diskutiert.

(prx) A. K. schrieb:
> nicht um die Komplexität der Namen der Maschinenoperationen. ;-)

:-))

Hallo,
Christopher J. schrieb:
> Schließlich gibt es doch etwa (ab v8.3-A) eine
> FJCVTZS-Instruktion; im Klartext: "Floating-point Javascript
> Convert to Signed fixed-point, rounding toward Zero"

Ich traue mich kaum zu fragen aber gibt es den Befehl wirklich?
Oder ist das vielleicht eine Art Pseudoanweisung in Form eines 
Assemblermakros?

rhf

Roland F. schrieb:
> Ich traue mich kaum zu fragen aber gibt es den Befehl wirklich?
> Oder ist das vielleicht eine Art Pseudoanweisung in Form eines
> Assemblermakros?

Was irritiert euch eigentlich so daran? Das ist eine stinknormale 
Konvertierung zwischen Fliesskomma- und Integerformat, deren 
Besonderheit einzig das darin definierte Verhalten bei Überlauf und 
Rundung ist.

Man hat offensichtlich festgestellt, dass es sich lohnt, diesen Befehl 
zu implementieren. Es geht auch ohne, mit dem Standardbefehl FCVTZS, ist 
dann aber umständlicher und langsamer. Die Bedeutung der Performance von 
JavaScript ist heute ziemlich gross.

https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions

Beispiel für sinnlose Komplexität anhand eines CALL Befehls, der 
ungefähr so in der VAX existierte:

Man baute einen Befehl für jedwede Art Unterprogrammaufrufe, die man 
sich ausdenken kann. Darin enthalten sind die komplette Behandlung des 
Stackframes einschliessen dessen, was Sprachen wie PASCAL benötigen 
(siehe x86 ENTER/LEAVE) und Anforderungen von Parameterübergabe von 
anderen bestimmten Sprachen.

Dieser Befehl enthält folglich einige Parameter, die nur in bestimmten 
Szenarien wirklich zu Operationen führen. Die aber in allen Szenarien 
zur Laufzeit dekodiert und im Microcode daraufhin überprüft werden 
müssen, und ggf mit Schleife in Microcode implementiert werden.

Schlaue Programmierer merkten bald, dass die meisten Aufrufe wesentlich 
schneller sind, wenn man sie mittels des weit simpleren 
Branch-Subroutine implementierte und den Rest zu Fuss programmierte. 
Brauchte man keinen Stackframe, fiel dieser Teil einfach weg, statt zur 
Laufzeit Aufwand zu erzeugen. Rest analog.

Den erwähnten ENTER/LEAVE Befehlen erging es genauso: Sie lohnen sich 
nicht. Ebenso erging es mit der Zeit den CALL Gates der Segmentierung 
von x86. Gedacht für bequemen Umgang mit Systemcalls zwischen Anwendung 
und Betriebssystem, sitzen die heute zwar noch im Microcode rum, werden 
aber geflissentlich ignoriert.

John Cocke von IBM hatte in der 70ern realen Mainframe-Code untersucht, 
den die damals schon recht ordentlichen Compiler dieser IBMs auswarfen. 
Und stellte fest, wie wenig des 370 Befehlssatzes tatsächlich oft 
verwendet wurde. Und dachte sich einen Prozessor aus, der nur das 
implementiert, was sich wirklich lohnt, und den eingesparten Aufwand 
sinnvoller investiert. Das Ergebnis hätte allerdings billigere Maschinen 
für gleiche Leistung gebracht, somit IBMs gute Einkünfte kannibalisiert. 
Weshalb das Konzept lange Zeit im Giftschrank entschwand.

Diese Komplexität realisierte also Konzepte nach dem Muster "nett 
gedacht und gut gemeint, aber effektiv für den Arsch". Obiger ARMv8 
Befehl ist umgekehrt: Man hat etwas gefunden, nach dem wirklich Bedarf 
besteht, und hat es nachgereicht.

MCUA schrieb:
>>Es ging aber noch weit krasser. Bei der VAX ging ...
> Allerdings hatte diese Firma auch den ALPHA-Prozessor.

Nachdem sie an der Weiterentwicklung der VAX beinahe koppheister ging 
und die Zeit zwischendrin mit MIPS R3000 überbrückte.

MCUA schrieb:
> Da sieht man von wem ARM abgekupfert hat.

Nicht von John Cocke. Dessen Erkenntnisse blieben geheim. Öffentlich war 
der Berkeley Zweig um David Patterson, der auch hinter RISC V steht.

MCUA schrieb:
> Diese Sprachen (auch C) benötigen in Wirklichkeit KEINEN Stackframe, sie
> sind nur zu blöd es auch anders zu machen.

In PASCALs wirds schon etwas komplizierter, weil lokale Funktionen auf 
den Stackframe der umgebenden Funktion(en) zugreifen können. Das ist ein 
wenig komplizierter und ist der eigentliche Sinn von ENTER.

MCUA schrieb:
> (die haben damals, wie sie selbst sagen, es "geschafft" mit "minimalem
> Aufwand" einen Prozessor "auf die Füße zu stellen".

War ein Schlüsselerlebnis in den 80ern. National Semiconductors 32K als 
sehr von der VAX inspirierte Architektur kannte ich bereits, NEC setzte 
damals mit V60/70 noch eins drauf. Der Vergleich mit ARM war für mich 
sehr erhellend.

MCUA schrieb:
> Solln wer wetten, dass das so geheim nicht war?

Das liesse sich deinerseits nur durch Fakten beweisen. Willst du damit 
nur gegen Wette rausrücken? ;-)

MCUA schrieb:
> DEC hatte schon eine CPU in IC-Form bevor es andere hatten!

Falls VAXen: Mir ging es oben um eine Weiterentwicklung der Performance. 
Höhere Integration unter weitgehender Beibehaltung der sequentiellen 
Arbeitsweise war problemlos möglich. Härter wurde es bei superskalarer 
Arbeitsweise.

Dafür muss man aus einem solchen Befehlssatz einen wichtigen Kern mit 
einfacher Befehlsstruktur für Hardware-basierte Ausführung extrahieren. 
Um den Rest dann wie gehabt zu implementieren, für geduldigere 
Kundschaft. Also quasi im CISC einen RISC-Kern finden. ;-)

Mit der 68000 Familie hatte Motorola ein ähnliches Problem, und bei 
68060 eine Lösung entsprechend diesem Ansatz. Bis sie erst auf 88K 
wechselten, dann auf PowerPC.

MCUA schrieb:
> Was eine CPU ist, mit starrem (damit uneffizientem) Befehlssatz.

Die andererseits die einzige RISC-artige Architektur im Highend-Bereich 
ist, die noch parallel zu x86_64 und ARM weiterentwickelt wird. Alpha 
und HP-PA sind komplett tot, MIPS weitgehend, und auch Intel hat IA64 
aufgegeben. Manchen, wie Alpha, mag man hinterher trauern, aber die 
Masse machts eben. Wenn man die Differenz mit genug Aufwand zuschütten 
kann, reduziert sich der effektive Unterschied.

Thomas W. schrieb:
> Daher war der Ansatz, moeglichst viel in Silizium zu packen, schon nicht
> so schlecht (die VAX hatte z.b. Queues in Hardware).

Ja, diese Arbeitsweise hatte ihre Zeit. Aber die lief eben ab.

Wobei es schon früher völlig andere Architekturen gab, wie die CDC 6600 
Ende der 60er mit viel einfacherer an RISC Prinzipien erinnernder 
Ausführungsstruktur, dafür aber mit modernen Konzepten paralleler 
Ausführung vieler Ausführungseinheiten, und bei der 7600 erheblichem 
Pipelining. Billig war das allerdings nicht.

MCUA schrieb:
> Aber für die Masse ist das nichts.

Kommt jetzt drauf an, wo du diese Masse siehst. Bei kleinen 
Mikrocontrollern, Milliardenfach in billige Geräte geklöppelt, oder ob 
Smartphones und PCs auch noch dazu zählen.

Interessant, dass ich von dir noch nichts über Renesas hörte. ;-)

Thomas W. schrieb:
> moeglichst viel in Silizium zu packen, schon nicht
> so schlecht (die VAX hatte z.b. Queues in Hardware). Sehr viel Aufwand
> in Silizium fuer ein kleines Teilproblem in einem Betriebssystem.

Sowas ist eigentlich bloss ein Haufen Mikrocode, basierend auf sehr 
wenig grundlegender Hardware für Locks. Später implementierte man nur 
diese Locks und überliess den Aufwand dem Programm. Das illustriert 
exakt einen wesentlichen Unterschied zwischen CISC und RISC.

Es zeigt sich dabei übrigens, dass die an dieser Stelle verwendeten 
blockierenden Befehle der CISC gegenüber alternativen Lock-Verfahren, 
wie man sie in POWER und ARM findet, real im Nachteil sind. Wem die bei 
heutiger Speicherhierarchie und Multiprocessing horrenden Latenzen auf 
die Nerven gehen, der kann bei den alternativen Verfahren die Zeit 
anderweitig nutzen.

Thomas W. schrieb:
> aber die Intel-Maschinen waren zwar technisch einfacher aber billiger.
> Schade eigentlich.

Der Wind drehte mit dem Pentium Pro, dem im Grundaufbau extrem 
langlebigen P6 Core. Das war der erste Intel, der aufgrund seiner 
radikal anderen Ausführungsstruktur mit den Highends leidlich mithalten 
konnte.

(prx) A. K. schrieb:
> Der Wind drehte mit dem Pentium Pro, dem im Grundaufbau extrem
> langlebigen P6 Core. Das war der erste Intel, der aufgrund seiner
> radikal anderen Ausführungsstruktur mit den Highends leidlich mithalten
> konnte.

Überspringt man Intels Netburst-Abirrung (Pentium 4), dann entsteht eine 
direkte evolutionäre Linie vom P6 Core bis zu den heutigen Golden Cove 
P-Cores im Alder Lake Prozessor.

Thomas W. schrieb:
> Multiprozessor war auch noch nicht.

Gab es schon früh. Das war nicht einmal selten, bloss teuer. Telefunkens 
TR-440 von ca 1970 gab es auch mit zwei Prozessoren, und das war nicht 
die einzige dieser Art.

MCUA schrieb:
> M32C ist 32 Bit, nicht 16.

Der M32C/8x ist klar ein 16-Bitter, was die Instruction Set Architecture 
angeht. Mag sein, dass die Implementierung schneller ist als beim sehr 
ähnlichen M16C/8x, der innere Aufbau breiter ist. Aber aus der Z80 wird 
bei mir trotz der ALU kein 4-Bitter und aus dem MC6804 kein 1-Bitter.

Die Bezeichnungen von Renesas sind allerdings ein ziemliches 
Verwirrspiel. Weil die M32C/8x stärker an die M16C/8x erinnern, als die 
M16C/8x an die M16C/6x. Und ich andererseits kaum einen Unterschied 
zwischen M16C/6x und R8C finden konnte.

W.S. schrieb:
> da muß man zum Diskutieren auf ältere Architekturen zurückgreifen.

So arg viel neue Architekturen gibts doch gar nicht. Oder welchen 
Vorschlag hättest du da? Über RISC V kann man in diesem Zusammenhang 
schlecht streiten.

> Ach Leute, ihr seid ja immer noch dabei, die µC in Schubladen
> einzusortieren.

Jau, und mit dem allerersten Beitrag beginnend. Ich dachte in diesem 
Thread ginge es um Schubladen.

(prx) A. K. schrieb:
> Über RISC V kann man in diesem Zusammenhang schlecht streiten.

Ist doch bestimmt auch nur ein Marketing-Name. :-)