Nachrichten

41

OS-Design / Global Descriptor Table (GDT)

« am: 23. March 2012, 15:16 »

Hallo Leute!

Ich hab da ein Problem mit der GDT.

Code: [Auswählen]

static void Gdt_SetEntry(uint32 index, uint32 base, uint32 limit, uint8 access,
uint8 gran) {
gdt.entry[index].base_low = (base & 0xFFFF);
gdt.entry[index].base_middle = (base >> 16) & 0xFF;
gdt.entry[index].base_high = (base >> 24) & 0xFF;

gdt.entry[index].limit_low = (limit & 0xFFFF);
gdt.entry[index].granularity = (limit >> 16) & 0x0F;

gdt.entry[index].granularity |= gran & 0xF0;
gdt.entry[index].access = access;
}

static void Gdt_InstallEntries() {
gdt_ptr.limit = (sizeof(gdt_entry) * GDT_ENTRIES) - 1;
gdt_ptr.base = (int) &gdt.entry[0];

Gdt_SetEntry(0, 0, 0, 0, 0);
Gdt_SetEntry(1, 0, 0xFFFFFFFF, 0x9A, 0xCF);
Gdt_SetEntry(2, 0, 0xFFFFFFFF, 0x92, 0xCF);
Gdt_SetEntry(3, 0, 0xFFFFFFFF, 0xFA, 0xCF);
Gdt_SetEntry(4, 0, 0xFFFFFFFF, 0xF2, 0xCF);

dprint("[GDT] sizeof gdt_entry %d Bytes", sizeof(gdt_entry));
dprint("[GDT] gdt_ptr.base 0x%X", gdt_ptr.base);
dprint("[GDT] gdt_ptr.limit 0x%X (GDT size %d Bytes)", gdt_ptr.limit, gdt_ptr.limit + 1);
dprint("[GDT] entry 1 0x%X", &gdt.entry[0]);
dprint("[GDT] entry 2 0x%X", &gdt.entry[1]);
dprint("[GDT] entry 3 0x%X", &gdt.entry[2]);
dprint("[GDT] entry 4 0x%X", &gdt.entry[3]);
dprint("[GDT] entry 5 0x%X", &gdt.entry[4]);

Gdt_Flush((uint32) &gdt_ptr);

dprint("[GDT] Returning from Gdt_Flush()");
}

global Gdt_Flush
Gdt_Flush:
mov eax, [esp+4] ; Get the pointer to the GDT, passed as parameter
lgdt [eax] ; Load new GDT Pointer

mov ax, 0x10 ; 0x10 is the offset in the GDT to out data segment
mov ds, ax ; Load all data segment selectors
mov es, ax
mov fs, ax
mov gs, ax
mov ss, ax
jmp 0x08:.flush ; 0x08 is the offset to our code segment: Far jump
.flush:
ret


Output:

Code: [Auswählen]

[GDT] Initializing GDT
[GDT] sizeof gdt_entry 8 Bytes
[GDT] gdt_ptr.base 0x102000
[GDT] gdt_ptr.limit 0x27 (GDT size 40 Bytes)
[GDT] entry 1 0x102000
[GDT] entry 2 0x102008
[GDT] entry 3 0x102010
[GDT] entry 4 0x102018
[GDT] entry 5 0x102020

Leider fehlt die letzte Zeile [GDT] Returning from Gdt_Flush(). Da dürfte
wohl etwas nicht funktioniert haben.

Da ich den Fehler nicht finden kann, wollte ich fragen ob jemand weiß was
ich falsch gemacht habe.

LG; nnosdev

42

OS-Design / Re: C oder C++

« am: 19. March 2012, 14:51 »

Aber ist man auf einer gewissen Ebene (nämlch auf einer sehr niedrigen) nicht irgendwo mal am Limit?
Es stellt sich die Frage, ob man an dieser Stelle wirklich auf Typensicherheit angewiesen ist.

