Wie lautet ein beispielhafter CISC-Befehl, den eine x86-Architektur verarbeiten kann?
Besitzen neuere x86-Prozessoren eigentlich noch irgendwelche Eigenschaften von CISC-Architekturen?
Torben schrieb: > Besitzen neuere x86-Prozessoren eigentlich noch irgendwelche > Eigenschaften von CISC-Architekturen? Ja. BTW: Was ist für dich der neueste x86 Prozessor?!
Karl Kawumm schrieb: > Torben schrieb: >> Besitzen neuere x86-Prozessoren eigentlich noch irgendwelche >> Eigenschaften von CISC-Architekturen? > > Ja. Inwiefern? > > BTW: > Was ist für dich der neueste x86 Prozessor?! i7
Torben schrieb: > Karl Kawumm schrieb: >> Torben schrieb: >>> Besitzen neuere x86-Prozessoren eigentlich noch irgendwelche >>> Eigenschaften von CISC-Architekturen? >> >> Ja. > Inwiefern? The terms CISC and RISC have become less meaningful with the continued evolution of both CISC and RISC designs and implementations. The first highly (or tightly) pipelined x86 implementations, the 486 designs from Intel, AMD, Cyrix, and IBM, supported every instruction that their predecessors did, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ but achieved maximum efficiency only on a fairly simple x86 subset that was only a little more than a typical RISC instruction set (i.e. without typical RISC load-store limitations). (aus: https://en.wikipedia.org/wiki/Complex_instruction_set_computer#CISC_and_RISC_terms) >> >> BTW: >> Was ist für dich der neueste x86 Prozessor?! > i7 Der ist x64 und nicht x86. x86 endetet irgendwoe bei Pentium-4 kurz nach der Jahrtausendwende. Wobei manche schon IA32 (ab intel80386) nicht mehr zu x86 zählen [obwohl dieser binär abwärtskompatibel zu seinen Vorgängern-architekturen ist]).
Torben schrieb: > Besitzen neuere x86-Prozessoren eigentlich noch irgendwelche > Eigenschaften von CISC-Architekturen? Hast du dir den "rep movs" Befehl einmal angesehen und unter dem RISC/CISC Gesichtspunkt betrachtet, oder klapperst du vorher erst einmal alle Fragen der Aufgabe ab?
Schön zu sehen ist vllt folgender Vergleich: ARM Cortex‑M4 processor instruction set (RISC) https://developer.arm.com/docs/100166/0001/programmers-model/instruction-set-summary/table-of-processor-instructions und die DSP Erweiterungen (CISC) https://developer.arm.com/docs/100166/0001/programmers-model/instruction-set-summary/table-of-processor-dsp-instructions
Autsch - x86 ... na dann dann halt MMX oder SSE4: DPPS - Skalarprodukt bestimmen https://www.felixcloutier.com/x86/dpps
A. K. schrieb: > Hast du dir den "rep movs" Befehl einmal angesehen und unter dem > RISC/CISC Gesichtspunkt betrachtet, CISC-Befehle zeichnen sich durch bestimmte Merkmale aus. Sie haben eine variable Länge und können daher mehr als ein Maschinenwort einnehmen. Das trifft auf klassische RISC-Befehle nicht zu. Der Befehl rep movs kopiert Speicherblöcke. Die Anzahl der Speicherblöcke ist dabei variabel. Aus diesem Grund kann dieser Befehl je nach Anzahl der Speicherblöcke sehr lang werden. Daraus kann ich schlussfolgern das der rep movs Befehl ein CISC-Befehl ist. Somit müssten reine x86-Architekturen zum Zweck der Abwärtskompatibilität CISC-Befehle verarbeiten können. Ist diese Logik richtig?
Karl Kawumm schrieb: >> i7 > > Der ist x64 und nicht x86. ist x64 nicht x86 mit einer x64-Erweiterung? Bei Wikipedia steht: Die Core-i-Serie von Intel ist eine Familie von mittel- bis hochpreisigen x86-Mikroprozessoren für Mobil- und Desktoprechner in typischen Anwendungsbereichen wie Büro, Arbeit, Internet, Multimedia, Freizeit und Spielen.
Torben schrieb: > Karl Kawumm schrieb: >>> i7 >> >> Der ist x64 und nicht x86. > > ist x64 nicht x86 mit einer x64-Erweiterung? > > Bei Wikipedia steht: Die Core-i-Serie von Intel ist eine Familie von > mittel- bis hochpreisigen x86-Mikroprozessoren für Mobil- und > Desktoprechner in typischen Anwendungsbereichen wie Büro, Arbeit, > Internet, Multimedia, Freizeit und Spielen. Nun ich sehe es es so das in der Wikipedia Begriffe wie GeneralPurpose CPU von intel und x86-architekture nach Belieben und Unfähigkeit des jeweiligen Autors vermischt werden. Ferner bin ich der meinung das ein intel 8086, ein Intel 80386 und ein intel Core i7 nicht dieselbe Architektur aufweisen. Daher kann man IMHO zwar Ableitungen bezüglich der Befehlssatzarchitektur aus einem intel-Prozessor von 1978 wie "Ist 100% CISC" treffen, die aber nicht wirklich übertragbar auf einen intel prozessor von 2008 und später sind. Des weiteren vertete ich den Standpunkt, das eine Diskussion was nun CISC-Eigenschaften und was nun RISC eigenschaftn resp. ein Prozessor reichlich akademisch sind. Das sollte auch das Zitat aus der englischsprachigen WP zu Ausdruck bringen.
Torben schrieb: >>> i7 >> Der ist x64 und nicht x86. > > ist x64 nicht x86 mit einer x64-Erweiterung? Ursprünglich nannte man die Architektur amd64. AMD hatte damit Intel überholt, die ewig (und im Prinzip erfolglos) an ihrer Itanium-Architektur herumgedoktort haben. Als Intel dann nachgezogen hat, haben sie den Terminus x86_64 ins Leben gerufen. Der Dreh der Architektur (und daher die bessere Akzeptanz im Vergleich zu Itanium) ist insbesondere, dass sie komplett rückwärtskompatibel im 32-bit-Modus betrieben werden kann. Im 64-bit-Modus wiederum erweitert sie nicht nur den Adressraum und die Registerbreite, sondern hat insbesondere den allgegenwärtigen Registermangel des ursprünglichen x86 behoben, indem sie je 8 weitere Integer- und Gleitkomma-Register bereitstellt. https://de.wikipedia.org/wiki/X64 Am grundsätzliche Befehlssatz hat sie aber nicht gerüttelt. Thomas K. schrieb: > und die DSP Erweiterungen (CISC) Wie kommst du darauf, die wären CISC? Hast du dir mal die Ausführungszeiten angesehen? Torben schrieb: > CISC-Befehle zeichnen sich durch bestimmte Merkmale aus. Sie haben eine > variable Länge und können daher mehr als ein Maschinenwort einnehmen. Insbesondere können sie in der Ausführungszeit stark variieren, genau daher ist REP MOVS (oder auch LDIR bei Z80) ein typischer CISC-Befehl. Das mit der einheitlichen Länge des Befehlsworts ist inzwischen auch bei RISC nicht mehr durchweg gegeben, denn es hat sich als unpraktikabel erwiesen. Nimmt man einheitlich ein langes Befehlswort, bläht es den Code überflüssig auf, nimmt man ein kurzes, muss man starke Einschränkungen im Befehlssatz in Kauf nehmen. Der Siegeszug von ARM dürfte daher wesentlich darin begründet sein, dass sie mit Thumb eben vom streng klassischen RISC in dieser Hinsicht abgewichen sind.
Torben schrieb: >> BTW: >> Was ist für dich der neueste x86 Prozessor?! > i7 Das ist doch nur alte aufgewärmte 14nm Schlonze mit Skylake Architektur. Daher uralt in PC Maßstäben. Die Ryzens sind die modernere Architektur.
Die ganze Diskussion um RISC und CISC ist heute doch weitgehend obsolet. Die Intention von RISC war, mit einem sehr schlanken aber schnellen Befehlssatz und mit Hilfe von Compileroptimierungen die Geschwindigkeit zu steigern. Bestes Beispiel sind die (ersten) Power-CPUs von IBM. Die koennen wirklich nur RISC. Das mit der gesteigerten Geschwindigkeit mag ja hinkommen, aber die Compileroptimierung liess dann doch zu wuenschen uebrig. Deutlich sichtbar an den Compilationsergebenissen und dem Speicherverbrauch der Executables. Eine marktbedeutende Nur-RISC Architektur gibt es doch gar nicht mehr.
Dummbeutel schrieb: > Bestes Beispiel sind die (ersten) Power-CPUs von IBM. MIPS passt besser. > Die koennen wirklich nur RISC. Weil IBM damals so vorsichtig war, RISC als Akronym von "Reduced Instruction Set Cycles" zu definieren. Es war von Anfang an ein sehr grosser Befehlssatz. Es waren anfangs auch Befehle mit variabler Ausführungszeit dabei - die m.W. teilweise per Microcode ausgeführt wurden. Zum klassischen RISC Begriff passt das nicht so recht. > Das mit der gesteigerten Geschwindigkeit mag ja hinkommen, aber > die Compileroptimierung liess dann doch zu wuenschen uebrig. Die Verlagerung der Komplexität von Hardware zu Compiler hatte schon in den 70ern mit John Cocke ziemlich deutliche Ergebnisse erbracht. Dieser Aspekt nahm allerdings an Relevanz ab, als genug Chipfläche investiert werden konnte, um per OOO-Implementierung die Nachteile von CISC zu kompensieren (ab Pentium Pro).
Dummbeutel schrieb: > Das mit der gesteigerten Geschwindigkeit mag ja hinkommen, aber > die Compileroptimierung liess dann doch zu wuenschen uebrig. Auch nur, weil Intel letztlich die Compileroptimierung versucht, durch „wirf mehr Gatter an die Front“ auf Chipniveau zu ersetzen. Damit sind sie zwar geschwindigkeitsmäßig erfolgreich, aber die Energiebilanz ist einfach unter aller Sau. In ein Gerät mit begrenzten energetischen Ressourcen kann man sowas nicht bauen. > Eine marktbedeutende Nur-RISC Architektur gibt es doch > gar nicht mehr. Was siehst du bei ARM, was nicht RISC wäre?
Jörg W. schrieb: > In ein Gerät mit begrenzten energetischen > Ressourcen kann man sowas nicht bauen. Intels Versuche, mit Atom-Derivaten im Android Handy/Tablet-Sektor zu landen, war zwar nicht allzu erfolgreich, aber in Fragen von Performance vs Energie war das in etwa vergleichbar. Es hatte in Android aber auch keine Vorteile und der Markt nahm das nicht an.
A. K. schrieb: > Es hatte in Android aber auch keine Vorteile und der Markt nahm das > nicht an. Das ist dann schätzungsweise der genau umgekehrte Effekt bei Server-CPUs: dort hatten die diversen RISC-CPUs am Ende auch keine Vorteile mehr gegenüber Intel oder AMD. Aber ein Geschwindigkeitswunder ist so ein Atom halt auch nicht gerade.
Dummbeutel schrieb: > Eine marktbedeutende Nur-RISC Architektur gibt es doch > gar nicht mehr. Dafür bald™ RISC V.
A. K. schrieb: > werden konnte, um per OOO-Implementierung die Nachteile von CISC zu ^^^^^^^^^^^^^^^^^^^^ Was ist OOO-Implementierung? Tüppfehler für OOP (ObjektOrientierte Programmierung)?
Jörg W. schrieb: > Aber ein Geschwindigkeitswunder ist so ein Atom halt auch nicht gerade. Als Intel damit anfing war deren Dualcore vergleichbar mit ARM Quadcores.
Karl Kawumm schrieb: >> werden konnte, um per OOO-Implementierung die Nachteile von CISC zu > ^^^^^^^^^^^^^^^^^^^^ > > Was ist OOO-Implementierung? Tüppfehler für OOP (ObjektOrientierte > Programmierung)? Kein Tippfehler. OOO = Out Of Order. https://en.wikipedia.org/wiki/Out-of-order_execution
A. K. schrieb: > Kein Tippfehler. OOO = Out Of Order. > https://en.wikipedia.org/wiki/Out-of-order_execution Danke, google hat mir für OOO nichts vernünftiges ausgespuckt. (openOffice.org und so nen Mist).
Jörg W. schrieb: >> Es hatte in Android aber auch keine Vorteile und der Markt nahm das >> nicht an. > > Das ist dann schätzungsweise der genau umgekehrte Effekt bei > Server-CPUs: dort hatten die diversen RISC-CPUs am Ende auch keine > Vorteile mehr gegenüber Intel oder AMD. x86 Server-CPUs wurden schneller schneller als die Server-RISCs, Intels Itanium inklusive. Wobei AMD daran einen wesentlichen Anteil hat, denn Intel wollte den 64-Bit Schritt in x86 ursprünglich nicht gehen, wurde von AMD dazu gezwungen. ARMs Mobil-CPUs wurden schneller schneller als Intels.
:
Bearbeitet durch User
A. K. schrieb: > Intels Server-CPUs wurden schneller schneller als die Server-RISCs. Und Windows durfte im Wesentlichen bei seiner angestammten CPU-Architektur bleiben. ;-) > Intel wollte den 64-Bit Schritt in x86 ursprünglich nicht gehen, wurde > von AMD dazu gezwungen. „Gezwungen“ ist gut. :)
:
Bearbeitet durch Moderator
Jörg W. schrieb: >> Intel wollte den 64-Bit Schritt in x86 ursprünglich nicht gehen, wurde >> von AMD dazu gezwungen. > > „Gezwungen“ ist gut. :) Aber genau so war es. AMD brachte die x86-64 Architektur raus, und mit den überlegenen Opterons die performante Hardware dazu. Intel hatte damals die durchwachsene erste Netburst Architektur für 32-Bit x86, und die durchaus performante Itanium Hardware für 64 Bit. Intel war gezwungen, darauf in Form von 64-Bit x86 zu reagieren, da sich Itanium nicht universell durchsetzte. Microsoft wiederum stellte klar, dass sie nur AMDs x86-64 unterstützen würden, keine zweite verschiedene 64-Bit x86 Variante von Intel.
Ein paar weiterführende Gedanken zu RISC vs. CISC: https://web.archive.org/web/20120916102105/http://semipublic.comp-arch.net/wiki/RISC_versus_CISC
Beitrag #6116388 wurde vom Autor gelöscht.
A. K. schrieb: > x86 Server-CPUs wurden schneller schneller als die Server-RISCs, Intels > Itanium inklusive. Ich glaube nicht, daß das der Hauptgrund für den Untergang von RISC oder gar Itanium war. Beide Architekturen beziehen ihren (theoretischen) Leistungsvorteil vom Compiler. Itanium hat diese Idee von RISC ja noch mal auf die Spitze getrieben, weil da der Compiler gleich mehrere Befehlsströme auf einmal optimieren sollte (EPIC). Aber die Kaufleute haben derart unverschämte Preise für die Compiler aufgerufen, daß die keiner so recht bezahlen wollte. Ergo gab es keine Software, die die neuen Architekturen hätte ausreizen können. Für Itanium wurde in letzter Sekunde noch versucht, ein x86 Kompatibilitätslayer zu etablieren. Aber da war es dann wirklich schon zu spät. Die x64 Konkurrenz war leistungsmäßig davon gezogen.
> unverschämte Preise für die Compiler aufgerufen
Die Preise fuer die harte Ware waren aber auch nicht ohne.
Ich erinnere mich an 200k fuer eine Kiste.
RISC war doch nur interessant, weil man durch den primitiven Befehlssatz Chipfläche einsparen konnte. Die Chipentwickler hatten damit auch ein leichteres Leben, und die Chips waren schnell am Markt. RISC hat gegenüber CISC sonst keinen Vorteil. Es spricht auch nichts dagegen die Befehle schnell zu machen, und trotzdem mehrere Varianten (nicht nur Load-Store) einzubauen. Kann sich noch jemand an den damals schnellsten Rechner erinnern? https://de.wikipedia.org/wiki/Alpha-Prozessor Dafür musste der Endanwender 50% mehr RAM für die gleiche Applikation kaufen, und RAM war richtig teuer. Die RISC Rechner waren primitiv, und waren auch nur schnell, wenn die Assembler Befehle in der richtigen Reihenfolge daherkamen. Die Hoffnung war, dass der Compiler es schon richten wird, das ging aber eher nicht auf.
Udo K. schrieb: > RISC war doch nur interessant, weil man durch den primitiven > Befehlssatz Chipfläche einsparen konnte. Ist es ja auch jetzt noch – oder was werkelt in deinem Telefon?
An die Minusbewerter hier im Forum: Schaut euch doch den Befehlssatz eines aktuellen Handys an... Bzw. Findet erst mal raus, welcher Prozessor in eurem Handy überhaupt welche Aufgaben hat... und da werkelt einiges mehr als nur ARM drinnen. Das hat mit RISC wie es im Elfenbeinturm von Patterson und Hennessy in den 80'ern definiert wurde, nicht viel zu tun.
Udo K. schrieb: > Jedenfalls kein RISC Prozessor :-) Ah ja. Dann hast du ihn dir wohl nicht so genau angesehen. Oder du definierst dir „RISC“ einfach mal so zurecht, damit das zu deiner Aussage passt (beispielsweise durch sturres Beharren auf der These, es wäre nur dann RISC, wenn auch wirklich alle Befehle gleich lang sind).
Udo K. schrieb: > Dafür musste der Endanwender 50% mehr RAM für die gleiche Applikation > kaufen, und RAM war richtig teuer. Wobei das ein 64-Bitter zu einem Zeitpunkt war, zu dem anderswo 32-Bitter üblich waren. Wodurch nicht nur der Code wuchs, sondern auch die Daten. Und nicht jeder code bloat ging auf Rechnung RISC. So beispielsweise die ursprüngliche Entscheidung, keine Bytes laden und speichern zu können, sondern dafür Mask/Merge-Operationen zu benötigen.
Udo K. schrieb: > Bzw. Findet erst mal raus, welcher Prozessor in eurem Handy überhaupt > welche Aufgaben hat... und da werkelt einiges mehr als nur ARM drinnen. Auch wenn in der PC-Tastatur ein 8051-Derivat werkelt, wird aus dem PC noch lange kein 8-Bit Rechner.
:
Bearbeitet durch User
Udo K. schrieb: > Das hat mit RISC wie es im Elfenbeinturm von Patterson und Hennessy > in den 80'ern definiert wurde, nicht viel zu tun. Ein heutiger Intel- oder AMD-Prozessor hat auch nicht mehr viel mit dem gemein, gegen die die ursprünglichen RISC-Architekturen vor 3 Jahrzehnten mal angetreten sind. Wenn du denen eine Weiterentwicklung zugestehst, dann darfst du dem RISC-Konzept auch eine Weiterentwicklung zugestehen hinsichtlich der dann irgendwann erkannten Schwächen des Konzepts, insbesondere der schlechten Codedichte. Trotzdem haben auch aktuelle ARMs noch hinreichend viel von den ursprünglichen RISC-Ideen an Bord: kurze Ausführungszeiten (also eben nichts wie die oben ins Feld geführten REP MOVS, bei dem es vom Inhalt der CPU-Register abhängt, wie lange der Befehl braucht), Drei-Adress-Code, Load-Store-Architektur.
Oliver S. schrieb: >>> Was ist für dich der neueste x86 Prozessor?! >> i7 > > Warum nicht der i9? > > Oliver Bezeichnungen wie i3 bis i9 sind in diesem Zusammenhang sinnlos, denn das sind Marketing-Namen innerhalb einer Implementierungs-Architektur. Das exakt gleiche Die kann dabei in mehreren dieser Klassen auftreten, mit unterschiedlicher Freischaltung von Cores und Features, während der gleiche Name "i5" für verschiedene Dies stehen kann, je nach Nummer dahinter.
Beitrag #6117328 wurde von einem Moderator gelöscht.
A. K. schrieb: > Udo K. schrieb: >> Bzw. Findet erst mal raus, welcher Prozessor in eurem Handy überhaupt >> welche Aufgaben hat... und da werkelt einiges mehr als nur ARM drinnen. > > Auch wenn in der PC-Tastatur ein 8051-Derivat werkelt, wird aus dem PC > noch lange kein 8-Bit Rechner. Na ja, der Prozessor der fürs telefonieren und fürs surfen wirklich benötigt wird, ist aber kein ARM... Auf ARM läuft nur die GUI. Aber zurück zum Thema: Was RISC ist, ist eine Definitionssache. Und den Begriff RISC hat Patterson und Hennessy in ihrem bekannten Buch Ende der 80'er definiert. Und nach der Definition gibt es heute noch genau einen Risc Prozessor, RISC-V mit 31 Befehlen, und den will heute keiner mehr wirklich haben. (Der braucht sogar Extension, um Bitmanipulationen oder Addition mit Carry durchzufürhren...)
Beitrag #6117342 wurde von einem Moderator gelöscht.
Beitrag #6117350 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > Udo K. schrieb: >> Das hat mit RISC wie es im Elfenbeinturm von Patterson und Hennessy >> in den 80'ern definiert wurde, nicht viel zu tun. > > Ein heutiger Intel- oder AMD-Prozessor hat auch nicht mehr viel mit dem > gemein, gegen die die ursprünglichen RISC-Architekturen vor 3 > Jahrzehnten mal angetreten sind. Wenn du denen eine Weiterentwicklung > zugestehst, dann darfst du dem RISC-Konzept auch eine Weiterentwicklung > zugestehen hinsichtlich der dann irgendwann erkannten Schwächen des > Konzepts, insbesondere der schlechten Codedichte. Trotzdem haben auch > aktuelle ARMs noch hinreichend viel von den ursprünglichen RISC-Ideen an > Bord: kurze Ausführungszeiten (also eben nichts wie die oben ins Feld > geführten REP MOVS, bei dem es vom Inhalt der CPU-Register abhängt, wie > lange der Befehl braucht), Drei-Adress-Code, Load-Store-Architektur. Natürlich kann man den Begriff RISC nach belieben aufweichen. Auch ein 80386 geht damit locker als RISC durch. Der hat die typischen Register-zu-Register Befehlen, und reine Load/Store Befehle sind ja auch da. Zum Glück sind CPU Entwickler nicht sehr pragmatisch, und bauen einfach ein, was sinnvoll ist.
Jörg W. schrieb: > Ein heutiger Intel- oder AMD-Prozessor hat auch nicht mehr viel mit dem > gemein, gegen die die ursprünglichen RISC-Architekturen vor 3 > Jahrzehnten mal angetreten sind. Wenn du denen eine Weiterentwicklung > zugestehst, dann darfst du dem RISC-Konzept auch eine Weiterentwicklung > zugestehen Wenn beide Konzepte eh nur noch wenig mit der Grundidee von vor 30 oder 40 Jahren zu tun haben und man sich auch selbst Techniken des Gegenübers bedient und somit alles verwischt - wieso beharrt man dann überhaupt noch auf so antiquitierte Begrifflichkeiten? Für mich macht die ganze Diskussion wenig Sinn.
Beitrag #6117371 wurde von einem Moderator gelöscht.
Beitrag #6117377 wurde von einem Moderator gelöscht.
Beitrag #6117382 wurde von einem Moderator gelöscht.
Beitrag #6117388 wurde von einem Moderator gelöscht.
Beitrag #6117389 wurde von einem Moderator gelöscht.
Le X. schrieb: > Für mich macht die ganze Diskussion wenig Sinn. Die Diskussion begann mit der Frage, was ein typischer CISC-Befehl sei. Die Antwort wurde im zweiten Posting gegeben.
Beitrag #6117412 wurde von einem Moderator gelöscht.
A. K. schrieb: > Bezeichnungen wie i3 bis i9 sind in diesem Zusammenhang sinnlos Du hast den Kern des Problems erfasst ;) Wobei das Hauptproblem ist, daß der TO völlig ahnungslos seine Hausaufgaben-Fragen hier abspult (das ist ja nicht der erste Thread zu dem Themenkreis), aber der Ersteller der Hausaufgaben noch viel weniger Ahnung von dem hat, was er da eigentlich fragt, und dazu auf dem Kenntisstand es letzten oder vorletzten Jahrtausends herumrätselt. Die Fragen sind ja gar nicht so abwegig, aber mit Bezug auf aktuelle Prozessoren völlig sinnlos. Oliver
Udo K. schrieb: > Na ja, der Prozessor der fürs telefonieren und fürs surfen > wirklich benötigt wird, ist aber kein ARM... > Auf ARM läuft nur die GUI. Alle anderen Prozessoren stecken in embedded Blackboxes, sind dem Anwender verborgenen Interface-Lösungen, wie Baseband oder die genannte PC-Tastatur, aber auch allerlei Sensoren, GPS, Flash-Chip uvam. Selbst dann, wenn sie aufs normale RAM zugreifen. Deren Implementierung ist meist nicht einmal für Techies wirklich interessant. Relevant für Anwendungen ist nur der Prozessor vom Android selbst, auch nicht der Baseband-Teil - selbst wenn der auf dem gleichen SoC sitzt. Wollte man PCs oder Handys über sämtliche Komponenten klassifizieren, die Prozessoren enthalten, würde das eine recht lange Liste, die u.U. nicht einmal der Hersteller des Gerätes vollständig kennt. > Was RISC ist, ist eine Definitionssache. Die RISC/CISC Diskussion hat einen ziemlichen Bart und erinnert - heute geführt - ein wenig an Gullivers Reisen. Ist ARM RISC, weil eindeutig am load/store Prinzip orientiert, oder CISC, weil die variablen LDM/STM Befehle nicht ins strenge Gerüst passen? Motorola hatte Coldfire als "variable length RISC" bezeichnet, weil man sich damals nicht ohne die "RISC" Assoziierung auf den Markt traute. Absurder gehts kaum. > Und den Begriff RISC hat Patterson und Hennessy in ihrem bekannten Buch > Ende der 80'er definiert. Wobei eine jahrzehntealte Definition an Sinn verlieren kann. Das ist wie bei der Definition von Harvard/Neumann Architekturen über reale Busse, die in dieser Form schon lange nicht mehr praktisch anwendbar ist.
:
Bearbeitet durch User
Udo K. schrieb: > Und nach der Definition gibt es heute noch genau einen Risc Prozessor, > RISC-V mit 31 Befehlen, und den will heute keiner mehr wirklich haben. Also dafür dass den RISC-V keiner will ist der gerade ziemlich am aufsteigenden Ast... Udo K. schrieb: > Der braucht sogar Extension, um Bitmanipulationen oder Addition mit > Carry durchzufürhren... Sowas nennt sich modulares Design. Man zieht nur rein, was man wirklich braucht und will. Wenn du das Ding als Softcore auf einem FPGA laufen lassen willst, kostet nun mal jede einzelne Instruction wertvolle Register, da ist es praktisch Dinge weglassen zu können.
Udo K. schrieb: > den Begriff RISC hat Patterson und Hennessy in ihrem bekannten Buch > Ende der 80'er definiert. Auch Definitionen haben ein Ablaufdatum. > nach der Definition gibt es heute noch genau einen Risc Prozessor, > RISC-V mit 31 Befehlen, und den will heute keiner mehr wirklich haben. "heute keiner mehr"? Kommst du aus der Zukunft? RISC-V erscheint gerade mal am Horizont, was die Verfügbarkeit von Silizium und Toolchain angeht. Und du stimmst schon den Abgesang an? Wie das Rennen ARM vs. RISC-V ausgeht, ist derzeit noch offen. IMHO.
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.