Hallo! Ich bin Anfänger in der µC Programmierung und programmiere z.Z. einen 8-Bit µC von Atmel mit AVR Studio 6.1 und gcc. Da ich zukünftig auch größere Projekte durchführen will, würde ich mich gerne mal informieren, was das genau mit der Bittiefe der µCs auf sich hat. Es gibt ja auch 32-Bit µCs... Mir ist klar, dass bei einem 8-Bitter in einem Rechenschritt 8 Bit verarbeitet werden und bei einem 32-Bitter eben 32. Heißt das also, um 32 Bit zu verarbeiten benötigt ein 8-Bitter 4 Takte und ein 32-Bitter nur einen, hab ich das richtig verstanden? Was genau ist dann bei der Programmierung zu beachten? Gibt es da Unterschiede, die zu beachten sind oder macht sich der Unterschied zwischen 8 und 32 Bit einfach nur in der Geschwindigkeit bemerkbar? THX, lG
Werner Weinwurm schrieb: > Heißt das also, um > 32 Bit zu verarbeiten benötigt ein 8-Bitter 4 Takte und ein 32-Bitter > nur einen, hab ich das richtig verstanden? Im Prinzip ja. Andererseits: wenn du exakt 8 Bit bearbeiten willst, braucht ein 32-Bitter dafür eben in seinen Registern trotzdem 32 Bits, und muss u. U. zusätzlichen Aufwand treiben, um dann genau die gewünschten 8 Bits da rauszupopeln. > Was genau ist dann bei der Programmierung zu beachten? Das hängt natürlich in erster Linie von deiner Programmiersprache ab. In Assembler ist alles ganz anders, und du schreibst alles neu. In C ist vieles gleich. Allerdings bleibt der Unterschied, dass ein ‘int’ auf einem 8-Bitter eine Größe von 16 Bits hat, während es auf einem 32-Bitter 32 Bits sind. Man kann seine C-Programme zwischen beiden Welten weitgehend portabel schreiben (erst recht, wenn man die seit C99 existierenden Datentypen wie ‘uint8_t’, ‘uint_fast8_t’ usw. konsequent benutzt), aber das passiert nicht automatisch. Kommt hinzu, dass 32-Bit-Architekturen in aller Regel die Daten auch im Speicher passend ausgerichtet haben möchten (32-Bit-Daten müssen also auf einer durch 4 teilbaren Adresse stehen), während den 8-Bittern das egal ist.
Werner Weinwurm schrieb: > 32 Bit zu verarbeiten benötigt ein 8-Bitter 4 Takte und ein 32-Bitter > nur einen, hab ich das richtig verstanden? Grob formuliert, ja. Je nach Instruktion kann das auf den 8-Bitter aber auch noch länger dauern. Der größere Unterschied ist der Adressraum. Die AVR's haben einen 16bit-Adressraum, die können also maximal 2^16 Bytes an Daten (RAM, IO-Register) ansprechen. Um mit Pointern/Adressen zu rechnen brauchen die also immer 2 Takte oder mehr, da der Core ja intern nur mit 8Bit arbeitet. Einige 8-Bitter (8051, PIC, einige der großen AVR's wimre) müssen komplizierte und Compiler-unfreundliche Umschaltmechanismen ("Banking") bemühen, um die Limitierung des Adressraums zu umgehen. 32bitter wie zB ARM haben einen 32bit-Adressraum, können also 4 GB an Daten direkt adressieren, und außerdem effizent mit den Adressen/Pointern rechnen. Dafür wird der Code aber auch etwas größer, da die Pointer-konstanten nunmal länger sind. Außerdem können diese den Flash, RAM, I/O-Register etc. komplett in einem Adressraum verwalten, d.h. die gleichen Instruktionen für Zugriff auf RAM&Flash verwenden. Bei Pointern ist es somit egal, wo sie hinzeigen. Dies vereinfacht die C/C++-Programmierung und den Compiler-Support. ARM-Chips sind daher zwar etwas teurer, ist aber außerhalb von Serien-Produktion relativ egal...
Kindergärtner schrieb: > Dafür wird der Code aber auch etwas größer, da die Pointer-konstanten > nunmal länger sind. Außerdem braucht eine RISC-Architektur jedoch prinzipbedingt immer zwei Befehle, um eine komplette Adresse zu laden. (Prinzipbedingt deshalb, weil die Befehlsbreite gleich der Busbreite ist, folglich kann man in einem Befehl nie eine Konstante der vollen Breite unterbringen.) > Außerdem können diese den Flash, RAM, I/O-Register > etc. komplett in einem Adressraum verwalten, d.h. die gleichen > Instruktionen für Zugriff auf RAM&Flash verwenden. Das hat aber nichts mit der Bitbreite zu tun, sondern mit der Architektur: bei Harvard gibt es getrennte Busse, dafür kann auf beiden Bussen (Daten und Befehle) gleichzeitig gearbeitet werden, aber man braucht besondere Befehle, um von einem auf den anderen Bus übergehen zu können. Sowas gab's schon bei der PDP-11 (split I&D). Bei von Neumann gibt es einen Bus, man hat nur eine Sorte Zeiger, dafür müssen die Zugriffe serialisiert werden. Atmel AVR ist halt derzeit der bekannteste Vertreter mit einer Harvard-Architektur. Wenn man seinen Mitstreiter MSP430 ansieht, dann hat der als 16-Bitter aber eine von-Neumann-Architektur (wie der ARM). Auch der Z80 (kein Controller, aber ebenfalls 8-Bitter) hat eine von-Neumann-Architektur.
Danke für die Infos, habe mir schon gedacht dass es bei Assembler ein größeres Problem ist... Mit Assembler habe ich noch absolut keine Erfahrung, werde es aber sicher irgendwann mal machen. Dann wird mir der Unterschied bestimmt klarer werden! Vielen Dank!
>Mir ist klar, dass bei einem 8-Bitter in einem Rechenschritt 8 Bit >verarbeitet werden und bei einem 32-Bitter eben 32. Heißt das also, um >32 Bit zu verarbeiten benötigt ein 8-Bitter 4 Takte und ein 32-Bitter >nur einen, hab ich das richtig verstanden? 8/16/32 Biter heisst zunächst mal nur dass die interne Registerbreite 8/16/32 Bit ist. Sonst nichts. der Bus aussen, die Anzahl der benötigten Takte und auch der Adressbereich ist daraus nicht absehbar. zB kann auch ein 8Biter auch grössere Indexregister haben als 8 Bit, und kann somit auch entsprechend mehr adressieren. (obschon ein 32Biter wohl keine 16bit Indexregister haben wird). In Realität gibt es oft nicht Die Harvard oder Die VonNeumann-Archit., sonderen Mischformen daraus. Auch wenn mit einem einzigsten Pointer der ganze (im uC vorhandene) Bereich adressiert werden kann, kann es trotzdem eine Harvard-Arch. sein.
> dass es bei Assembler ein größeres Problem ist Nein, ein Problem ist es nicht. Du kannst problemslos auf 8bit Mikrocontrollern 32bit Berechnungen durchführen und umgekehrt. Am schnellsten sind natürlich Operationen in der nativen Breite. Das heisst aber keineswegs, dass die Prozessoren mit den anderen Breiten Probleme hätten. Ein Problem wäre für mich, wenn etwas nicht geht, oder nur mit extremen Aufwand. Wenn zum Beispiel ein 64Bit Personal Computer nicht imstande wäre, Textdateien mit 8bit Zeichensatz zu lesen. Oder wenn ein 8bit Mikrocontroller keine 32bit Prüfsummen für Ethernet berechnen könnte. Oder wenn man an einen 32bit PC keine 16bit USB Scanner anschließen könnte. Doch all das geht selbstverständlich und ganz ohne Probleme. > Prinzipbedingt deshalb, weil die Befehlsbreite gleich der Busbreite ist Das trifft nicht auf AVR Mikrocontroller nicht ganz zu. Denn die laden mit einem einzigen Takt einen ganzen Befehl aus dem Programmspeicher, und der ist 16 Bit breit, obwohl die Register, das RAM und die I/O Schnittstellen 8 Bit breit sind. Deswegen kann der ATmega1284 ohne besondere Erweiterung auch 128 Kilobyte Programmspeicher nutzen, obwohl sein Programmzähler nur 16 Bit (entsprechend 65536 Adressen) breit ist.
Stefan schrieb: >> Prinzipbedingt deshalb, weil die Befehlsbreite gleich der Busbreite ist > > Das trifft nicht auf AVR Mikrocontroller nicht ganz zu. Der ist ja auch kein echter RISC-Prozessor. Schon deshalb nicht, weil er genügend Befehle hat, die mehr als einen Takt für die Abarbeitung brauchen. (RISC-Philosophie ist es ja, den Prozessor so weiter runterzubrechen, dass alles in einem Takt geht.) > Deswegen kann der ATmega1284 ohne besondere Erweiterung auch 128 > Kilobyte Programmspeicher nutzen, obwohl sein Programmzähler nur 16 Bit > (entsprechend 65536 Adressen) breit ist. Andere Baustelle. Ein klassischer 32-bit-RISC-Prozessor hat halt die unteren 2 Bits seines PCs hart auf 0 gehabt. ARM ist dann nicht mehr klassisch, denn mit dem Thumb haben sie 16-bit-Opcodes eingeführt, und das eigentlich unbenutzte Bit 0 des PC dann als Kennzeichen für die Unterscheidung zwischen ARM und Thumb genommen.
Jörg Wunsch schrieb: > Außerdem braucht eine RISC-Architektur jedoch prinzipbedingt immer > zwei Befehle, um eine komplette Adresse zu laden. (Prinzipbedingt > deshalb, weil die Befehlsbreite gleich der Busbreite ist, folglich > kann man in einem Befehl nie eine Konstante der vollen Breite > unterbringen.) Das ist nicht korrekt. Korrekt ist, er kann die Addresse nicht in einem Opcode unterbringen. Aber dafür braucht es keine 2 Befehle also auch nicht zweimal Rechenzeit sondern lediglich den Zugriff auf zusätzliche Daten (die auch der CISC braucht) Beispiel die ARM Pseudo Instruction "LDR rD, =Label" die exakt eine Instruktion LDR rD, [PC+#] und einen immediate-Wert (&Label) hinterlegt.
Maxx schrieb: > Beispiel die ARM Pseudo Instruction "LDR rD, =Label" die exakt eine > Instruktion LDR rD, [PC+#] und einen immediate-Wert (&Label) hinterlegt. Für Daten, die „nah genug“ am aktuellen Code dran sind, umgeht man damit das Problem einfach (und auf einem kleinen Controller sind dann vermutlich alle Daten „nah genug“ dran ;).
Jörg Wunsch schrieb: > Maxx schrieb: >> Beispiel die ARM Pseudo Instruction "LDR rD, =Label" die exakt eine >> Instruktion LDR rD, [PC+#] und einen immediate-Wert (&Label) hinterlegt. > > Für Daten, die „nah genug“ am aktuellen Code dran sind, umgeht man > damit das Problem einfach (und auf einem kleinen Controller sind dann > vermutlich alle Daten „nah genug“ dran ;). Und wem das nicht reicht, der kann bei ARM auch auf MOV32 ausweichen. Dann hat man diesen vermeintlichen Nachteil auch beseitigt. Außerdem existiert "der ARM" nicht. Bei den meisten ARM Cores ist eine Harvard Architektur im Sinne von getrennten Daten und Befehlsbussen implementiert. Zumindest bei ARM Prozessoren mit Thumb-2 Befehlssatz ist der Code in realen Anwendungen auch nicht unbedingt größer als beispielsweise AVR Code. Das kommt sehr auf die Komplexität an -- und die muss dabei nicht mal so groß sein.
Marcus Harnisch schrieb: > Zumindest bei ARM Prozessoren mit Thumb-2 Befehlssatz ist der Code in > realen Anwendungen auch nicht unbedingt größer als beispielsweise AVR > Code. Das wollte ich damit auch nicht behauptet haben. Thumb ist ganz sicher der Trick, mit dem ARM den 32-Bittern in dieser Hinsicht zum Durchbruch verholfen hat. Es ging ja nur darum, die Unterschiede überhaupt zu benennen.
Ein typ. RISC kann, wie geschrieben, definitiv nicht die complette Addresse im Opcode unterbringen (höchst ein Displacem.), was eindeutig grosser Nachteil ist.. Und deshalb sind deswegen auch weitere(r) Takt(e) nötig. LDR (das eigentlich jede CPU kennt) ändert daran auch nichts. >RISC-Philosophie ist es ja, den Prozessor >so weiter runterzubrechen, dass alles in einem Takt geht. RISC soll (leider) möglichst einfach sein, typ.weise immer gleiche OP-Code-Länge. Und wenn er selbst dann noch mehr als 1 Takt braucht (was oft bei LD/ST der Fall ist), ist es eben noch ein schlechter RISC. >..lediglich den Zugriff auf zusätzliche Daten (die auch der CISC braucht) Nö. Der CISC verputzt alles in einem.
Jörg Wunsch schrieb: > Für Daten, die „nah genug“ am aktuellen Code dran sind, umgeht man > damit das Problem einfach (und auf einem kleinen Controller sind dann > vermutlich alle Daten „nah genug“ dran ;). Sind sie ja, denn die Daten stehen in vergleichbaren CISCs direkt an der Instruktion. Also nur um die Instruktionslänge von PC entfernt. Hier darfst du dir nun ein paar Byte mehr bis MB mehr Platz lassen.
MCUA schrieb: > Ein typ. RISC kann, wie geschrieben, definitiv nicht die complette > Addresse im Opcode unterbringen (höchst ein Displacem.), was eindeutig > grosser Nachteil ist.. > Und deshalb sind deswegen auch weitere(r) Takt(e) nötig. Das ist auch beim CISC nötig. die zusätzlichen Bytes kommen auch nicht per Magie hinein. Beim x86 z.B. verlängert der Immediate das Kommando um entsprechend 1/4/8 Bytes.
> Der ist ja auch kein echter RISC-Prozessor. Bei Wikipedia steht das aber so: http://de.wikipedia.org/wiki/Atmel_AVR Auch viele Bücher und der Conrad Shop bezeichnen die AVR Chips as RISC Controller. Und ATMEL erklärt sogar, warum es RISC Controller sind: http://www.atmel.com/technologies/cpu_core/avr.aspx
Ein 8-bitter muss bei breiteren Operanden diese 8 bit-weise verarbeiten.
Das artet dann schon mal in grausammen Code aus. Auf einem 32bitter ist
das ein Befehl.
In C:
uint32_t a, b, c;
c = a + b;
Assembler:
626C EB48 MOVSF 0x48, 0x700
626E F700 NOP
6270 EB49 MOVSF 0x49, 0x701
6272 F701 NOP
6274 EB4A MOVSF 0x4A, 0x702
6276 F702 NOP
6278 EB4B MOVSF 0x4B, 0x703
627A F703 NOP
627C 50D9 MOVF FSR2L, W, ACCESS
627E 0F44 ADDLW 0x44
6280 6EE9 MOVWF FSR0L, ACCESS
6282 CFDA MOVFF FSR2H, FSR0H
6284 FFEA NOP
6286 50EE MOVF POSTINC0, W, ACCESS
6288 0107 MOVLB 0x7
628A 2700 ADDWF nBytes, F, BANKED
628C 50EE MOVF POSTINC0, W, ACCESS
628E 2301 ADDWFC dest, F, BANKED
6290 50EE MOVF POSTINC0, W, ACCESS
6292 2302 ADDWFC pChunk, F, BANKED
6294 50EE MOVF POSTINC0, W, ACCESS
6296 2303 ADDWFC src, F, BANKED
6298 5100 MOVF nBytes, W, BANKED
629A 6E4C MOVWF [0x4C], ACCESS
629C 5101 MOVF dest, W, BANKED
629E 6E4D MOVWF [0x4D], ACCESS
62A0 5102 MOVF pChunk, W, BANKED
62A2 6E4E MOVWF [0x4E], ACCESS
62A4 5103 MOVF src, W, BANKED
62A6 6E4F MOVWF [0x4F], ACCESS
Stefan schrieb: >> Der ist ja auch kein echter RISC-Prozessor. > > Bei Wikipedia steht das aber so: http://de.wikipedia.org/wiki/Atmel_AVR Die Definition, was genau RISC ausmacht, ist ziemlich offen. Nicht einmal die genaue Aufdröselung des Akronyms ist eindeutig, denn IBM hatte das C bei der Power Architektur angesichts der Grösse des Befehlssatzes wohlweislich als "Complexity" bezeichnet. Was heute auch die bessere Variante ist. Denn genau darum geht es: die Komplexität der Befehle gering zu halten, nicht die Anzahl. Die Krone setzte dem Motorola/Freescale auf, indem sie die Coldfire-Architektur, urspünglich eine reduzierte Version der 68020, ebenfalls als RISC bezeichneten. Weil der Begriff damals grad en vogue war. Nur ist das reichlich absurd.
>Sind sie ja, denn die Daten stehen in vergleichbaren CISCs direkt an der >Instruktion. Nein. In der Instruktion. >> Ein typ. RISC kann, wie geschrieben, definitiv nicht die complette >> Addresse im Opcode unterbringen (höchst ein Displacem.), was eindeutig >> grosser Nachteil ist.. >> Und deshalb sind deswegen auch weitere(r) Takt(e) nötig. >Das ist auch beim CISC nötig. die zusätzlichen Bytes kommen auch nicht >per Magie hinein. Nö, is nicht. Die 'zusätzlichen Bytes' stehen im OPCode, der ggfs (je nach CPU) schon in einem gelesen werden kann. >Die Krone setzte dem Motorola/Freescale auf, indem sie die >Coldfire-Architektur, urspünglich eine reduzierte Version der 68020, >ebenfalls als RISC bezeichneten. Die nennen das nicht RISC sondern VL(VariableLengh)-RISC. (also eigentlich ein Widerspruch in sich, wohl um auf Reduzierung vs 68k hinzudeuten).
MCUA schrieb: >>Sind sie ja, denn die Daten stehen in vergleichbaren CISCs direkt an der >>Instruktion. > Nein. In der Instruktion. Genau wie beim Thumb-2 (Pseudo)befehl MOV32. Mit acht hintereinanderliegenden Bytes wird eine beliebige 32bit Konstante geladen. Dabei ist es vollkommen egal, ob die Daten in der Instruktion liegen, oder angehängt, oder wie im Falle von MOV32 auf zwei Opcodes verteilt wurden. Ausschlaggebend ist, dass sie sequentiell gelesen werden können.
Jürgen Schmied schrieb: > Assembler: Naja, da hast du dir die grauseligste Architektur als Beweis ausgesucht. ;-) Eine Akkumulator-Architektur halt. Auf dem AVR:
1 | add r18,r22 |
2 | adc r19,r23 |
3 | adc r20,r24 |
4 | adc r21,r25 |
Nur: viele Operationen in kleinen Controllern brauchen keine 32 Bits. Die müssen dann auch nicht erst vier Befehle dafür generieren.
MCUA schrieb: > VL(VariableLengh)-RISC. (also eigentlich ein Widerspruch in sich, > wohl um auf Reduzierung vs 68k hinzudeuten). Yep, um trotz definitiver CISC den damaligen Modebegriff RISC unbedingt irgendwie unterbringen zu können. Was natürlich komplette Verarsche ist.
>Genau wie beim Thumb-2 (Pseudo)befehl MOV32. Mit acht >hintereinanderliegenden Bytes wird eine beliebige 32bit Konstante >geladen. Ja und? Selbst wenn das in 1 Takt gehen würde (was meist nicht der Fall ist) sind damit die etlichen Nachteile der RISC ja nicht beseitigt. >Ausschlaggebend ist, dass sie sequentiell gelesen werden können. Nö. Ausschlaggebend ist, WAS sequentiell gelesen werden kann.
Jörg Wunsch schrieb: > Naja, da hast du dir die grauseligste Architektur als Beweis > ausgesucht. ;-) Compiler-Output für 8-Bit CISCs zu lesen ist eine Zumutung. Wegen der Umständlichkeit bei der Umsetzung von C, aufgrund der ziemlich schrägen Mnemotechnik der Befehle und weil Banking keine Freude macht. > Eine Akkumulator-Architektur halt. Wobei eine Akkumulator-Architektur nur dann ein Problem ist, wenn die bei Compilern häufig verwendeten Datentypen grösser sind als der Akku. Ist der Akku aber ausreichend breit, dann sieht der Code ganz ordentlich aus. Nur gibts nicht mehr viele solcher Architekturen (z.B. Freescale 68x11/12). Das war bis weit in die 60er Jahre aber ziemlich verbreitet.
MCUA schrieb: > Selbst wenn das in 1 Takt gehen würde (was meist nicht der Fall ist) > sind damit die etlichen Nachteile der RISC ja nicht beseitigt. Tja. Trotz der Nachteile hat sich der Kram durchgesetzt. Wenn man vom ARM im Controllerbereich absieht, ist ja inzwischen alles x86-Einheitsbrei. Die einstmals so stolzen RISCs: alle verschwunden. POWER, SPARC, PA-RISC, MIPS (nur noch als PIC32, also als Controller). So viel zu den Nachteilen.
MCUA schrieb: > Selbst wenn das in 1 Takt gehen würde (was meist nicht der Fall ist) > sind damit die etlichen Nachteile der RISC ja nicht beseitigt. Aus welcher Sicht betrachtest du das grad? Dem Programmierer kanns egal sein, ob MOV32 aus 2 Befehlen zusammengesetzt wird, oder ob es einer ist. Wichtig ist hier, dass es schneller ist als das alte LDR r,=adr, was nichtsequentell aus dem Flash laden musste damit nicht selten Waitstates kostet. Wobei Compiler bei Optimierung auf Platz immer noch gerne die alte Version verwenden, weil kleiner (6 Bytes statt 8). Klar ist 1 Takt schneller als 2. Ich betrachte da aber eher das Gesamtergebnis. Wenns schnell genug ist, dann sind mir solche Details egal. Andernfalls habe ich den falschen Prozessor gewählt oder zu blöd programmiert. Und da man bei 32-Bittern zu mindestens 99% in Hochsprache programmiert, kann es eigentlich ziemlich egal sein, was unten rauskommt. Wenn schnell genug und klein genug. Mögliche atomare Verarbeitung bestimmter Speicher/IO-Operationen ersparen im Controller-Umfeld allerdings ein paar Kleinigkeiten, das stimmt schon.
Jörg Wunsch schrieb: > Wenn man vom ARM im Controllerbereich absieht, ist ja inzwischen > alles x86-Einheitsbrei. Die einstmals so stolzen RISCs: alle > verschwunden. POWER, SPARC, PA-RISC, MIPS (nur noch als PIC32, also > als Controller). POWER und SPARC sind noch da, aber vorwiegend im Bereich grösserer Systeme. Dort aber dafür mit Schmackes.
A. K. schrieb: > Wobei Compiler bei Optimierung auf Platz immer noch > gerne die alte Version verwenden, weil kleiner (6 Bytes statt 8). Mögliche weitere Gründe: - Der literal pool mit den Adressen kann vom Linker geschickt so plaziert werden, dass er von mehreren Stellen verwendet werden kann. Damit wird die Codegröße weiter reduziert und die Anzahl der Relocations verringert. - Der Performance Nachteil wirkt sich in der Praxis geringer aus als uns manche glauben machen wollen. - Man kann Werte im literal pool leichter patchen :) Gerade in einer Harvard Architektur mit nicht-trivialer Pipeline sind die Performanceeinflüsse nicht mehr so einfach zu beschreiben. Ist der belegte Slot in der Prefetch unit für die zweite Hälfte eines MOV32 in einer bestimmten Situation nun besser genutzt, wenn ein "echter" Befehl darin läge?
A. K. schrieb: > POWER und SPARC sind noch da, aber vorwiegend im Bereich grösserer > Systeme. POWER weiß ich nicht so genau, aber SPARC? Zumindest Sun hatte das schon vor Jahren aufgegeben. Wer macht das denn noch? (Ich fand SPARC eigentlich als Architektur immer ganz hübsch.)
>Tja. Trotz der Nachteile hat sich der Kram durchgesetzt. >Wenn man vom ARM im Controllerbereich absieht, ist ja inzwischen >alles x86-Einheitsbrei. Würde ja heissen, es gäbe heute (ausser X86 bei PC) nur noch diese (RISC) Archit. Was aber total falsch ist. Es sind immer noch 2stell. Anzahl verschiedener Archit. im Umlauf. > Selbst wenn das in 1 Takt gehen würde (was meist nicht der Fall ist) > sind damit die etlichen Nachteile der RISC ja nicht beseitigt. Nachteile deshalb, weil (für viele entspr. CISC-Befehle) RISC einfach mehrere Befehle (damit auch mehr Speicher erforderlich, weit mehr als wenn CISC-OPcode wäre) und auch mehrere Takte benötigt (also damit langsamer ist). Also, bei gleicher f, brauchts mehr Mem und ist langsamer! Das reicht, um abgewählt zu werden. Das finde ich grade in 2013 ein Witz, weil Gates nun so günstig sind.
Jörg Wunsch schrieb: > POWER weiß ich nicht so genau, aber SPARC? Zumindest Sun hatte das > schon vor Jahren aufgegeben. Wer macht das denn noch? Erst vor wenigen Tagen war die Hot-Chips Konferenz, da gabs gleich 3 neue, 2 SPARCs und 1 POWER. http://www.heise.de/newsticker/meldung/Hot-Chips-Tausendkerner-fuer-Unix-1945955.html http://www.heise.de/ix/meldung/Hot-Chips-Oracles-SPARC-M6-als-Datenbankmonster-1945360.html http://www.heise.de/newsticker/meldung/Hot-Chips-Power-Geschuetz-von-IBM-1943751.html
Jörg Wunsch schrieb: > Wenn man vom ARM im Controllerbereich absieht, ist ja inzwischen > alles x86-Einheitsbrei. Die einstmals so stolzen RISCs: alle > verschwunden. POWER, SPARC, PA-RISC, MIPS (nur noch als PIC32, also > als Controller). So viel zu den Nachteilen. Also als ich das letzte Mal nachgesehen habe, gabs IBM noch. Und sie bauten noch Power(5) CPUs. Dito hat ORCL zwar eine Menge Mist gebaut mit den tollen Sachen, die sie sich mit SUN zum Schnäppchenpreis einverleibt haben. Aber die SPARC Architektur lebt in Form der UltraSparc und Niagara (CoolThreads) Linien noch fröhlich vor sich hin. Und selbst wenn Larry diese Produktlinien fallen lassen sollte - Fujitsu wird noch laaaange weiter SPARCs bauen (sie bauen ja eh die besten dieser Klasse). Mit PA-RISC könntest du (leider) Recht haben. Da hat sich HP wohl doch etwas zu sehr auf Intel und deren Flagship Itanic verlassen. Eng verbunden im Untergang ist die Alpha Architektur (ehemals DEC, dann COMPAQ, zuletzt HP) Aber wenn sich immer das Beste durchsetzen würde, dann gäbe es weder den 8086 noch MS-DOS noch VHS noch Merkel. (huch, hoffentlich wird mein Beitrag jetzt nicht nach Offtopicanien verschoben ;) PS: daß RISC gleichzusetzen wäre mit Instruction Size = Busbreite, würde ich nicht unterschreiben. Es gibt (gab?) auch VLIW Architekturen, die trotzdem RISC sind. XL
Axel Schwenke schrieb: > PS: daß RISC gleichzusetzen wäre mit Instruction Size = Busbreite, würde > ich nicht unterschreiben. Das hat ja auch nichts miteinander zu tun. Entscheidend ist ein einfach handhabbares Befehlsformat, vorzugsweise mit nur einer Befehlsbereite, um sich den Terz mit der Dekodierung von Befehlen variabler Länge zu ersparen. Erst recht wenn man davon mehrere pro Takt dekodieren will. Aber wie breit die Befehle konkret sind ist irrelevant. Es wäre auch ziemlicher Unfug, bei einem 64-Bit Prozessor bloss deshalb die (skalaren) Befehle 64 Bit breit zu machen. Und Thumb(1) hat ein reines 16-Bit Befehlsformat - der einzig abweichende Befehl lässt sich als Kombination zweier Befehle verstehen und auch so ausführen.
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.