?
weil die daten der variablen immer gleich nach dem verlassen des scopes (in deinem fall das verlassen der funktion) verloren gehen, musst du um die daten lesen zu können theoretisch den code der aufrufenden funktion ausführen, den stack frame der aufgerufenen funktion aber beibehalten, die daten im code der aufrufenden funktion an der stelle der auf den aufruf der aufgerufenen funktion folgenden instruktion lesen und oder ändern und danach wieder in die aufgerufene funktion zu der instruktion, welche auf den rücksprung in die aufrufende funktion folgt, zurückspringen, wobei du deren rücksprung adresse auf die instruktion nach den lese- und oder schreibinstruktionen der aufrufenden funktion setzen musst. wie du siehst müssen sich also die aufrufende und die aufgerufene funktion kennen, damit eine derartige konstruktion funktioniert. natürlich könntest du aber in der aufgerufenen funktion den stack frame durchlaufen, um die aufrufende funktion zu identifizieren und anschliessend angepasst auf den aufruf reagieren zu können, aber irgendwann wird das ganze programm vielleicht ein wenig unübersichtlich, platformabhängig, unstrukturiert, langsam oder schlicht und einfach unwartbar, weil du die notwendigen metadaten über die aufrufenden funktionen irgendwo speichern musst. in diesem fall bietet sich natürlich eine hash-table in der du die metadaten der aufrufenden funktionen mit der adresse des prolog codes der aufrufenden funktionen verküpfst und bequem auslesen kannst an. vergiss aber nicht, dass du aufgrund der stack frame manipulation für alle methoden-aufrufe an der hash-table instanz den stack frame der aufrufenden funktion im code für den zugriff auf die daten der aufgerufenen funktion, welcher sich in der aufrufenden funktion befindet, zurückholen musst.
ps: vielleicht habe ich dich auch nur falsch verstanden.