Mikroprozessoren - Speicher/Ram

Wenn das, was du im folgenden zitierst, da tatsächlich drinstehen sollte, dann waren die Bücher garnicht so gut.

Vermutlich hast du aber garnicht zitiert, sondern nur das widergegeben, was du davon verstanden hast...

Ja natürlich, praktisch jeder sogar. Sogar die CPUs im ganz normalen PC können das und machen das (nämlich bei jedem Startvorgang). Direkt nach dem Einschalten sind sämtliche Caches abgeschaltetet und das Speichersystem noch garnicht initialisiert. Es bleibt also garnix anderes über, als zumindest die allerersten Befehle direkt aus dem BIOS-ROM abzuarbeiten. Dagegen, daß der viel langsamer ist als der Kern der CPU, gibt es das Wundermittel der Waitstates. die CPU dreht einfach Leerrunden, bis der Speicher bereit ist, die gewünschten Daten zu liefern.

Nö, das kann man tatsächlich nicht, wenn der Core warten muß, dann sind immer irgendwelche Flipflops beteiligt, selbst dann, wenn die Elemente zwar synchron, aber mit geringerem Takt betrieben werden.

Unsinn. Wenn die Quelle schnell genug und synchron ist, dann verbessert eine Zwischenspeicherung das Laufzeitverhalten kein bißchen, sondern verschlechtert es im Gegenteil logischerweise um wenigstens einen Takt.

Unsinn. Welcher Ladevorgang wieviel Zeit kostet hängt vor allem davon ab, mit welcher Busbreite der Speicher angebunden ist. Ist er mit z.B.

32Bit angebunden, dann kostet es natürlich mindestens die doppelte Zeit, ein nicht aligntes 32Bit-Word zu lesen, denn es sind dazu ja Zugriffe auf _zwei_ Speicheradressen erforderlich. Und das gilt vollkommen unabhängig davon, ob der Speicher synchron oder asynchron angebunden ist und ob es RAM oder ROM ist.

"nicht immer" != "nie". Auf den bei üblichen Controllern eingebauten RAM können jene im Allgemeinen auch ohne größere Verrenkungen zugreifen.

Schon lange. Zum einen hat nicht jeder Cache, zum anderen kann quasi jeder, der Cache hat, auch ohne Cache arbeiten, und desweiteren gibt es Controller mit eingebautem Flash.

Jeder, der einen x86 kennt und jetzt meint, er wüsste alles über Prozessorarchitektur, sollte sich mal einen PIC anschauen.

Hä? Heißt das, mein 'sort.com' aus 47 Bytes Programmcode, welches Dateien bis 30k sortieren kann, habe ich nur geträumt?

Doch, genau das wird deine CPU tun. Speicher wird auf allen größeren Prozessoren wortweise adressiert. Wenn du 16 bit haben willst, der Speicherbus aber 32 bit breit ist, wird halt ein 32-bit-Wort angefordert und die unbenutzten Bits Prozessor-/RAM-seitig ausgeblendet. Wenn dein

16-bit-Wort eine 32-bit-Grenze überschreitet, müsste der Prozessor aus einem Ladebefehl zwei Buszyklen machen, und das macht nicht jeder. Einzig bei 8-bittern, die 16-bit-Operationen eh immer aus zwei Buszyklen zusammensetzen, ist das egal, Wobei es da auch welche gibt/gab, die den Carry bei der Adressrechnung nicht richtig hinbekommen, und daher besser ausgerichtete Werte haben sollten.

Stefan

*Michael Eggert* wrote on Sun, 06-12-10 01:14:

Auch Prozessoren konnten schon immer Code direkt aus ROMs verarbeiten ohne ihn vorher in ein RAM (interne Register seien hier nicht dazugerechnet) zu kopieren. Bekanntes Beispoiel ist der Atari ST, aber auch BIOS und BASIC der IBM-kompatiblen arbeitete so IIRC.

Stefan Engler schrieb:

.=2E.

So weit, so richtig.

