Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - SSJ7Gohan

Seiten: 1 2 [3] 4 5 ... 20
41
Offtopic / Fehler im Grafikkarten-Treiber??
« am: 27. January 2006, 21:58 »
So schwer ist Multiprozessoring eigentlich nicht, mein OS kann es mittlerweile auch :D
Neue Linux Kernels und Windows sollten eigentlich richtig funktionieren.
42
Offtopic / Fehler im Grafikkarten-Treiber??
« am: 27. January 2006, 21:21 »
Ich hab auch ein A8N-SLI sowie 1GB Corsair RAM, aber nur nen AMD Athlon64 und ne 7800GT, da tritt dieses Problem bei keinem Spiel bisher auf. Ausserdem habe ich nur 32 Bit Windows installiert.
43
Lowlevel-Coding / Stack nach Exception
« am: 26. January 2006, 21:10 »
Ah ne, nicht von EFLAGS, sondern von CS. PL ist das Privileg Level (= der Ring :D)
44
Lowlevel-Coding / Stack nach Exception
« am: 26. January 2006, 19:11 »
Wenn das PL der gepushten EFLAGS anders ist als das aktuelle PL.
45
Lowlevel-Coding / Welchen Assembler nehmt ihr?
« am: 25. January 2006, 17:55 »
Als Editor für Assembler/C/C++ benutz ich gedit, den Standard Gnome Texteditor. IMHO gibt es für C/C++/Asm für Linux/BSD/Unix keine guten IDEs. Visual Studio ist recht gut, läuft aber nur unter Windows und kann keine ELF Dateien erzeugen. Ein gutes Beispiel für eine IDE ist IMHO eclipse, auch wenn man damit nur Java Code bearbeiten kann.
46
Lowlevel-Coding / Welchen Assembler nehmt ihr?
« am: 25. January 2006, 15:45 »
Ich nutze NASM, weil GAS eine schlechtere Syntax hat (auch wenn man auf Intel umschaltet) und Probleme mit 16 Bit Code hat. Wenn man mit GAS vernünftigen 16 Bit Code erstellen könnte, würde ich wohl GAS nutzen, da ich dann eine einheitliche Syntax für Inline Assembly und die Assembler Dateien hab.
47
Lowlevel-Coding / Ring0 -> Ring3
« am: 23. January 2006, 20:19 »
Die Kernelstacks müssen in alle Prozesse gemappt sein.
Du kannst es dann so pushen / popen

Code: [Auswählen]
; cr3 pushen
mov eax, cr3
push eax

; [...]
; scheduler aufrufen, stacks ändern usw.

pop eax
mov cr3, eax
48
Lowlevel-Coding / Ring0 -> Ring3
« am: 23. January 2006, 19:38 »
Im TSS muss man CR3 nicht eintragen (siehe die letzten Posts).

CR3 wird bei einem Interrupt nie geändert - egal ob Software oder Hardwaretasking.

Du mappst einfach den Kernelstack jedes Threads in jeden Prozess. (Der Kernel ist ja normalerweise eh in alle Prozesse gemappt). Dann kannst du ganz einfach das CR3 ändern indem du "mov eax, [deine_thread_struktur + offset des cr3 registers]" und "mov cr3, eax" machst. Du kannst natürlich auch CR3 immer auf den Taskstack pushen und dann popen, ich mache das aber nicht, weil bei mir nicht alle Tasks unterschiedliche CR3s haben (ein CR3 Switch kostet einige Hundert P4 Taskzyklen)
49
Lowlevel-Coding / c kernel / richtige parameterübergabe?
« am: 19. January 2006, 17:50 »
Achso, wenn du die Parameter haben willst, machst du das am besten so:
Code: [Auswählen]
push bp
mov bp, sp

mov ax, [bp + 4]

pop bp
ret
oder
Code: [Auswählen]
enter 0, 0
mov ax, [bp + 4]
leave
ret

