Können 32-Bit-Computer Zahlen anzeigen, die über 4,3 Milliarden groß sind?
Man hat mir mal früher gesagt, um herauszufinden wie groß eine zahl maximal sein darf damit eine gewisse Anzahl Bits diese noch überwältigen können, muss man nur die anzahl an: "x2" so häufig mit sich selbst multiplizieren, so groß wie die jeweilige Bitzahl ist.
Also um zu wissen wie viel zum Beispiel 8 Bit kann, müsste man nur: 2x2x2x2x2x2x2x2 = 256 aneinander hängen und ausrechnen.
Das heißt, dass die Limitierung von 8 bit bei der zahl "256" liegt und nicht mit größeren zahlen überwältigen kann, als diese "256". Soweit wie ich es damals verstanden habe!
Wenn man aber nun einen 32-Bit-Computer noch hat, was würde passieren wenn man mit zahlen interaggieren würde, die größer sind als: "4.294.967.296"?
z.b. wenn man in einem Computerspiel mehr Spielgeld sammeln würde als "4.294.967.296"?
Oder wenn man z.b. versuchen würde mit einem Taschenrechnerprogramm eine Zahl zu errechnen, die größer als 4.294.967.296?
Was würde dann passieren? Könnten 32-Bit-Computer diese Zahl überhaupt verarbeiten oder würden die abstürzen, crashen oder was würde dann passieren?
6 Antworten
Zunächst sollte man sich damit beschäftigen, was ein 32-Bit / 64-Bit Computer ist.
Die Bit-zahl gibt an, wieviele Bits an Daten eine CPU in einem Rechenschritt verarbeiten kann.
Das bedeutet aber nicht, dass ein Computer nicht in der Lage ist, Zahlen "anzuzeigen", die größer als die Bitzahl ist und auch nicht, dass er nicht mit ihnen rechnen kann.
Die Berechnungen müssen nur in mehreren Rechenschritten durchgeführt werden. Das, und dass das Zerteilen der Aufgabe in Rechenschritte verbraucht natürlich mehr CPU-Zeit, weshalb 64 Bit-Systeme manches schneller machen können als 32 Bit Systeme.
Das stimmt. Das ist aber beim RAM schwieriger.Wenn du mit großen Zahlen rechnest und die CPU mehrere Rechenzyklen dafür braucht, dann ist das ja ok. Aber eine Speicheradresse, auf der eine CPU etwas machen soll (lesen/schreiben) die muss leider in diese 32 Bit passen.
GIbt es eigentlich einen Grund warum man direkt auf 64bit gegangen ist und nicht zuerst auf 48Bit ?
Ich meine 16 Exabyte an möglichen Arbeitsspeicher ist schon eine übertriebene Hausnummer vorallem zu WIndows XP zeiten damals, als 64Bit raus kam...
Normalerweise ist es bei Halbleitern und generell Schaltungen immer einfacher zu verdoppeln. 32 auf 48 wäre eine ver-1,5-fachung. Das wäre zwar möglich, aber den aufwand manchmal nicht wert.
Wass genau muss man in die CPU Physisch verbauen, das diese 64bit kann? Müssen da dann nicht mehr Chips oder Gather verbaut werden als wenn man 48Bit konstruieren würde?
Mit runden 2-er-Potenzen geht so manches einfacher. Ein 48-bit-Register würde 6 Bytes im Speicher belegen, eine Multiplikation wäre 48bit x 48bit = 96bit, also 12 bytes, und Arrays von Adressen müssten in 6-er-Schritten inkremetiert werden, was komplexere Rechenoperationen benötigt als 4er oder 8er-Schritte.
Klar braucht man bei 64 bit mehr Gatter als bei 48 bit, aber bei 64 bit kann man sich immer sicher sein, dass man kein weiteres Architekturupgrade mehr brauchen wird.
Auch das ist nicht notwendigerweise so.
Die alten 8-Bit-Prozessoren hatten üblicherweise 16 (nicht 8) Adressleitungen und konnten somit (nativ) 64 KiB Speicher adressieren. Der 8086 (Ururur...großvater der heutigen x64-Prozessoren) hatte sogar 20 Adressleitungen (war aber etwas komplizierter zu verwenden als es sich anhört).
Außerdem habe ich mich immer geweigert, zu verstehen, wieso 32-Bit-Prozessoren mit ihrem 32-Bit-Adressbus nur 4 GiByte adressieren konnten und nicht 32 GiWorte von je 32 Bit Länge (was 16 GiByte entspricht). (Bei den ersten 16-Bit-Prozessoren hatte es noch einen gewissen Sinn, den Speicher 8-Bit-Wort-weise statt 16-Bit-Wort-weise anzusprechen - Speicherplatz war damals ziemlich teuer, ich erinnere mich noch an 9,99 DM für einen 1-KiByte-IC. Aber auch da gab es schon genügend Fachleute, die 16 Bit Wortbreite für das einzig Sinnvolle hielten - sollte man mal aus Ersparnisgründen einzelne 8-Bit-Einheiten brauchen, konnte man ja immer noch eine kleine Software-Routine verwenden, das wurde schließlich so selten wirklich benötigt, dass die Programme für 16-Bit-Wortbreite insgesamt immer noch sowohl kürzer als auch schneller waren; Textverarbeitung war so ziemlich das Einzige, das noch byteweise arbeitete (Unicode war noch nicht erfunden), war aber nicht die Hauptaufgabe von Computern - wörtlich Rechnern.)
Man kann auch mit größeren Zahlen arbeiten, aber die Anzahl der korrekten Stellen ist begrenzt. Es gibt verschiedene Zahlenformate, die standardisiert sind. Es liegt am Programm, richtig damit umzugehen, bzw. im Prozessor ist das schon integriert. Beispielsweise gibt es Fließkommazahlen. Intern wird, vereinfach ausgedrückt, eine Zahl und ein Exponent gespeichert. Fiktives Beispiel: Die Zahl 12345 und der Exponent 100 (zur Basis 10) werden gespeichert. Damit wird die Zahl 12345 mit 100 Nullen dargestellt. Ich schreib's jetzt nicht aus. ;) Somit lassen sich große/kleine Zahlen darstellen, obwohl der Speicherplatz begrenzt ist. Es "leidet" eben die Genauigkeit darunter.
Auch in 32 bit-Computern kann man Zahlen in mehr als 4 Bytes abspeichern.
Aber ja: in 32 bits kannst du "nur" deine 4 Milliarden Zustände unterscheiden.
Warum sind dann aber 32 bit computer auf 4gb arbeitsspeicher begrenzt?
Mit 32 Bit kann man nur 4GB addressieren, allerdings gab es zeitweise Prozessoren mit "PAE" (physical address extension) bei denen man mit ein paar zusätzlichen Bits eine Speicherbank wählen konnte, um doch einen größeren Gesamt-Speicher zu addressieren.
Man hätte auch Prozessoren mit speziellen Adressregistern bauen können, die aus 2 einfachen Registern zusammengesetzt sind, und dadurch 64 bit addressieren können.
Bei 8 bit Prozessoren war diese Methode sogar Standard: sie enthielten doppelte Register, um 16 bit Addressen zu verarbeiten.
Also wie genau kann ich nicht sagen. Aber mathematisch wenden die da Tricks an um mehrere 32bit zahlen zu nutzen. Nur können die nur 4gb RAM adressieren. Das ist Maximum und soweit ich weiß auch nicht umgehbar
Die Adressbusbreite ist nicht notwendigerweise gleich der Datenbusbreite. Die 8-Bit-Prozessoren hatten so gut wie alle einen 8 Bit breiten Datenbus für ihre 8 BIt breiten "Maschinenworte", aber einen 16 Bit breiten Adressbus für 64 KiByte RAM.
(Der 2650 (iirc) hatte nur 15 Bit Adressleitungen und verwendete ein Bit als "Indirektionsbit" (d. h. wenn dies 1 war, wurde der Inhalt der adressierten Speicherzelle und der ihrer Nachfolgerin als Adresse der eigentlichen Daten interpretiert), der 8086 (Ururur...großvater der heutigen x64er) hatte sogar 20 Bit Adressbusbreite. Und auch auf der Seite der Harware außerhalb des Prozessors gab es z. B. den C128, der bis zu 128 KiByte adressieren konnte - der hatte zwei "Speicherbänke", zwischen denen er per Software-Schalter hin- und herschalten konnte (war noch etwas komplizierter - schließlich liegt auch das ROM im gewöhnlichen Adressraum).)
Abgesehen davon müssten es eigentlich 4 GiWorte (zu je 32 Bit Breite) sein (entspricht 16 GiByte) statt nur 4 GiByte. Hier habe ich mich immer geweigert, einzusehen, wieso man diese völlig bescheuerte Aufteilung der schönen 32-Bit-Worte in einzelne Bytes forciert.
Für Integralwerte stimmt das, mit n Bits lassen sich 2^n verschiedene Zustände darstellen, so einfach ist das.
Bei Fließkommazahlen nutzt man eien Exponentialschreibweise, allerdings sorgt das dann dafür daß Zahlen die die Präzision überschreiten nicht mehr unterscheidbar sind, insbesondere gilt dabei, daß die Präzision nicht linear über den Zahlebereich verteilt ist.
Ein 32-Bit Rechner hat mehrheitlich 32-Bit Register(*) und kann diese Zahlen effizient verrechnen. Das bedeutet aber nicht, daß man nicht auch größere Zahlen verarbeiten kann.
Obwohl Du nur das kleine 1x1 kennst, kannst Du doch trotzdem zwei Zahlen a 10 Stellen multiplizieren oder auch addieren, Du arbeitest Ziffernweise.
Und so kannst Du das dann auch machen, nur, daß Du natürlich gleich auf Blöcken arbeitest, um die Zahl der Operationen klein zu halten.
(*) Genaugenommen haben viele 32-Bit Rechner auch breitere Register für SIMD o.ä. . Je nach verfügbaren Operationen könnten diese auch genutzt werden.
Auch für Ganzzahlen stimmt dies in dieser Form nur bedingt - in der 8-Bit-Ära war es für Assembler-Programmierer Routine, 16-Bit- oder 32-Bit-Ganzzahlen zu verarbeiten (die dann natürlich in mehreren Bytes abgelegt wurden). Offensichtlich ist dieses Wissen seit der 32-Bit-Ära ziemlich in Vergessenheit geraten.
Was stimmt nur bedingt?
Arbitrary Precision ist bei Integralwerten absolut kein Hexenwerk und einfach umzusetzen, aber wenns eh schon fertig vorhanden ist ... (GMP etc.)
Bei FP ist das deutlich haariger, aber auch da gibt es ja MPFR usw. .
Deine Ausführung hier bedeutet, dass die Behauptung, "breitere" Zahlen ließen sich nicht darstellen, überhaupt nicht stimmt. Meinst du das?
Ja, ich kann natürlich generell beliebig breite Zahlen darstellen und verarbeiten - okay, wenn wir keine TM mit unbeschränktem Band nehmen, dann ist der Arbeitsspeicher das Limit sowie ggf. einfach auch die Geduld, wenn die Zahlen zu groß werden.
Aber allgemein gilt schon, daß ich mit n Bits eben 2^n verschiedene Zustände (zum Beispiel verschiedene Integralwerte) unterscheiden und kodieren kann, auch wenn n prinzipiell nicht auf die native Wortbreite des Systems beschränkt bleiben muß.
Mit dem Arbeitsspeicher hat's aber wohl nicht so gut geklappt weil dieser ist bis heute bei 32Bit System auf diese 4 Milliarden Bytes limitert (4GB).