Nachrichten

81

OS-Design / Memory Management

« am: 13. December 2004, 21:03 »

Aber, wieso ist die "Linked"-Liste schneller?

Allgemein schnell. Damit meinte ich Memory Management mit einer linked-list.

Wenn man das ganze in eine "Vector"-Klasse steckt, kann ich die Liste auch dynamisch vergrößern und verkleiner

Ja, wenn du immer kontinuierlich hinternander Pages frei hast...

MfG GhostCoder[/quote]

82

Lowlevel-Coding / BMP Laden ...

« am: 13. December 2004, 20:55 »

rtfm

83

Offtopic / Lizenzen

« am: 13. December 2004, 20:53 »

Ich kümmer mich eigentlich ziemlich wenig um diesen Lizenzkram...
Von mir aus, kann jeder mit jedem Code machen, was er will, solange
der den Author nennt und würdigt.
Und natürlich der Code nur im Sinne des Authors verwendet wird.
Und das nenn ich jez die GhostCoder Licence (GCL)

Sorry, dass musste einfach sein...,

MfG GhostCoder

84

Lowlevel-Coding / C-Funktionen...

« am: 12. December 2004, 17:44 »

Wird den überhaupt was ausgegeben, wenn du wie ein verrückter nach 0xA0000 schreibst?
Ansonsten kann ich dir net helfen, mit Video mach ich im Moment noch nichts...

MfG GhostCoder

85

Lowlevel-Coding / C-Funktionen...

« am: 12. December 2004, 16:37 »

@Roshl:

Nee, der Code ist schon richtig, da nach dem PutChar Aufruf nichts mehr kommt, kann er auch direkt zu PutChar springen, und das ret von PutChar springt dann zurück zu dem Punkt, nach dem "call _main". Sieht wie ne kleine Optimierung aus. Schreib doch mal hinter dem PutChar aufruf

Code: [Auswählen]


asm("cli\n\thlt")


Was passiert den dann?

MfG GhostCoder

86

OS-Design / Memory Management

« am: 12. December 2004, 16:29 »

@sp:

das Problem bei dir ist, das bei 1000 malloc's Schluß ist, und der Table direkt 12kb frisst. Außerdem dauert es z.B. wenn du z.B. das 999zigste Mal malloc aufrufst, total lange bis du durch alle vorhandenen Blöcke durch bist. Musst ja bedenken, das du später noch 2 Layer(Block und vm) darunter liegen hast, die auch Zeit brauchen. Außerdem, wenn du z.B. den 500sten Block freigibst, müssen wenn das nächste mal der 500er Block benutzt werden soll, und der Block mehr/weniger Speicher als der vorherige 500ste Block braucht, alle folgenden Blöcke geändert (und derInhalt verschoben) werden.

Ne linked-list ist also schon das beste(und schnellste)...

MfG GhostCoder

87

Lowlevel-Coding / Paging und Multitasking

« am: 12. December 2004, 13:29 »

Hiho,

das mit der gdt/idt hab ich schon probiert, bringts nichts. Aber, muss der Scheduler auch reingemappt werden? Oder zeigt der Eintrag in der IDT auf ne physikalische Addresse?

MfG GhostCoder

88

OS-Design / Multitasking

« am: 12. December 2004, 13:26 »

Hiho,

mein Paging Directory ist ja nicht an einer festen Stelle, daher kamen die Probleme, aber hab das jetzt so gelöst, das ich die OpCodes passend überschreibe, ist ja auch kein Problem... Vielleicht änder ich das mal...

Ja, ist schon klar das das pg-dir an ner linearen Addresse liegt, wäre sonst auch irgendwie "komisch"

Aber sonst läuft mein Code ziemlich gut und schnell. Endlich!
MfG GhostCoder

89

OS-Design / Memory Management

« am: 12. December 2004, 13:22 »

Hiho,

so mache ich das ja auch...
Hast du auch schon die Aufräumfunktion für den Heap?

MfG GhostCoder

90

Lowlevel-Coding / Paging und Multitasking

« am: 11. December 2004, 23:41 »

Hiho,

ich hab bei mir jetzt Paging und Multitasking (die höllische Kombination ) soweit am laufen. Nur zwei Probleme gibt es noch...

1. Userprozesse laufen nur, wenn der KernelCode (1mb-4mb) in den Addressraum gemappt ist, woran kann das liegen? Was wird alles durch Paging beeinflußt? GDT? IDT? Scheduler? usw...

