Stack-/Framepointer
-
Kann mir mal wer den Unterschied, wenn es einen gibt, zwischen Stack- und Framepointer erklären(Ausführlich ist immer gut
)Und bringt es wirklich was wenn man ein Register mehr, durch -fomit-frame-pointer
bekommt...?Danke.
-
Kyon schrieb:
Kann mir mal wer den Unterschied, wenn es einen gibt, zwischen Stack- und Framepointer erklären(Ausführlich ist immer gut
)Und bringt es wirklich was wenn man ein Register mehr, durch -fomit-frame-pointer
bekommt...?Danke.
das kommt wie üblich drauf an. generell bringt es selbst dann etwas, wenn das zusätzliche register nicht gebraucht wird. man spart nähmlich den code, um den stackframe anzulegen; das ist potentiell schneller (auf heutigen prozessoren macht es aber eher nichts aus), und man spart nat. auch den speicherplatz auf dem stack. der schalter ist also nie schädlich, ausser beim debuggen (und evtl. beim stack-unwinding während einer exception, aber dann interessiert sich sowieso niemand mehr für performance
). der grosse nachteil ist eben nur beim debuggen, dass du ohne framepointer keinen zugriff auf locale variablen hast. man schaltet es während der entwicklung also besser aus.zum unterschied zw. stack- und framepointer:
beide zeigen auf eine position im stack, klar, aber:
der stackpointer zeigt immer dorthin, wo das letzte element abgelegt oder reserviert wurde, das ist ganz automatisch und wird vom prozessor unmittelbar ausgeführt. der framepointer dagegen wird durch softwaregesteuert. man macht es so, dass beim eintritt in eine funktion der framepointer mit dem an dieser stelle gültigen stackpointer initialisiert wird (der alte wert (von der aufrufenden funktion) wird unmittelbar vorher auf dem stack abgelegt und beim verlassen der funktion restauriert). der effekt ist, dass sich die relative position von funktionsargumenten und lokalen variablen bzgl. des framepointers nie ändert. diese relative position ist also eine konstante für jede einzelne lokale variable und jedes argument und ausserdem dem debugger bekannt, was es diesem ermöglicht, dir den wert jeder variable anzeigen zu lassen. der stackpointer verändert sich dagegen in der funktion (primär wenn andere funktionen aufgerufen werden, oder auch um temporäre zwischenzuspeichern u.ä.), er kann also nicht so ohne weiteres benutzt werden, um variablen wiederzufinden (der debugger ist eben nicht so schlau wie du). ein weiterer vorteil ist, dass man über den framepointer auf den stackframe der aufrufenden funktion zugreifen kann - das ist in c++ allerdings ohne bedeutung, weil dort ja keine lokalen funktionen möglich sind.
-
Vielen Dank, wie immer
Wo wir gerade dabei sind; in einem der IA32 Optim.-Guides hab ich gelesen, dass auf Variablen auf dem Stack mit einem 8 Bit Offset relativ zu dem Pointer in ESP/EBP zugegriffen wird( im Gegensatz zu einer 32 Bit Adressierung bei Daten auf dem Free store/Heap). Ist da was dran? Der Pointer in ESP/EBP ist aber nicht der Stackpointer, oder?
-
Kyon schrieb:
Vielen Dank, wie immer
Wo wir gerade dabei sind; in einem der IA32 Optim.-Guides hab ich gelesen, dass auf Variablen auf dem Stack mit einem 8 Bit Offset relativ zu dem Pointer in ESP/EBP zugegriffen wird( im Gegensatz zu einer 32 Bit Adressierung bei Daten auf dem Free store/Heap). Ist da was dran? Der Pointer in ESP/EBP ist aber nicht der Stackpointer, oder?
es gibt beide formen mit 8bit und 32bit rel. offset. die 8bit form führt aber logischerweise zu einem 3byte kürzeren befehl (vorausgestzt man kann überhaupt auf die variable mit 8bit offset zugreifen) und ist daher i.d.R. vorzuziehen. darum muss man sich allerdings nur selten kümmern. mehr-pass assembler (und compiler sowieso) machen das normalerweise automatisch, nur bei 2-pass assmblern wie nasm muss evtl. selbst hand anlegen (wobei auch nasm mehr-pass assemblierung unterstützt, wenn man das explizit angibt).
-
Also selber machen will da nichts
Ich vertraue meinem Compiler(jedenfalls meistens); hat mich nur gerade mal interessiert weil nix im Fernsehen kommt....Danke für die schnellen Antworten.