Nachrichten

21

OS-Design / Re: Speicherverwaltung

« am: 05. June 2008, 10:07 »

Die Bedingung dass die Address größer 0 sein muss ist unnötig.
Außerdem wird die Variable loop in deinem Beispiel nicht initialisiert, die Abfrage if(loop > 0) ist also Schwachsinn. Gemeint war hier wohl eher if(lower_limit > 0).
Ansonsten scheint deine Berechnung in Ordnung zu sein. (Ich gehe davon aus dass du loop als Index in ein Array von 32 Bit Zahlen benutzt; bei einem Bytearray ist die Division durch 32 natürlich falsch)
Ich würde mir aber überlegen, ob die Angabe eines Limits nach oben nicht sinnvoll ist. Schließlich möchtest du nicht, dass ISA DMA Pages in einem Bereich über 16 MiB allokiert werden. Die Behandlung aller Spezialfälle die auftreten könnten fällt warscheinlich mit der Angabe einer oberen Grenze leichter.

22

Lowlevel-Coding / Re: Bootsektor schreiben auf FAT12 Disk

« am: 02. June 2008, 12:06 »

Wenn du einfach den Bootsektor überschreiben willst unter Linux reicht einfach ein
sudo cat bootsector.bin > /dev/fda"
. Wenn du Dateien schreiben willst ist die Benutzung des Loopback Devices am einfachsten.

23

OS-Design / Re: Speicherverwaltung

« am: 01. June 2008, 16:45 »

Den Speicher für DMA kannst du dahin mappen wo du möchtest.
Alle Memory-Mapped Devices brauchen Zugriff auf bestimmte physische Pages. Dazu gehören viele PCI Devices, APICs und andere Geräte. (HPET z.B.)

24

OS-Design / Re: HAL

« am: 28. May 2008, 23:15 »

Das ganze wird nicht funktionieren, da die Anweisungen der Prozessoren ganz anders aussehen. Auf dem x86 wird ein jmp Befehl zum Beispiel zu der Bitsequenz 0xFF 0x12345678 assembliert. Auf einem ARM, MIPS oder PPC Prozessor stellt die gleiche Bitsequenz einen völlig anderen Befehl dar, falls diese Bytesequenz überhaupt gültig ist. (aufgrund von Alignments auf RISC Prozessoren oder einfach dadurch dass es keinen Opcode gibt der mit 0xFF beginnt)

25

OS-Design / Re: HAL

« am: 26. May 2008, 22:19 »

So einen Hack gibt es im Allgemeinen auch nicht.

IIRC habe ich mal so einen Hack für 2 oder 3 Architekturen gesehen. Ich weiß aber nicht mehr wo das war. Aber auch mit so einem Hack macht es natürlich keinen Sinn nur ein Kernel-Image zu verwenden. Der Hack wäre ja ausserdem nicht erweiterbar auf andere Architekturen.

26

OS-Design / Re: HAL

« am: 26. May 2008, 19:03 »

Ja, um verschiedene Kernels kommst du auch mit HAL nicht herum. Wenn du ein HAL benutzt ist aber der Anteil des Codes den du für jede Architektur neu schreiben musst geringer als ohne .
Wie bluecode gesagt hat würde ein Kernelimage für viele Architekturen schon allein vom Format der Instructions her nicht funktionieren.

Zum HigherHalf Kernel:
Du kannst natürlich auch solange Paging noch deaktiviert ist Teile des Systems initialisieren (z.B. lesen der GRUB Infos), nur ist das je nach verwendeter Programmiersprache schwierig zu handhaben. In C musst du alle Pointer auf globalen Addressen anpassen, in Assembly ist das ganze wsl. noch etwas übersichtlicher da du ja alle Speicherzugriffe die dein Kernel macht kennt (und somit die Gefahr geringer ist das du Zugriffe auf globale Variablen übersieht). Im Allgemeinen ist es jedoch empfehlenswert schnell Paging zu aktivieren um nicht ganz triviale Addressmanipulationen zu vermeiden .

27

OS-Design / Re: HAL

« am: 16. May 2008, 15:13 »

Ja, in einer solchen Situation muss man sich die Typen der stdint.h natürlich selbst definieren. Wenn wir die Typen aus der libc benutzen wollen geht das natürlich nur, wenn wir überhaupt eine libc haben. (Sprich: Nicht im Kernel)
In dem Fall, das der Compiler keine libc bereitstellt (im Kernel oder eben auch bei Microcontrollern) stimme ich euch natürlich zu.

