Forum: Mikrocontroller und Digitale Elektronik Wieso spricht man bei den 8 Bit-AVRs von RISC?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von 1 Punkt für Gryffindor (Gast)


Lesenswert?

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

von Max M. (prokrastinator)


Lesenswert?


von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
Beitrag #7119185 wurde von einem Moderator gelöscht.
Beitrag #7119189 wurde von einem Moderator gelöscht.
Beitrag #7119213 wurde von einem Moderator gelöscht.
von Falk B. (falk)


Angehängte Dateien:

Lesenswert?

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.

Beitrag #7119234 wurde von einem Moderator gelöscht.
Beitrag #7119243 wurde von einem Moderator gelöscht.
von 1 Punkt für Gryffindor (Gast)


Lesenswert?

Falk B. schrieb:

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

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Achim M. (minifloat)


Lesenswert?

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

von michael_ (Gast)


Lesenswert?

Deshalb gibt es auch in der Taktfrequenz zu beachten.

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Achim M. (minifloat)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

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

von EAF (Gast)


Lesenswert?

Falk B. schrieb:
> mittlerweile Dutzende Versionen

Auch vom AVR gibts Nachbauten mit erheblich mehr Leistung.
z.B. der MD-328D
32MHz interner Takt bei 3,3V, bei 1,8V noch bis zu 20MHz
12 Bit ADC
Einige Befehle, mit weniger Taktzyklen, als das Original.
Und noch ein paar mehr Features.

von Jobst M. (jobstens-de)


Lesenswert?

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

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

1 Punkt für Gryffindor schrieb:
> Wenn ich es richtig verstehe brauchen RISC meistens nur 1 Zyklus je
> Befehl im Gegensatz zu den CISC

Das verstehst du falsch.
Sprich es einfach mal komplett aus:

ReducedInstructionSetComputer
versus
ComplexInstructionSetComputer.

Das ist der tatsächliche Unterschied. Komplexe Instruktionen führen 
mehrere Aktionen durch (Beispiel DJNZ Decrement Register, Vergleich auf 
0, Sprung je nachdem ob 0 oder nicht). Sowas spart Maschinencode, der 
zumeist aus einem langsamen EPROM oder so gelesen werden mußte, führt 
aber dazu, daß zumeist nur ganz bestimmte Register benutzt werden 
müssen, um die Auswahl des Registers nicht in den Maschinencode einbauen 
zu müssen.

Bei RISC Architekturen verkneift man sich solche komplexen Befehle und 
legt stattdessen mehr Wert darauf, eine Operation mit einem beliebigen 
Register machen zu können, was eben die Bezeichnung bzw. Registernummer 
im Maschinencode erfordert.

Ob und wieviel Maschinentakte jeweils ein Maschinenbefehl braucht, ist 
was anderes. Und ob man bei Atmel AVR von Risc redet oder nicht, ist 
eigentlich nur PR-Geschwafel. Klingt heuer werbewirksamer als wenn man 
es Ottokar genannt hätte.

W.S.

von Eine Frage (Gast)


Lesenswert?

> Wieso spricht MAN ...

Wer spricht eigentlich von Risc? Wir Techniker oder Amtels 
Marketingabteilung?

von Oliver S. (oliverso)


Lesenswert?

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

von DerEgon (Gast)


Lesenswert?

Eine Frage schrieb:
> Wir Techniker oder Amtels
> Marketingabteilung?

Naja, wer schon mal den Befehlssatz des 6809 gesehen hat, und den mit 
dem des AVR vergleicht, der wird einen gewissen Unterschied nicht 
abstreiten können. Der 6809 ist ein schönes Beispiel für einen 
8-Bit-Prozessor mit relativ wenigen Registern, aber sehr komplexen 
Befehlen mit vor allem auch sehr komplexen Adressierungsarten.

Dafür brauchen fast alle Befehle mehr als einen Taktzyklus.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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

von Max M. (prokrastinator)


Lesenswert?

Falk B. schrieb:
> 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. ;-)

https://jaycarlson.net/microcontrollers/
Biquad Filter:
20Mhz Tiny: 160ksps
72Mhz EFM8: 202ksps
48Mhz SAMD10 (M0+): 1822ksps
48Mhz STM32F: 1648ksps
Ist klar was man nimmt wenn man Leistung braucht.

Was moderneres als den EFM8 kenne ich bei 8051 nicht.
Der originale 8051 hat viele Verbesserungen erfahren, aber das Konzept 
ist eben alt.
Der war ein Kind seiner Zeit und hat wie auch der AVR seinen Markt.

Falk B. schrieb:
> Soll keine sinnlose Diskussion zum Thema AVG
> gegen 8051 werden.
Genau!

