Verwirrung: Wikibooks 2³²

hallo

ich lese grad ein wenig über das dualsystem und bin auf folgenden artikel gestossen.

dort heisst es:

Beispiel: Der Intel 80386 arbeitet mit einem Adressbus von 32 Bit. Wieviel Speicher kann er damit adressieren?

Lösung: Mit 32 Bit lassen sich 2³² verschiedene Dualzahlen darstellen, eine für jede Speicheradresse. Das heißt, der Intel 80386 kann 2³² = 4.294.967.296 Byte adressieren. Dies sind 4.194.304 Kilobyte oder 4096 Megabyte oder 4 Gigabyte....

ehm, 4.294.967.296 Byte. hm? warum byte? sollte es nicht eher heissen:

32 bit = 4 bytes und
2³² = 4.294.967.296 möglichkeiten

warum wird dort von 4.294.967.296 Byte gesprochen? wenn überhaupt sind es 4.294.967.296 bit bzw. bit-möglichkeiten. wenn man diese 8er bit blöcke mit der möglichkeit multiplizieren würde, wären es 16GB aber man redet ja nicht von volumen. oder sehe ich das völlig falsch?

volkard

das byte ist die kleinste adressierbare einheit.
mit 2^32 möglichen zeigern kann man also nur 2^32 byte-adressen unterscheiden.
ein array of char könnte nur 4G groß sein.

ein bit ist gar nicht einzeln adressierbar. weil bits auch gar nicht einzeln aus dem ram gelesen werden sollten, sondern immer gleich ein ganzes byte auf einmal.

hallo volkard danke für dein posting und so spät noch unterwegs?

mit 2^32 möglichen zeigern kann man also nur 2^32 byte-adressen unterscheiden.

das verwirrt ein wenig. 32 bit sind doch 4 bytes und nicht 1 byte. soll das heissen, dass ein byte so oder so ein ganzes 32bit register belegt oder wie soll ich verstehen das es 2^32byte bedeutet.

und bezieht sich die 4gb grenze dann pro array in einem programmcode oder für das gesamte programm welches im arbeitsspeicher liegt? und ist das so zu verstehen, dass das 32bit prozessor register exakt max 4gb adressieren kann, weil ihm mit 2^32 keine weitere möglichkeit mehr zur verfügung steht um eine adresse zu interpretieren? das würde sehr sinn machen und vieles erklären. z.B. warum 64bit CPU's so toll sein sollen :).

ach wenn das alle stimmt dann geht mir jetzt echt ein licht auf. das würde ja bedeuten das man einen 32bit prozessor wirklich wort wörtlich so nennen muss. das heist, ein 32 bit prozessor arbeitet bzw. rechnet dann wohl immer mit 32bit und nicht mit 8 oder 16 bit. das heisst: wenn ich eine char variable auf den speicher lege, dann interpretiert der prozessor diese 8bit gleich als 32bit oder wie? wie interpretiert ein 32 bit prozessor dann einen short int oder long int? macht er aus einem long int zwei int's?

das verwirrt ein wenig. 32 bit sind doch 4 bytes und nicht 1 byte. soll das heissen, dass ein byte so oder so ein ganzes 32bit register belegt oder wie soll ich verstehen das es 2^32byte bedeutet.

2^32 Byte deshalb, weil jede Adresse genau ein Byte bezeichnet. Und dass wir mit 32-Bit 2^32 Adressen bauen können, hast du im ersten Posting ja schon erkannt. Jede `Möglichkeit' adressiert ein Byte.

32 Bit sind 4 Byte, richtig. Ein Byte kann natürlich in ein 32 Bit Register gepackt werden, die drei höherwerten Bytes wären dann aber einfach auf null gesetzt oder würden beliebige Werte enthalten, das weiß ich nicht genau.

und bezieht sich die 4gb grenze dann pro array in einem programmcode oder für das gesamte programm welches im arbeitsspeicher liegt? und ist das so zu verstehen, dass das 32bit prozessor register exakt max 4gb adressieren kann, weil ihm mit 2^32 keine weitere möglichkeit mehr zur verfügung steht um eine adresse zu interpretieren? das würde sehr sinn machen und vieles erklären. z.B. warum 64bit CPU's so toll sein sollen

Die 4 GB Grenze bezieht sich auf das komplette System. Es gibt nur einmal diese 2^32 Werte `im Computer', wenn du so willst. Und mit den 64 Bit CPUs liegst du auch genau richtig, die können entsprechend 2^64 Byte adressieren.

