Speicherzugriffe & Zeigerspielchen...

[fat-lobyte]

Also zum Thema malloc() kann ich dir sagen, dass es einen Ziemlich guten Algorithmus in der glibc gibt.
Er hat eigentlich keinen Namen, wird allerdings "Doug Lea's malloc()" genannt: http://g.oswego.edu/dl/html/malloc.html

Er funktioniert mithilfe von "Bins", die Zeiger auf Listen von Speicherblöcken halten, die die passende Größe haben. Hier kannst du dir wirklich die Tatsache ausnutzen, dass die glibc Open Source ist: Lade dir eine Kopie herunter, und sieh mal im source in die datei malloc/malloc.c. Dort ist nicht nur der Quellcode, sondern eine recht detaillierte beschreibung des Algorithmus.
Empfehlen würde ich allerdings nicht die neueste Version, die ist nämlich mit 64 bit Code, Multithreading Sicherheit und zusätzlichen validierungschecks vollgestopft. Am besten bei google.com/codesearch nach "mALLOc" suchen, und dann eine Ältere Version ( <= 2.1 ) anschaun.

[Dirty Oerti]

Tag!

Wo willst Du es denn haben?

Die GDT und die IDT sowie ein paar grundlegende Funktionen möchte ich im unteren Bereich des Speichers legen.
(Von 0 bis 640 KB). Diesen Teil sperre ich dann komplett gegen Zugriffe (ich lass ihn einfach nicht vom MemoryManager verwalten).

Das wäre quasi eine FAT, die das Dateisystem.

Eine FAT? Könnte mich erinnern, dass das anders funktioniert.
Wie ich das mit der Bitmap meine:

Bitmap: (angezeigt werden einzelne Bits)

0001010111011110111
1101011111100000001
1111111111111111011
1100000000000000000
0000000001110000000

usw.

0 bedeutet frei, 1 bedeutet belegt.
Ganz simpel und relativ schnell (bei kleinen Bitmaps)

"Doug Lea's malloc()"

Ja, den kenn ich. Bzw ich hab schon was davon gehört.
Und der soll so schnell sein?
Das ist gut zu wissen...
Danke!

[fat-lobyte]

"Doug Lea's malloc()"

Ja, den kenn ich. Bzw ich hab schon was davon gehört.
Und der soll so schnell sein?
Das ist gut zu wissen...
Danke!

Nein, der ist eigentlich alles andere als schnell
Aber er ist ziemlich Speichersparend und verhindert Fragmentierung, ist also recht robust. Andererseits, so langsam ist er auch nicht (Spezialfälle werden gut ausgenutzt).

[Dirty Oerti]

Schnell für das, was er kann

[Dirty Oerti]

So..ich bin dabei es zu versuchen.
Aber irgendwie will das nicht so recht.
Kann sein, dass ich irgendwie aufm Schlauch stehe oder so, aber es will einfach nicht funktionieren.

Die Struktur muss im Speicher folgendermaßen aussehen:

http://wiki.osdev.org/images/5/53/Gdt_entry.png

Hier mein Code:

Code: Alles auswählen

void _gdt_set_gate(int num, unsigned long base, unsigned long limit, unsigned char access, unsigned char gran)
{
    char *C_entry =&Zgdt + num*8 -1;
    short size_uchar = sizeof(unsigned char);//1
    short size_ushort = sizeof(unsigned short);//2

    //Limit low
    memcpy(C_entry,(limit & 0xFFFF),size_ushort);
    C_entry ++;
    //base low
    memcpy(C_entry,(base & 0xFFFF),size_ushort);
    C_entry ++;
    //base middle
    memcpy(C_entry,((base >> 16) & 0xFF),size_uchar);
    C_entry ++;
    //access
    memcpy(C_entry,(access),size_uchar);
    C_entry ++;
    //granularity
    memcpy(C_entry,(((limit >> 16) & 0x0F)|(gran & 0xF0)),size_uchar);
    C_entry ++;
    //base high
    memcpy(C_entry,((base >> 24) & 0xFF),size_uchar);
    C_entry ++;
}

Fehlerbeschreibung ist kurz: Er startet neu (normales Verhalten bei einem Fehler in diesem Bereich).

Wenn ihr zusätzliche Infos braucht...nur raus damit.

MfG
Daniel

[Dirty Oerti]

Um nicht an der Stelle stecken zu bleiben, wird momentan folgendes in Kernel (dort, wo ich all das brauch) getan:

Es wird eine GDT erstellt.
Diese wird per "memcpy" an die Stelle 0 geschrieben.

Nachteil: Es wird doppelter Speicher für die GDT benötigt (Einmal die GDT, die zusammengebastelt wird und dann noch ihre Kopie, die auch wirklich dann verwendet wird).
Außerdem muss eine Änderung der GDT immer in die Kopie übertragen werden.
Heißt: Mehr zu tun => längere Zeit