von Georg G. (df2au)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

Georg G. schrieb:
> Select Registerbank
Aber genau davon redet Falk doch.
Eine Menge zusätzlicher Arbeit um Speicherbänke umzuschalten, auf Xram 
zuzugreifen, Registerinhalte zu sicher und wieder herzustellen etc.pp.
Das kann der 8051 eben nicht gut im Vergleich zu neueren Konzepten und 
deswegen hat er eben auch nur noch eine Nischenanwendung.
Das gleiche erlebt gerade der AVR vs M0+ und wir werden es vielleicht 
wieder erleben bei ARM vs. RiscV.

Das ist nunmal so.
Die Fertigungsmethoden werden besser man kann neue Tricks in Silizium 
verpacken, von den gemachter Erfahrungen profitieren, etwas besseres 
bauen.
Und da wo es Vorteile hat ersetzt das Neue das Alte.
Kein Grund für Rückzugsgefechte oder das Alte zu belächeln.
Alles ein Kind seiner Zeit und wer nicht mit der Zeit geht, der geht mit 
der Zeit.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Lust L. (lust)


Lesenswert?

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.

von Lust L. (lust)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

>oder den teilweise überbordend komplexen
>Renesas R8C..M32C (16-Bitter).

M32C ist 32 Bit, nicht 16.
Als der rauskam hat der viele uCs in den Schatten gestellt.


---------------------------------------------------------------------


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

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

>Ist vei Flash halt das generelle Problem.
...
>Die Digitallogik der CPU könnte man halt problemlos schneller bekommen,
>die Flash-Zugriffe nicht.

...
Reichen 8,3 ns AccTime?
(bei AVR ist das allerdings sowiso egal)


---------------------------------------------------------------------


>Was mir noch bei 8051 gefällt: Bitadressierbares RAM und SFR
...
>Außerdem können Additionen, Subtraktionen,
>Vergleiche und logische Operationen direkt in den 256 Bytes RAM
>ausgeführt werden.
...

Na das ist ja mal ein "riessiger" Speicherbereich

>Der originale 8051 hat viele Verbesserungen erfahren, aber das Konzept
>ist eben alt.

Die Speicher-Archik ist nicht verbessert worden.
(insbes hätte man den winzigen Bitadr. Bereich vergrössern können, und 
auch n paar IndexReg zubauen können)


---------------------------------------------------------------------


>Der 6809 ist ein schönes Beispiel für einen
>8-Bit-Prozessor mit relativ wenigen Registern, aber sehr komplexen
>Befehlen mit vor allem auch sehr komplexen Adressierungsarten.
>Dafür brauchen fast alle Befehle mehr als einen Taktzyklus.

Das kann man heute (bei gleicher Architekt) viel schneller haben.
siehe bsp auch STM8

: Bearbeitet durch Moderator
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von DerEgon (Gast)


Lesenswert?

MCUA schrieb:
> Das kann man heute (bei gleicher Architekt) viel schneller haben.

Ach? Wo wäre das? (bezogen auf den 6809)?

von MCUA (Gast)


Lesenswert?

>> Das kann man heute (bei gleicher Architekt) viel schneller haben.
> Ach? Wo wäre das? (bezogen auf den 6809)?
Nein, direkter Vergleich zu 6809 so nicht zu kaufen.
Aber man könnte es schneller machen, wenn man es wollte (oder auch im 
FPGA)

von MCUA (Gast)


Lesenswert?

>.. wenn man das Potential seiner integrieren
>Hardware-Module zusammen mit dem breiten Interrupt-Spektrum
Das soll wohl ein Witz sein?
Das Interrupt-Systerm beim AVR ist katastrophal.

von Lust L. (lust)


Lesenswert?

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

von Max M. (prokrastinator)


Lesenswert?

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.

Aber was ist der Sinn, wenn eine MCU die die 20fache Leistung bringt 
nicht mehr kostet, bzw. die Stückzahlen so gering sind das die 
Stückkosten einer MCU im Rauschen untergehen?
Klar, ich konnte auch auf dem 8085 tolle Dinge machen.
In der 5fachen Zeit, mit dem 10fache HW Aufwand und auch mit brachialen 
Optimierungen war schnell schluss.
Bei einem EFM8 würde ich da in einem Tag in C coden und ausser 
Spannungsversorgung und zwei kerkos würde die MCU nichts brauchen.
Trotzdem wäre die dann 100mal schnelle, würde ein 20tel des Stromes 
benötigen, 1% der Gesammtkosten verursachen.

