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.
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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: > sind die Datenbreiten von acht bit auf bis zu 68 Bit angewachsen Wenn schon klugscheißen, dann bitte richtig: sind wohl eher 64 Bit.
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.
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.