2. Wenn Userprozesse nicht cs=8 und ds=16 bekommen, krieg ich immer die "Fehlermeldung" CPL != DPL. Woran kann das liegen?

MfG GhostCoder

91

Lowlevel-Coding / Deskriptor

« am: 11. December 2004, 19:50 »

Code: [Auswählen]


void idt_Init()
{
psIDT=(struct IDT*)KernelAlloc(sizeof(struct IDT)*IDT_COUNT);

DWORD dwDesc[2]={(sizeof(struct IDT)*IDT_COUNT) << 16,(DWORD)psIDT};
char *ptr=(char*)dwDesc+2;

memset(psIDT,0,sizeof(struct IDT)*IDT_COUNT);
asm("lidt (%0)"::"r"(ptr));
}


MfG GhostCoder

92

Lowlevel-Coding / Deskriptor

« am: 11. December 2004, 13:14 »

Ups, du meintest die Macroversion...
Sorry, hab mich verlesen!

Die muss TeeJay dann aber erklären!

MfG GhostCoder

93

Lowlevel-Coding / Deskriptor

« am: 11. December 2004, 13:12 »

Hiho,

also als erstes definierst du wie der Deskriptor aussehen soll (hier meine idt)

Code: [Auswählen]


struct GATE
{
WORD wOffset0_15;
WORD wSelector;
WORD wFlags;
WORD wOffset16_31;
};


