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.
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.
Angehängte Dateien:
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.
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.
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
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.
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
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: > 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.
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.
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.
> Wieso spricht MAN ...
Wer spricht eigentlich von Risc? Wir Techniker oder Amtels
Marketingabteilung?
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
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.
> 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: > 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!
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.
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.
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.
>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
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.
MCUA schrieb: > Das kann man heute (bei gleicher Architekt) viel schneller haben. Ach? Wo wäre das? (bezogen auf den 6809)?
>> 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)
>.. 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.
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...
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.
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.
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
>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.
> 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.
>> 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)
Ben B. schrieb: > Ich erinnere mal an den C64 Immer noch "aktuell"! Siehe: https://www.youtube.com/watch?v=PSBo-TpEJ24
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.
> 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)
>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.
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.
>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.
Ä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
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.
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.
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.
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.
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
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.
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
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 ;-)
>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)
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
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.
>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).
Die winzigen 1614er Tiny möchte ich hier auch ausdrücklich empfehlen. Zwar SMD aber mit äußerst bastler-lötfreundlichem Pinabstand!
> [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.
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.
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.
:
Bearbeitet durch User
(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.
>Berechenbarer Determinismus in der Code-Abarbeitung. Mangels Pipeline. Der AVR hat eine Pipeline, wenn auch eine sehr kurze.
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 ;-)
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?
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"
:
Bearbeitet durch User
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
:
Bearbeitet durch User
(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.
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.
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.
>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)
AMD K6-2 schrieb: > Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören? Weil diese Abkürzungen zu Marketing Bullshit verkommen sind.
>Nicht zu wissen, wo eine Instruktion >anfängt oder endet, ist doch ziemlicher mist. Auch bei CISC weiss man wo eine Instruktion anfängt.
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.
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
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.)
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.
> 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)
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.
>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.
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
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.
:
Bearbeitet durch User
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
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 :)
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.
Also ich frage mich schon lange, was dieses RISC eingentlich sein soll. Autoaufkleber mit "No RISC, No Fun" finde ich jedenfalls komplett daneben.
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
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: > Autoaufkleber mit "No RISC, No Fun" finde ich jedenfalls komplett > daneben. Wer RISC und "risk" nicht auseinanderhalten kann ...
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!!!! ;-)
Axel S. schrieb: >> Wie kann der gleiche Maschinenbefehl zu CISC und RISC gehören? > > Äpfel und Birnen. Nö, NOP ist bspw. CISC wie RISC.
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
(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.
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
(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).
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
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.
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. ;-)
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.
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
:
Bearbeitet durch User
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
>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".
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.
:
Bearbeitet durch User
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)
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.
>> 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?
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? ;-)
Na, der Eine hat mit dem Anderen ein bisschen telefoniert, hat sich ein bisschen bezahlen lassen.
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
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.
>..dann auf PowerPC..
Was eine CPU ist, mit starrem (damit uneffizientem) Befehlssatz.
Hat Motorola falsch gemacht. (Nur der Name war gut gewählt)
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
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.
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.
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.
:
Bearbeitet durch User
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
>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.
(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
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
Angehängte Dateien:
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
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.
(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.
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
(prx) A. K. schrieb: > Über RISC V kann man in diesem Zusammenhang schlecht streiten. Ist doch bestimmt auch nur ein Marketing-Name. :-)
>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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.