Thema: x86-64 Speicherverwaltung

[Programm Noob]

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

[FreakyPenguin]

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.

[Programm Noob]

Ich benutze momentan unter 32 Bit ein statisches Array, weil wie gesagt dynamische sich nicht kompilieren lassen.

[FreakyPenguin]

Was verstehst du unter dynamischen Arrays?
Im Zweifelsfall würde ich empfehlen C/C++/Pascal zu lernen.

[Programm Noob]

Ich verstehe unter einem Dynamischen Array
uint32_t speicher;
uint32_t array[speicher];

[kevin]

Mach ein uint32_t* array und allozier den Speicher zur Laufzeit.

[Programm Noob]

OK daran hab ich noch nicht gedacht. Die idee ist nicht schlecht das setze ich morgen mal um.

Programm Noob

[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

[bluecode]

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?

[kevin]

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.

[Svenska]

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.

[Programm Noob]

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.

[erik.vikinger]

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 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

[bluecode]

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.

[kevin]

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.

[Svenska]

Also nach dem Link geht sowas trotzdem nicht, wenn ich grad nichts übersehe:

Code: [Auswählen]

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ß

[bluecode]

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).

[Programm Noob]

Dann könnte man doch einfach eine Funktion machen, die einem das Arry erstellt und die adresse zurückgibt.

Code: [Auswählen]

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

[FreakyPenguin]

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.

[Programm Noob]

Gut. Das mit dem rückgabewert, da habe ich nicht drauf geachtet.