Kann mir von Euch vielleicht in kurzen Stichpunkten nennen, worin sich 8bit-Prozessoren von 32bit-Prozessoren unterscheiden? Unterscheiden die sich denn wirklich so viel voneinander? Sind denn nicht die grundlegenden Funktionen bei 8-bit und 32-bit-Prozessoren identisch, so mit den Timern, den Interrupts...? Der Hauptunterschied müsste doch darin liegen, dass ich einen viel größeren Adressraum habe - wo ich früher nur 8bit breite Register habe, müssten die Register bei 32-bit-Prozessoren nun eben 32bit groß sein, und durch den größeren Adressraum hab ich eben auch viel mehr Speicherkapazität als bei 8bit-Controllern? Oder gibt es noch "gravierende" Unterschiede?
Schau dir halt mal die Architektur eines modernen Desktop Prozessors an. Von mir aus noch 32 Bit. Dann vergleiche mit AVR. Die 24 Bit Unterschied dürften hier deine kleinste Sorge sein. Lange Reder kurzer Sinn: Die grundlegende Architektur wird bei "gößeren" Prozessoren immer auch komplizierter. Mehr Features (Modi, MMX), mehr Clocks, mehr Schalter, mehr parallität (Multicore, Threading), mehr gesonderte spezielle Recheneinheiten (FPU, Vectoreinheiten, Crypto, Shader (bei Grafikkarten)). Desweiteren könntest du deine Frage selbst beantworten wenn du einfach mal die Datenblätter(mehrzahl) eines STM32 (z.B.) und eines Atmega vergleichst. gruß cyblord
cyblord ---- schrieb: > Desweiteren könntest du deine Frage selbst beantworten wenn du einfach > mal die Datenblätter(mehrzahl) eines STM32 (z.B.) und eines Atmega > vergleichst. die sind aber alle in englischer Sprache :-(
Opossum schrieb: > cyblord ---- schrieb: >> Desweiteren könntest du deine Frage selbst beantworten wenn du einfach >> mal die Datenblätter(mehrzahl) eines STM32 (z.B.) und eines Atmega >> vergleichst. > > die sind aber alle in englischer Sprache :-( Ohne die Fähigkeit Datenblätter in englisher Sprache zu verstehen bist im Bereich "Microcontroller" ohnehin verloren. Wozu machst du dir also Gedanken? Lern halt Englisch. Muss heute halt.
cyblord ---- schrieb: > Lern halt Englisch. Muss heute halt. Im Bereich Hobbybastler und Handwerker/Techniker ist Englisch nicht so verbreitet wie bei Ingenieuren. Es hilft aber nichts, da muß man irgendwie durch. Siemens/Infineon/Osram hatten mal noch Datenblätter zweisprachig deutsch und englisch. Immerhin, sie machten sich diese Mühe. Das verschwindet aber allmählich ganz zu Gunsten von Englisch. Opossum schrieb: > Kann mir von Euch vielleicht in kurzen Stichpunkten nennen, worin sich > 8bit-Prozessoren von 32bit-Prozessoren unterscheiden? Grundsätzlich in der Registerbreite.
>Siemens/Infineon/Osram hatten mal noch Datenblätter zweisprachig deutsch >und englisch. Immerhin, sie machten sich diese Mühe. Das verschwindet >aber allmählich ganz zu Gunsten von Englisch. Das schwappt aber nun zunehmend richtung chinesisch. Also chinesisch lernen ... ;-)
Opossum schrieb: > die sind aber alle in englischer Sprache :-( So ist das. Die Hersteller haben keine Lust ihre Datenblätter in 3000 Sprachen herauszugeben.
Jens G. schrieb: > Das schwappt aber nun zunehmend richtung chinesisch. Also chinesisch > lernen ... ;-) Aach, deswegen fragt mich mein Acrobat Reader in letzter Zeit immer öfter, ich müßte zur richtigen Darstellung aller Inhalte den chinesischen Zeichensatz downloaden! ;-) Was ich mir sehr gut vorstellen kann: Daß Datenblätter in Zukunft mal gemischt chinesisch/englisch sein werden.
Wilhelm Ferkes schrieb: > Opossum schrieb: > >> Kann mir von Euch vielleicht in kurzen Stichpunkten nennen, worin sich >> 8bit-Prozessoren von 32bit-Prozessoren unterscheiden? > > Grundsätzlich in der Registerbreite. Also vom Befehlssatz her bleiben die ähnlich? Ähnliche Assemblerbefehle und so nen kram?
Opossum schrieb: > Und warum gibt es hier drinnen nur ein 8bit-Tutorial? Das ist kein "8-Bit Tutorial" sonder ein AVR Tutorial. Wenn du ein PIC Tut schreibst, dann gibts hier auch ein PIC Tutorial. Und wenn du ein STM32 Tutorial schreibst dann gibts das hier auch. Vorher leider nicht. Weil die wachsen nicht aufm Baum. Und es gibt allerhand Infos auch zum Thema 32-Bitter. Siehe hier: http://www.mikrocontroller.net/articles/STM32 gruß cyblord
Opossum schrieb: > die sind aber alle in englischer Sprache :-( Und schon hast du einen weiteren Unterschied: Bei 8-Bit Controllern ist die Chance, mit Deutsch weiter zu kommen, deutlich grösser als bei 32-Bit Controllern. ;-)
>> Grundsätzlich in der Registerbreite. >Also vom Befehlssatz her bleiben die ähnlich? Ähnliche Assemblerbefehle >und so nen kram? Der Befehlssatz hat überhaupt nichts mit der Bitbreite zu tun (es sei denn, es gibt paar Befehle, die nur bei höherer Bitbreite Sinn machen). Der Befehlssatz hängt eigentlich nur vom Erfindergeist der Hersteller ab.
Opossum schrieb: > Also vom Befehlssatz her bleiben die ähnlich? Ähnliche Assemblerbefehle > und so nen kram? Ähnlichkeit ist ein sehr dehnbarer Begriff. Verglechen mit Quantencomputern sind sich alle bisher erfundenen Prozessoren zweifellos verblüffend ähnlich. Andererseits zeigen die früheren(?) Kriege zwischen AVRlern und PIClern, dass man je nach Perspektive auch zwischen 8-Bittern grossse Unterschiedene sehen kann. Du musst also die Kriterien definieren, die für dich Ähnlichkeit ausmachen. Der Assembler-Befehlssatz allein ist meisten ziemlich verschieden, egal wieviele Bits. Da gabs sogar welche, die zwar binärkomptibel waren, aber sehr unterschiedliche Befehlssätze verwendeten (z.B. Intel 8088 vs NEC V20). Und andererseits eine Prozessorfamilie mit 16- und 32-Bit Modellen mit identischem Befehlssatz.
Opossum schrieb: > Und warum gibt es hier drinnen nur ein 8bit-Tutorial? Wieso sollte es nur noch eine Berechtigung für Prozessoren mit mindestens 32 bit geben?
>Der Befehlssatz hat überhaupt nichts mit der Bitbreite zu tun......
Ja, wenn man nur mit den Registern rechnet, muss man nur die jeweiligen
Reg-Nr's benennen.
Aber ab und zu sollen ja auch Imm-Werte da rein, oder direkt verrechnet
werden. Dann ist es schon ein Unterschied, obs max nur 8 Bit sind oder
mehr.
Also der Punkt ist der, dass man einen Prozessor nicht einfach in unterschiedlichen Versionen der Bitbreite kaufen kann. Man kann nicht sagen: "Ich hätte gern den Prozessor, aber nicht mit 8 Bit sondern mit 32, der Rest aber gleich." - Das mag es zwar auch geben, aber nur bei sehr speziellen Prozessortypen, die nicht sonderlich relevant sind. Wenn man nämlich ein paar mehr Bits hat, dann muss man die ja auch mit Konstanten laden können. Der Befehl, der diese Konstante mitbringt ist dann auch größer. Um ein einzelnes Bit aus 8 auszuwählen braucht man 3 Bits. Bei 32 Bits sind schon 5 Auswahlbits nötig, also ein anderer Befehl. Es gibt auch Bitschiebe-/-rotationsbefehle. Der hat dann auch die 5 Auswahlbits statt 3. Die paar mehr Bits haben also Auswirkung auf die Befehle. Das ist aber nicht der Hauptgrund. Eigentlich gibt es für jeden Anwendungsfall angepasste Prozessoren. Wenn man mehr Rechenleistung braucht, dann hat der Prozessor meist gleich 32/64 Bits, mehr MHz, mehr Speicher, Division/Multiplikation und Vektoroperationen. Reicht ein bisschen Rechenleistung, bisschen Menüführung und Steuerungskram, dann nimmt man halt einen kleinen Prozessor: 8 Bits, ohne Mul/Div, wenige MHz. Es gibt halt meistens gleich das Gesamtpaket. 4/8 Bits, aber 3 GHz macht halt nur in sehr wenigen Fällen Sinn und deshalb sieht man das Praktisch nicht.
Bei den Microcontrollern nicht ganz uninteressant: Bei den 8-Bittern ist die Peripehrie in der Regel (mit Ausnahmen, natürlich) einfacher, Du wirst wenige 8-Bit-µCs mit DMA finden. Bei 16-Bit und 32-Bit ist DMA eher Standard, d.h. die CPU kann sich um andere Sachen kümmern, als Werte vom ADC oder SPI abzuholen. Bei AVR z.B. mußt Du das alles in Interrupts zu Fuß machen. Wie gesagt, Ausnahmen gibt's, z.B. den XMega.
MCUA schrieb: > Aber ab und zu sollen ja auch Imm-Werte da rein, oder direkt verrechnet > werden. Dann ist es schon ein Unterschied, obs max nur 8 Bit sind oder > mehr. Es gab mit den Transputern eine Architektur, deren Befehlscodierung vollständig unabhängig von der Datenbreite war. Befehle waren in Bytes codiert, 4 Bit Code und 4 Bit Wert. Der Wert konnte Opcodes, Konstanten und Displacements darstellen und wurde über Präfixcodes kumuliert, so dass ein 32-Bit Wert bis zu 8 solcher Bytes beanspruchte. Die Befehlscodierung von RISCs mit fester Befehlslänge ist unabhängig von der Bitbreite der Register, denn es passen ohnehin nur maximal 16 Bit Konstanten in in 32 Bits codierte Befehle. Stefan Helmert schrieb: > Also der Punkt ist der, dass man einen Prozessor nicht einfach in > unterschiedlichen Versionen der Bitbreite kaufen kann. Im Prinzip hast du natürlich Recht. Aber keine Regel ohne Ausnahme, denn bei ebendiesen Transputer konnte man genau das. Der T212 hatte 16 Bits, die T414 32 Bits. Der Befehlssatz war identisch.
@MCUA (Gast) >>Der Befehlssatz hat überhaupt nichts mit der Bitbreite zu tun...... >Ja, wenn man nur mit den Registern rechnet, muss man nur die jeweiligen >Reg-Nr's benennen. Du solltes schon vollständig mich zitieren, dann hättest Du auch die von mir gemachte Einschränkung mitbekommen. Grundsätzlich muß sich der Befehlssatz nicht grundlegend ändern, bloß weil wir die Bitbreite ändern. Aber kann erweitert werden auf die Spezifika bei einer höheren Bitbreite. Der Befehlssatz von Intel-Prozessoren wurden wohl bisher seit 16bit bis 64bit auch immer nur erweitert (MMX, SSE) und angepaßt, aber nicht grundsätzlich komplett neu erdacht. Du kannst also mit der alten Basissyntax auch die 64-Bitter bedienen (auch wenn neue Register hinzugekommen sind, oder aufgebohrt wurden (AX wird zu EAX ...)
Stefan Helmert schrieb: > Also der Punkt ist der, dass man einen Prozessor nicht einfach in > > unterschiedlichen Versionen der Bitbreite kaufen kann. Man kann nicht > > sagen: "Ich hätte gern den Prozessor, aber nicht mit 8 Bit sondern mit > > 32, der Rest aber gleich." - Das mag es zwar auch geben, aber nur bei > > sehr speziellen Prozessortypen, die nicht sonderlich relevant sind. gabs mal: 8088, 8086, 80186, 80286, 80386... Heute eher selten. Edit: zu spät.
Gregor B. schrieb: > 8088, 8086, 80186, 80286, 80386... Mal sehen, ob jetzt der uralte Streit wieder auflebt, ob die 68008 CPU nun ein 8-, 16- oder 32-Bitter war. ;-)
A. K. schrieb: > Mal sehen, ob jetzt der uralte Streit wieder auflebt, ob die 68008 CPU > nun ein 8-, 16- oder 32-Bitter war. ;-) Bist du wohl still ....
XMegas sind eigentlich schon 16 Bitter und laut meinen Messungen schneller als viele 32 Bitter. Dafür aber auch komplex wie die 32 Bitter mit ARM Architektur. Außer die STM32 F4. Die sind momentan kaum schlagbar(für mich). Da ist alles andere wischi waschi ;-) Oder täusche ich mich...
Chose schrieb: > XMegas sind eigentlich schon 16 Bitter und laut meinen Messungen > schneller als viele 32 Bitter. Dafür aber auch komplex wie die 32 Bitter > mit ARM Architektur. Was sind das fuer Messungen? Gibts da irgendwelche Doku dazu?
Christoph schrieb: > Was sind das fuer Messungen? Sie sind beim Pintogglen schneller als ein 32-Bitter wie der LPC2106, folglich müssen sie zu mindestens 64-Bittern äquivalent sein.
A. K. schrieb: > Christoph schrieb: >> Was sind das fuer Messungen? > > Sie sind beim Pintogglen schneller als ein 32-Bitter wie der LPC2106, > folglich müssen sie zu mindestens 64-Bittern äquivalent sein. :) Wow, Atmel hat es mit den Xmegas geschafft die Performance eines 8-Bitters zu verachtfachen. Wieso machen die dann keine Werbung damit??
Christoph schrieb: > Wow, Atmel hat es mit den Xmegas geschafft die Performance eines > 8-Bitters zu verachtfachen. Wieso machen die dann keine Werbung damit?? Weil sich nichts geändert hat. Auch schon ein 20MHz AVR ohne X ist dabei schneller als ein 60MHz LPC2106. ;-) Die erste Generation der LPC2000 hatte eine berüchtigt langsame GPIO. Weshalb NXP in der nächsten Generation eine schnelle Version nachschob. http://tech.groups.yahoo.com/group/lpc2000/message/4000
Opossum schrieb: > Kann mir von Euch vielleicht in kurzen Stichpunkten nennen, worin sich > 8bit-Prozessoren von 32bit-Prozessoren unterscheiden Als erstes mal die ALU: beim 8 bitter ist sie (Tadaa) 8 bit weit, beim 32 bitter, wer hätte es gedacht, 32 bit. > Unterscheiden die sich denn wirklich so viel voneinander? Sind denn > nicht die grundlegenden Funktionen bei 8-bit und 32-bit-Prozessoren > identisch, so mit den Timern, den Interrupts...? Normalerweise haben Prozessoren keine Timer, die findet man eher auf MCUs. > Der Hauptunterschied müsste doch darin liegen, dass ich einen viel > größeren Adressraum habe - wo ich früher nur 8bit breite Register habe, > müssten die Register bei 32-bit-Prozessoren nun eben 32bit groß sein, > und durch den größeren Adressraum hab ich eben auch viel mehr > Speicherkapazität als bei 8bit-Controllern? Speicherkapazität != Adressraum Ansonsten: Nicht zwingend. Der PC (program counter) ist auf vielen mir bekannten 8 bittern 16 Bit weit (64 KB Adressraum). Auf moderneren 32 bittern ist der PC oft 40 bit oder noch grösser, erlaubt also wesentlich mehr physischen Speicher als 2^32 bit (4 GB). Hauptunterschied ist meines Erachtens die Wortbreite der ALU.
Tom M. schrieb: > Als erstes mal die ALU: beim 8 bitter ist sie (Tadaa) 8 bit weit, beim > 32 bitter, wer hätte es gedacht, 32 bit. Na endlich sind wir wieder beim Thema (Sorry Helmut ;-). Die Z80 CPU hat eine 4-Bit ALU.
A. K. schrieb: > Mal sehen, ob jetzt der uralte Streit wieder auflebt, ob die 68008 CPU > nun ein 8-, 16- oder 32-Bitter war. ;-) Genau, und der 68000er im Amiga war viel besser als der im Atari ST!
Tom M. schrieb: > bekannten 8 bittern 16 Bit weit (64 KB Adressraum). Auf moderneren 32 > bittern ist der PC oft 40 bit oder noch grösser Hättest du ein Beispiel eines 32-Bit Prozessors mit einem 40-Bit Program Counter? Wohlgemerkt dem PC selbst, also dem unmittelbar nutzbaren Programmadressraum. Nicht dem durch irgendwelche Segmente oder Pages zustande kommenden erweiterten logischen oder physikalischen Adressraum.
Zunächst kann man mit 1-Bit Rechnern schon Steuerungen und dergleichen machen, z:b. SPS. Motorola stellte so einen 1-bit Kontroller zeitweise her. Zum Rechnen mit einzelnen Ziffern braucht man schon 4 bit, das hatten die allerersten Kontroller (der 4004, von Intel ?) Zum Umgang mit Texten, Buchstaben, Satzzeichen usw. braucht man 8bit. Das haben die meisten einfachen Kontroller. Früher waren dazu auch die vier-bit RAM's usw. der 4-bit-Technik passend. Alles mit mehr als 8 bit bringt eigentlich nichts besonders Besseres dazu, nur ist beim Rechnen mit mehrstelligen Zahlen das Rechnen einfacher, denn, wenn 32-Bit-Zahlen addiert werden müssen, brauchts dazu eine Folge von mindestens 4 Schritten, dazu eventuell noch Übertragverarbeitung oder Vorzeichenarithmetik. Ein 32-Bitter kann diese Addition schon mit einem Befehl ausführen. Bei der Verarbeitung von Texten bringen mehr als 8 bit eigentlich garnichts, da sind 16-Bit Datenworte eigentlich schon Verschwendung. Etwas anders sieht es bei den Adressen aus, da sind 8bit schon unbrauchbar wenig, 16 bit geht gerade und bei der gigantischen Resourcenverschwendung heutzutage brauchts mindestens 24-bit- oder noch größere Adressen.
A. K. schrieb: > Hättest du mir ein Beispiel eines 32-Bit Prozessors mit einem 40-Bit > Program Counter? Wohlgemerkt dem PC, nicht dem irgendwie zustande > kommenden physikalischen Adressraum. hmm erwischt, mir ist keine bekannt. Ich vermische da Program Counter (aka. Instruction Pointer), virtuelle Adressräume deren Abbildung auf physikalischen Adressen.
Peter R. schrieb: > Bei der Verarbeitung von Texten bringen mehr als 8 bit eigentlich > garnichts, da sind 16-Bit Datenworte eigentlich schon Verschwendung. Es sei denn man sitzt in China, Japan oder Korea.
Die Unterscheidung in 8, 16 und 32 Bit ist IMO aus der PC-Welt entliehen. Bei µCs gelten andere Maßstäbe. Es gibt ja auch so ulkige Dinge wie 32-Bit-µCs im DIP8-Gehäuse (Beitrag "Cortex-M0+ im DIL8 von NXP."). Von Vorteil ist, wenn man das gesamte RAM in einem Stück / mit einem Zeigerregister ansprechen kann. Das geht meist auch mit nominellen 8-Bittern. Mehr Bits braucht man selten, solange die Rechenleistung als solche für die Anwendung reicht.
Detlev T. schrieb: > Von Vorteil ist, wenn man das gesamte RAM in einem Stück / mit > einem Zeigerregister ansprechen kann. Stimmt. > Das geht meist auch mit nominellen 8-Bittern. Meistens... Ein paar Midrange-PICs freilich tanzen da etwas aus der Reihe, mit 368 Bytes RAM und einem 8-Bit Zeiger. Dessen 9. Bit versteckt sich im Statusregister.
Um noch einmal auf Deine ursprüngliche Frage zurückzukommen: Opossum schrieb: > Unterscheiden die sich denn wirklich so viel voneinander? Sind denn > > nicht die grundlegenden Funktionen bei 8-bit und 32-bit-Prozessoren > > identisch, so mit den Timern, den Interrupts...? In diesen Funktionen wie Timern und Interrupt-Behandlung unterscheiden sich schon die unterschiedlichen 8-Bit Architekturen. Das ist also kein Unterscheidungsmerkmal zwischen 8- und 32-Bit-Prozessoren. Opossum schrieb: > wo ich früher nur 8bit breite Register habe, > > müssten die Register bei 32-bit-Prozessoren nun eben 32bit groß sein Das ist das wensentliche Unterscheidungsmerkmal zwischen 8- und 32-Bit-Prozessoren. Der maximal linear adressierbare Adressraum wird durch die breiteren Register auch größer, ob ich den dann auch tatsächlich physikalisch adressieren kann, hängt dann wiederum davon ab, ob dies bei einem speziellen Prozessor vorgesehen ist (z.B. durch eine ausreichende Anzahl an Adressleitungen) oder nicht. Siehe die kleinen Derivate ohne externen Bus, die zwar theoretisch 4G adressieren könnten, praktisch aber z.B. nur 8k verbaut haben.
>Wieso sollte es nur noch eine Berechtigung für Prozessoren mit >mindestens 32 bit geben? Manche haben die (berechtigte? oder unberechtigte?) Meinung, dass in Zukunft wohl sehr wenige bis gar keine neuen 8 Biter mehr aufgelegt, wegen der hohen Entw-kosten (bei bspweise 40 nm), und weil sich die Silic-kosten nur für den CPU-Anteil fast nicht mehr unterscheiden. (Diese Meinung impliziert aber, dass sogenannte 32-Biter überall besser wären/sind, als 8-Biter. Was aber Quatsch ist. Manchmal sind es wohl eher 32/3-Biter) >Ein 32-Bitter kann diese Addition schon mit einem Befehl ausführen. Muss nicht, kommt auf die konkr. Anforderung (bsp Art der Daten, Adressierung) an. >...Aber kann erweitert werden auf die Spezifika bei einer höheren Bitbreite. Ja. Macht nur keiner! (jedenfalls keiner von denen, die man für typ. Embedd-Sachen bezahlen könnte) >Zum Rechnen mit einzelnen Ziffern braucht man schon 4 bit, das hatten >die allerersten Kontroller (der 4004, von Intel ?) Vielleicht erster Mikro-Kontroller, aber nicht Kontroller. Intel hat (schlecht) bei PDP abgekupfert. Auch DEC hatte da schon an Mikro-Kontrollern gearbeitet. >Etwas anders sieht es bei den Adressen aus, da sind 8bit schon >unbrauchbar wenig, ....... >Die Unterscheidung in 8, 16 und 32 Bit ist IMO aus der PC-Welt >entliehen. Bei µCs gelten andere Maßstäbe. CPUs (auch MCUs) werden norm.weise nach der inneren Regbreite benannt, völlig unabhängig von der Adr.breite. (Sinn bei 4-Bit-Datenbreite mit 4-Bit-Adressraum ?) Allerdings kann man noch drüber streiten wie breit das Reg nun denn wirklich ist. >XMegas sind eigentlich schon 16 Bitter Ne, der olle Kern ist doch (zu fast 100%) der gleiche. Die hätten Jahre Zeit gehabt das zu erweitern.
Gregor B. schrieb: > Opossum schrieb: >> wo ich früher nur 8bit breite Register habe, >> müssten die Register bei 32-bit-Prozessoren nun eben 32bit groß sein > > Das ist das wensentliche Unterscheidungsmerkmal zwischen 8- und > 32-Bit-Prozessoren. Nicht wirklich. Schon weil es sowas wie "die Register" gar nicht gibt. Die allermeisten 8-Bitter können Registerpaare als 16-Bit Register verwenden, sowohl als Adreßzeiger als auch für generische Arithmetik. Oft haben die kombinierten Register sogar eigene Namen: z.B. ist auf dem Z80 HL == M oder in den AVRs ist R31:R30 == Z Andererseits arbeitet man auch auf 16-, 32- und 64-Bit CPUs sehr oft mit 8-Bit Datentypen (z.B. für Text). Typisch werden dazu die langen Register wieder in kürzere Teile geteilt. Z.B. auf x86 wird AX in AXH und AXL geteilt. Es ist dann Ansichtssache, ob man das als "Es gibt AXL und AXH, die zu AX kombiniert werden können" oder als "Es gibt AX, das zu AXL/AXH geteilt werden kann" interpretiert. Ein halbwegs sicheres Unterscheidungmerkmal ist wie schon gesagt wurde, die Breite der ALU. Aber auch da gibt es Ausreißer. XL
Axel Schwenke schrieb: > Ein halbwegs sicheres Unterscheidungmerkmal ist wie schon gesagt wurde, > die Breite der ALU. Ich setze alles auf Datenbusbreite. ;-)
x-Bit schrieb: > Ich setze alles auf Datenbusbreite. ;-) Mein Pentium P54 war aber kein 64-Bit Prozessor. Wird Haswell etwa ein 256-Bit Prozessor?
MCUA schrieb: >>Wieso sollte es nur noch eine Berechtigung für Prozessoren mit >>mindestens 32 bit geben? > Manche haben die (berechtigte? oder unberechtigte?) Meinung, dass in > Zukunft wohl sehr wenige bis gar keine neuen 8 Biter mehr aufgelegt, > wegen der hohen Entw-kosten (bei bspweise 40 nm), und weil sich die > Silic-kosten nur für den CPU-Anteil fast nicht mehr unterscheiden. > (Diese Meinung impliziert aber, dass sogenannte 32-Biter überall besser > wären/sind, als 8-Biter. Was aber Quatsch ist. > Manchmal sind es wohl eher 32/3-Biter) Man kann das gerade deswegen als Vorteil von 8Bit sehen da keiner einen 32Bit in >150nm Geometrien bezahlen würde, weiterhin muss man hier schauen wo überwiegend 8Bitter verwendet, z.b. in Steuerungen (Weisse Ware), Sensoren und in Low power Anwendungen. Ein CortexM0+, auch wenn er nur xx uA/MHz verbraucht, ist immer nur für den Active Mode gut (und das gilt dann auch meistens nur je höher getaktet wird). Wenn der Controller meistens schläft und nur kurz aufwachen muß, braucht man low power im Sleep Mode und das möglichst stabil über den ganzen Temperaturbereich. In 90nM und drunter geht der Stromverbrauch gerade im Sleep Mode hoch, und im active mode runter. Ich würde zb. nie solch einen Chip (soll er von mir aus gar 64Bit haben) in eine Steuerung oder Sensorapplikation einsetzen, einen 8Bitter der in >150nm gefertigt wurde aber sehr wohl, was einen Stromverbrauch im Power Down Modus von 100nA und weniger erlaubt - wohlgemerkt mit vollem SRAM Erhalt. Beantwortet wohl auch die Frage wozu noch einen 8Bit nehmen wenn man für denselben (oder niedrigeren) Preis einen 32Bitter mit mehr Flash/SRAM bekommt...
Florian schrieb: > Ware), Sensoren und in Low power Anwendungen. Ein CortexM0+, auch wenn > er nur xx uA/MHz verbraucht, ist immer nur für den Active Mode gut (und Nur der Vollständigkeit halber: 0,6µA mit RAM-Erhalt (STM32L, EFM32) ist zwar mehr als die 0,1µA vom ATmega88PA, aber aber direkt stromfressend nun auch nicht. Aber klar, wenn man von einem 32-Bitter nichts hat ausser mehr Aufwand, dann lohnt der auch nicht.
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.