Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Assembler, kleines Verständisproblem (https://www.delphipraxis.net/20392-assembler-kleines-verstaendisproblem.html)

d3g 18. Apr 2004 16:52

Re: Assembler, kleines Verständisproblem
 
Zitat:

Zitat von Christian Seehase
dennoch ist in den Opcodes der Befehle auch ein Segmentregister (CS, DS, ES, FS, GS, SS) mit kodiert, dessen Inhalt mit zur Adressbildung herangezogen wird.

Du meinst also, dass für jedes Segment ein eigener logischer Adressraum geschaffen wird? Dieses Verhalten müsste doch betriebssystemabhängig sein, da es eigentlich zu Lasten der Performance geht, wenn man logische Adressräume schafft, obwohl man mit dem Register den gesamten linearen bzw. sogar den gesamten physikalischen Adressraum adressieren könnte. Auf 8086 machte das ja noch Sinn, weil man 20 bit für die Adressierung von 1 MB Speicher braucht, das Register aber nur 16 bit breit war, aber heute? Bei Betriebssystemen, die also gar keine Adressraumtrennung zwischen Prozessen machen, könnte man dann auf eigene logische Adressräume für einzelne Register verzichten, oder sehe ich das falsch?

Christian Seehase 18. Apr 2004 22:40

Re: Assembler, kleines Verständisproblem
 
Moin d3g,

Zitat:

Zitat von d3g
könnte man dann auf eigene logische Adressräume für einzelne Register verzichten, oder sehe ich das falsch?

könnte man. ;-)

In Windows laufen ja mehrere Prozesse "gleichzeitig".
Damit die beim Laden aufgelösten Adressen nicht immer neu berechnet werden müssen, wenn auf einen anderen Thread umgeschaltet wird, macht es Sinn einen definierten Nullpunkt zu haben, relativ zu dem dann adressiert werden kann.

Beispiel:
Ein Prozess wird ausgelagert, da er lange nicht benögtigt wurde.
Jetzt ist der phyiskalische Speicher in dem dieser Prozess lag aber von einem anderen belegt worden.
Um jetzt den ausgelagerten Prozess an eine andere physikalische Adresse zu legen müsste man, ohne Segmentregister, erst einmal alle beim Laden aufgelösten Adressen anpassen. Dies lässt sich umgehen, indem einfach die Segementregister für den Prozess auf einen neuen Wert gesetzt werden.
Schon passen die vorberechneten Werte wieder, da sie relativ zum jeweiligen Segmentregister zugreifen.

d3g 19. Apr 2004 17:20

Re: Assembler, kleines Verständisproblem
 
Zitat:

Zitat von Christian Seehase
Um jetzt den ausgelagerten Prozess an eine andere physikalische Adresse zu legen müsste man, ohne Segmentregister, erst einmal alle beim Laden aufgelösten Adressen anpassen. Dies lässt sich umgehen, indem einfach die Segementregister für den Prozess auf einen neuen Wert gesetzt werden.
Schon passen die vorberechneten Werte wieder, da sie relativ zum jeweiligen Segmentregister zugreifen.

Das klingt einleuchtend. Jedoch hat die Segmentierung nichts mit der physikalischen Adresse im Speicher zu tun, dazu ist das Paging zuständig. Ich habe gerade nachgesehen: Linux zum Beispiel übersetzt eine logische Adresse zuerst über die Segmentation Unit in eine lineare und dann über die Paging Unit in eine physikalische Adresse. Pointer wie ebp könnten dann doch gleich eine lineare Adresse beinhalten, denn das würde einen Performancevorteil ergeben, weil die Adresse nicht zuerst noch per Segmentation in eine lineare Adresse umgewandelt werden muss. Eine zusätzliche Angabe des Registers, auf das sie sich bezieht, ist somit unnötig, zumal der gesamte adressierbare Speicher in ein Register passt und es nicht mehr -- wie auf dem 8086 -- eine zusätzliches Register für Adressierung geben muss.

Christian Seehase 19. Apr 2004 19:57

Re: Assembler, kleines Verständisproblem
 
Moin d3g,

Zitat:

Zitat von d3g
...denn das würde einen Performancevorteil ergeben, weil die Adresse nicht zuerst noch per Segmentation in eine lineare Adresse umgewandelt werden muss.

Das erzähl mal Intel ;-)

Zitat:

Zitat von d3g
Eine zusätzliche Angabe des Registers, auf das sie sich bezieht, ist somit unnötig,...

Nur sind in den Opcodes der Befehle die Segmentregister automatisch mit enthalten. Du kommst nicht drum herum.

Wie jetzt ein Betriebssystem die Möglichkeiten eines Prozessors nutzt ist wieder eine andere Sache.

d3g 19. Apr 2004 20:06

Re: Assembler, kleines Verständisproblem
 
Zitat:

Zitat von Christian Seehase
Das erzähl mal Intel ;-)

Was hat Intel damit zu tun? Die Speicherverwaltung ist doch einzig und allein Sache des Betriebssystems.

Zitat:

Zitat von Christian Seehase
Nur sind in den Opcodes der Befehle die Segmentregister automatisch mit enthalten. Du kommst nicht drum herum.

Wirklich? Warum braucht das Betriebssystem dann noch eine Speicherverwaltung, wenn der Prozessor Segmentation und Paging von selbst macht?

:wiejetzt:

Christian Seehase 19. Apr 2004 20:15

Re: Assembler, kleines Verständisproblem
 
Moin d3g,

Zitat:

Zitat von d3g
Die Speicherverwaltung ist doch einzig und allein Sache des Betriebssystems.

Dennoch ist jedes Betriebssystem für die Adressbildung auf die Möglichkeiten der zugrunde liegenden CPU angewiesen.

d3g 19. Apr 2004 20:23

Re: Assembler, kleines Verständisproblem
 
Zitat:

Zitat von Christian Seehase
Dennoch ist jedes Betriebssystem für die Adressbildung auf die Möglichkeiten der zugrunde liegenden CPU angewiesen.

Nun ja, die CPU sollte doch bei Angabe einer physikalischen Adresse auf diese zugreifen können. Wenn es eine CPU gibt, die das nicht kann, dann möchte ich wissen, wie das Betriebssystem Paging vollzieht. Schließlich ist das Resultat des Pagings eine physikalische Adresse. Wenn die CPU nun auf den Speicher anhand physikalischer Adressen zugreift, ist die eiegentliche Speicherverwaltung doch komplett in der Hand des Betriebssystems. Und an dieser Stelle stellt sich für mich die Frage: warum Pointer in einem logischen Adressraum verwenden, wenn man sie doch gleich im linearen Adressraum verwenden könnte?


Alle Zeitangaben in WEZ +1. Es ist jetzt 04:41 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz