Hallo,
im Netzt habe ich bezüglich der Unterschied einige Beiträge gefunden,
allerdings wird immer die selbe Erklärung abgegeben.
Dass ein 8-Bit in einem Zug max. bis 256 zahlen Berechnen kann und
16-Bit bis 16^2 und so weiter...
Aber was ich hier nicht verstehe ist, wie das im Code zu verstehen ist.
Wenn ich z.B mit ein 8-Bit µC in einer Weil-Schleife ein wert x immer
mit 2 Addiere:
int main()
{
int x = 0;
while ( x < 200)
{
x=x+2;
}
}
was zählt hier alles zu dieser max. 256 berechenbare Zahlen?!
ich meine, die Ausführung von "int x = 0;" ist am endefekt auch ein
Rechenschritt oder "while ( x < 200)". Der Code ist ja nicht nur
rechne mal x=x+2;
was ist hier mein Denkfehler. Danke im Voraus
Gruß
Heizer
Mit einer ordentlichen Compileroptimierung würde hier gar nichts
gerechnet werden, sondern x auf die Konstante 200 gesetzt, und dann
geht's weiter …
In erster Linie beschreibt diese Zahl die Breite von Datenbus und
Registern. Dabei schließt es noch nicht einmal aus, dass bspw. ein
8-bit-Prozessor auch 16-bit-Arithmetik eingebaut hat. Sowas gab's
schon beim Z80.
Hallo,
ein großer Denkfehler ist schonmal dieser: wenn Du in C programmierst,
hast Du mit der darunterliegenden CPU-Architektur (ob 8-16-32 Bit oder
1-Bit Turing-Maschine) nichts zu tun!
Und: die Einschränkung z.B. bei 8 Bit auf 256 Werte bezieht sich auf die
Zahlengröße, die der Prozessor intern mit nur einer Operation
verarbeiten kann. Natürlich kann er auch größere Zahlen verarbeiten, muß
dafür aber schon mehrere Rechenschritte nacheinander verarbeiten. Diese
werden ihm (hoffenlich zielführend ;) vom Programmierer direkt
(Assembler) oder durch den Compiler vorgegeben.
Gruß,
Thomas
Mit einem 8 Bit µC kannst du nicht in einem Schritt 200 + 200 rechnen.
Hierfür sind mehrere Schritte notwendig.
Und 16 Bit = 2^16 Möglichkeiten (nicht 16^2)
bei + 2 addieren und einem 8Bit uInt würde der Zähler zählen :
2
4
6
...
250
252
254
0
2
Du kannst auf einem 8Biter auch ein 16Bit int definieren. Funktioniert,
da der Compiler weiß, wie er damit umzugehen hat. Kostet aber massig
Rechenzeit.
Maik S. schrieb:> Kostet aber massig Rechenzeit.
Das ist eine maßlose Übertreibung. Es kostet genau einen Takt mehr,
für die zweite Addition in der ALU.
64-Bit Ganzzahlen mögen auf einem kleinen 8-Bitter „massig Rechenzeit“
kosten.
Maik S. schrieb:> Mit einem 8 Bit µC kannst du nicht in einem Schritt 200 + 200 rechnen.
Doch, das ergibt 144 und ein gesetztes Überlauf-Flag (carry).
Maik S. schrieb:> Du kannst auf einem 8Biter auch ein 16Bit int definieren. Funktioniert,> da der Compiler weiß, wie er damit umzugehen hat. Kostet aber massig> Rechenzeit.
Die Definition kostet keinerlei Rechenzeit. Die Rechnerei mit 16 Bit
Zahlen geht recht schnell.
picalic schrieb:> Hallo,>> ein großer Denkfehler ist schonmal dieser: wenn Du in C programmierst,> hast Du mit der darunterliegenden CPU-Architektur (ob 8-16-32 Bit oder> 1-Bit Turing-Maschine) nichts zu tun!> Und: die Einschränkung z.B. bei 8 Bit auf 256 Werte bezieht sich auf die> Zahlengröße, die der Prozessor intern mit nur einer Operation> verarbeiten kann. Natürlich kann er auch größere Zahlen verarbeiten, muß> dafür aber schon mehrere Rechenschritte nacheinander verarbeiten. Diese> werden ihm (hoffenlich zielführend ;) vom Programmierer direkt> (Assembler) oder durch den Compiler vorgegeben.>> Gruß,>> Thomas
Hallo,
Prinzipiell hast du recht. Allerdings sind die Standarddefinitionen von
"int" etc. schon von der zu Grudne liegenen Architektur abhängig, oder ?
Heizer schrieb:> Dass ein 8-Bit in einem Zug max. bis 256 zahlen Berechnen kann und> 16-Bit bis 16^2 und so weiter...
Nein. Es bedeutet, daß eine Zahl, die auf einmal verarbeitet werden
kann, nur 256 verschiedene mögliche Zustände kennt, also z.B. bei einem
vorzeichenlosen Integer den Bereich von 0 bis 255. Will man mit größeren
Zahlen arbeiten, muss man die Berechnungen aus mehreren separaten
8-Bit-Berechnungen zusammenstückeln.
> int main()> {> int x = 0;>> while ( x < 200)> {> x=x+2;> }>> }>> was zählt hier alles zu dieser max. 256 berechenbare Zahlen?!
Gar nichts. Das hat damit überhaupt nichts zu tun. x ist ein int, der
auf 8-bit-µCs in der Regel 16 Bit breit ist. Die Addition kann also
nicht als einzelne Aktion durchgeführt werden, sondern muss aus zwei
8-Bit-Additionen zusammengesetzt werden. Auf einem 16-Bit-System dagegen
gibt es eine direkte 16-Bit-Addition.
Jörg Wunsch schrieb:> Maik S. schrieb:>> Kostet aber massig Rechenzeit.>> Das ist eine maßlose Übertreibung. Es kostet genau einen Takt mehr,> für die zweite Addition in der ALU.
Oder mit anderen Worten: Doppelt so viel.
Maik S. schrieb:> Allerdings sind die Standarddefinitionen von "int" etc. schon von der zu> Grudne liegenen Architektur abhängig, oder ?
Jein: ‘int’ umfasst gemäß C-Standard immer mindestens den Wertebereich
von -32767 bis +32767, benötigt also wenigstens 16 Bit.
Rolf Magnus schrieb:>> Das ist eine maßlose Übertreibung. Es kostet genau einen Takt mehr,>> für die zweite Addition in der ALU.>> Oder mit anderen Worten: Doppelt so viel.
Wobei das eine Milchmädchenrechnung ist, da ringsum meist so viel
anderes „Beiwerk“ anfällt, dass die eigentliche CPU-Zeit für die
Rechnung kaum noch ins Gewicht fällt.
Jörg Wunsch schrieb:> Das ist eine maßlose Übertreibung. Es kostet genau einen Takt mehr,> für die zweite Addition in der ALU.
Hmm...
Bei de Addition hier ok, wobei +100% in meinen Augen schon viel ist.
Wenn man Multipliziert oder dividiert ist der Faktor aber wesentlich
höher, da dann sogar 32Bit Zahlen möglich sind.
Gerade am Anfang bin ich gerne über solche "Kleinigkeiten" gestolpert.
Danke für die Erklärungen.
Also das heist jetzt;
Wenn ein 8-Bit und 1MHz µC nur mit Zahlen zwischen 0-256 Arbeitet würde
er auch die 1Mhz einhalten, also 1 Milion Befehle in der Sekunde?
wenn nur ein Zahl größer als 256 abgearbeitet wird dann habe ich 999999
Schritte in der Sekunde. Richtig?
Maik S. schrieb:> Wenn man Multipliziert oder dividiert ist der Faktor aber wesentlich> höher, da dann sogar 32Bit Zahlen möglich sind.
Hängt aber auch wieder von der Hardware ab.
Beispiel: der AVR als 8-Bitter hat in den besser ausgebauten Versionen
einen 16-Bit-Multiplizierer als Hardware an Bord, der genauso in zwei
Taktzyklen multiplizieren kann, wie die CPU zwei 16-Bit-Zahlen addieren
könnte.
Die Register-/Busbreite sagt also nur in starken Grenzen etwas darüber
aus, wie schnell es am Ende wirklich abläuft. Wenn einen die Details
interessieren, muss man sich schon in die konkrete Architektur
einlesen.
Heizer schrieb:> 1 Milion Befehle in der Sekunde?
Das ist doch nur eine ganz grobe Hausnummer!
In vielen praktischen Fällen wird die tatsächliche
Verarbeitungsgeschwindigkeit überhaupt nicht von der Rechenzeit
dominiert, sondern von dem, was rundum passiert (Speicherzugriffe,
IO-Zeiten).
Du theoretisierst das viel zu sehr. Wende dich lieber praktischen
Aufgaben zu. ;-)
Jörg Wunsch schrieb:>> Oder mit anderen Worten: Doppelt so viel.>> Wobei das eine Milchmädchenrechnung ist, da ringsum meist so viel> anderes „Beiwerk“ anfällt, dass die eigentliche CPU-Zeit für die> Rechnung kaum noch ins Gewicht fällt.
Naja, was fällt denn so an? Werte aus dem Speicher lesen. Braucht auch
doppelt soviel Zeit. Werte vergleichen auch. Werte von A nach B kopieren
ebenfalls. Wenn du nur eine 8-Bit-Instruktion durch eine mit 16 Bit
ersetzt, merkt man natürlich keinen signifikanten unterschied. Wenn man
aber alles von 8 auf 16 bit umstellt, schon.
Heizer schrieb:> Also das heist jetzt;> Wenn ein 8-Bit und 1MHz µC nur mit Zahlen zwischen 0-256 Arbeitet würde> er auch die 1Mhz einhalten, also 1 Milion Befehle in der Sekunde?
1 MHz heißt eine Million Taktzyklen pro Sekunde. Wieviele Befehle in
der Zeit ausgefürt werden, hängt vom Prozessor und von den
auszuführenden Instruktionen ab.
> wenn nur ein Zahl größer als 256 abgearbeitet wird dann habe ich 999999> Schritte in der Sekunde. Richtig?
Wenn du auf einem AVR (Additon in 1 Taktzyklus) eine Million mal
hintereinander ohne Sprung oder sonstige Dinge dazwischen nur Zahlen
addierst und sonst nichts tust und alle sind 8-bit-Zahlen und nur ein
paar sind 16-Bit-Zahlen, dann würde das stimmen.
Heizer schrieb:> Wenn ein 8-Bit und 1MHz µC nur mit Zahlen zwischen 0-256 Arbeitet würde> er auch die 1Mhz einhalten, also 1 Milion Befehle in der Sekunde?> wenn nur ein Zahl größer als 256 abgearbeitet wird dann habe ich 999999> Schritte in der Sekunde. Richtig?
Ein 8-Bitter kann nur mit Zahlen von 0-255 arbeiten.
Wenn er 1 Millionen Schritte/Sekunde abarbeitet, dann macht er das
immer, egal was es zu tun gibt.
Jörg Wunsch schrieb:> Du theoretisierst das viel zu sehr. Wende dich lieber praktischen> Aufgaben zu. ;-)
So ist es!
Jörg Wunsch schrieb:> Heizer schrieb:>> 1 Milion Befehle in der Sekunde?>> Das ist doch nur eine ganz grobe Hausnummer!>> In vielen praktischen Fällen wird die tatsächliche> Verarbeitungsgeschwindigkeit überhaupt nicht von der Rechenzeit> dominiert, sondern von dem, was rundum passiert (Speicherzugriffe,> IO-Zeiten).>> Du theoretisierst das viel zu sehr. Wende dich lieber praktischen> Aufgaben zu. ;-)
ja ich weis:) Ich möchte es ja erst verstehen.
Noch eine Frage taucht jetzt auf.
Einmal ist die Rede von 1 Milion Taktzyklen und einmal Schritte. Was ist
was und kann mir eine ein Beispiel Code zeigen was z.B ein Schritt sein
könnte oder ein Taktzyklus. Danke
Heizer schrieb:> Einmal ist die Rede von 1 Milion Taktzyklen und einmal Schritte. Was ist> was und kann mir eine ein Beispiel Code zeigen was z.B ein Schritt sein> könnte oder ein Taktzyklus. Danke
Den Begriff "Schritt" hast du hier eingeführt. Also mußt du uns
eigentlich sagen, was damit gemeint ist.
Bei den Antworten wurden verschiedene Definitionen angenommen. Gemeint
sein kann ein Taktzyklus oder die Ausführung einer Instruktion. Eine
Instruktion kann je nach Prozessor einen oder mehrere Taktzyklen
brauchen oder mit nachfolgenden Instruktionen gemeinsam in einem
Taktzyklus ausgeführt werden.
Rolf Magnus schrieb:> Naja, was fällt denn so an?
Entscheidungen, Sprünge. In der Praxis ist eine 16-Bit-CPU (bspw. ein
MSP430) kaum schneller als eine vergleichbar moderne 8-Bit-CPU (wie
ein AVR).
Dass ein 32-Bit-ARM mit oftmals viel höherer Taktfrequenz schneller
ist, ist wiederum kaum verwunderlich, wobei er als echter RISC eben
auch keine Speicheradresse mit einem Befehl laden kann. Ohne den
Thumb-Befehlssatz (der die Codedichte enorm zunehmen lassen hat)
wäre ich mir gar nicht mal so sicher, ob der ARM den Siegeszug hätte
bestreiten können, auf dem er momentan ist.
Es gibt Architekturen, bei denen laeuft ein einfacher Befehle in einem
Taktzyklus, bei anderen braucht's 4 oder 12 Taktzyklen fuer einen
einfachen befehl. kompliziertere Befehle brauchen das doppelte, drei,
oder vierfache einen einfachen befehles.
einfacher befehl : Inc, dec
nicht einfach : add
komplizierter : call
Siehe ASM instruction manual des betreffenden controllers.
Jörg Wunsch schrieb:> Rolf Magnus schrieb:>> Naja, was fällt denn so an?>> Entscheidungen, Sprünge.
Entscheidungen auf Basis von Vergleichen. Zwei 16-Bit-Werte vergleichen
kostet natürlich genau wie zwei 16-Bit-Werte addieren doppelt soviel wie
bei 8 Bit. Der Sprung selbst natürlich nicht. Auf einem AVR brauche ich
also bei 16 Bit 33% mehr Zeit (4 statt 3 Zyklen), wenn der Sprung
stattfindet, 50% mehr (3 statt 2 Zyklen), wenn er nicht stattfindet.
> In der Praxis ist eine 16-Bit-CPU (bspw. ein MSP430) kaum schneller als> eine vergleichbar moderne 8-Bit-CPU (wie ein AVR).
Bei gleichem Takt und gleicher "Takt-Effizienz" der Befehle? M.a.W.
braucht ein MSP430 auch nur einen Taktzyklus pro Addition, und kann er
gleichzeitig auf Daten und Code zugreifen? Sonst kann man es nicht
vergleichen.
> Dass ein 32-Bit-ARM mit oftmals viel höherer Taktfrequenz schneller> ist, ist wiederum kaum verwunderlich, wobei er als echter RISC eben> auch keine Speicheradresse mit einem Befehl laden kann.
Und du meinst, wenn man ARMe 8 Bit breit, aber sonst gleich aufbauen
würde, daß die kaum langsamer wären als in 32 Bit?
> Ohne den Thumb-Befehlssatz (der die Codedichte enorm zunehmen lassen hat)
Ist das wirklich so extrem? Ich habe den Unterschied noch nie in der
Praxis angeschaut, aber soweit ich weiß, braucht man bei Thumb mehr
Instruktionen, die dafür aber jeweils halb so groß sind. Also
Platzersparnis < 50%, dafür mehr Rechenzeit.
hmm,
Das heist also dass allein Bit Zahl und Frequenz/Takt Angaben nicht
ausreichen um eine Aussage zu treffen, ob jene µC schneller ist oder
langsammer. Mann müsste zusätzlich in den Architekutr sich
reinschnupper.
Aber nicht destotrotzt sind es doch signifikante Angaben oder?
Heizer schrieb:> Noch eine Frage taucht jetzt auf.>> Einmal ist die Rede von 1 Milion Taktzyklen und einmal Schritte. Was ist> was und kann mir eine ein Beispiel Code zeigen was z.B ein Schritt sein> könnte oder ein Taktzyklus. Danke
Ich würde es so veranschaulichen.
In der Grundschule hast du das kleine Einmal Eins auswendig gelernt.
Um 5 * 7 zu 'rechnen' brauchst du nicht wirklich gross rechnen, sondern
du kannst das Ergebnis 'in einem Schritt' angeben.
Das bedeutet aber nicht, dass du nicht auch größere Zahlen
multiplizieren kannst. Du hast auch gelernt, wie du 34 * 78 rechnen
kannst. Nur eben nicht 'in einem Schritt'. Du benutzt eine Vorschrift,
wie du mit den 'einfacheren Operationen' die komplexeren zusammensetzen
kannst.
In diesem Zusammenhang könnte man sich eine 8 Bit CPU wie dich
vorstellen, der eben nur im Zahlenraum bis 100 die Operation
'Multiplikation' durchführen kann. Für alles darüber hinausgehende,
musst du Algorithmen anwenden, wie du auf komplexere Art und Weise die
gewünschte Operation machen kannst. Eine 16 Bit CPU wäre dann zb jemand,
der nicht nur wie du die Multiplikationen bis 10 * 10 in einem Schritt
machen kann, sondern alle Multiplikationen bis 100 * 100. Für alles was
darüber hinausgeht, benutzt er ebenfalls wieder die Algorithmen. Aber
das was für dich bei 34 * 78 noch Aufwand war, das ruft der 'in einem
Schritt ab'. Eine CPU mit noch größerer Bitbreite könnte dann zb alle
Multiplikationen bis 1000 * 1000 'in einem Schritt' rechnen.
Du siehst also: Eine 8 Bit CPU kann selbstverständlich auch mit größeren
Datenbreiten 'umgehen' (im Sinne von: man kann die Berechnung dort
durchführen). Nur kann sie das eben nicht 'in einem Schritt' machen,
sondern muss die Operation gegebenenfalls aus mehreren einfachen
Schritten zusammensetzen.
Und nein, so wie du das jetzt versuchst zu rechnen, so einfach ist das
nicht. Das sind Milchmädchenrechnungen, die du anstellst. In der Praxis
ist ein Programm auf einer 16 Bit CPU nicht doppelt so schnell, weil ein
Programm ja nicht nur aus 16 Bit Operationen besteht, sondern aus einem
gesunden Mix aus Operationen, die nicht nur Arithmetik umfassen.
Was natürlich nicht heisst, dass man einer 8 Bit CPU sinnloserweise 16
Bit Arithmetik aufhalst, wenn es nicht notwendig ist. Mache ich
Zeitberechnnungen mit Stunden, Minuten und Sekunden, dann weiss ich im
Vorfeld schon, dass ich den Zahlenbereich 0 bis 60 nicht verlassen
werde. Also werde ich da keine 16-Bit int benutzen sondern nur 8 Bit
Datentypen, um die 8 Bit CPU von der 16 Bit Arithmetik zu befreien.
Ich glaub, die Zuordnung einer CPU zu einer bestimmten Gruppe ist schon
etwas komplexer als dargestellt wird. Häufig kann man eine CPU bei
Betrachtung unterschiedlicher Eigenschaften (Registerbreite, Datenbus
u.ä.) unterschiedlich einordnen. Deshalb auch mehrfach der Hinweis die
Architektur als Gesamtheit zu betrachten.
Rolf Magnus schrieb:>> Ohne den Thumb-Befehlssatz (der die Codedichte enorm zunehmen lassen hat)>> Ist das wirklich so extrem? Ich habe den Unterschied noch nie in der> Praxis angeschaut, aber soweit ich weiß, braucht man bei Thumb mehr> Instruktionen, die dafür aber jeweils halb so groß sind. Also> Platzersparnis < 50%, dafür mehr Rechenzeit.
Dafür kann man 2 Thumb Befehle gleichzeitig aus dem Flash laden, der
wiederrum bei höherer Taktrate mit Waitstate arbeitet.
Heizer schrieb:> Mann müsste zusätzlich in den Architekutr sich> reinschnupper.
Und man muß natürlich auch die Aufgabe betrachten, die es zu erledigen
gilt.
Heizer schrieb:> Das heist also dass allein Bit Zahl und Frequenz/Takt Angaben nicht> ausreichen um eine Aussage zu treffen, ob jene µC schneller ist oder> langsammer.
genau
> Mann müsste zusätzlich in den Architekutr sich> reinschnupper.
Da gibt es noch viele andere Faktoren, wie zb. Pipelining oder Caching.
Pipeling beschreibt ob in einer CPU zb gleichzeitig mehrere Befehle 'in
Arbeit' sind.
Caching beschreibt, ob die CPU wirklich jedesmall in den langsameren
Hauptspeicher gehen muss um sich von dort Werte zu holen oder zu
speichern oder ob es da einen zwischengeschalteten schnellen Speicher
gibt, über den die Operation läuft.
> Aber nicht destotrotzt sind es doch signifikante Angaben oder?
Ja, aber es sind nicht die einzigen. Man kann über Bitbreite und
Taktfrequenz durchaus eine Tendenz definieren, aber im Einzelfall können
die Ergebnisse davon auch signifikant abweichen.
Du machst ja ein Kraftfahrzeug auch nicht nur an der Anzahl der
Sitzplätze und der PS fest.
Rolf Magnus schrieb:> Sonst kann man es nicht vergleichen.
Genau darauf wollte ich hinaus. Es wird eben gern rein nach diesen
Schlagworten verglichen, aber die Bus- und Registerbreite ist eben
nur ein kleiner Teil der Gesamtperformance.
Was zB auch einen grossen Einfluss hat, ist, ob ein Indexregister
vorhanden ist, oder mehrere gleichwertige.
Deswegen haengt man die Entscheidung fuer eine Familie nicht an
irgendwelchen von Marketing Leuten erdachten Schlagworten auf, sondern
an :
-Variation der Features ueber die Familie
-Skalierbarkeit ueber die Familie
-Lagerhaltung, bei sich, und beim Lieferanten
-Zuverlaessigkeit der Lieferkette
-Tools
-Support, zB von Kollegen
-Preisgestaltung
-Stueckzahlen
Hi
Lasst mich auch mal en wenig klugsch...
Maik S. schrieb:> Und 16 Bit = 2^16 Möglichkeiten (nicht 16^2)
16 Bit ist 2^16-1 weil angefangen wird mit 0. Bei 2^16 brauchts für eine
Verarbeitung in einem Rutsch schon den 32 bitter...
Heizer schrieb:> Aber was ich hier nicht verstehe ist, wie das im Code zu verstehen ist.> Wenn ich z.B mit ein 8-Bit µC in einer Weil-Schleife ein wert x immer> mit 2 Addiere:
Mach dir doch mal den Spaß, und addiere binär. Du weißt, das eine binäre
Zahl nicht größer sein´kann als 1. Wie im Dezimalsystem, wenn dein
Ergebnis >9 wird und du einen Übertrag in die nächste Dekade hast,
geschieht das bei Binärzahlen schon, wenn eine Zahl >1 wird.
Also 1 + 1 = 10, bei Binäraddition versteht sich. Nun nimmst du die
maximal größte darstellbare Zahl mit 8 Bits, nein das ist nicht 256,
sondern eben wegen der mitzurechnenden 0 nur 255, und addierst 1 dazu.
11111111 oder 11111111
+ 1 + 00000001
= 100000000 = 100000000
Dazu rechnest du wie du gelernt hast, nur im Binärsystem. Du siehst, 8
Bit reichen nicht mehr. Mit einzelnen bits schlagen wir uns aber bei
Speicherzugriffen nicht herum und deshalb wird einkomplett zweites Byte
für das Ergebnis benötigt. Da man immer schneller werden möchte und auch
eine höhere Dichte bei den Chipherstellern entwickelt wurde, sind die
Datenbreiten von acht bit auf bis zu 68 Bit angewachsen. Vielleicht gibt
es aber auch schon 128 bitter, wer weiß.
Gruß oldmax
oldmax schrieb:> Hi> Lasst mich auch mal en wenig klugsch...>> Maik S. schrieb:>> Und 16 Bit = 2^16 Möglichkeiten (nicht 16^2)> 16 Bit ist 2^16-1 weil angefangen wird mit 0. Bei 2^16 brauchts für eine> Verarbeitung in einem Rutsch schon den 32 bitter...
2^16 Möglichkeiten ist korrekt.
Die Null ist die erste Möglichkeit.... 0 != null
Heizer schrieb:> Das heist also dass allein Bit Zahl und Frequenz/Takt Angaben nicht> ausreichen um eine Aussage zu treffen, ob jene µC schneller ist oder> langsammer. Mann müsste zusätzlich in den Architekutr sich> reinschnupper.
Wenn du bei einem Auto weißt, wieviel PS der Motor hat und wieviele
Zylinder, bedeutet das auch nicht, daß du deshalb weißt, wie schnell es
fährt. Da gibt's dann doch noch zwei oder drei Dinge mehr zu
berücksichtigen, und so ist das beim Prozessor auch.
oldmax schrieb:>> Und 16 Bit = 2^16 Möglichkeiten (nicht 16^2)> 16 Bit ist 2^16-1 weil angefangen wird mit 0.
Und die ist unmöglich? Oder warum wird sie nicht mitgezählt?
> Heizer schrieb:>> Aber was ich hier nicht verstehe ist, wie das im Code zu verstehen ist.>> Wenn ich z.B mit ein 8-Bit µC in einer Weil-Schleife ein wert x immer>> mit 2 Addiere:>> Mach dir doch mal den Spaß, und addiere binär. Du weißt, das eine binäre> Zahl nicht größer sein´kann als 1. Wie im Dezimalsystem, wenn dein> Ergebnis >9 wird und du einen Übertrag in die nächste Dekade hast,> geschieht das bei Binärzahlen schon, wenn eine Zahl >1 wird.
Genau genommen sprichst du hier vom Dualsystem.
> Dazu rechnest du wie du gelernt hast, nur im Binärsystem. Du siehst, 8> Bit reichen nicht mehr. Mit einzelnen bits schlagen wir uns aber bei> Speicherzugriffen nicht herum und deshalb wird einkomplett zweites Byte> für das Ergebnis benötigt.
Das zusätzliche Bit kommt zwar nicht in den Speicher, ist aber nach der
Berechnung in Form des Übertrags durchaus da. Das nutzt man dann, damit
man, genau wie man es in der Schule lernt, größere Zahlen mit Übertrag
zusammenaddieren kann.
> Da man immer schneller werden möchte und auch eine höhere Dichte bei den> Chipherstellern entwickelt wurde, sind die Datenbreiten von acht bit auf> bis zu 68 Bit angewachsen. Vielleicht gibt es aber auch schon 128> bitter, wer weiß.
Nun, irgendwann lohnt sich das nicht mehr, weil man so große
Integerzahlen nur selten braucht. Und bei den Anwendungen, wo 64 Bit
nicht reichen, sind meist auch 128 Bit zu wenig.