Ja, ich habe mal auf dem Dreirad angefangen, dann das Fahrrad mit 
Stützrädern, die Mofa, die CB1000.
Heute Renault Kombi mit Klima.
Ich bin mir sicher ich könnte die Strecke auch mit dem Dreirad fahren.
Wäre eben nur recht mühseelig.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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. Da bieten sich neue Abkürzungen an, 
auch wenn die Technik eigentlich gar nicht neu ist.

Wenn man nun Umgekehrt fragt, was RISC bedeutet, ist die Antwort quasi 
das Datenblatt des Mikrocontrollers, für den der Begriff erfunden wurde.

Irgendwann sprangen weitere Firmen auf den Zug auf und nannten ihre 
Produkte ebenfalls RISC. So dass die technischen Fakten dahinter immer 
mehr aufgeweicht wurden. Der Begriff wurde zunehmend zu einem unklaren 
Wischiwaschi, bis er an Bedeutung verlor. Die Grenzen sind schon lange 
verlaufen.

Ich wetter es gibt inzwischen mehr Prozessoren, die ein bisschen CISC 
und ein bisschen RISC sind, als eindeutig einer der beiden Kategorien 
zuweisbar.

Gleiches gilt auch für Von Neumann versus Harvard Architektur. Aktuelle 
Mikrocontroller sind weder das eine noch das andere, bzw. von beidem ein 
bisschen.

In der Ausbildung/Studium ist wichtig zu wissen, was der Prüfer hören 
will. In meinem Fall wurde ein antiquarisch alter technischer Stand 
abgefragt, der auf Bauteilen beruhte, die schon zu meiner Geburt kaum 
noch verwendet wurden. Da war die Elektronik noch einfacher in 
Schubladen einzusortieren, es gab weniger Vielfalt.

von Oliver S. (oliverso)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

>RISC ist ein Marketing Begriff.
Stimmt so nicht.

>Ich wette es gibt inzwischen mehr Prozessoren, die ein bisschen CISC
>und ein bisschen RISC sind, als eindeutig einer der beiden Kategorien
>zuweisbar.
Stimmt.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

>> 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!
(Neuere AVR von MCH haben lediglich 2 davon)

von EAF (Gast)


Lesenswert?

Ben B. schrieb:
> Ich erinnere mal an den C64

Immer noch "aktuell"!
Siehe: https://www.youtube.com/watch?v=PSBo-TpEJ24

von Falk B. (falk)


Lesenswert?

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.

von Roland F. (rhf)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

> gegen Interruptprioritäten.....
> und scheint in der Praxis auch selten ein Problem zu sein.
... ist aber immer dann ein Problem, wenn das System komplizierter wird 
(und man daher mehrere Prio braucht)
(dann wird eben kein AVR genommen)

von MCUA (Gast)


Lesenswert?

>Es macht das Programmieren sehr bequem..
nicht nur das Programmieren; es ist oft garnicht anders möglich, als 
dass man mehr. Prio braucht, weil die CPU es sonst überhaupt nicht 
schafft!
Diese Prio's gibt es ja nicht zum Spass.
Und schon der 68k hatte 8 davon.

von (prx) A. K. (prx)


Lesenswert?

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

Prefetching und Delay Slot sind wirklich verschieden.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

>oder ich stelle mir eine stabile Zeitbasis damit hin (z.B. 10
>oder 100Hz)
Natürlich kann man darin 'alles' abfragen.
Aber dann sinds ms keine us.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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

: Bearbeitet durch User
von Lust L. (lust)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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.

von Max M. (prokrastinator)


Lesenswert?

Ben B. schrieb:
> Minimalbeschaltung von dem Ding

Das war damals so.
Ram, Eprom, Adressdekoder, Timerbaustein, Uart Baustein etc. pp.
Auf Lochraster mit Fädeltechnik, weil es PCB Pool Herstellung zu 
erträglichen Preisen auch nicht gab.
Deswegen schlug der 8051 ja ein wie eine Bombe.
Anfangs nur mit Maskenprogrammierten ROM, später der 8751 mit Eprom im 
Keramikgehäuse mit Quarzglasfenster, der sein Gewicht in Gold wert war.
Heute denkt man 'was für ne olle Gurke' aber damals war das eine 
Offenbarung.
Flash, ISP, Debug, davon hat man damals nicht mal geträumt.

Leistungsstarke CPUs brauchten viel ext. Beschaltung, die Controller die 
das intern hatten, waren nicht leistungsstark.
Heute bekommt man beides zu Preisen für die ich damals nicht mal ein 2K 
Eprom bekommen konnte und die Tools bekommt man geschenkt.
Wir mussten noch betteln gehen und Raubkopieren was das Zeug hält.
Dann kamen die Dongel auf...

