Verwirrung: Wikibooks 2³²

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.

super vielen dank euch allen für die tolle hilfestellung. eine lustige erleuchtung hätte ich dann noch zu erwähnen: viele menschen schieben die maus in wirrwarr bewegungen hin und her, wenn sich nichts mehr reckelt. wenn ich mich richtig besinne ist das eigentlich fatal oder? da der prozessor so glaube ich, bei tastatur/maus eingaben den momentanen befehl beendet. demzufolge hat eine schnelle mausbewegung bei einem bereits hängenden system eigentlich kein wirklich nützlicher einfluss, im gegenteil. :p

supertux schrieb:

Kauf dir ein Buch über Rechnerarchitektur, oder gleich das hier:
ARM System Developer's Guide | ISBN: 1558608745

...und wenn's ARM sein soll, ohne arm zu werden:
http://www.arm.com/miscPDFs/14128.pdf
^^hinweis für n-man: dies ist keine raubkopie.
supertux: dein buchvorschlag sieht interessant aus. das hole ich mir auch.

da der prozessor so glaube ich, bei tastatur/maus eingaben den momentanen befehl beendet.

der kriegt interrupts bei mausbewegungen, wobei der angefangene befehl immer noch zu ende abgearbeitet wird

demzufolge hat eine schnelle mausbewegung bei einem bereits hängenden system eigentlich kein wirklich nützlicher einfluss, im gegenteil.

ach, das kannst so nicht sagen. wenn man sieht, wie sich der maus-pfeil bewegt, dann zeigt das zumindest, dass die kiste nicht vollkommen hängt.

supertux

+fricky schrieb:

...und wenn's ARM sein soll, ohne arm zu werden:
http://www.arm.com/miscPDFs/14128.pdf
^^hinweis für n-man: dies ist keine raubkopie.
supertux: dein buchvorschlag sieht interessant aus. das hole ich mir auch.

Ich überlegte, ob ich den Link zur Referenz stellen sollte, da habe ich mich allerdings fürs Buch entschieden. Die PDF ist geil, aber nur wenn man auch die ARM Architektur bereits kennt und weiß, worum es geht, darum ist sie eine Referenz. Das Buch dagegen ist keine Referenz sondern ein Buch, in dem die ARM Architektur erklärt wird, also man bekommt mehr als nur eine Tabelle mit Daten, sondern auch viel Hintergrundswissen, warum man sich für die ARM Arch für das eine oder andere entschieden hat. Das ist die Bibel für ARM Einsteiger und generell für Leute, die ein bisschen über (RISC) Rechenarchitektur wissen wollen (wie der OP).

eine blöde frage noch: es ist nicht möglich mit einer anwendung anzuzeigen, was der prozessor gerade verarbeitet oder? höchstens für das eigene auszuführende programm könnte man den assembler simulieren, aber nicht für alles was im system gerade läuft oder?

abc.w

Lauter Informatiker hier

Um die Verwirrung um den 32 Bit Adressbus noch mehr zu verstärken: Wenn man sich das Datenblatt vom 80386 anschaut, findet man "nur" 30 Adressleitungen, also "nur" 30 Bit... Wie macht er denn das bloss mit 32 Bit?

volkard

abc.w schrieb:

findet man "nur" 30 Adressleitungen, also "nur" 30 Bit... Wie macht er denn das bloss mit 32 Bit?

windows-auslagerungsdatei.

leider muss ich nochmals einhaken weil es doch nicht ganz klar ist. eine adressierung hat ja immer 1 byte und deswegen gehen mir diese 4 bytes, was ja 32 bit's sind, einfach nicht aus dem kopf.

Nachtfalke@night schrieb:

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.

und genau das verstehe ich nicht. wenn eine adresse aus 1 byte besteht, wären das ja nur 2^8, also 256 unterschiedliche adressen. und: "Jede `Möglichkeit' adressiert ein Byte" versteh ich nicht. jede möglichkeit besteht aber immer aus 4 bytes. wo setze ich falsch an? ah, jetzt vielleicht: diese möglichkeiten haben garnichts mit der adresse ansich zu tun, sondern der dezimale wert der aus den möglichkeiten entsteht, ist die adresse und das wiederum 1 byte? hm

Nachtfalke@night schrieb:

...aber ein Lesevorgang auf einem 32 Bit System findet tatsächlich immer über 4 Byte auf einmal statt.

aber was wenn ich ein char aus dem speicher lese? dann benötige ich ja nur 1 byte. wie kann der prozessor hier dann 4 bytes lesen?

Nachtfalke@night schrieb:

Ein long int ist meines Wissens auf einem 32 Bit System auch nur 32 Bit, d.h. nicht mehr als ein normales int.

okay sorry, ich meinte eigentlich ein double. wie sieht es hier aus, das wären 8 bytes. danke schonmal

Bashar

treppe schrieb:

leider muss ich nochmals einhaken weil es doch nicht ganz klar ist. eine adressierung hat ja immer 1 byte und deswegen gehen mir diese 4 bytes, was ja 32 bit's sind, einfach nicht aus dem kopf.

Du musst mal zwischen der Adresse und dem, was adressiert wird, unterscheiden. Eine Anschrift ist ja auch kein Haus, sondern nur 4 Zeilen Text. Also: Der Speicher ist in 2^32 adressierbare Einheiten aufgeteilt. Um so eine Adresse anzugeben, brauchst du 4 Byte. Das, was du damit adressierst, sind aber einzelne Bytes.

Nachtfalke@night schrieb:

...aber ein Lesevorgang auf einem 32 Bit System findet tatsächlich immer über 4 Byte auf einmal statt.

aber was wenn ich ein char aus dem speicher lese? dann benötige ich ja nur 1 byte. wie kann der prozessor hier dann 4 bytes lesen?

Er liest 4 Bytes und wirft davon 3 weg, schätze ich.