new() soll ja jedes Objekt anlegen egal von welchen Typen. Da ist void* doch irgendwie passend, oder nicht?

43

Softwareentwicklung / Re: QEMU - Debug-Messages an Gastsystem schicken

« am: 19. March 2012, 14:36 »

Okay, es lag tatsächlich daran und jetzt seh ich auch, dass du das in deiner ersten Antwort scho geschrieben hast ...
Gut, das ist jetzt echt bitter.. 

Was muss man jetzt noch machen wenn jedes Byte sofort angezeigt werden soll das an COM1 geschickt wird?
Wenn ich das Programm starte, bekomme ich nicht sofort den Output. Würde das gerne in Echtzeit sehen..

44

Lyrisches Eck / Haustürklingel

« am: 19. March 2012, 13:27 »

Die Haustüklingel an der Wand,
der Mädchenbusen in der Hand,
sind beides Dinge wohlverwandt!

Denn,  wenn man eines leis' berührt
man innen drinnen deutlich spürt,
dass unten draußen einer steht,
der sehnsuchtsvoll nach Einlass fleht.

45

Softwareentwicklung / Re: Dokumentation

« am: 19. March 2012, 13:22 »

Das sieht gut aus, danke!

46

OS-Design / Re: C oder C++

« am: 19. March 2012, 13:21 »

Naja einmal korrekt implementiert müsste man dann nie mehr ein neues "new_xyz()"
schreiben oder nicht?

47

Softwareentwicklung / Re: QEMU - Debug-Messages an Gastsystem schicken

« am: 19. March 2012, 13:19 »

Naja es ist egal was ich schicke. Es kommt nichts an (bzw. es wird nichts im Terminal angezeig).

Code: [Auswählen]


// Mir würde es reicht wenn überhaupt mal etwas angezeigt wird :D

if (address != 0) {
for (b = 0; b < 100; b++)
outb(address, b); // Schickt an ein gefundenes COM-Port
}

*EDIT

Oder könnte es auch an QEMU liegen? Ich führe es mit

Code: [Auswählen]

qemu -kernel kernel
über ein Makefile aus.

48

Softwareentwicklung / Re: QEMU - Debug-Messages an Gastsystem schicken

« am: 19. March 2012, 01:01 »

Na klar!

Bin mir auch nicht ganz sicher, ob das so funktioniert wie ich mir das
gedacht hab ... ^^

Also diesmal mit Comments:

Code: [Auswählen]

unsigned int *ptraddr;
unsigned int address;

// BIOS Data-Area http://www.lowlevel.eu/wiki/BIOS_Data_Area
ptraddr = (unsigned int *) 0x00000400;

int a, b;

for (a = 0; a < 4; a++) {
address = *ptraddr;

// Wenn address != 0 dann ist das die Anfangsadresse
// des jew. COM-Portes
if (address != 0) {
for (b = 0; b < 100; b++)
outb(address, a); // Schickt an ein gefundenes COM-Port
}
*ptraddr++;
}

und hier nochmal die outb() Funktion:

Code: [Auswählen]


static inline void outb(uint16 port, uint8 val)
{
   __asm__ __volatile__ (
   "outb %b0, %w1"
   :
   : "a"(val), "d"(port));
}


49

OS-Design / Re: C oder C++

« am: 19. March 2012, 00:51 »

Okay, Templates sind sicherlich eine angenehme Sache. Aber jetzt auf die schnelle wüsste ich nichts
wo ich die tief im Kernel brauchen könnte. Scoped-Lock ist ein nettes Design-Pattern! Aber theoretisch liese sich das
einigermaßen simpel auch mit C realisieren.

Ich habe ein recht interessantes PDF im Netz gefunden.
Auf Seite 18 bzw. 19 kann man recht schnell sehen wie sich so etwas machen liese.
Das dürfe ganz im Sinne von taljeth sein, oder? ^^

50

Softwareentwicklung / Re: QEMU - Debug-Messages an Gastsystem schicken

« am: 18. March 2012, 23:32 »