Der 8051 war für ASM Coder und kleine Industriesteuerungen gedacht.
C-Compiler waren ziemlich indiskutabel langsam und Speicherhungrig, wenn 
man denn jemanden kannte der irgendwo arbeitet wo die Fa. sich einen 
geleistet hat.
Optimiert haben die nicht nennenswert und C war ganz deutlich langsamer 
als ASM.
Internet gab es nicht, Datenblätter hat man sich aus Büchern 
rauskopiert, die man sich erbettelte.

Der AVR war deutlich besser für optimierende C compiler geeignet, 
überwand viele Probleme des 8051 und setzte sich schnell durch.

Ist klar das mit den immer besser werdenden Prozessen heute MCUs auf dem 
Markt sind gegen die die ollen Teile echt alt aussehen.
Aber ohne die hätte es die wunderbare MCU Welt von heute nicht gegeben 
und das darf man durchaus anerkennen wenn man über die ollen MCUs 
spricht.

Heute scheitert der Noob mit ESP32 dualcore und >300KB an LED Blinky und 
schwingt große Reden darüber wie rückständig doch so ein AVR ist.
Meine Herren, für einen Arduino nano mit IDE hätte man 1990 seine Oma 
vor die Bahn geschubst und niemand der wusste wovon er sprach hätte 
daran etwas anstößig gefunden.

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

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

von Stefan ⛄ F. (stefanus)


Lesenswert?

Max M. schrieb:
> Flash, ISP, Debug, davon hat man damals nicht mal geträumt.

Doch davon hat man geträumt. Was habe ich den AT89C1051 gefeiert, damit 
machte das Mikrocontroller-Basteln erst richtig Spaß.

Danach kam für mich der ATmega328 mit ISP und DebugWire, was wiederum 
ein gewaltiger Sprung nach vorne war.

Seit dem sind die Sprünge gefühlt kleiner geworden. Jetzt geht es mehr 
um komplexere Peripherie-Einheiten, nachdem die Kernprobleme gelöst 
sind.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Max M. (prokrastinator)


Lesenswert?

Stefan ⛄ F. schrieb:
> Seit dem sind die Sprünge gefühlt kleiner geworden. Jetzt geht es mehr
> um komplexere Peripherie-Einheiten, nachdem die Kernprobleme gelöst
> sind.

Mehr Speicher, mehr Speed, mehr Peripherie, bessere Toolchains.
Aber die Opas haben den Weg bereitet und man darf ihnen Respekt zollen 
;-)

von MCUA (Gast)


Lesenswert?

>man kann sich auch beim AVR Interrupts
>mit 300..500kHz reinballern lassen,
Ein bisschen "reinballern" geht ja beim AVR.
Immerhin hat er INT-Möglichkeit 1 Prio.

