Speichermanagement von Blitz

Übersicht

BlitzBasic

Allgemein

	Eingeproggt Betreff: Speichermanagement von Blitz	Mi, Aug 20, 2008 17:27 Antworten mit Zitat
Hallo, Ich stellte mir heute die Frage, ob der Speicher den lokale Variablen in einer Funktion immer belegt ist oder dynamisch verwaltet wird. Dachte mir mal wieder, das kann ja ned so schwer sein, das mess ich mal geschwind mit dieser Funktion: https://www.blitzforum.de/foru...gbarer+ram die ich folgender Maßen verwendete: Code: [AUSKLAPPEN] [EINKLAPPEN] Global memorybank=CreateBank(32) DebugLog "Alle Angaben in verfügbaren Seicher [byte]) api_GlobalMemoryStatus memorybank DebugLog "anfangs: "+PeekInt(memorybank,34) testfunct() api_GlobalMemoryStatus memorybank DebugLog "ende: "+PeekInt(memorybank,34) WaitKey() End Function testfunct() Local var1=1 Local var2=1 api_GlobalMemoryStatus memorybank DebugLog "Nach Vars reservieren: "+PeekInt(memorybank,3*4) End Function (Sorry, ich habe die Function "GetMemoryStatus" umbenannt, weil "api_GlobalMemoryStatus" besser in mein decls-Schema passte) Nunja, jedenfalls wenn man das testet, dann kann man nicht feststellen dass die lokalen Variablen RAM belegen würden... Jetzt also meine Frage: wie handhabt Blitz das? Wird der Speicher woanders hergenommen (virtueller Speicher, Pagefile?) oder belegt Blitz gleich beim Programmstart sämtlichen Speicher, den alle globalen und lokale Variablen brauchen? (Das würde bedeuten, dass lokale Vars nicht dynamisch gemanaged werden) und für alle Neugierigen: Warum will ich das wissen? Die Optimierung die man da eventuell rausholen könnte war zwar der Beginn, warum ich mich damit beschäftigte aber der Optimierungseffekt wird minimal sein.. absolut vernachlässigbar. Ich beschäftige mich nur noch damit, weil es mcih interessiert und ich das einfach aufklären will. Als Programmierer muss man ja wissen, wie sich variablen verhalten... Danke für alle die sich der Thematik annehmen, Christoph. (Aber bitte: Wenn ihr Erkenntnisse habe, die ich noch nicht habe, dann gebt mir gleich einen Code dazu der das aufzeigt. Herum-orakeln und phantasieren kann ich auch selbst)
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

Betreff: Speichermanagement von Blitz

Mi, Aug 20, 2008 17:27
Antworten mit Zitat

Hallo,

Ich stellte mir heute die Frage, ob der Speicher den lokale Variablen in einer Funktion immer belegt ist oder dynamisch verwaltet wird. Dachte mir mal wieder, das kann ja ned so schwer sein, das mess ich mal geschwind mit dieser Funktion:
https://www.blitzforum.de/foru...gbarer+ram

die ich folgender Maßen verwendete:

Code: [AUSKLAPPEN]

Global memorybank=CreateBank(32)

DebugLog "Alle Angaben in verfügbaren Seicher [byte])

api_GlobalMemoryStatus memorybank
DebugLog "anfangs: "+PeekInt(memorybank,3*4)

testfunct()

api_GlobalMemoryStatus memorybank
DebugLog "ende: "+PeekInt(memorybank,3*4)
WaitKey()
End

Function testfunct()
Local var1=1
Local var2=1

api_GlobalMemoryStatus memorybank
DebugLog "Nach Vars reservieren: "+PeekInt(memorybank,3*4)
End Function

(Sorry, ich habe die Function "GetMemoryStatus" umbenannt, weil "api_GlobalMemoryStatus" besser in mein decls-Schema passte)

Nunja, jedenfalls wenn man das testet, dann kann man nicht feststellen dass die lokalen Variablen RAM belegen würden... Jetzt also meine Frage: wie handhabt Blitz das? Wird der Speicher woanders hergenommen (virtueller Speicher, Pagefile?) oder belegt Blitz gleich beim Programmstart sämtlichen Speicher, den alle globalen und lokale Variablen brauchen? (Das würde bedeuten, dass lokale Vars nicht dynamisch gemanaged werden)

