Hallo und guten Morgen liebe Gemeinde. Ich hätte da eine kurze Verständnisfrage bzgl. Mikrocontrollern. Es gibt ja 8 Bit, 16 Bit und 32 Bit Controller. Nun zur Frage: Hat das vielleicht mit der Verarbeitung der Bits zu tun? Ich denke mir halt folgendes: 8 Bit: 0 bis 255 Zustände 16 Bit: 0 bis 64... Zustände 32 Bit: 0 bis .... Zustände Hat das mit der Addition und Subtraktion der einzelnen Bits zu tun? Danke für die Antworten im Voraus. Gruß Max
Hallo Max, das verstehst du etwas falsch: mit "Zuständen" hat das nichts zu tun (was verstehst du darunter?). Die Bitangabe bei den Controllern gibt die Breite das Datenbusses an. Unter dem Stichwort wirst du auch hier im Forum einiges finden. Gruß Dennis
Sorry, da habe ich mich falsch ausgedrückt. Ich meinte statt "Zustände" die unterschiedlichen Bitkombinationen. Z. B. 1. Bit = 0b00000000 2. Bit = 0b00000001 3. Bit = 0b00000010 4. Bit = 0b00000011 5. Bit = 0b00000100 6. Bit = usw. Ich dachte, dass bei einem 16 Bit Controller das Bit doppelt so groß ist. Oder habe ich das etwas falsches verstanden? Gruß Max
Ähm... du hast einiges falsch verstanden, sorry! 1 Bit ist immer gleich groß.. Lies dir doch erstmal ein paar Wiki-Artikel durch, ordne deine Gedanken und frag nochmal konkret nach! Stichworte: Adressbus, Datenbus, Mikrocontroller, Zahlenformate, Bitverarbeitung, ... Und nochmals: die Zahl beim Controller ist die Datenbusbreite, also die Anzahl der Bits, die gleichzeitig "geladen" werden können. Gruß Dennis
Ein 8bit uC kann mit zahlen zwischeb 0 und 255 rechnen, ein 16bitterit Zahlen zwischen 0 und 65536 und ein 32bitter mit Zahlen zwischen 0 und (2^32)-1.
Max H. schrieb: > Ein 8bit uC kann mit zahlen zwischeb 0 und 255 rechnen, ein > 16bitterit > Zahlen zwischen 0 und 65536 und ein 32bitter mit Zahlen zwischen 0 und > (2^32)-1. ... in einem Zyklus :-) auch ein 8Bit uC kann mit 32Bit Zahlen rechnen. Er kriegt aber halt nur 8 Bit in einem Zyklus auf seinen Datenbus. Somit muss er in mehreren Zyklen rechnen bei größeren Zahlen. Der C-Compiler abstrahiert das aber weg.
Hi Ich bin heut mal wieder etwas kleinlich... >Ein 8bit uC kann mit zahlen zwischeb 0 und 255 rechnen, ein 16bitterit >Zahlen zwischen 0 und 65536 und ein 32bitter mit Zahlen zwischen 0 und >(2^32)-1. Muss heißen ein 16 bitter mit Zahlen zwischen 0 und 65535. Also 1 Zahl weniger... Schönes Wochenende Oldmax
oldmax schrieb: > Muss heißen > ein 16 bitter mit Zahlen zwischen 0 und 65535. Also 1 Zahl weniger... > Schönes Wochenende > Oldmax also kann er nicht mit -5 rechnen?
will man zwei 16bit zahlen mit einander Addieren und man hat einen 8bit µC wird die Addition in zwei getreten schritten vollzogen. hat man eine 16bit µC, so geht das in einem Schritt.
1 | 8bit µC: |
2 | |
3 | zahl 1=32: 00000000|0010000 |
4 | zahl 2=265: 00000001|0000000 |
5 | |
6 | schritt 1: 00100000 + 00000000 = 00100000 kein übertrag |
7 | schritt 2: 00000000 + 00000001 = 00000001 |
8 | |
9 | ergebniss 288: 00000001|00100000 |
oldmax schrieb: > Muss heißen > ein 16 bitter mit Zahlen zwischen 0 und 65535. Also 1 Zahl weniger... Sry, Tippfehler. Bei 8 und 32 bit war's ja richtig... Peter II schrieb: > also kann er nicht mit -5 rechnen? In der Zweierkomplement Darstellung kann der 16bitter mit Zahlen zwischen -32768 und +32767 rechnen. Für einen n-bitter: zwischen -2^(n-1) und +2^(n-1)-1
Hi noch mal ein Nachtrag: Datenbusbreite = Aussage, wieviele Bytes mit einer Adressierung in den Controller gelangen. Bspw. Ein 4 Bit Befehl in Assembler muss bei einem 8 Bitter mit vier Speicherzugriffen erfolgen. Zwischendurch wird geprüft, ob ein weiterer Speicherzugriff erforderlich ist. So ist z, B. beim Z80 ein CALL Befehl 4 Byte lang: 2 Byte Befehle, 2 Byte Sprungadresse. Ein 16 Bitter braucht dafür nur 2 und ein 32 Bitter nur einen einzigen Speicherzugriff und schups, weiß er, was zu tun ist. Zum rechnen nutzen sie schon lange Arithmetikprozessoren. Gruß oldmax
oldmax schrieb: > Bspw. Ein 4 Bit Befehl in Assembler muss bei einem > 8 Bitter mit vier Speicherzugriffen erfolgen. ? > beim Z80 ein CALL Befehl 4 Byte lang: 2 Byte Befehle, 2 Byte > Sprungadresse. Eher 3. 1x Opcode, 2x Adresse. > Zum rechnen nutzen sie schon lange Arithmetikprozessoren. Arithmetikeinheiten, nicht Arithmetikprozessoren. Die Zeit separater Arithmetikprozessoren ist lange vorbei.
Uh also ganz ehrlich, es würde einigen (auch dem TO) eher Helfen ein Rechnerarchitektur-Skript zu lesen oder zumindest zu überfliegen. Die "Bittigkeit" einer MCU hat doch nix damit zu tun, mit welchen Zahlen die rechnet. Oder welche Werte darstellbar (was soll das hier überhaupt heißen...) sind. Dennis S. schrieb: > Die Bitangabe bei den Controllern gibt die > Breite das Datenbusses an. Und nichts anderes. Max H. schrieb: > Ein 8bit uC kann mit zahlen zwischeb 0 und 255 rechnen, ein > 16bitterit > Zahlen zwischen 0 und 65536 und ein 32bitter mit Zahlen zwischen 0 und > (2^32)-1. Max H. schrieb: > Peter II schrieb: >> also kann er nicht mit -5 rechnen? > In der Zweierkomplement Darstellung kann der 16bitter mit Zahlen > zwischen -32768 und +32767 rechnen. > > Für einen n-bitter: zwischen -2^(n-1) und +2^(n-1)-1 A. K. schrieb: > oldmax schrieb: >> Bspw. Ein 4 Bit Befehl in Assembler muss bei einem >> 8 Bitter mit vier Speicherzugriffen erfolgen. > > ? Er meint wohl eher 4 Byte Befehl, dann passt es auch mit vier Speicherzugriffen.
Marian B. schrieb: > Dennis S. schrieb: >> Die Bitangabe bei den Controllern gibt die >> Breite das Datenbusses an. > > Und nichts anderes. Also sind der 68000 und der 80386SX 16-Bitter und der 68008 sowie der 8088 8-Bitter? Oder doch was anderes? mfg.
Marian B. schrieb: >> Die Bitangabe bei den Controllern gibt die >> Breite das Datenbusses an. > > Und nichts anderes. Dummerweise ist man bei diesem Kriterium bei Mikrocontrollern auf eine Klassifizierung des Hersteller angewiesen. Denn oft gibt es keinen extern sichtbaren Datenbus - und wenn doch, dann ist der nicht zwangsläufig so breit wie die internen Busse. Und bei vielen Prozessoren jenseits der hier üblichen ohne Betriebssystem arbeitenden Mikrocontroller läufst du mit diesem Kriterium auf. Mangels klarer Erkenntnis, welcher der etlichen unterschiedlich breiten Datenbusse dafür zu Rate gezogen werden sollte. Der Versuch, ein festes und einheitliches Kriterium von für das N in "N Bit Prozessor" zu definieren, ist problematisch. Irgendwo gibts immer ein Beispiel, wo das in die Hose geht.
Dennis S. schrieb: > 1 Bit ist immer gleich groß. Nö, gibts in 0,33 , 0,5 , 5,0 , 15 , 30 und 50 Liter.
Thomas Eckmann schrieb: > Also sind der 68000 und der 80386SX 16-Bitter und der 68008 sowie der > 8088 8-Bitter? Oder doch was anderes? Klar doch. Und aktuelle x86er sind 256-Bitter. Was doch eine ziemliche Entwicklung ist, angesichts der vor noch nicht allzu langer Zeit gerne verwendeten 16-Bitter namens Athlon64 (im Hypertransport). ;-)
Marian B. schrieb: > Die "Bittigkeit" einer MCU hat doch nix damit zu tun, mit welchen Zahlen > die rechnet. Oder welche Werte darstellbar (was soll das hier überhaupt > heißen...) sind. > > Dennis S. schrieb: >> Die Bitangabe bei den Controllern gibt die >> Breite das Datenbusses an. > > Und nichts anderes. Glaubst du wirklich, dass der TO mit dem Wort "Datenbus" viel anfangen kann? Da die ALU meistens gleich viele Bits hat wie der Datenbus, könnte man es vereinfacht so sagen...
Und oft genug hat sie das nicht, wenn der Prozessor überhaupt nur eine ALU hat. Zudem ist die Breite von internen Strukturen für den C-Programmierer weitestgehend irrelevant, und für den C-Programmieranfänger erst recht. Wenn es also darum geht, ist die Einordnung "8-Bit für kleine Sachen (was ist klein?), 16-Bit wenns etwas mehr sein darf (aha) und 32-Bit wenn es richtig was zu tun gibt (?)" hilfreicher bzw. auch nicht, weil das wieder eine Nicht-Aussage ist. un nu?
Marian B. schrieb: > Und oft genug hat sie das nicht, wenn der Prozessor überhaupt nur eine > ALU hat. Oder wenn die ALU nur 4 Bits hat (Z80). Oder gar nur eines (6804).
Nanu, sowohl beim Z80 als auch beim 6804 finde ich nur Blockschaltbilder mit 8 Bit Registern. Woher hast du diese Info?
Kein Name schrieb: > Nanu, sowohl beim Z80 als auch beim 6804 finde ich nur Blockschaltbilder > mit 8 Bit Registern. Woher hast du diese Info? Bei der Z80 ALU hat sich das schon länger rumgesprochen. Im Datasheet steht es natürlich nicht drin. http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html Beim M6804 ist offiziell: http://bitsavers.trailing-edge.com/pdf/motorola/6804/M6804_MCU_Manual_Sep85.pdf
Max H. schrieb: > Marian B. schrieb: >> Die "Bittigkeit" einer MCU hat doch nix damit zu tun, mit welchen Zahlen >> die rechnet. Oder welche Werte darstellbar (was soll das hier überhaupt >> heißen...) sind. >> >> Dennis S. schrieb: >>> Die Bitangabe bei den Controllern gibt die >>> Breite das Datenbusses an. >> >> Und nichts anderes. > Glaubst du wirklich, dass der TO mit dem Wort "Datenbus" viel anfangen > kann? Da die ALU meistens gleich viele Bits hat wie der Datenbus, könnte > man es vereinfacht so sagen... Naja, zumindest bringt ihm ein klar definierter Suchbegriff (Hilfe zur Selbsthilfe!) ganz bestimmt mehr als die nachfolgende "esotherische" Diskussion. Ich halte es eben für sinnvoller erstmal mit Grundlagen anzufangen als gleich das komplette Fachgebiet mit allen Feinheiten auszubreiten. Gruß Dennis Edit: Zumal ich selber nur einen Bruchteil der ET / TI beherrsche... :-)
Erst einmal vielen Dank für die bisherigen Infos und die dafür rege Mitarbeit. Aber wie Dennis schon gut auf den Punkt gebracht hat... "Hilfe zur Selbsthilfe". Klar sagen mir die Harvard- und Von-Neumann Archicktektur und der Unterschied zwischen RISC und CISC etwas, aber anscheinend habe ich es (noch) nicht richtig verstanden. Also bitte ganz konkret.... Was ist wichtig, um den Unterschied zwischen 8, 16 und 32 Bittern zu verstehen? Datenbus, Rechenwerk und ... ?? Vielen Dank für die Antworten im Voraus. Gruß Max
Max H. schrieb: > Datenbus Meines Erachtens nicht, weil die Breite des Datenbusses nicht eindeutig ist vgl. intern und extern.: Es zählt eher die Breite der Register. Der 68000 war ein 32 Bit Prozessor, auch wenn er extern nur einen 16 Bit Datenbus hatte. Die Breite des Datenbusses ist eigentlich nur für die Geschwindigkeit relevant, während die Breite eines Registers essentiell ist und sich auf die ganze Architektur auswirkt. Bei der Datenbusbreite kann es ja auch sein, dass er intern z.B. 32 Bit breit ist und nur extern, aus Layout- oder Kostengründen 16-bittig (oder gar 8-bittig, siehe 68008) ausgeführt wurde. Im allgemeinen gilt ja, das die interne Breite des Datenbusses gleich der Bitbreite der Register ist. Es gab z.B. einige OMAP Prozessoren von TI (z.B. OMAP 1710), die extern auch "nur" einen 16 Bit Datenbus hatten - auf das interne RAM und Flash ROM (auch Cache) wurde aber 32 bittig zugegriffen. Im Prinzip waren das 32 Bit ARM Prozessoren. Allerdings gibt es wohl keine eindeutige Definition. Natürlich gibt es auch Sonderfälle, z.B. die Saturn CPU von den alten HP Taschenrechnern (HP48). Die arbeitete intern mit 64 Bit Registern, hatte aber extern nur einen 4 Bit Datenbus. Auch brauchte sie jede Menge Taktzyklen für einfache Operationen, von RISC keine Spur. Ich würde diese CPU jetzt auch nicht eine 64 Bit CPU nennen, allerdings auch keine 4 Bit.
klausro schrieb: > Es zählt eher die Breite der Register Noch eine Ergänzung: Wichtig ist natürlich auch, ob die elementaren Befehle der CPU die Grundrechenarten ist der kompletten Breite der Register bewerkstelligen können, also primär load, store, add, sub, cmp und die Bitoperationen. Zwar lief grad' bei den CISC Prozessoren auch oft ein Mikrocode ab (z.B. benötigte der 68000 für eine 16x16 -> 32 Bit Multiplikation IMHO 71 Taktzyklen), aber er benötigte dazu trotzdem nur einen Maschinenbefehl. Also der Versuch einer Definition: Entspricht die Bit-Breite des (internen) Datenbuses der Bit-Breite der Register UND können die elementaren Operationen (s.o.) in 1 bis wenigen Taktzyklen abgearbeitet werden, so entspricht die Wortbreite der CPU dieser Bit-Breite.
8 Bit: 11000011 256 verschiedene Zahlen/Zustände 16 Bit: 10101010 11000011 65535 verschiedene Zahlen 32 Bit: 11100111 10110110 10101010 11000011 4,3 Millionen verschiedene Z. Ein 8 Bit Prozessor/Microcontroller arbeitet Intern mit 8 Bit Registern (also Speicherstellen), ein 16 Bit Prozessor mit 16, ein 32 Bit Prozessor mit 32 Bits. Je mehr Bits, desto grössere Zahlen kann er Intern verarbeiten. Will man bei einem 8 Bit Prozessor z.B. die Zahl 10.000 verarbeiten, muss man mit 2 Registern arbeiten, und Bits von einem in das andere Register verschieben oder berechnen. Das ist dann bei einem 16 Bit Prozessor wesentlich einfacher. Es gibt auch Anwendungen/Programme, wo 8 Bit ausreichen. Ich hab z.B grad einen 16 Bit Controller, aber für eine Berechnung bräuchte ich ein paar Bits mehr. (Warum hat der nicht wenigstens ein einzelnes 24 oder 32 Bit Register??)
>Ein 8 Bit Prozessor/Microcontroller arbeitet Intern mit 8 Bit Registern >(also Speicherstellen), ein 16 Bit Prozessor mit 16, ein 32 Bit >Prozessor mit 32 Bits. Stimmt so nicht, weil ua Register unterschidl. breit sein können. Was man sagen kann ist, dass die Bit-Breite der Register, die norm. für Daten-berechnung genommen werden (also bsp nicht IndexRegister) als Mass für die CPU-Bezeichnung genommen wird. Insbes hat die Adressierungsbreite (bsp 8Bit CPU mit 16 oder 24Bit Adr-Bereich) damit nichts zu tun (obschon die Adr-Berechnung umso einfacher geht, je breiter auch die Datenregister sind). Und selbst wenn man die Adressierungsbreite berücksichtigt, bleibt noch offen, wieviele OPcode-bits die CPU denn auf einmal lesen kann; ganz zu schweigen davon wie viele Takte sie denn jeweils benötigt.
Ich würde die maximale logische Breite der ALU zur Unterscheidung verwenden. Also die Datenbreite, die die ALU in einem Befehl verarbeitet. Und das über alle typischen ALU-Operationen. Ich würde mal sagen: ADD, SUB, AND, OR, NOT, CMP. Das eliminiert ALUs, die physisch schmaler sind als logisch (z.B. Z80) oder die einige Operationen auch breiter als normal können (wieder Z80, 16-Bit INC). XL
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.