Lowlevel
Lowlevel => OS-Design => Thema gestartet von: hackgod am 11. May 2005, 17:42
-
Hab mir gestern dieses Kernel Tutorial unter osdever.net angeguckt
(das was an erster stelle unter tutorials steht).
Nun meine Frage: der Typ hat die GDT und die IDT unter C definiert,
hier werden diese aber in Assembler definiert. Wieso? Bringt das einen
Geschwindigkeits-Bonus oder weswegen?
mfg
hackgod
-
Letztendlich wird C ja auch in Asm übersetzt;)
Ist mehr oder weniger Geschmackssache
-
also macht das keinen großen unterschied? dann mach ich das mit C,
dann is die Implentierung leichter zu verstehen :wink:
-
Die Compiler optimieren meist so gut, dass bei so kleinen Teilen nicht viel an Speed zu holen sein wird durch reines ASM
-
also macht das keinen großen unterschied? dann mach ich das mit C,
dann is die Implentierung leichter zu verstehen :wink:
Abgesehen das die meisten die wohl eh nur einmal beim Start setzen.
-
bei callgates kann es vorkommen dass man die manchmal umbelegt, wenn man die nicht benutzt dann braucht mans wirklich nur am Anfang.
-
hmm jetzt bin ich am grübeln...
beim idt-teil benutzt er in der funktion idt_install eine funktion memset.
nun weiss ich nich ob die weg muss wenn ich paging benutzen will oder
ob das nichts ausmacht.
so wie es aussieht is das bloss eine funktion
um einen bestimmten bereich mit einem bestimmten wert zu füllen.
hier der teil aus der main.c ohne implentierung:
unsigned char *memset(unsigned char *dest, unsigned char val, int count)
{
/* Add code here to set 'count' bytes in 'dest' to 'val'.
* Again, return 'dest' */
}
Nun hab ich bedenken ob das beim paging später stören könnte. Ich
probiers eben aus, aber bitte eben eine meinung zu meinen bedenken.
mfg
hackgod
-
Memset ist auch in jeder C Library vorhanden, die Funktion dürfte wohl Paging-erprobt sein! ;)
-
Genau. Und die wird auch unter Windows noch verwendet, um zum Beispiel den Inhalt einer kompletten Struktur mit 0 zu füllen.
-
scheisse. bochs macht jetzt zicken. folgendes steht in der bootlog.txt:
00000981354e[CPU ] load_seg_reg: GDT: ES: index(0200) > limit(000017)
00000981354e[CPU ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
was soll das bedeuten?
-
Ich würde sagen du versuchst nen Selektor zu laden der nicht innerhalb der definierten Grenzen der GDT liegt
-
was mich wundert ist, dass dieser fehler erst aufgetreten ist, nachdem ich
ISRs für die exceptions eingefügt hab. selbst das auskommentieren der
funktion hilft nich. für mich siehts aus, als wenn ein index(welcher denn?)
über einem limit(welches???) liegt. aber ich hab echt keinen plan woran
das liegen könnte. die deskriptoren nutzen den ganzen 4 GB Adressraum
und starten bei 0(wie in TeeJays PM-Tutorial).
Oh mann, gestern klappte es noch ohne probleme....
-
der DESKRIPTOR scheint ausserhalb der grenzen der gdt zu liegen das was du bei base und limit für LGDT machst^^
-
Soll ich eben den Code posten? Ich komm da echt nich hinter. Die
Deskriptoren liegen dem Code nach innerhalb der GDT. Ich dachte nur
zum besseren Verständnis die ganzen GDT-Funktionen zu posten.
-
gdt.h:
struct gdt_entry
{
unsigned short limit_low;
unsigned short base_low;
unsigned char base_middle;
unsigned char access;
unsigned char granularity;
unsigned char base_high;
} __attribute__((packed));
struct gdt_ptr
{
unsigned short limit;
unsigned int base;
} __attribute__((packed));
gdt.c:
#include <gdt.h>
struct gdt_entry gdt[3];
struct gdt_ptr gp;
extern void gdt_flush();
void gdt_set_gate(int num, unsigned long base, unsigned long limit, unsigned char access, unsigned char gran)
{
gdt[num].base_low = (base & 0xFFFF);
gdt[num].base_middle = (base >> 16) & 0xFF;
gdt[num].base_high = (base >> 24) & 0xFF;
gdt[num].limit_low = (limit & 0xFFFF);
gdt[num].granularity = ((limit >> 16) & 0x0F);
gdt[num].granularity |= (gran & 0xF0);
gdt[num].access = access;
};
void gdt_install()
{
gp.limit = (sizeof(struct gdt_entry) * 3) - 1;
gp.base = &gdt;
gdt_set_gate(0,0,0,0,0);
gdt_set_gate(1,0,0xFFFFFFFF,0x9A,0xCF);
gdt_set_gate(2,0,0xFFFFFFFF,0x92,0xCF);
gdt_flush();
};
kernel32.asm:
global _gdt_flush
extern _gp
_gdt_flush:
lgdt [_gp]
mov ax, 0x10
mov ds, ax
mov es, ax
mov fs, ax
mov gs, ax
jmp 0x08:flush2
flush2:
ret
Das sind jetzt nur die GDT-Funktionen. Ich bin echt am verzweifeln. Keine
Ahnung wo der Fehler liegen kann.