Autor Thema: x86-64 Speicherverwaltung  (Gelesen 8395 mal)

Programm Noob

  • Gast
Gespeichert
« 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

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #1 am: 05. September 2010, 23:22 »
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

  • Gast
Gespeichert
« Antwort #2 am: 05. September 2010, 23:24 »
Ich benutze momentan unter 32 Bit ein statisches Array, weil wie gesagt dynamische sich nicht kompilieren lassen.

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #3 am: 05. September 2010, 23:28 »
Was verstehst du unter dynamischen Arrays?
Im Zweifelsfall würde ich empfehlen C/C++/Pascal zu lernen. ;-)

Programm Noob

  • Gast
Gespeichert
« Antwort #4 am: 05. September 2010, 23:31 »
Ich verstehe unter einem Dynamischen Array
uint32_t speicher;
uint32_t array[speicher];


kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 05. September 2010, 23:33 »
Mach ein uint32_t* array und allozier den Speicher zur Laufzeit.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Programm Noob

  • Gast
Gespeichert
« Antwort #6 am: 05. September 2010, 23:41 »
OK daran hab ich noch nicht gedacht. Die idee ist nicht schlecht das setze ich morgen mal um.

Programm Noob

Programm Noob

  • Gast
Gespeichert
« Antwort #7 am: 06. September 2010, 00:00 »
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

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #8 am: 06. September 2010, 11:12 »
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?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 06. September 2010, 11:54 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 06. September 2010, 12:34 »
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

  • Gast
Gespeichert
« Antwort #11 am: 06. September 2010, 13:49 »
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

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 06. September 2010, 14:05 »
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
Reality is that which, when you stop believing in it, doesn't go away.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #13 am: 06. September 2010, 14:20 »
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.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 06. September 2010, 14:21 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #15 am: 06. September 2010, 14:29 »
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ß

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #16 am: 06. September 2010, 14:34 »
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).
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

Programm Noob

  • Gast
Gespeichert
« Antwort #17 am: 06. September 2010, 14:38 »
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

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #18 am: 06. September 2010, 14:40 »
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

  • Gast
Gespeichert
« Antwort #19 am: 06. September 2010, 14:41 »
Gut. Das mit dem rückgabewert, da habe ich nicht drauf geachtet.

 

Einloggen