boah, auf diesen sensationellen artikel zu bits versuche ich noch kurz, etwas kurz zur bedeutung der bit-breite in prozessoren zu sagen (insb. für die frage von ich, was denn die 64bit mit RAM zu tun haben sollen):
an alle, die von rechnerarchitektur ein klein wenig verstehen: ich weiss dass das folgende übelst vereinfacht ist, zT in dieser Form sogar falsch, auch von der historischen reihenfolge. keine angst, ich weiss auch, wie es genauer geht, korrigiert mich bitte nur, wenn etwas dadurch verständlicher wird
eine der häufigsten und wichtigsten funktionen einer cpu ist das ablegen von werten im RAM. eingaben, ausgaben, zwischenresultate, andauernd legt die CPU etwas im RAM ab. ein teil davon wird zwar im cache zwischengelagert, aber davon merkt die cpu normalerweise nichts, sie schmeisst einfach immerzu daten in den Arbeitsspeicher und holt sie dort auch wieder heraus.
will ein programm, dass die cpu etwas aus dem arbeitsspeicher liest oder dorthin schreibt, muss es ein maschinen-code-befehl abgeben. dieser ist meist im Stil "Bewege [einen bestimmten Wert] an [eine bestimmte adresse im RAM].
der wesentliche punkt ist nun die Adresse im RAM. Wenn die CPU etwas im RAM ablegen will, wie findet sie es dann wieder? ganz einfach: in dem jedes bit im RAM durchnummeriert wird, und die Nummer dieses RAM-Blocks bestandteil des befehls ist. eben die speicher-adresse.
nun erinnere dich an den beitrag von commander: mit 16 stellen kann man sehr viel grössere zahlen darstellen als mit 8 stellen. wenn nun nur 8 stellen aufs mal verarbeiten kann, kannst du nichts an die speicheradresse 500 senden, denn mit 8 stellen kannst du nur den speicherblock 0-256 adressieren.
was kann man da machen? der erste schritt ist, nicht jedes bit einzeln durchzunummerieren. wenn der prozessor mit 8 bit rechnet, kann man davon ausgehen, dass die meisten werte, die er abspeichern will, auch 8 bit umfassen (halt allenfalls nullen voranstellen). das ermöglicht nun, nur jede 8 stelle aufzunummerieren; der befehl "speichere an RAM-Block 2" heisst nun nicht mehr, dass der Wert in das 2.bit und folgend geschrieben werden soll, sondern eben in das 9. bis 16. bit...
als nächsten schritt kann man diese 8bit-blöcke zusammenfassen, immer in einen tieferen und in einen höheren. der befehl "speichere in den untere teil von RAM-Block 2" dass der wert in den bereich 17-24 geschrieben werden soll, der obere teil sind dann die bits 25-32
ok, das scheint fürs erste ausgereizt. man kann zwar noch weitere unterteilungen machen, aber irgendwann gibt es zuviele befehle, oder die blöcke werden zu gross, um auch noch kleine zahlen halbwegs effizient abzuspeichern.
nächste idee: man segmentiert. auf aktuellen betriebssystemen laufen ja bekanntlich mehrere programme gleichzeitig, die cpu wechselt alle paar millionstelsekunden den sogenannten kontext. nun will man ja nicht, dass die daten, die programm a vor ein paar rechenschritten gespeichert hat, ein paar tausendstelsekunden später von programm b überschrieben werden - sinnvoller ist es, man vergibt je einen eigenen adressbereich.
sagen wir mal, programm a habe den adressbereich 0-255, b liegt auf 256-511. wenn nun die CPU den kontext von a nach b wechselt, teilt sie einer instanz beim RAM mit, dass in der folge sämtliche anfragen für den zweiten bereich gelten werden. damit kann nun wesentlich mehr ram tatsächlich benutzt werden, vor allem, wenn sich programme in unterprogramme unterteilen lassen, die je einen eigenen kontext und damit auch einen eigenen speicherbereich haben (das sind dann u.a. die threads).
wichtig ist bei diesem system nur, dass es dann immer noch einen bereich gibt, wo programme und vor allem threads (die zum selben programm gehören) miteinander daten austauschen können, dies ist dann der shared memory.
aber irgendwie ist auch dies nicht so ganz befriedigend. auch wenn mit dem überspringen von adressen mit 8 bit 512 byte abgelegt werden können, und mehrere programme eigene adressblöcke haben, irgendwo gibt es grenzen. zB, dass ein programm nur mit 512 bytes arbeiten kann, was ganz offensichtlich zu wenig ist, zB für photoshop, wo ein einzelnes bild ja mehrere millionen bytes umfasst. und irgendwie muss die cpu ja auch den kontext benennen können, und wenn sie nur 8bit als parameter für ihre befehle zur verfügung hat, sind beim besten willen nicht mehr als 256 solche bereiche möglich. 256*512: selbst in dieser grob vereinfachten umgebung kann nicht mehr als 128 kilo-byte angesprochen werden. irgendwie muss da etwas anderes her.
das einfachste ist in diesem fall natürlich, dass man der cpu beibringt, auch befehls-argumente mit mehr als 8 stellen verarbeiten zu können. und weil die 2er-reihe in der informatik so viel sinn ergibt, war die nächste cpu-generation eben die 16bit-prozis (8086-286 von intel).
mit 16 bit, kann eine CPU sage und schreibe 65536 adressen ansprechen. boaaah. mit einigem tweaking und einem extrem fortschrittlichen betriebssystem wie MS-DOS konnte man mit diesen 65536 Adressen ganze 640 kBit ansprechen. es gibt leute die waren sich völlig sicher, dass niemand jemals mehr brauchen würde.
damit hatten sie auch recht, bis es dann etwas graphischer wurde. wenn du einen bildschirm mit 640*480 pixel in 8 farben ansprechen willst, brauchst du halt einfach 2400 kbit. nur um jedes einzelne pixel ansprechen zu können, mit noch fast keinen farben. mit einer scheissauflösung. ohne überhaupt auch nur eine einzige nicht-grafik-variable im ram abgelegt zu haben. games und graphische oberflächen waren denn auch die wesentlichen triebfedern, die an der 640kbit-grenze genagt haben; falls du erfahrungen aus den DOS-zeiten hast, erinnerst du dich vielleicht noch an die bes*****nen tools wie XMS, ohne die kein game lief. da ging es nur darum, die cpu ein klein wenig zu bescheissen um eben die höheren adressbereiche ansprechen zu können.
enter 32bit-computing, namentlich intels 386er resp. schon einige zeit zuvor: 68k von motorola (dieser sagenumwobene chip war auch ein wesentlicher grund, weshalb apple 5 jahre vor microsoft in der lage war mehr als nur gerade buchstaben an den monitor zu zeichnen...). 32bit ermöglicht es, dass ein Programm ganze 4 gigabyte anspricht. Das war 1984 mehr als man sich vorstellen konnte. mehr als man platz auf der festplatte hatte, und 4 gigabyte RAM wären wirklich schlicht unerschwinglich teuer gewesen.
aber nicht nur 4GB pro Prozess: der 68k und der 386 brachten auch die oben genannte Segmentierung direkt auf die CPU, ohne jegliche Cheats and Tricks (Stichwort: Memory Management Unit, MMU).
nun ist es aber so, dass 4GB unterdessen keine speziell grosse datenmenge mehr ist. jeder anständige film ist grösser (und die werden ja alle am computer erstellt), ja sogar mit photoshop ist man bald einmal auf 4GB angelangt. und grosse datenbanken in firmen befinden sich schon seit längerem im terabyte-bereich, und davon möchte man einfach nicht nur 4GB im RAM halten... von wissenschaftlichen rechnungen mit den von commander bereits erwähnte wirklich grossen zahlen ganz zu schweigen...
mit 64bit ist es nun möglich, dass ein einzelner prozess sage und schreibe 17'179'869'184 gigabytes (16 exabytes) ansprechen kann. zum vergleich: laut wikipedia entsprichen alle daten, die irgendwo auf der welt ausgedruckt zur verfügung stehen, schätzungsweise ungefähr 5 exabyte.
es braucht seeeeehr viel phantasie um sich vorzustellen, wie man eine derart riesige datenmenge füllen könnte, erst recht noch innerhalb von vernünftiger zeit. aber es ist durchaus anzunehmen, dass für gewisse sachen auch das irgendeinmal nicht mehr reichen wird.
wie sehr schon die 4GB der 32bit-rechner, wie wir sie nun wieder mit den neuen intel-macs erhalten eine brutale grenze ist oder nicht, ist schwer zu sagen, für alle, die sich nicht in extremsten anwendungen wiederfinden, sollten aber 32bit für jedes einzelne unterprogramm, noch einen moment lang reichen. wie gesagt bietet os x bis dato nicht einmal an, in GUI-Prozessen mit 64bit-Adressierung zu fahren.
nichtsdestotrotz: viele haben noch in guter erinnerung, was der wechsel von 16bit auf 32bit für neue möglichkeiten mit sich gebracht hat. da ist es nur klar, dass alle marketingabteilungen dieser welt vom jetzt anstehenden wechsel nach 64bit das blaue vom himmel versprechen.
Hack doch nicht so auf dem armen Bill rum...