Also ich hab das Tutorial gelesen und versucht das zum Laufen zu bekommen.

Aber leider scheint es nicht zu funktionieren.

Der folgende Code soll nur zeigen, wie ich Bytes an das Port
schicke. Ist das vom Prinzip her richtig?

Code: [Auswählen]

// ...
unsigned int *ptraddr;
unsigned int address;

ptraddr = (unsigned int *) 0x00000400;

int a, b;

for (a = 0; a < 4; a++) {
address = *ptraddr;

if (address != 0) {
for (b = 0; b < 100; b++)
outb(address, a);
}
*ptraddr++;
}
// ...


static inline void outb(uint16 port, uint8 val)
{
   __asm__ __volatile__ (
   "outb %b0, %w1"
   :
   : "a"(val), "d"(port));
}


51

Softwareentwicklung / Dokumentation

« am: 16. March 2012, 20:31 »

Kann mir jemand ein gutes Tool für die Dokumentation meiner Software empfehlen?
Es sollte natürlich gratis sein 

52

OS-Design / Re: C oder C++

« am: 19. February 2012, 14:52 »

Okay, also wirklich entscheiden kann ich mich jetzt nicht ^^

Persönlich tendiere ich nach wie vor eher zu C++ weil ich ganz einfach die Sprache "schöner" und nachvollziehbarer finde als C (ja, auch wenn man mit C dasselbe anstellen kann wie mit C++)

Eigentlich sollte euch doch allen klar sein C++ kann gar nicht viel besser sein als C:

Code: [Auswählen]

c == c++

Das hängt u.A vom Compiler ab ob C==C++ 

53

Softwareentwicklung / Re: QEMU - Debug-Messages an Gastsystem schicken

« am: 17. February 2012, 17:31 »

Also bin in dieser Geschichte noch blutiger Anfänger.. ^^

Hab hier was gefunden. Bin ich damit auf der richtigen Spur?

54

Softwareentwicklung / QEMU - Debug-Messages an Gastsystem schicken

« am: 17. February 2012, 13:15 »

Ich würde gerne (und ich weiß, dass es geht - nur nicht wie) Debug-Messages an das Gastsystem schicken.
Und zwar über die VM an mein Ubuntu-Terminal um genau zu sein.

Hat da jemand schon Erfahrung damit? Verzeiht mir falls man das auch googeln kann, ich hab darüber nichts gefunden.

55

OS-Design / Re: C oder C++

« am: 17. February 2012, 12:59 »

Wo es allerdings in Sachen "so tun, als gäbe es einen Zusammenhang" (was auch immer du damit meinst) einen Unterschied zwischen C und C++ geben sollte, kann ich im Moment nicht nachvollziehen.

Damit ist Code wie dieser gemeint ^^

Code: [Auswählen]

typedef struct
{
    int anzahlRaeder;
    char* hupTon;
    int geschwindigkeit;
}Auto;

void Auto_init(Auto *this, int anzahlRaeder, char* hupTon);
void Auto_fahre(Auto *this);
void Auto_hupe(Auto *this, int anzahl);

oder dieser..

Code: [Auswählen]

typedef struct
{
    Auto* pAuto;
}Garage;

void Garage_init(Garage *this);
void Garage_init2(Garage *this, Auto *pAuto);
void Garage_einparken(Garage *this, Auto *pAuto);
void Garage_ausparken(Garage *this);

Um auch noch mehr Senf loszuwerden, könnte ich noch anbieten, dass man in C nichtsdestotrotz auch objektorientiert programmieren kann – die Frage ist dann nur, ob man das will, mit Funktionspointern für Methoden, ohne impliziten this-Pointer und ohne so aparte¹ Sachen wie Konstrukturaufrufen mit new und Destruktoraufrufen mit delete.

Präprozessor to the rescue? 

Eben das wäre mir zu umständlich. Dann doch lieber C++