Wenn nun aber schon eine andere ISR am laufen ist (die zwar nicht im 
kleinen us Bereich aufgerufen werden muss, dafür aber einiges mehr an 
CPU-Zeit braucht, ist es vorbei mit "reinballern".
Dann wird das nämlich vom AVR verschlafen.
Das wäre nicht so, gäbe es mehrer Prio-Ebenen!
(klar kann man es auch über Software (in der ISR) umschalten, hat dann 
aber (genauso) das Problem, dass dadurch die INT-Belastung viel zu hoch 
ist, so dass am Ende der CPU-Overhead viel zu gross ist. man kann eben 
keine Hardware durch Software ersetzen)

von Lust L. (lust)


Lesenswert?

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 😉

: Bearbeitet durch User
von Stefan ⛄ F. (stefanus)


Lesenswert?

Lust L. schrieb:
> Die AVR128Dx28 haben
> ein SmallDIP Gehäuse mit ebendiesem Raster

Na das freut mich. Ich dachte es gäbe nur noch alten Kram in DIP.

von MCUA (Gast)


Lesenswert?

>Mit dem 2,54mm Raster komme ich viel besser zurecht.
Nur gibt es da jetzt nicht grad die grösste Auswahl.
Bei 40/44 Pins (im Extremfall 68 oder 84 -PLCC) ist meist Schluss.


>> Flash, ISP, Debug, davon hat man damals nicht mal geträumt.
>Doch davon hat man geträumt.
Von ISP hat man lange nicht geträumt, weil die Schaltung doch rel. 
aufwändig.
Man musste halt einen ICE nehmen, oder TryAndError mit EPROM-Emulator 
(was heute fast keiner mehr kennt).

von Lust L. (lust)


Lesenswert?

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

von Lust L. (lust)


Lesenswert?

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

Die neueren AVRs haben derer zwei.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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

von Idiotengriller (Gast)


Lesenswert?

1 Punkt für Gryffindor schrieb:
> Mir war nicht klar dass man Branches und
> Load/Store Instruktionen bei diesem Vergleich nicht mitzählt.

Es ist halt die Frage, wieviel Buszugriffe nötig werden und ob pipelines 
im Spiel sind. Bei Branches gibt es eben den Fall das der nächste Befehl 
der falsche ist weil die berechnung des IF- ausdruckes was anderes 
ergeben hat.

Der Streit um RISC oder CISC ist ohnehin reichlich 'akademisch', man 
mischt in seine Prozessoren halt was man grad braucht (breiter 
registersatz, viele Addressmodis, pipelining, ...) egal ob es zu RISC 
oder CISC gezählt wird.

von Lust L. (lust)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

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

von Lust L. (lust)


Lesenswert?

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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

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

von Falk B. (falk)


Lesenswert?

(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

;-)

von AMD K6-2 (Gast)


Lesenswert?

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?

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

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

von (prx) A. K. (prx)


Lesenswert?

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

von Ron T. (rontem)


Lesenswert?

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"

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von DPA (Gast)


Lesenswert?

"variable length RISC" ist ein oxymoron.

von Falk B. (falk)


Lesenswert?

(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? ;-)

von Falk B. (falk)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von Stefan ⛄ F. (stefanus)


Lesenswert?

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

Weil diese Abkürzung zu einem reinen Marketing Spruch verkommen ist. 
Dort wird gelogen, dass sich die Balken biegen, aber man darf das nicht 
sagen. Irgendwann denkt man, es sei wahr, danach wird man verwirrt.

von MCUA (Gast)


Lesenswert?

>Wie können ein CISC-
>und ein RISC-Prozessor den gleichen Befehlssatz haben?
Kann er nicht.


>Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören?
Kann er.
Es müssen ja nicht alle Maschinenbefehle gleich sein.
'MOV R1, R2' kann es überall geben


>Ein Meisterwerk des Sinn umkehrenden Marketings lieferte Motorola ab,
>indem sie das eingedampfte 68020-Derivat Coldfire als "variable length
>RISC" verkauften.
So falsch war diese Bezeichnung nichtmal.
Das ist doch das was wir hier sehen:
RISC und CISC nähern sich an, vermischen sich.
Und das ist auch das Optimum, denn reiner RISC ist schlecht, genauso wie 
reiner CISC schlecht ist.
(ein reiner RISC ist ja zu blöd, 'draussen' im Speicher ein Bit zu 
setzen)

von Stefan ⛄ F. (stefanus)


Lesenswert?

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

Weil diese Abkürzungen zu Marketing Bullshit verkommen sind.

von MCUA (Gast)


Lesenswert?

>Nicht zu wissen, wo eine Instruktion
>anfängt oder endet, ist doch ziemlicher mist.
Auch bei CISC weiss man wo eine Instruktion anfängt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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

Ich such mir eine Stelle irgendwo im Maschinencode raus. Woher weiss ich 
jetzt, ob die Instruktion da anfängt oder nicht? Oder ob sie es gar nur 
manchmal tut, und manchmal nicht?

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

Ja

von MCUA (Gast)


Lesenswert?

Also wenn man bei CISC nicht wüsste wo Anfang und Ende ist, könnte keine 
CPU das dekodieren. (Zugegeben ist es aufwändiger, 10 verschiedene 
Längen zu dekodieren als nur eine einzige oder zwei.)

von (prx) A. K. (prx)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

> Für mich sind Fixe länge der Instruktionen das, was RISC architekturen
> überhaupt erst interessant macht.
Genau das ist aber uneffizient, weil der OP-Code zu viel Speicher 
braucht.
(Telefunken hatte mal eine CPU mit glaubich 56-Bit-Befehlssatz)

von DPA (Gast)


Lesenswert?

MCUA schrieb:
> Also wenn man bei CISC nicht wüsste wo Anfang und Ende ist, könnte keine
> CPU das dekodieren.

Nein, die CPU ist an einer Position im Code, und nimmt an, dass da eine 
Instruktion ist. 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.

von MCUA (Gast)


Lesenswert?

>Nein, die CPU ist an einer Position im Code,...
Die CPU ist aber nicht irgentwo im Code, sondern ist (anhand vorigem 
Befehl) gezielt schon genau dahin gesprungen, also weis sie auch, dass 
da ein Befehl steht.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von M.A. S. (mse2)


Lesenswert?

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

: Bearbeitet durch User
von Falk B. (falk)


Lesenswert?

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

Pi mal DAUMEN schon ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

von DPA (Gast)


Lesenswert?

M.A. S. schrieb:
> 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!

Zum debuggen ist es nützlich. Ich will eventuell den Code auch mal 
disassembeln & nachvolziehen, und da ist es dann mist, wenn man mal am 
falschen Ort anfängt, oder ein besonders cleverer assembler freak 
unterschiedliche Instruktionen im gleichen Bereich je nach Anfangsoffset 
verstecken kann.

von Fahrradkette (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Lesenswert?

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.

von DerEgon (Gast)


Lesenswert?

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

Wer RISC und "risk" nicht auseinanderhalten kann ...

von Falk B. (falk)


Lesenswert?

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!!!! ;-)

von IT Archäologe (Gast)


Lesenswert?

Axel S. schrieb:
>> Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören?
>
> Äpfel und Birnen.

Nö, NOP ist bspw.  CISC wie RISC.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von IT Archäologe (Gast)


Lesenswert?

(prx) A. K. schrieb:
> RISC und CISC mit
> gleichem Maschinenbefehl zu finden, also gleicher Codierung, könnte
> schwieriger werden. ;-)