28

OS-Design / Re: HAL

« am: 16. May 2008, 11:48 »

Das Problem ist ja gerade, dass du nicht weißt wie lang sie "in echt" sind.
int, long etc. können unterschiedlich lang sein. Also kannst du auch über die Länge der von dir neu definierten Typen nichts sicheres aussagen. int32_t, int16_t haben immer die geforderte feste Größe, ansonsten entspricht der verwendete Compiler nicht dem ANSI C Standard.
Woher möchstest du wissen, das dein selbst definierter int32_t auch 32 Bit lang ist? Das kannst du nur mit Sicherheit auf allen Platformen garantieren, wenn du die Typen aus der stdint.h benutzt.

29

OS-Design / Re: HAL

« am: 15. May 2008, 15:55 »

Multitasking (auch Software Multitasking) basiert natürlich schon auf platformspezifischen Funktionen (schließlich müssen die Register ja direkt manipuliert werden), du könntest daher Funktionen wie createThread(pointer entry) oder switchThread(struct thread *nextone) auch in das HAL einbauen.
Was die IPC betrifft sind Funktionen zur Syncronisation von Threads notwending, nützlich wären etwa atomicCompareAndSwap(pointer dest, pointer source, uint value) [für die Implementation von Spinlocks und Semaphores] oder yield() . [eine hlt Instruktion damit der Scheduler die CPU anhalten kann, wärend alle Threads blocken]

30

OS-Design / Re: HAL

« am: 15. May 2008, 14:10 »

Einige Funktionen für die virtuelle Speicherverwaltung (Page mappen, Page unmappen, Zugriffsrechte setzen) sind auch stark platformabhängig. Eventuell möchtest du auch ACPI etc. direkt im Kernel implementieren, wobei man das durchaus als Treiber auslagern könnte.

31

Offtopic / Re: Juhuuuuuuuuu

« am: 13. May 2008, 09:02 »

In meinem OS läuft die Kommunikation der Treiber mit den Anwendungen und die der Treiber untereinander über ein ähnliches Interface ab, wie TCP/IP Sockets unter Windows/Linux/BSD etc.
Es gibt Server (identifiziert durch einen Namen) zu denen sich Clients verbinden können und dann Bytes schicken können.
Um das ganze übersichtlicher zu gestalten plane ich einen Device Manager einzubauen, einfach ein Programm, bei dem alle Treiber registriert werden und in Klassen (Blockdevice, Netzwerkkarte, Tastatur, Grafikkarte, Terminal etc.) eingeteilt werden. Zusätzlich wird dann noch für jede Klasse ein default Treiber zugewiesen. Eine Anwendung kann dann einfach den Device Manager nach dem benötigten Gerät fragen oder das default Gerät benutzen. Manche Geräte, wie das Terminal auf dem die Anwendung läuft oder (bei Fs Treiber) auf welche Festplatte der Fs-Treiber zugreifen soll, wird man durch das Setzen von Environment Variablen zuweisen könnten (bzw. die Vorgabe vom Device Manager überschreiben können).

32

Offtopic / Re: Juhuuuuuuuuu

« am: 12. May 2008, 11:08 »

Der APIC Timer und die HPET haben Auflösungen im Nanosekundenbereich.

33

Lowlevel-Coding / Re: 64Bit Integer mit FPU oder 32Bit CPU

« am: 27. April 2008, 14:35 »

Achso, stimmt, ich hatte garnicht an 80 Bit Floats, sondern nur an 64 Bit Floats gedacht.

In dem Fall kannst du natürlich die FPU nutzen. Mit der Nutzung der FPU für Integer Operationen habe ich keine Erfahrung, du kannst es ja mal ausprobieren, ich würde aber vermuten, dass Integer Operationen schneller sind. Andererseits hat die FPU fdiv Operationen (die allerdings auch sehr langsam sind), die man sonst aufwendig nachbilden muss. Mich würde mal interessieren, was da bessere Performance bietet. GCC verwendet auf jeden Fall Integer Register.

Eventuell ist MMX/SSE auch noch eine Alternative, ich bin mir aber nicht sicher, ob es auf Skalaren operierende Divisions-Instruktionen gibt.

34

Lowlevel-Coding / Re: 64Bit Integer mit FPU oder 32Bit CPU

« am: 27. April 2008, 10:29 »