Jaein - kommt drauf an, was Du unter Cache verstehst. Wenn Dein Cache =3D die xx(xx) kB (auf mehreren Levels) sind, die moderne HF-CPUs brauchen, um den Geschwindigkeitsunterschied zwischen externem Speicher und Core wenigstens halbwegs ausgleichen zu k=F6nnnen, dann kann das so sein - mu=DF aber nicht.

Wenn Dein Cache =3D die n Register sind, die entsprechend der Pipelinetiefe gebraucht werden, um Instruktionen zwischenzuspeichern, dann d=FCrfte das meistens so sein.

Wer redet denn hier von asynchron? Wenn Du direkt adressierbaren statischen (externen)Speicher hast, dann legst Du die Adresse an und holst Dir den zu dieser Adresse geh=F6renden Befehl rein - im selben Takt. Adresse raus mit der fallenden Flanke der clock, Daten rein mit der steigenden. Damals (tm) gab's dazu sogar spezielle SRAM- und EPROM-Bausteine (ok, das war zu Zeiten, als 33 MHz schnell waren...) die dann intern die Adresse selbst hochz=E4hlen konnten, so da=DF Du f=FCr konsekutive Zugriffe die Adresse nur einmal gebraucht hast. Nimm einen Chip mit Harvard-Architektur dazu, und Du kannst mit einem Adressbus, einem Datenbus und einem Programmbus pro Takt ein Daten- und ein Programmwort gleichzeitig in die CPU bringen - kontinuierlich, wenn die SW-Optimierung gut genug ist.

Neumodischer Kram... ;-)

Doch - gerade dann. Weil ein physikalischer Zugriff eben immer nur das holen kann, was auf dem Bus liegt. Wenn Du den mit 32 bit organisierst, dann liegen eben immer diese 32 bit an. Da macht es sogar sehr viel Sinn, alles auf 32-bit aligned hinzulegen, damit Du f=FCr ein Datenwort (oder Programmwort) nicht zweimal zugreifen mu=DFt. Noch mehr Sinn (oder eigentlich richtig interessant) macht das bei Prozessoren, die einen Befehl auch in einem Datenwort unterbringen. Auf neumodisch eben RISC.

Geht auch, wird in der Hardware aber sehr aufw=E4ndig und kostet dann dort auch zus=E4tzliche Takte. Alignen ist billiger und schneller, kostet halt ggf. zus=E4tzlichen Speicher - oder eine CPU, die gut genug ist, z.B. 4*8 Bytes parallel einzulesen und dann wie-auch-immer entsprechend unabh=E4ngig zu verarbeiten. Schlimm wird's, wenn Deine 16 (oder 8) bit =FCberhaupt nicht mehr aligend sind - stell' Dir vor, Deine CPU m=FC=DFte (bei einem 32-bit Bus) zwei mal lesen, um ei 16-bit Wort zu kriegen, weil das eine Byte auf der einen und das andere Byte auf der n=E4chsten (32-bit Basis-)Adresse abgelegt ist. Geht nicht? Geht schon - wir schlagen uns hier gerade mit so einem Fall rum: eine Struct wird von einem Ger=E4t an ein anderes gegeben, und die Programmierer hatten keine Lust, die Structs auf beiden Ger=E4ten synchron zu halten. Der eine schreibt struct* raus, der andere liest char* ein :-(((((

Gru=DF Markus

Ich meine alle Elementen des Prozessors, die Werte zwischenspeichern. Das (musste mich selbst auch erst belehren lassen) geh=F6rt mit zum RAM/Cache der Prozessoren. Ich meinte damit ausdr=FCcklich auch die Register, wie aus der Gesamtschau des Artikels hervorgehen sollte.

Ich glaub jetzt das Steuerwerk der fr=FChen 8086'er speicherte genau einen kompletten Befehl zwischen, bevor er ausgef=FChrt wurde.

Die B=FCcher sind schon Ur-Alt und aus Zeiten des LC-80 (dessen CPU mit dem Displaycontroler identisch ist). Unter anderem wurden CPU's mit intr, intr und NMI und welche ohne INTR verglichen und die Vor- und Nachteile beschreiben. Viel ging um den Z80 und einige PIC's.

=DCbrigens der Zinke, Otto: Hochfrequenztechnik (Band II) ist gar nicht zum Verstehen geschrieben