Das ist Kokolores, Klar ist NOP der gleiche Maschinenbefehl, wenn er das 
gleiche in der Maschine tut. Ob der Code dazu in Hex 0xDEADBEEF oder 
0x15926536 lautet, ist grad egal.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von hex-fan (Gast)


Lesenswert?

(prx) A. K. schrieb:
> 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.

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

von (prx) A. K. (prx)


Lesenswert?

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?

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Jörg W. schrieb:
> ARM mal DAUMEN :)

Törööh!

Eigentlich ist diese ganze Diskussion eine Blase ohne Bodenkontakt. 
Nannte man früher auch Leidenfrostsches Phänomen. Aber da kochte man 
noch mit Wasser.

Und warum irgend ein "man" bei den 8 Bit-AVRs von RISC spricht, gehört 
in die PR-Abteilung. Aber es ist mal wieder eine nette Gelegenheit, ohne 
konkretes Thema zu diskutieren, wenn's im Biergarten regnet.

W.S.

von Christopher J. (christopher_j23)


Lesenswert?

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"

von (prx) A. K. (prx)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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?"

Prost!
(das Wichtigste zuerst)

Sie hätten ihn auch Ottokar nennen können. Den ARMv8. Also frag dazu 
lieber die Eltern.

W.S.

von (prx) A. K. (prx)


Lesenswert?

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!

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

:-))

von Roland F. (rhf)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>Ein Befehl, der nichts ändert, ist ein NOP. Wie der intern abläuft,
>ist doch völlig egal (bis auf die Zyklenzahl natürlich).
...
>Ein Befehl, der nichts ändert, ist ein NOP. Wie der intern abläuft,
>ist doch völlig egal
Streitet euch nicht über einen NOP-Befehl, dazu braucht man keine CPU.


> Autoaufkleber mit "No RISC, No Fun"
Ja, ist 90er.
Aber ist das heute vorbei?


>Und warum irgend ein "man" bei den 8 Bit-AVRs von RISC spricht, gehört
>in die PR-Abteilung.
Sagen wir zu 75% ist die Bezeichnung sinnvoll,  zu 25% ist es Marketing.


>Obwohl die (68k) einen ziemlich
>komplexen Befehssatz hatte, ging die Länge eindeutig aus dem ersten
>Befehlswort hervor.
Ist nicht schlecht, Gibts heute noch.


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


>Beispiel für sinnlose Komplexität anhand eines CALL Befehls.....
>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.
Diese Sprachen (auch C) benötigen in Wirklichkeit KEINEN Stackframe, sie 
sind nur zu blöd es auch anders zu machen.
Es gibt hunderte Möglichkeiten ein CALL umzusetzen.


>Und dachte sich einen Prozessor aus, der nur das
>implementiert, was sich wirklich lohnt, .........
Da sieht man von wem ARM abgekupfert hat.
(die haben damals, wie sie selbst sagen, es "geschafft" mit "minimalem 
Aufwand" einen Prozessor "auf die Füße zu stellen".

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

DEC hatte schon eine CPU in IC-Form bevor es andere hatten!
(es wurde intern zurück gehalten, um ihre eigenen diskreten CPUs zu 
verkaufen)

von (prx) A. K. (prx)


Lesenswert?

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.

von MCUA (Gast)


Lesenswert?

>> Da sieht man von wem ARM abgekupfert hat.
>Nicht von John Cocke. Dessen Erkenntnisse blieben geheim.
Solln wer wetten, dass das so geheim nicht war?

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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? ;-)

von MCUA (Gast)


Lesenswert?