Das war nicht ernstgemeint. Ich würde den Präprozessor für diese Sachen nicht benutzen. Impliziter this-Pointer, new und delete sind Syntaxdetails. Mein C-Code muss nicht wie C++-Code aussehen. Ich kann den this-Pointer einfach explizit mitgeben und direkt Konstruktor und Destruktor statt new aufrufen.

Nun aber genau bietet C++ eben den Komfort von impliziten this-Pointern um die man sich nicht kümmern muss bzw.
der automatisierte Aufruf des Destructors bei lokalen Objekten die man in C "von Hand" zerstören müsste, oder?

Warum benützen wir nicht ganz normal das Wort fancy? Wir sagen doch auch "Manager" und nicht "Leiter" ^

Tun wir das? Du gehörst wohl auch zu den Leuten, die Laptop statt Klapprechner sagen?

Du hast mich erwischt Klapprechner ist auch gut ^^

56

OS-Design / Re: C oder C++

« am: 16. February 2012, 21:57 »

Ich persönlich steh ja absolut auf die Möglichkeit objektorientiert zu programmieren.

Geht mit C wunderbar.

Mir ist schon klar, dass man mit C objektorientiert programmieren kann. Aber in diesem Falle fällt die
Wahl dann wohl auf C++ da sie ja nicht nur so tut als Dinge einen Zusammenhang hätten wogegen
man in C schon mehr Aufwand betreiben muss um sauber objektorientiert zu programmieren.

Erstmal ist das ja sowieso eine Glaubensfrage. Wenn du C++ willst, dann solltest du den Kernel auch in C++ programmieren. So einfach ist das.

Und hinterher keinem anderen die Schuld dafür geben.

Also hältst du C++ eher für die falsche Wahl?

Um auch noch mehr Senf loszuwerden, könnte ich noch anbieten, dass man in C nichtsdestotrotz auch objektorientiert programmieren kann – die Frage ist dann nur, ob man das will, mit Funktionspointern für Methoden, ohne impliziten this-Pointer und ohne so aparte¹ Sachen wie Konstrukturaufrufen mit new und Destruktoraufrufen mit delete.

Präprozessor to the rescue? 

Eben das wäre mir zu umständlich. Dann doch lieber C++


Warum benützen wir nicht ganz normal das Wort fancy? Wir sagen doch auch "Manager" und nicht "Leiter" ^

57

OS-Design / C oder C++

« am: 15. February 2012, 21:55 »

Lasst mal was hören Leute ^^

Ich persönlich steh ja absolut auf die Möglichkeit objektorientiert zu programmieren.

Gibts ein paar Tipps bzw Ratschläge die einem helfen können für welche Sprache
man sich konkret entscheidet?

58

Softwareentwicklung / Re: OS-Dev mit Intelassembler

« am: 15. February 2012, 21:51 »

Ich hab mich ebenfalls für die Intel-Syntax entschieden:

Code: [Auswählen]

section multiboot
MB_MODULEALIGN equ 0x0 ;not used
MB_MEMINFO equ 0x0 ;not used
MB_FLAGS equ MB_MODULEALIGN | MB_MEMINFO
MB_MAGIC equ 0x1BADB002
MB_CHECKSUM equ -(MB_MAGIC + MB_FLAGS)

align 4
dd MB_MAGIC
dd MB_FLAGS
dd MB_CHECKSUM

section .text

extern init

global _start
_start:
mov esp, kernel_stack
call init

_stop:
    cli
    hlt

    jmp _stop

section .bss
resb 8192 ; 8kB stack
kernel_stack:

Und das dafür vorgesehene Makefile entsprechend geändert:

Code: [Auswählen]

# Main Makefile

SRCS = $(shell find -name '*.[cS]')
OBJS = $(addsuffix .o,$(basename $(SRCS)))

CC = gcc
AS = nasm
LD = ld

ASFLAGS = -f elf
CFLAGS = -m32 -Wall -g -fno-stack-protector -nostdinc
LDFLAGS = -melf_i386 -Ttext=0x100000