Danach kommen die Flags, das heißt(welches Bitmuster entsteht, wenn das PRESENT bit gesetzt ist.

Code: [Auswählen]


#define IDT_PRESENT  0x8000
#define IDT_TRAP     0x0700
#define IDT_INT      0x0600
#define IDT_TASK     0x0500
#define IDT_32       0x0800
#define IDT_DPL0     0x0000
#define IDT_DPL1     0x2000
#define IDT_DPL2     0x4000
#define IDT_DPL3     0x6000


Dann die realisierung:

Code: [Auswählen]


void idt_SetGate(DWORD dwIndex,WORD wSelector,DWORD dwOffset,WORD wFlags)
{
asGates[dwIndex].wOffset0_15=dwOffset & 0xFFFF;
asGates[dwIndex].wOffset16_31=(dwOffset >> 16) & 0xFFFF;
asGates[dwIndex].wSelector=wSelector;
asGates[dwIndex].wFlags=wFlags;
}


Wenn du jetzt die Funktion aufruft, verkmüpfst du die o.g. flags einfach mit einem binären oder. also z.b.

Code: [Auswählen]


idt_SetGate(0x20,8,__scheduler,IDT_PRESENT | IDT_32 | IDT_INT | IDT_DPL0);


So einfach geht das...

MfG GhostCoder

94

OS-Design / Memory Management

« am: 11. December 2004, 13:05 »

Hiho,

da bin ich wieder

Also, bei mir hab ich ein ziemlich einfaches Heap System eingebaut. Erstmal die HEAP struct:

Code: [Auswählen]


struct HEAP
{
    DWORD dwFlags;
    DWORD dwSize;
    DWORD dwPageSize;
    struct HEAP *psNext;
};

Es funktioniert also wie eine einfach verkettete Liste. Wenn du jetzt mittels HeapAlloc Speicher haben willst, durchsucht die Funktion alle vorhandenen Blöcke, und schaust ob zwischen dwPageSize und dwSize genug Platz ist, eine neue Heapstruct+Speicher anzulegen, soll heißen, wenn ein Block noch Speicher hat, den zu nutzen. Wird da nichts gefunden, wird nach nicht gesuchten Blöcken gesucht(mittels dwFlags,dazu später). Wird auch da nichts gefunden, werden einfach die passendene Anzahl Pages (VirtualAlloc) geholt, am Anfang der Pages wird die struct geschrieben, und der Heapspeicher folgt danach. Zurückgegeben wird dann immer

Code: [Auswählen]


(void*) (psHeap+sizeof(struct HEAP));


HeapFree setzt die Flags des Blockes (die Heapstruct liegt ja direkt vor dem Heapbuffer) auf Null.

Als letzte Funktion gibt es noch HeapClean (unter Win32 heißt die ein bisschen anders), und die räumt einfach alle unbenutzten Blöcke auf(gibt deren Speicher frei, und löscht sie aus der Liste). Und hier krankt mein Ansatz, der ganze Vorgang ist ziemlich schwer zu realisieren, hab die Funktion auch noch nicht implementiert...

Ein anderer Ansatz wäre, eine verkettete Liste aus Pages zu machen. Also, wenn eine Page 4096 Bytes fasst, und die Heapstruct 16 Byte groß ist, kann man ja 255 heapstructs + prev/next zeiger in eine Page packen, und darüber die Heapblöcke verwalten... Die heapstruct müsste dann nurnoch über einen blockzeiger erweitert werden. Der Vorteil wäre, das die HeapClean Funktion jetzt viel einfacher zu realisieren wäre, Nachteil aber, das es lange dauert, bis man zu einem Zeiger(von HeapAlloc zurückgegeben) die passende Heapstruct findet (Alle heap pages durchgehen, und vergleichen...). Musst du selber entscheiden, welche Variante du wählst, wobei meine Ansätze doch eher einfach sind, gibt noch viele andere Prinzipe...

Wichtig ist nurnoch das die Heap Funktionen als libs in Userprozesse eingebunden werden, das einzige Kernelinterface für Speicher sollten die VirtualAlloc,VirtualFree,... Funktionen sein, damit einige Programme( wie .z.b viele aktuelle Spiele) ihre eigenen, schnelleren Heap Funktionen nutzen können!

Hoffe, es ist einigermaßen verständlich geworden...
MfG GhostCoder

95

Lowlevel-Coding / Sectoren laden - Problem

« am: 11. December 2004, 12:35 »

Kein Problem immer wieder gerne,

solange es jetzt funktioniert...

96

Lowlevel-Coding / PIC und aktueller IRQ

« am: 11. December 2004, 12:33 »

Hiho,

soweit ich weiß, musst du für jeden int einen eigenen Handler schreiben, die können aber z.B. alle einen Handler aufrufen, der als Parameter die int nr. hat. In nasm läßt sich das gut über Macros realisieren...

MfG GhostCoder

97

OS-Design / Memory Management

« am: 10. December 2004, 20:34 »

Hiho,

ich hab bei mir die Speicherverwaltung folgendermaßen realisiert:

Unterste Schicht ist der Blockallocator, der eine(!) physikalische Page zurückgibt. Das hab ich über eine Stack gelöst.

Danach kommt die Schicht für virtuelle Pages. Die Funktionen reservieren im virtuellen Addressraum Pages, und mappen die (wenn gewünscht) mittels dem Blockallocator auf physikalische Pages. Ne passende Win32 Funktion hierfür wäre VirtualAlloc/VirtualFree.

und wie malloc/free funktioniert erkläre ich nachher, habe jetzt keine Zeit mehr, sonst bringt mich meine Freundin um Wobei das mit dem Header schon richtig ist...

MfG GhostCoder

98

OS-Design / Multitasking

« am: 10. December 2004, 20:28 »

Hiho,

das Problem tritt ja erst auf, wenn du Paging an hast. Das du den passenden Codeselektor hast, ist klar, und ds kann man ja auch einfach setzen...

Aber du musst ja, während du noch im Speicherbereich des Prozesses bist, den Wert vom Kernel cr3 (Paging Directory) finden, dann setzen, danach den Scheduler Code ausführen, und dann wieder cr3 des neuen Prozesses setzen.

Eigentlich könnte man gut dafür tss benutzen, sonst kann man noch den OpCode finden, der cr3 setzt, und dann einfach den Parameter setzen, also z.B. suchste nach 0x12345678, wenn du als Dummy im Scheduler

Code: [Auswählen]


mov eax,0x12345678
mov cr,eax


Was jetzt aber schneller, und effizienter ist, weiß ich noch nicht. Aber wahrscheinlich nehme ich Methode 2...

MfG GhostCoder

99

Lowlevel-Coding / Deskriptor

« am: 10. December 2004, 13:17 »

Find ich schon, siehe oben...

100

Lowlevel-Coding / Sectoren laden - Problem

« am: 10. December 2004, 13:15 »

Hiho,

ehrlich gesagt hab ich Moment keine Lust mich durch den Code zu wühlen
Aber irgendwie scheint es mir, das du int 0x13 falsch aufrust(Siehe al und ah vor dem int)...

MfG GhostCoder