Na, der Eine hat mit dem Anderen ein bisschen telefoniert, hat sich ein 
bisschen bezahlen lassen.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Jörg W. schrieb:
> Keineswegs, aber das wurde oben schon diskutiert.

Also, wenn ich diesen Thread betrachte, dann neige ich dazu, es schöner 
zu finden, wenn das Ding eben Ottokar hieße.

W.S.

p.s. Naja, immer nur bierernst zu sein, wird mit der Zeit auch 
langweilig.

von MCUA (Gast)


Lesenswert?

>..dann auf PowerPC..
Was eine CPU ist, mit starrem (damit uneffizientem) Befehlssatz.
Hat Motorola falsch gemacht. (Nur der Name war gut gewählt)

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Thomas W. (dbstw)


Lesenswert?

Moin, -

bei der Diskussion RISC/CISC sollte man auch die Hardware-Umstaende der 
damaligen Zeit (ca. 1980-1990) beruecksichtigen: Speicher war langsam 
und teuer (richtig teuer), Massenspeicher waren auch langsam und teuer. 
Die Maschinen waren auch (nach heutigen Standard) langsam (200MHz war 
wohl das Limit), Multiprozessor war auch noch nicht.

Daher war der Ansatz, 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. Und 
OpenVMS ist schon ein komplexes Betriebssystem (verglichen mit dem Unix 
der '80 - 90'er).

Auf der VAX (oder in der DEC-Welt) waren auch Fortran, Pascal, MACRO(!) 
und  ADA (es gab wohl einen Vertrag mit dem US-Militaer) Sprachen der 
Wahl. Der C-Compiler (DEC-C und VAX-C) war wirklich schlecht. Das war 
auch eine Zeit, wo die Compiler noch Hand gekloeppelt wurden.

Dann hatte DEC versucht, mit der Alpha-Architektur den Markt zu drehen, 
aber die Intel-Maschinen waren zwar technisch einfacher aber billiger. 
Schade eigentlich.

Gruesse

Th.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

Gut, Highend-Bereich ist was anderes.
Da kann man reinbuttern was geht, egal wie hoch der Speicherbedarf ist, 
egal was es kostet (und selbst da stellt sich ja die 
(MultiProzessor)Frage wie viele andere (günstigere) CPUs man dafür 
kriegen könnte).
Aber für die Masse ist das nichts.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

>bei der Diskussion RISC/CISC sollte man auch die Hardware-Umstaende der
>damaligen Zeit (ca. 1980-1990) beruecksichtigen: Speicher war langsam
>und teuer (richtig teuer), Massenspeicher waren auch langsam und teuer.
>Die Maschinen waren auch (nach heutigen Standard) langsam (200MHz war
>wohl das Limit), Multiprozessor war auch noch nicht.
Die Umstände der damaligen/jeweiligen Zeit sind nat. immer zu 
berücksichtigen.
Im Endeffekt geht es um Kosten, also: was kann es was kostet es.
Das war in den 50ern, 60ern schon so.
DEC hatte Ende der 60ern CPUs (damals noch nicht in IC-Form) heraus 
gebracht, nicht weil es teurer sondern billiger als bei IBM war.
Früher (50er, 60er) war Massenspeicher als IC-Form fast nicht möglich 
weil extrem teuer.
Die damaligen Trommelspeicher oder auch Magnetkernspeicher waren (auch 
für damalige Verhältnisse) extrem langsam.
Man musste also guggen (!), dass man nicht zu viele Speicherzugriffe 
benötigt.
Jeder eingesparte Speicher-Cyclus war ein Vorteil.
Daher kommen die CISC eigentlich her. Es gab also schon einen Grund 
dafür.
Und auch heute ist das Problem (prinz.) immer noch so, weil grosser 
Speicher zwar billig ist, aber (eben wegen der Grösse) rel. weit weg von 
der eigentl. CPU ist; was heisst, dass dadurch die Zugr./Lat.Zeit auch 
rel. langsam ist.
Es macht also auch heute keinen Sinn die primitivste (RISC) CPU zu 
bauen.

>Multiprozessor war auch noch nicht.
Gabs da auch schon. Bsp Cray.

von (prx) A. K. (prx)


Lesenswert?

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

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

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.

: Bearbeitet durch User
von MCUA (Gast)


Lesenswert?

Renesas hat den M32C.. nicht ohne Grund so benannt.
Zugegeben, es ist dort nicht alles 32 Bit.
Daten-Register können zu 32 Bit komb. werden (was teils auch bei M16C 
mögl war), aber insbes. Rechnungen >16 Bit sind dort viel besser 
möglich,
 auch weil die A-Register dort 24 und nicht 16 Bit breit sind, was 