Das ist schneller und ändert BP nicht.
50
Lowlevel-Coding / c kernel / richtige parameterübergabe?
« am: 19. January 2006, 17:42 »
In der Print Funktion addest du 4 zu BP.
Der Stack wächst nach unten, du must subtrahieren.
51
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 19. January 2006, 16:32 »
Bei meiner Bochs Version funktioniert die RTC auch nicht richtig, wenn ich die Option angebe.
52
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 18. January 2006, 22:03 »
Keine Ahnung, auf Bochs funktionieren die Timer (PIT, RTC, APIC) eh nicht richtig.
53
Das Wiki / Wie soll anfangen ?!!?!
« am: 18. January 2006, 20:26 »
Du kompilierst deinen C++ Code mit einem Compiler wie GCC und fügst ihn zum Kernelimage dazu. Wir haben hier ein C++ Kerneltutorial. Um C++ nutzen zu können, musst du aber im Protected Mode sein. (Ein 32Bit Modus der CPU mit Speicherschutz usw.) (Einige Bootloader wie GRUB schalten automatisch in den PM, so das du nur wenig Assemblercode brauchst und sofort mit C++ weitermachen kannst)
54
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 18. January 2006, 20:23 »
Bei Bochs sind die Timer nicht genau.
Bei VMware sollten sie etwa die richtige Geschwindigkeit haben. Bei Qemu funktionieren sie auch richtig.
55
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 18. January 2006, 19:19 »
Irgentwann wärend des Interrupthandlers, wann ist egal, du wirst nur keine neuen Interrupts mehr kriegen, bis du ihn gesendet hast.
56
tyndur / Microkernel oder Monolithischer Kernel
« am: 18. January 2006, 17:58 »
Allgemein ist ein Monolitischer Kernel einfacher als ein Microkernel.
Ein Monolitischer Kernel kann auch klein sein. Er muss eigentlich nur Speicher und Prozessmanagement enthalten (naja, Prozessmanagement eigentlich nicht, das kann auch in Module), der Rest kann in Module ausgelagert werden. Beim Microkernel sind die Treiber ja Prozesse, deshalb braucht der Kernel noch IPC Funktionen. Ausserdem werden die Treiber komplexer, weil sie miteinander kommunizieren müssen.
57
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 18. January 2006, 15:13 »
Jede Millisekunde geht nicht, aber du kannst 1024x pro Sekunde Interrupts auslösen, also annähernd 1ms. Soweit ich weiß, ist 1024 HZ sogar die Normaleinstellung. Hier gibts Beschreibungen der RTC, wo alles genau drinnen steht: http://www.nondot.org/sabre/os/articles/MiscellaneousDevices/
58
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 18. January 2006, 11:55 »
Code: [Auswählen]
// set real time clock frequency
outByte(0x70, 0xA);
byte = inByte(0x71) & 0xF0;
outByte(0x70, 0xA);
outByte(0x71, byte | 0xF);

Das sorgt dafür, das die Realtime Clock jede Sekunde 2x einen Interrupt generiert.

Code: [Auswählen]
// read status register c
outByte(0x70, 0xC);
inByte(0x71);
Das musst du nach jedem Interrupt aufrufen, um der RTC zu zeigen, der der Interrupt verarbeitet wurde.

Code: [Auswählen]
outByte(0x70, 0xB);
outByte(0x71, byte & 0xBF);
Deaktiviert die RTC wieder.

Wenn der Code auch auf älteren Prozessoren laufen soll, kannst du Delays nur mit dem PIT oder der RTC machen. Die RTC kann auch so programmiert werden, das sie 1024 Interrupts pro Sekunde generiert, so kannst du auch ungenaue Delays verwirklichen.
59
tyndur / Microkernel oder Monolithischer Kernel
« am: 17. January 2006, 22:29 »
Der Ansatz des Microkernels verhindert ja keine bösartigen Treiber. Er verhindert nur, das das System durch Programmierfehler abstürzt.

Ein HDD Treiber kann z.B. den MBR überschreiben und eigene Codestücke reinschreiben. Zum abstürtzen können die Treiber das System nicht mehr so leicht bringen, aber indirekt zerstören können sie es. Wenn man sie jedoch in den Kernelmode verlegt, können sie das ganze System wegen einem Bufferoverflow (die aber in Treiber eigentlich nicht sein sollten o.o) abstürzen lassen.
60
Lowlevel-Coding / Warteschleife mit Zeitangabe (in Millisekunden)
« am: 17. January 2006, 22:19 »
Du arbeitest doch im RM, oder?
Dann kansnt du den APIC nicht verweden. Der TSC ist von der Vorgehensweise aber ähnlich: Mit dem Befehl rdtsc kannst du lesen, wie viele Takte schon seit dem einschalten vergangen sind. Da du aber nicht weißt, wie viele Takte/Sekunde der Prozessor hat, muss du das erst herauskriegen.

Das geht so:
- Du programmierst die Realtime Clock (oder nen anderen Timer) so, das sie zweimal (oder wie oft auch immer) pro Sekunde einen Interrupt auslöst.
- Dann wartest du bis der Interrupt auftritt.
- Im IRQ8 Handler führst du rdtsc aus. Jetzt hast du in EDX:EAX einen 64 Bit Wert, die Anzahl der Takte. Die speicherst du und wartest wieder auf einen Interrupt
- Nachdem der IRQ das zweite mal ausgeführt wurde, machst du das ganze nochmal, subtrahierst die Werte voneinander und multiplizierst sie mit 2 (da der interrupt ja nicht jede sekunde, sondern jede 0,5te Sekunde ausgeführt wurde.)
- Jetzt hast du die Anzahl an Takten pro Sekunde
- Die Interrupts kannst du wieder deaktivieren

Wenn du jetzt einen delay haben willst, gehst du so vor:
- Du multiplizierst die Anzahl der Millisekunden (oder Microsekunden, oder was auch immer), die du warten willst, durch (TAKTE_PRO_SEKUNDE / 1000) oder halt 1000000 bei Microsekunden.
- Jetzt hast du die Anzahl der Takte die du warten willst
- Jetzt führst du rdtsc aus, und addirest zu dem Wert die Anzahl der Takte. Jetzt weißt du in wie vielen Takten du fertig gewartet hast.
- Jetzt machst du solange garnichts, und ließt mit rdtsc ununterbrochen den TSC, und überprüfst ob du schon fertig bist mit warten. Wenn ja springst du einfach zum Caller zurück.
Seiten: 1 2 [3] 4 5 ... 20

Einloggen