das heisst: wenn ich eine char variable auf den speicher lege, dann interpretiert der prozessor diese 8bit gleich als 32bit oder wie? wie interpretiert ein 32 bit prozessor dann einen short int oder long int? macht er aus einem long int zwei int's?

Ein char belegt natürlich weiterhin nur ein Byte im Speicher, aber ein Lesevorgang auf einem 32 Bit System findet tatsächlich immer über 4 Byte auf einmal statt. Compiler optimieren Variablen deshalb oft so, dass sie an einer durch vier teilbaren Adresse beginnen, so kann z.B. ein int in einem Rutsch gelesen werden, andernfalls würde man zwei Lesezyklen benötigen... Ein long int ist meines Wissens auf einem 32 Bit System auch nur 32 Bit, d.h. nicht mehr als ein normales int.

Und dass wir mit 32-Bit 2^32 Adressen bauen können, hast du im ersten Posting ja schon erkannt. Jede `Möglichkeit' adressiert ein Byte.

also als beispiel:

00110101 00110101 00110101 00110101
00110101 00110101 00110101 00110101
00110101 00110101 00110101 00110101
00110101 00110101 00110101 00110101
00110101 00110101 00110101 00110101
....das jetzt 4.294.967.296 mal, wobei jede zeile hier natürlich einen anderen binärcode enthalten würde

korrekt soweit oder? jede zeile hier repräsentiert nun also 32 bit also 4 bytes. für eine adressierung werden alle bit blöcke verwendet, aber inetwa so:

00000000 00000000 00000000 00110101

kommt das hin? es kann ja schlecht:

00110101

sein. sonst müsste man von 16gb (4x4) sprechen. wenn das alles stimmen sollte, dann sind ja jeweils drei bytes nie belegt. warum also rechnet der prozessor also nicht mit 8bit? logisch, somit hätte er nur 256 adressierungsmöglichkeiten. demnach heisst dies: zwar werden alle 4 8bit blöcke verwendet, weil es nunmal 32bit sind, aber für die adressierung wird nur ein 8bit block verwendet und demnach im speicher auch nur 1 byte physikalischer speicher belegt und zwar so, das auch wirklich 4gb ausgenutzt werden können und keine jeweils 3 null bytes sinnlos belegt werden. sprich: den arbeitsspeicher kümmert das ganze weniger, er belegt bis alles voll ist, der prozessor hingegen arbeitet nunmal mit dem 4er 8bit block. richtig? das heisst, der prozessor erhält nie:

00110101

sondern (wenn nur ein byte) immer sowas wie:

00000000 00000000 00000000 00110101

dann noch eine frage bezüglich den 4gb. es ist ja so das sowohl eine adresse speicher für sich verschlingt und aber auch der wert der hinter der adresse liegt. demnach müsste man 8gb arbeitspeicher haben oder geht es dei der 32bit cpu angabe nur um die adressierungsmöglichkeit?

Vermutlich wäre es für dich jetzt am besten, einfach mal drüber zu schlafen, morgen früh wird dir alles klar sein! Trotzdem fasse ich jetzt nochmal zusammen:

Jede Adresse ist 32 Bit lang, besteht also aus 4 Byte. Binär dargestellt reichen die Adressen also von
00000000 00000000 00000000 00000000
bis
11111111 11111111 11111111 11111111

Für die Adressierung werden natürlich immer alle 4 Byte benötigt, sonst wäre die Adresse unvollständig und nicht eindeutig.

es kann ja schlecht:

00110101

sein. sonst müsste man von 16gb (4x4) sprechen. wenn das alles stimmen sollte, dann sind ja jeweils drei bytes nie belegt. warum also rechnet der prozessor also nicht mit 8bit? logisch, somit hätte er nur 256 adressierungsmöglichkeiten. demnach heisst dies: zwar werden alle 4 8bit blöcke verwendet, weil es nunmal 32bit sind, aber für die adressierung wird nur ein 8bit block verwendet und demnach im speicher auch nur 1 byte physikalischer speicher belegt und zwar so, das auch wirklich 4gb ausgenutzt werden können und keine jeweils 3 null bytes sinnlos belegt werden. sprich: den arbeitsspeicher kümmert das ganze weniger, er belegt bis alles voll ist, der prozessor hingegen arbeitet nunmal mit dem 4er 8bit block. richtig?

Bei der Adresse sind immer alle 4 Byte belegt, aus den oben genannten Gründen. Und hier widersprichst du dir ja selbst: Wenn der Prozessor nur 8 Bit der 32 Bit Adresse verwenden würde, wären wie von dir schon gesagt ja nur 256 Speicherzellen adressierbar. So lassen sich die 4GB nicht erreichen! Als erster Grundsatz jetzt: Eine Adresse ist immer 32 Bit lang und verweist auf eine Speicherzelle.

Eine Speicherzelle wiederrum ist ein Byte groß. Das hat mit den Adressen aber nichts zu tun! Die Adressen sind 32 Bit lang und verweisen jeweils auf eine Speicherzelle, in der 8 Bit gespeichert werden können.

dann noch eine frage bezüglich den 4gb. es ist ja so das sowohl eine adresse speicher für sich verschlingt und aber auch der wert der hinter der adresse liegt. demnach müsste man 8gb arbeitspeicher haben oder geht es dei der 32bit cpu angabe nur um die adressierungsmöglichkeit?

Zunächst einmal belegen nur die Werte hinter der Adresse tatsächlich Speicher. Die Adressen sind ja nicht permanent irgendwo gespeichert sondern ergeben sich vielmehr implizit: Du weißt wo der Speicher beginnt (bei Adresse 00000000 00000000 00000000 00000000) und wo er aufhört. Du weißt auch, in welchen Schritten die Adressen erhöht werden, nämlich byteweise. Möchtest du jetzt eine solche Adresse speichern, dann benötigst du dafür 4 Byte im Speicher, weil die Adresse ebenso lang ist. Die gespeicherte Adresse belegt jetzt 4 Byte im Speicher und kann selbst über eine 4 Byte lange Adresse angesprochen werden. Die Adresse, mit der du die gespeicherte Adresse ansprechen kannst, belegt aber zunächst keinen Speicher, außer du speicherst sie auch irgendwo!

Klingt jetzt vllt. kompliziert, ergibt aber durchaus Sinn. Mach jetzt aber erstmal deinen Kopf frei, vermutlich bist du eh schon afu den Weg ins Bett, und lies es dir morgen in aller Ruhe durch.

misst, du hast mich ertappt. ja, ich bin nicht mehr so 100%ig hier . vielen dank für deine tollen beiträge und das um diese uhrzeit . werd es mir morgen nochmals duchlesen. good night!

treppe schrieb:

ach wenn das alle stimmt dann geht mir jetzt echt ein licht auf. das würde ja bedeuten das man einen 32bit prozessor wirklich wort wörtlich so nennen muss. das heist, ein 32 bit prozessor arbeitet bzw. rechnet dann wohl immer mit 32bit und nicht mit 8 oder 16 bit. das heisst: wenn ich eine char variable auf den speicher lege, dann interpretiert der prozessor diese 8bit gleich als 32bit oder wie?

ein 32-bitter ist in der lage, 32 bits parallel zu verarbeiten, das heisst nicht, dass er's immer tun muss. er hat normalerweise 32 datenleitungen, manche benutzen auch einen schummelmodus, indem sie weniger datenleitungen multiplexen und nur die register, der interne bus und/oder die ALU 32-bittig sind. viele 32-bitter können auch einzeln auf 8 und 16-bit wörter zugreifen, einige nicht.
btw: wie viel speicher so'n prozessor adressieren kann, hat mit seiner registerbreite nix zu tun.

noch schnell weitere fragen. rein theoretisch müsste es eine variable mit der adresse 1 und 4294967296 geben oder? es hiess zwar eine adressierung hat immer 1 byte, aber wie kann dann das bei der 4294967296'sten adressierung möglich sein? 4294967296 müsste 4 bytes sein.

und zuguter letzt noch eine: ich habe mal gehört das ein compiler (z.B. für C++) den variablen gleich zur entwicklungszeit eine adresse vergibt. jetzt frage ich mich, wie kann das möglich sein? stichwort kollision mit anderen anwendungen, die bereits im speicher diese adressen für sich reserviert haben.

ich dachte eigentlich das die adressierung der prozessor bzw. der RAM (was den jetzt? :)) selber nornimmt und der compiler bei der übersetzung zwar keine variablen namen mehr benutzt aber auch keine adressierung, sondern vielmehr sowas:

int i = 10;

mov eax, 10

wie man sieht, hier ist keine "adressse" zu sehen. der prozessor schiebt also den wert 10 in das register. die adressierung findet also nicht direkt durch den compiler statt.

Bashar

Es gibt leider nur sehr wenige Register, in der Regel sehr viel weniger als Variablen. Der Compiler ist also bemüht, an jeder Stelle eine möglichst optimale Auswahl der Variablen, die in Registern gehalten werden, zu treffen. Der Rest liegt im Speicher.

Zu der Frage davor: Der Compiler erzeugt viele Adressen, die sich auf irgendwas anderes beziehen, lokale Variablen und Funktionsparameter werden z.B. relativ zum Stack adressiert. Aber selbst feste Adressen werden vom virtuellen Speichermechanismus des Betriebssystems im Speicher so platziert, dass sich keine zwei Programme ins Gehege kommen können.

treppe schrieb:

noch schnell weitere fragen. rein theoretisch müsste es eine variable mit der adresse 1 und 4294967296 geben oder? es hiess zwar eine adressierung hat immer 1 byte, aber wie kann dann das bei der 4294967296'sten adressierung möglich sein?

es geht bei 0 los. die niedrigste adresse (bei 32 adressleitungen) ist 0 (alle bits auf 0) und die höchste ist (2^32)-1 (alle bits auf 1). also kann man auf eine adresse 4294967296 gerade so eben nicht mehr zugreifen.

der stack ist doch ein speicher-register direkt in der CPU oder? also der stack hat nichts mit dem RAM zu tun oder? und ich weiss, der stack ist sehr begrenzt. jetzt stellen sich mir viele weitere fragen. wie löst das dann der prozessor wenn mehrere anwendungen gleichzeitig laufen? dann müsste es doch irgendwann längst ein stack-overflow geben, was es aber nicht tut.

soviel ich weiss, arbeitet der prozessor jeden befehl einzeln ab, egal wieviele anwendungen gerade im RAM geladen sind. nach dem motto: wer was braucht, kommt an die reihe, stimmt das? wenn man viele anwendungen offen hat und die visuell etwas tun (z.B. eine statusbar die sich ändert) sieht es für das menschliche auge ja so aus, als würden alle anwendungen paralell laufen, aber das ist garnicht so oder? das sieht wahrscheinlich nur so aus, weil der prozessor natürlich extrem schnell den binär code einzelner anweisungen verarbeitet. kommt meine theorie hin? also grundsätzlich läuft es nach dem prinzip: was der prozessor zum rechnen bekommt, wird stück für stück verarbeitet, unabhängig davon wieviele anwendungen und sogar das system selber, gerade arbeitet. denn grundsätzlich ist auch das betriebssystem nur eine "anwendung".

in einem kleinen ablaufsshema könnte dies so aussehen (das system läuft und 10 weitere anwendungen):

(für uns sichtbar)
ein button einer anwendung wird geklickt

a) prozessor interpretiert den interrupt 33h
-> programm 6 ändert einen wert im speicher
-> prozessor führt aus und dann...
b) (von a)...der system kernel weiss wo an x,y "gelickt" wurde
c) interrupt 10h operationen werden vom kernel an die cpu geschickt
d) der grafikspeicher wird beschrieben
e) visuelle ausgabe wird aktuallisiert

so ungefähr sollte dies zu verstehen sein oder nicht? grundsätzlich ist vom booten und laden des bootloader über das laden aller system teile und arbeiten am pc eigentlich eine theoretische "ablaufzeit" festgelegt. denn das system und alle anderen programme werden zeilenweise ausgeführt und wenn es nicht sowas wie schleifen (z.B. für bildschirmausgaben) geben würde, würde meiner meinung nach irgendwann der prozessor keine arbeit mehr haben und es wäre ein schwarzer bildschirm zu sehen sein, jedoch mit aktiver hardware.

+fricky schrieb:

treppe schrieb:

noch schnell weitere fragen. rein theoretisch müsste es eine variable mit der adresse 1 und 4294967296 geben oder? es hiess zwar eine adressierung hat immer 1 byte, aber wie kann dann das bei der 4294967296'sten adressierung möglich sein?

es geht bei 0 los. die niedrigste adresse (bei 32 adressleitungen) ist 0 (alle bits auf 0) und die höchste ist (2^32)-1 (alle bits auf 1). also kann man auf eine adresse 4294967296 gerade so eben nicht mehr zugreifen.

okay das stimmt :). das heisst also es gibt eine adresse 4294967295 und diese ist aber dann 4 bytes gross?

Bashar

treppe schrieb:

der stack ist doch ein speicher-register direkt in der CPU oder?

Nein, der Stack ist im Speicher (außer vielleicht bei manchen Microcontrollern).

wozu gibt es ihn dann überhaupt wenn er sowieso im hauptspeicher liegt? und wenn nun 10 anwendungen geladen werden, warum gibt es dann keinen stack-overflow?

treppe schrieb:

der stack ist doch ein speicher-register direkt in der CPU oder? also der stack hat nichts mit dem RAM zu tun oder?

in der cpu steckt normerweise nur der stack-pointer. der stack-speicher selber ist ausserhalb. es gibt aber auch prozessoren mit 'nem internen stack, der ist dann aber ziemlich klein.

treppe schrieb:

und ich weiss, der stack ist sehr begrenzt. jetzt stellen sich mir viele weitere fragen. wie löst das dann der prozessor wenn mehrere anwendungen gleichzeitig laufen? dann müsste es doch irgendwann längst ein stack-overflow geben, was es aber nicht tut.

es kann mehrere stacks geben, dafür muss man einfach nur den stackpointer auf einen anderen wert setzen und sich den alten zustand merken.

treppe schrieb:

soviel ich weiss, arbeitet der prozessor jeden befehl einzeln ab, egal wieviele anwendungen gerade im RAM geladen sind. nach dem motto: wer was braucht, kommt an die reihe, stimmt das?

ja, und die umschaltung übernimmt das OS. dabei werden periodisch fast alle prozessorregister ausgetauscht, auch der stack-pointer und der instruction pointer.

treppe schrieb:

wenn man viele anwendungen offen hat und die visuell etwas tun (z.B. eine statusbar die sich ändert) sieht es für das menschliche auge ja so aus, als würden alle anwendungen paralell laufen, aber das ist garnicht so oder?

richtig. hinzu kommt noch, dass visuelle aktionen gebuffert werden und dann mit einem rutsch ein update erfolgt, so dass es erst recht so aussieht, als würden die programme gleichzeitig arbeiten.

treppe schrieb:

das sieht wahrscheinlich nur so aus, weil der prozessor natürlich extrem schnell den binär code einzelner anweisungen verarbeitet. kommt meine theorie hin?

das passt in etwa.

treppe schrieb:

also grundsätzlich läuft es nach dem prinzip: was der prozessor zum rechnen bekommt, wird stück für stück verarbeitet, unabhängig davon wieviele anwendungen und sogar das system selber, gerade arbeitet. denn grundsätzlich ist auch das betriebssystem nur eine "anwendung".

auch das kommt ungefähr hin.

treppe schrieb:

...und wenn es nicht sowas wie schleifen (z.B. für bildschirmausgaben) geben würde, würde meiner meinung nach irgendwann der prozessor keine arbeit mehr haben und es wäre ein schwarzer bildschirm zu sehen sein, jedoch mit aktiver hardware.

den bildaufbau, refresh usw. übernimmt eigens dafür gemachte hardware, grafikkarte, videocontroller, etc.

treppe schrieb:

das heisst also es gibt eine adresse 4294967295 und diese ist aber dann 4 bytes gross?

wie viele bytes pro adresse zu finden sind, ist architekturabhängig. auf ner x86 pc-gurke sind's z.b. 1 byte (8 bits) pro adresse.

Bashar

treppe schrieb:

wozu gibt es ihn dann überhaupt wenn er sowieso im hauptspeicher liegt?

Ich versteh die Logik hinter der Frage nicht.

und wenn nun 10 anwendungen geladen werden, warum gibt es dann keinen stack-overflow?

Jede hat ihren eigenen Stack.

supertux

treppe schrieb:

wozu gibt es ihn dann überhaupt wenn er sowieso im hauptspeicher liegt? und wenn nun 10 anwendungen geladen werden, warum gibt es dann keinen stack-overflow?

der Stack ist nur der Name für einen Bereich im Speicher (außer bei speziellen Mikrokontrollern). Wir Menschen nennen ihn so, weil man damit Systeme besser modellieren kann. Wo letztendlich der Stack im RAM sich befindet, weiß die CPU durch den Stack-Pointer.

Kauf dir ein Buch über Rechnerarchitektur, oder gleich das hier:
ARM System Developer's Guide | ISBN: 1558608745
da kannst du jede Menge lernen, wie ein "einfacher" Prozessor arbeitet und gibt's sogar Einblicke in "wie kann ich ein einfaches Betriebssystem" schreiben. Die ARM Architektur ist wunderbar, zum Lernen super geeignet, außerdem ist ARM Hardware an sich billig genug, dass man sich ein Embedded System locker leisten kann, um damit zu spielen und lernen.