Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: Programm Noob am 05. September 2010, 23:19
-
Moin
Nachdem Ich vorhin gesehen habe, das wenn ich mir für die Physische Speicherverwaltung ein statisches Array anlege, 512 GB Physischen RAM bräuchte, was natürlich viel zu viel ist.
Dynamische Arrays sorgen immer für kompiler Fehler, daher die Frage:
Wie verwalte ich am besten den Physischen Speicher unter x86-64?
Programm Noob
-
Naja ein statisches Array ist eh unabhängig von der Breite des Adressbusses keine gute Idee. Und wenn dein Code nicht kompiliert hat das vermutlich auch eher wenig mit der Plattform zu tun. Du kannst mit auf 64-Bit-Systemen natürlich genau die selben Methoden zur Speicherverwaltung benutzen wie beispielsweise mit 32-Bit auch.
-
Ich benutze momentan unter 32 Bit ein statisches Array, weil wie gesagt dynamische sich nicht kompilieren lassen.
-
Was verstehst du unter dynamischen Arrays?
Im Zweifelsfall würde ich empfehlen C/C++/Pascal zu lernen. ;-)
-
Ich verstehe unter einem Dynamischen Array
uint32_t speicher;
uint32_t array[speicher];
-
Mach ein uint32_t* array und allozier den Speicher zur Laufzeit.
-
OK daran hab ich noch nicht gedacht. Die idee ist nicht schlecht das setze ich morgen mal um.
Programm Noob
-
Warum gehen dynamische Array, also so wie ich es oben geschrieben habe nicht? Die Metode so mit dem Array finde ich nämlich sehr schön.
Programm Noob
-
Weil dynamische Arrays nur auf dem Stack gehen, d.h. als nicht-static Definition innerhalb einer Funktion. Wie soll das auch sonst funktionieren? Wird da plötzlich der Heap deines Kernels ohne das du dafür Funktionen zur Verfügung stellst größer?
-
Bevor es für Verwirrung sorgt: Globale Variablen liegen nicht auf dem Heap, sondern in .data/.rodata/.bss und sind Teil der Binary. Der Compiler hat vom Heap keine Ahnung, der kommt erst mit malloc/free ins Spiel.
-
Woher soll der Compiler zur Compilezeit wissen, welche Zahl in "speicher" drin steht? Bedenke, dass dein Code zur Compilezeit umgesetzt wird, nicht zur Laufzeit.
Zur Laufzeit werden Funktionen wie malloc() ausgeführt.
Ich wiederhole taljeths Vorschlag, erstmal C zu lernen.
-
Ich kann C. aber irgendwann wurde im IRC mal gesagt, das bei C99 dynamische Arrays gehen würden. Ich setze gerade taljeth's Vorschlag um.
-
Hallo,
Ich kann C.
Soll das jemand kommentieren? ;)
aber irgendwann wurde im IRC mal gesagt, das bei C99 dynamische Arrays gehen würden
Der nächste C-Standard soll VLA unterstützen aber damit ist gemeint das innerhalb von Funktionen, also auf dem Stack-Frame, Arrays mit variabler Länge, z.B. in Abhängigkeit eines Funktions-Parameters, angelegt werden dürfen. Damit stehen dann dem Stack-Overflow die Türen wieder weit offen, da möchte ich an meinen Exploit von http://forum.lowlevel.eu/index.php?topic=2224.msg25456#msg25456 (http://forum.lowlevel.eu/index.php?topic=2224.msg25456#msg25456) erinnern.
Zur Compile-Zeit geht das einfach nicht, das sollte doch offensichtlich sein! Die Länge von statischen Arrays muss auch statisch sein, also zur Compile-Zeit bekannt und zur Laufzeit unveränderbar!
Grüße
Erik
-
aber irgendwann wurde im IRC mal gesagt, das bei C99 dynamische Arrays gehen würden
Der nächste C-Standard soll VLA unterstützen aber damit ist gemeint das innerhalb von Funktionen, also auf dem Stack-Frame, Arrays mit variabler Länge, z.B. in Abhängigkeit eines Funktions-Parameters, angelegt werden dürfen.
Nein, der momentane C-Standard (C99) unterstützt das bereits, siehe auch gcc docu (http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html).
-
Der nächste C-Standard soll VLA unterstützen aber damit ist gemeint das innerhalb von Funktionen, also auf dem Stack-Frame, Arrays mit variabler Länge, z.B. in Abhängigkeit eines Funktions-Parameters, angelegt werden dürfen.
In welchem Jahr lebst du, erik? C99 kann das.
-
Also nach dem Link geht sowas trotzdem nicht, wenn ich grad nichts übersehe:
int blubber(char* s)
{
int x;
x = strlen(s);
char neu_s[x];
printf("%s\n", neu_s);
return x;
}
Neu ist, dass der Ausdruck nicht mehr zur compilezeit bekannt sein muss, es reicht, wenn er beim Sprung in die Funktion bekannt und konstant ist. Also etwas ausrechnen und dann ein dynamisches Array der entsprechenden Größe erzeugen lassen geht trotzdem nur mit malloc() oder so.
Gruß
-
Das geht sehr wohl noch. Ist ja im Prinzip exakt das Beispiel auf der Seite... Der Ausdruck muss auch nicht beim Sprung in die Funktion bekannt sein (abgesehen von VLAs als Funktionsargumente).
Es wird einfach zu dem Zeitpunkt der Definition des VLAs Speicher auf dem Stack reserviert. Ab diesem Zeitpunkt kann sich die Größe des Arrays allerdings natürlich auch nicht mehr ändern (insofern ist es nach m.E. kein dynamisches Array, wie beispielsweise std::vector).
-
Dann könnte man doch einfach eine Funktion machen, die einem das Arry erstellt und die adresse zurückgibt.
uint32_t *make_array(size_t n)
{
uint32_t array[n]
return &array;
}
int main(void)
{
int i = 234;
int size = i + 40;
uint32_t *array = make_array((size_t)size);
printf("Array Adresse: %x\nArray größe:%d\n", array , size);
}
Oder würde das nicht gehen?
Programm Noob
-
Das ist grad doppelt falsch. Erstens hat &array den typ uint32_t**, und zweitens ist es keine gute Idee, einen Zeiger auf eine lokale Variable zurück zu geben, da dieser Speicher ja eben nur im Block gültig ist, in dem er angefordert wurde.
-
Gut. Das mit dem rückgabewert, da habe ich nicht drauf geachtet.
-
@Programm Noob
Das ist jetzt nicht böse gemeint, aber anstatt C zu lernen, solltest du dich mal mit Assembler beschäftigen!
Spätestens wenn du verstanden hast wie ein Stack und damit auch dein C-Code funktionieren, weißt du das dein Bsp., ich sags mal nett, nicht funktionieren kann!
-
Dazu würde es eigentlich reichen, wenn man liest, was die gcc Doku (wie oben gelinkt) dazu sagt:
The storage is allocated at the point of declaration and deallocated when the brace-level is exited. [...] Jumping or breaking out of the scope of the array name deallocates the storage. [...]
-
Hallo,
Der nächste C-Standard soll VLA unterstützen ....
In welchem Jahr lebst du, erik? C99 kann das.
Okay, Du hast recht. Ist das wirklich von Anfang an im C99-Standard mit drin gewesen (also seit 1999) oder ist das erst mit einem der 3 TCs später dazu gekommen? Die aktuelle C99-Spezifikation ist von 2007.
Einige Compiler können VLAs bis heute nicht.
Grüße
Erik
-
Einige Compiler können VLAs bis heute nicht.
Soweit ich mich erinnere wollte Microsoft den C99 Standard nicht unterstützen in ihren Compilern. Ob sich das mittlerweile geändert hat, weiß ich ehrlich gesagt nicht. Und die Leute bei gcc sind ja auch noch nicht vollständig kompatibel, siehe hier (http://gcc.gnu.org/c99status.html).