nnOS: $(OBJS)
$(LD) $(LDFLAGS) -o $@ $^

%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $^

%.o: %.S
$(AS) $^ $(ASFLAGS) -f elf -o $@

clean:
rm $(OBJS)

qemu:
qemu -kernel nnOS

.PHONY: clean


59

Softwareentwicklung / Re: .intel_syntax

« am: 15. February 2012, 17:39 »

Also ich hab jetzt mal versucht das Tutorial mit NASM zu assemblieren..

Code: [Auswählen]

section multiboot
MB_MODULEALIGN equ 0x0 ; not used
MB_MEMINFO equ 0x0 ; not used
MB_FLAGS equ MB_MODULEALIGN | MB_MEMINFO
MB_MAGIC equ 0x1BADB002
MB_CHECKSUM equ -(MB_MAGIC + MB_FLAGS)

dd MB_MAGIC
dd MB_FLAGS
dd MB_CHECKSUM

section .text

extern init

global _start
_start:
mov esp, kernel_stack
call init

_stop:
    cli
    hlt

    jmp _stop

section .bss
resb 8192 ; 8kB stack
kernel_stack:

Bezüglich der Syntax wird auch nicht gejammert, aber wenn ich den Kernel
boote mit qemu schreibt er mir kein Hello World raus.

Hab am Linkerskript nichts geändert, die ist noch 1:1 gleich wie hier,
nur die Makefile hab ich entsprechend verändert..

Code: [Auswählen]

# ...
CC = gcc
AS = nasm
LD = ld

#ASFLAGS = -m32
ASFLAGS = -f elf
#...
%.o: %.S
$(AS) $^ $(ASFLAGS) -f elf -o $@
#$(CC) $(ASFLAGS) -c -o $@ $^
#...

Komm nicht dahinter.. der Multiboot-Header sollte so stimmen. Und auch das Linker-Skript
sollte das Objekt entsprechend aufbauen.
Nur bei

Code: [Auswählen]

$(AS) $^ $(ASFLAGS) -f elf -o $@ im Makefile bin ich mir nicht ganz sicher, aber es soll schon eine ELF sein oder?



*EDIT:
Okay, ich hab beim Multiboot-Header kein align angegeben.

Code: [Auswählen]

;...
align 4
dd MB_MAGIC
dd MB_FLAGS
dd MB_CHECKSUM
;...


60

Softwareentwicklung / Re: .intel_syntax

« am: 15. February 2012, 11:24 »

Wenn du eine genauere Fehleranalyse haben willst als das, musst du genauer beschreiben, wie sich das Nichtfunktionieren denn genau äußert. In diesem Forum ist das leider so eine Unart, dass wir ständig unsere Kristallkugeln verlegen, sonst würden wir uns natürlich selbst drum kümmern, uns die Informationen zu beschaffen.

Jaaa das kenn ich, das passiert mir auch ständig ^^

Also was ich jetzt gemacht habe, ist den Tutorialcode genommen (Commit dd51ecfc) und darauf folgenden Patch angewendet:

Code: [Auswählen]

--- a/start.S
+++ b/start.S
@@ -19,8 +19,9 @@
 // sichtbar)
 .global _start
 _start:
+    .intel_syntax noprefix
     // Stack initialisieren
-    mov $kernel_stack, %esp
+    mov esp, kernel_stack

     // C-Code aufrufen
     call init
Das funktioniert bei mir einwandfrei. Aber AT&T-Syntax ist eh besser.

Wenn ich die Intel-Syntax verwende wird ganz einfach das Hello World nicht angezeigt.
Ein Bekannter meinte mit

Code: [Auswählen]

mov esp, offset kernel_stack
würde es dann doch gehn. Tut es auch. Er meinte das wäre wegen GNU erforderlich.
Werde dann wohl mit NASM assemblieren ^^


Bevorzugst du AT&T aus rein ästhetischen Gründen oder hat das auch einen
praxisorientieren Hintergrund?

LG