und für alle Neugierigen: Warum will ich das wissen?
Die Optimierung die man da eventuell rausholen könnte war zwar der Beginn, warum ich mich damit beschäftigte aber der Optimierungseffekt wird minimal sein.. absolut vernachlässigbar. Ich beschäftige mich nur noch damit, weil es mcih interessiert und ich das einfach aufklären will. Als Programmierer muss man ja wissen, wie sich variablen verhalten...

Danke für alle die sich der Thematik annehmen, Christoph.
(Aber bitte: Wenn ihr Erkenntnisse habe, die ich noch nicht habe, dann gebt mir gleich einen Code dazu der das aufzeigt. Herum-orakeln und phantasieren kann ich auch selbst)

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	ChristianK	Mi, Aug 20, 2008 18:14 Antworten mit Zitat
Lokale Variablen werden üblicherweise auf dem Stack gespeichert. Jedes Programm bekommt beim Start eine bestimmte Menge davon zugewiesen (1 MB, kann aber erweitert werden). Wäre auch etwas umständlich, für jede lokale Variable Speicher vom Betriebssystem anzufordern. Der Stack wird btw auch für Parameter benutzt, weshalb unendliche Rekursion immer in einem Stack Overflow resultiert.
AdvanceLcd Intel Core 2 Duo 3.2 GHz, 4 GB RAM, GeForce 8800 GTX \| MacBook Pro 15,4″ Intel Core 2 Duo 2.4 GHz, 2 GB RAM, GeForce 8600M GT

ChristianK

Mi, Aug 20, 2008 18:14
Antworten mit Zitat

Lokale Variablen werden üblicherweise auf dem Stack gespeichert. Jedes Programm bekommt beim Start eine bestimmte Menge davon zugewiesen (1 MB, kann aber erweitert werden). Wäre auch etwas umständlich, für jede lokale Variable Speicher vom Betriebssystem anzufordern. Der Stack wird btw auch für Parameter benutzt, weshalb unendliche Rekursion immer in einem Stack Overflow resultiert.

AdvanceLcd
Intel Core 2 Duo 3.2 GHz, 4 GB RAM, GeForce 8800 GTX | MacBook Pro 15,4″ Intel Core 2 Duo 2.4 GHz, 2 GB RAM, GeForce 8600M GT

	Eingeproggt	Mi, Aug 20, 2008 18:23 Antworten mit Zitat
1 MB für alle Funktionspointer und lokale Variablen in den Funktionen? Naja, klingt nicht viel, aber wenn man drüber nachdenkt... Reicht wahrscheinlich für jedes Spiel locker aus. Das heißt, wenn ich lokale Variablen verwende, werden die zwar im RAM gehalten aber im "Stack-Kontingent"? und um nochmal auf meine sture denkweise zurückzukehren: Das heißt lokale Vars sind dynamisch und werden beim beenden der Funktion aus dem Stackspeicher gelöscht? mfG und Danke, Christoph.
Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

Eingeproggt

Mi, Aug 20, 2008 18:23
Antworten mit Zitat

1 MB für alle Funktionspointer und lokale Variablen in den Funktionen?
Naja, klingt nicht viel, aber wenn man drüber nachdenkt... Reicht wahrscheinlich für jedes Spiel locker aus.
Das heißt, wenn ich lokale Variablen verwende, werden die zwar im RAM gehalten aber im "Stack-Kontingent"?
und um nochmal auf meine sture denkweise zurückzukehren: Das heißt lokale Vars sind dynamisch und werden beim beenden der Funktion aus dem Stackspeicher gelöscht?

mfG und Danke, Christoph.

Gewinner des BCC 18, 33 und 65 sowie MiniBCC 9

	da_poller	Mi, Aug 20, 2008 18:36 Antworten mit Zitat
Eingeproggt hat Folgendes geschrieben: Das heißt lokale Vars sind dynamisch und werden beim beenden der Funktion aus dem Stackspeicher gelöscht? sicher sagen kann ich es nicht aber ich gehe davon aus da die variable nach der funktion =0 ist und daher wohl nciht existiert bzw beim abfagen neu erstellt wird.. lg poller

da_poller

Mi, Aug 20, 2008 18:36
Antworten mit Zitat