Die FPU unterstützt keine Integer Operationen. Beim Laden in die FPU werden sie in Floating Point umgewandelt und es gibt zwangsläufig Genauigkeitsverluste. (unsigned 12345678 wird zu sowas wie: +1,2345 * 10^7)

35

Offtopic / Re: FA Betriebssystementwicklung

« am: 11. April 2008, 21:51 »

Natürlich kann man die 32 Bit Register und alle 32 Bit Instruktionen im RM bentzten, es muss halt immer ein 0x66 Operand Size Override Prefix davor. (das selbe Prefix bewirkt im PM, dass man überhaupt noch auf 16 Bit Register zugreifen kann.) Man kann allerdings nicht mehr als 1 MB Speicher addressieren.

36

Lowlevel-Coding / Re: Global Descriptor Table

« am: 10. April 2008, 21:16 »

OS/2 benutzte z.B. Ring2 (ich denke auch Ring1, bin mir aber nicht sicher). Es läuft daher nicht auf früheren Versionen von VMWare.
Mit "modern" wollte ich ausdrücken, das heutige Desktopsysteme wie Linux, BSD Varianten oder Windows die Ringe 1 & 2 nicht nutzen. Ich hab das Wort absichtlich in Anführungsstriche geschrieben, da modern immer sehr relativ ist.
Dass Xen Ring1 benutzt habe ich nicht gewusst; es ist aber interessant, dass Ring1 doch noch benutzt wird, danke für die Info.

37

Lowlevel-Coding / Re: Global Descriptor Table

« am: 10. April 2008, 21:06 »

Wozu 9 Deskriptoren? Ring 1 und 2 werden von "modernen" Systemen nicht mehr benutzt, Hardwarezugriffe werden über Ring0 bzw. den Kernel durchgeführt, Treiber laufen je nach Kernelmodell (Microkernel oder Monolith) in Ring3 oder 0. Generell brauchst du für Ring0 und 3 jeweils ein Code und ein Datensegment. Für Multitasking brauchst du noch einen TSS Deskriptor, evt. können zusätzliche Deskriptoren nützlich sein, wenn du mithilfe von FS oder GS auf thread-lokale Datenstrukturen oder andere wichtige Strukturen zugreifen willst.

38

OS-Design / Re: Graphische Oberfläche mit GRUB, C und VGA

« am: 07. February 2008, 20:04 »

Nunja, du brauchst einen funktionierenden Kernel mit Virtual Memory Management, Multitasking/threading und minimalen IPC Funktionen. Die darauf aufbauenden Anwendungen werden dann vergleichsweise wenig Zeit beanspruchen, vor allem, wenn du eine vorhandene C Library etc. benutzt. Wenn du etwas programmiererfahrung hast (auch im Lowlevel Bereich, du solltest wissen wie Pointer funktionieren und wie die I/O auf x86 CPUs funktioniert etc.) dann ist eine einfache GUI in wenigen Monaten möglich. Es ist allerdings fraglich, ob es sinnvoll ist, möglichst schnell eine schicke GUI zu implementieren. Ein stabiler Kernel und das Kerneldesign sind die wichtigsten Komponenten in einem OS. Viele Hobby OS Entwickler hier konzentrieren sich zunächst auf den Kernel und sein Design, bevor sie "highlevel" Userspace Applikationen implementieren.

39

Offtopic / Re: Kleine Frage zu NASM...

« am: 13. January 2008, 18:43 »

Btw, "add [Zaehler], 20" würde auch nicht funktionieren, da NASM den Typ von Labels nicht speichert. Nasm weiß nichts davon, dass du Zaehler mit db 0 initialisiert hast, Zaehler ist einfach nur eine Addresse für NASM. NASM verlangt Prefixe wie "add byte [Zaehler], 20", wenn die Größe des Speicherzugriffs nicht durch ein Register bestimmt ist.

40

Lowlevel-Coding / Re: Zahl in Text umwandeln

« am: 12. January 2008, 18:21 »

Das dekrementieren von bx ist richtig
Beim ersten Anblick sehe ich da keinen Bug, evt. liegt der Fehler in der Ausgabe?

EDIT: Hab doch nen Fehler gefunden:

Code: [Auswählen]

mov [String+bx],dxHier verwendest du einen 16 Bit Memory Zugriff, der dir die vorherigen Stellen mit 0 überschreibt.

Code: [Auswählen]

mov [String + bx], dlSollte funktionieren.