erhebliche Vorteile bringt.
(wenn es also ein typ 16-Biter wäre, dürfte er keine Register > 16 Bit 
haben) (oder sollten die den 24-Biter nennen?)
Auch ist im OP-Code dsp24 u. abs24 möglich, was beim M16C nicht ging.
MOV geht beim M32C.. auch mit 32 Bit (L-Spezif).
Ausführungszeiten sind schneller, weniger Takte (gut das hat nichts mit 
der Breite zu tun).

Die R8C-CPU ist die gleiche wie die von M16C, allerd. intern nur mit 
8-Bit-Bus (haben auch kein XMEM-IF).
Man hat das halt billiger gemacht.

Diese MCUs waren/sind ab Mitte der 90er anderen weit voraus.
Erst später haben andere etwas aufgeholt.

Verwirrspiel?
Daran sieht man, dass Renesas die CPUs (zusätzl. zur Perif.) immer 
erweitert hat und nicht (wie bsp. Atmel oder auch andere) daran 
eingeschlafen sind.
(Was wurde an 8051 an der Speicher-Architek. erweitert? nix)
M16C20 - M16C60 - M16C80 - M32C - R32C, sind alles aufsteigende Serien.
(keine dieser Serien ist zu blöd 'drausen' atomic ein Bit zu setzen oder 
32 Bits auf ungerade Speicher-Adressen zu verteilen oder INT-Ebenen zu 
haben)
Der R32C stellt den 68k in den Schatten!
Beim RX (neuer) ist man da z.T  wieder zurück gerudert;
  der ist in manchen Teilen besser, in anderen (Adress.Arten) 
schlechter.

von W.S. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Der M32C/8x ist klar ein 16-Bitter,

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

Na OK, der tatsächlich noch (prinzipiell) verfügbare Rest der vormaligen 
Vielfalt ist heuer dank Corona oder einer anderen Ausrede nur noch 
tröpfchenweise zu haben, da muß man zum Diskutieren auf ältere 
Architekturen zurückgreifen.

W.S.

von (prx) A. K. (prx)


Lesenswert?

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.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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

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

von MCUA (Gast)


Lesenswert?

>da muß man zum Diskutieren auf ältere Architekturen zurückgreifen.
Hab verstanden.
Du willst Telefunken (der so schwer ja gar nicht ist) als neuen 
MCU-Standard etablieren.

von Johannes (Gast)


Lesenswert?

Im Endeffekt bewegen sich beide Grundrichtungen aufeinander zu.

In den Urzeiten konnte man noch gut zwischen RISC und CISC unterscheiden 
weil die CPUs so einfach gestrickt waren, dass man gerade so die 
Grundfunktionalität umsetzen konnte.

Heute überbieten sich die Hersteller gegenseitig darin jede erdenkliche 
Erweiterung in das Design zu kloppen. Transistoren gibts im Überfluss 
und wenn man nichts sinnvolles damit anfangen kann werden halt Caches 
implementiert.

x86 als letzter richtiger CISC Vertreter hat sich auf eine kleinere 
(aber immer noch umfangreiche) Anzahl von Kernbefehlen reduziert. (Die 
ganzen Stringops vom 8086er gehen zB. zwar prinzipiell noch, aber die 
Performance ist nicht sinnvoll.)

Umgekehrt gibt es (bei x86 und z.B. ARM) immer mehr Opcode-Erweiterungen 
für Spezialzwecke, siehe der Java Befehle oben. (*)
Die ganzen Erweiterungen wie z.B. AVX haben eh ihre völlig eigene 
Codierung und sind alle ziemlich eindeutig CISC.

Wer sich mal zu Gemüte führen will wie komplex x86 Befehle tatsächlich 
werden können, vor allem bei den ganzen Erweiterungen, dem sei diese 
Seite hier empfohlen: http://ref.x86asm.net/coder64.html

Es gibt viele sinnvolle 1byte/2byte Opcodes auf x86 die auch wesentlich 
kürzer sind als ihre (32/64bit) RISC Pendants, z.B. "ADD <register>, 
<register>" oder PUSH/POP, aber natürlich auch Entgleisungen für 
teilweise sogar halbwegs alltägliche Dinge, wie z.B. CVTSI2SS um einen 
int zu float zu konvertieren (4 bytes) oder halt so richtige 
Entgleisungen für sehr spezielle Dinge (glaub 9 oder 12 bytes sind die 
längsten x86 Opcodes momentan.)


(*): Der Rundungsmodus in der JVM entspricht nicht dem Standard auf x86, 
daher muss man dort vor jedem assemblierten Java Code den Rundungsmodus 
im CPU MSR umschalten was nervig ist und Zeit kostet. Daher wohl der 
Befehl.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.