Eingeproggt hat Folgendes geschrieben:

Das heißt lokale Vars sind dynamisch und werden beim beenden der Funktion aus dem Stackspeicher gelöscht?

sicher sagen kann ich es nicht aber ich gehe davon aus da die variable nach der funktion =0 ist und daher wohl nciht existiert bzw beim abfagen neu erstellt wird..

lg poller

	ChristianK	Mi, Aug 20, 2008 19:12 Antworten mit Zitat
Eingeproggt hat Folgendes geschrieben: Das heißt lokale Vars sind dynamisch und werden beim beenden der Funktion aus dem Stackspeicher gelöscht? Der Stack funktioniert ja eigentlich nach First-In-First-Out Prinzip. Für lokale Variablen eignet sich das aber weniger, weil man sonst immer in umgekehrter Reihenfolge auf den Speicher zugreifen müsste, in der man die Variablen deklariert hat. Deshalb nutzt man (bzw der Compiler) den Stack-Pointer, der immer auf das oberste Byte im Stack zeigt. Zum Beispiel würde diese Funktion Code: [AUSKLAPPEN] [EINKLAPPEN] Function func(x, y) Local a a = x + y Return a End Function ungefähr so abgearbeitet werden: Code: [AUSKLAPPEN] [EINKLAPPEN] push = Variable auf Stack ablegen sp = Stack-Pointer Aufruf: push y (Position 1) push x (Position 2) Funktion: Variable a hat Position 3, sp ist jetzt auf Position 2 [sp+1] = [sp] + [sp-1] Return [sp+1] Hier wird der Stack aufgeräumt, indem der Stack-Pointer wieder auf die Ausgangsposition zurück gesetzt wird. sp = sp-2 Das ist jetzt vielleicht nicht ganz korrekt, aber so nach dem Prinzip funktioniert es. Man kann also mit dem Stack-Pointer und bestimmten Offsets jede lokale Variable/Parameter ansprechen. Aufgeräumt wird, indem man den Pointer so positioniert, wie er vor dem Aufruf der Funktion war.
AdvanceLcd Intel Core 2 Duo 3.2 GHz, 4 GB RAM, GeForce 8800 GTX \| MacBook Pro 15,4″ Intel Core 2 Duo 2.4 GHz, 2 GB RAM, GeForce 8600M GT

ChristianK

Mi, Aug 20, 2008 19:12
Antworten mit Zitat

Eingeproggt hat Folgendes geschrieben:

Das heißt lokale Vars sind dynamisch und werden beim beenden der Funktion aus dem Stackspeicher gelöscht?

Der Stack funktioniert ja eigentlich nach First-In-First-Out Prinzip. Für lokale Variablen eignet sich das aber weniger, weil man sonst immer in umgekehrter Reihenfolge auf den Speicher zugreifen müsste, in der man die Variablen deklariert hat. Deshalb nutzt man (bzw der Compiler) den Stack-Pointer, der immer auf das oberste Byte im Stack zeigt.

Zum Beispiel würde diese Funktion

Code: [AUSKLAPPEN]

Function func(x, y)
Local a
a = x + y

Return a
End Function

ungefähr so abgearbeitet werden:

Code: [AUSKLAPPEN]

push = Variable auf Stack ablegen
sp = Stack-Pointer

Aufruf:
push y (Position 1)
push x (Position 2)

Funktion:
Variable a hat Position 3, sp ist jetzt auf Position 2

[sp+1] = [sp] + [sp-1]
Return [sp+1]

Hier wird der Stack aufgeräumt, indem der Stack-Pointer
wieder auf die Ausgangsposition zurück gesetzt wird.
sp = sp-2

Das ist jetzt vielleicht nicht ganz korrekt, aber so nach dem Prinzip funktioniert es. Man kann also mit dem Stack-Pointer und bestimmten Offsets jede lokale Variable/Parameter ansprechen. Aufgeräumt wird, indem man den Pointer so positioniert, wie er vor dem Aufruf der Funktion war.

AdvanceLcd
Intel Core 2 Duo 3.2 GHz, 4 GB RAM, GeForce 8800 GTX | MacBook Pro 15,4″ Intel Core 2 Duo 2.4 GHz, 2 GB RAM, GeForce 8600M GT