Nachrichten

121

Offtopic / ExportStructure..java

« am: 09. January 2012, 16:39 »

Ich brauche eine Rückmeldung zum Code, welcher den Zugriff auf x86-Srukturen konvertiert. Ich hoffe jmd hier kann Java lesen. Das ginge zwar mit C wesentlich einfacher, aber ich bin halt schon sehr weit mit dem Import für Java. Der Code hat ein Indent von 4 Zeichen und wird von Pastebin nicht korrekt dargestellt.

http://pastebin.com/gXMVMhB7

Kann da mal jemand drüber schauen? Sind alle Bits, Offsets, Byte-Orders und Flags korrekt? Der Code besteht aus 6 Klassen:
- InterruptDescriptorTablleRegister
- InterruptDescriptor
- GlobalDescriptorTableRegister (äquivalent zu Local)
- GlobalDescriptor (äquivalent zu Local)
- PageDirektoryEntry (äquivalent zu PageTableEntry)
- TaskSegmentDescriptor, unfertig

Jede Klasse beinhaltet die Methoden read und write, sowie einen Feldselektor "Field", welcher das Feld auswählt. Einige Klassen beinhalten zusätzlich Unterklassen für Flags und komprimierte Werte. Die Methode read gibt entweder einen 32-Bit Integerwert oder ein Objekt einer der Unterklassen zurück. Die Methode write nimmt ein solches Objekt entgegen und schreibt es in "structure".

Der Parameter "int start" ist überflüssig.

Ich beschäfte mich gerade mit dem Bootloader (GRUB). Nach 4 Stunden (und einem Haufen anstrengender Fehlermeldungen) habe ich erfolgreiches Plattenimage für Bochs kreiert.

122

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 07. January 2012, 07:02 »

Wer sein System allerdings professionell einsetzen möchte

Kannst du das konkretisieren? Was ist "professioneller Einsatz"?

Lass es mich so formulieren: Jemand der seine CPU übertaktet zieht Performance der Reliabiliy vor.

123

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 06. January 2012, 20:51 »

Btw: man kann die Elemente einer Baumstruktur auch in einer Tabelle halten und mit Indices auf diese zugreifen, oder zum Pfad eines Elements den Hash bilden und über Hashtables gehen.

124

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 06. January 2012, 20:15 »

Für den Heimrechner sicherlich keine unvorteilhafte Alternative. Wer sein System allerdings professionell einsetzen möchte, wird sich lieber 2x überlegen, ob er günstige Performance haben möchte, oder lieber mehrere Systeme verbindet um zu parallelisieren und somit die Performance erhöht bzw. das Risiko vermindert.

Edit: das setzt natürlich voraus, dass sowohl die verwendete Plattform als auch seine Aufgabenstellung massive Parallelisierung unterstützen und sein Code vom Compiler nach Abhängigkeiten analysiert und auf mehre Cores oder das Netzwerk verteilt werden kann.

125

OS-Design / Re: Optimale Baumstrukturen fuer malloc/free

« am: 06. January 2012, 19:07 »

Baumstrukturen sind meiner Ansicht nach nicht sehr robust. Es gibt zu viele Faktoren, welche das Verhalten beeinflussen könnten. Man sollte meiner Ansicht nach immer mit einem Fehler oder Defekt der Hardware rechnen und die Auswirkungen minimieren. Im Zweifelsfall kann das Risiko auch durch Redundanz weiter verringert werden.

Aus diesem Grund verwende ich lieber Vektor-Arrays als verlinkte Listen bzw. lieber Hashmaps als Baumstrukturen.

126

OS-Design / Re: GUI LowLevel

« am: 06. January 2012, 16:56 »

OT: Gibt es ein standardisiertes Protokoll zur Kommunikation mit OpenGL-Hardware? Wenn ja, würde ich damit irgendwann Grafikprimitive, GUI Komponenten und Desktop beschleunigen. Ansonsten gibt es auch noch Mesa3D.

127

OS-Design / Re: GUI LowLevel

« am: 05. January 2012, 21:04 »

Bei VirtualBox sind die Extensions für 3D-Hardware-Beschleunigung standardmäßig deaktiviert.

Wenn ich das richtig sehe, bedeutet die Ausführung von Shader-Code auf der GPU dort eine Verletzung des Sandbox-Prinzips. Auch bin ich mir nicht ganz sicher ob Grafiktreiber im Allgemeinen Vorkehrungen gegen Schadcode getroffen haben.

Bezüglich DMA ging ich bisher davon aus, dass bestimmte Bereiche im RAM gemappt werden. Falls das zutrifft könnte man Speicherschutz mit Segmenten erreichen. Abgesehen davon bin ich nicht sehr glücklich darüber, dass die Ingenieure von PC-Hardware davon auszugehen scheinen, dass Bedrohungen für ein System ausschließlich durch Software bestehen und folglich den Hardware-Komponenten eines Systems bedingungslos vertrauen.

128

OS-Design / Re: Bootbarer Mikrokernel mit Hypervisor für Semantischen Code

« am: 05. January 2012, 16:56 »

Musste gerade feststellen, dass ich in den vorherigen Posts vermehrt den Begriff "Bytecode" verwendet habe. Mir war der Unterschied zwischen Bytecode und Maschinencode nicht bewusst, aus dem Kontext geht hoffentlich hervor, dass ich x86-Maschinencode meinte.

129

Offtopic / Re: Eigene CPU

« am: 04. January 2012, 15:58 »

Wenn ich mich richtig erinnere, weist libc Speicher ausschließlich im Vielfachen der Größe einer 4kb Page zu.

130

Offtopic / Re: Eigene CPU

« am: 04. January 2012, 01:53 »

Bei genauerem Hinsehen fiel mir auf, dass ich eine Seite vergessen hatte. Dort wurde Paging als Mittel gegen Fragmentierung ausführlich diskutiert.

Insgesamt hatte ich immer den Eindruck, dass sich sowohl Windows als auch Linux etwas schwer tun mit vielen kleineren malloc/free.

131

Offtopic / Re: Eigene CPU

« am: 03. January 2012, 22:07 »

Nachdem ich mir sämtliche Posts zum Thema durchgelesen habe möchte ich zuallererst meinen Respekt zum Ausdruck bringen. Die Konzepte sind insgesamt sehr durchdacht und innovativ. Es ist wirklich gut zu erfahren, dass es noch andere Personen gibt, die sich intensiv mit der Materie auseinandersetzen.

Ab Seite 2 hat sich mir allerdings die Frage aufgedrängt, welcher Umstand zur Diskussion über die Defragmentierung des physikalischen Speichers geführt hat. Hat Paging nicht ursprünglich die essentielle Aufgabe externe Fragmentierung zu unterbinden?

Früher oder später werde ich ebenfalls mit der Fragestellung konfrontiert werden, wie der physikalische Speicher verwaltet werden soll. Aus diesem Grund habe ich mir überlegt, ob es sinnvoll wäre, pro Page jeweils nur Datentypen gleicher Größe zuzuordnen. Sowohl die Belegung innerhalb der Pages, als auch die Zuweisung der Pages würden in Tabellen festgehalten werden. Bei adäquater Implementierung in Hardware könnte freier Speicher in amortisiert konstanter Zeit zugewiesen werden. Dies würde auch die Implementierung eines Garbage Collectors in Hardware begünstigen, da der Speicher bei kurzlebigen Allokationen (zB Lokale Objekte immerhalb einer Funktion) nicht fragmentiert wird.

132

OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?

« am: 27. December 2011, 12:09 »

GUI auf Shell aufsetzen oder direkt auf den Kernel?

Wie genau würdest du eine GUI auf die Shell aufsetzen? Die ganze GUI als Shellskript schreiben?

Hihi, das habe ich mich auch gefragt. Ich dachte, entweder ist das wirklich quatsch, oder ich verstehs bloss nicht.

133

Softwareentwicklung / Re: OS-Dev mit Intelassembler

« am: 26. December 2011, 17:12 »

Bei NASM kannst du entweder das BIN-Format (-f bin) und die ORG-Direktive verwenden, oder das ELF-Format (-f elf) und mit ld linken. Wenn du deinen ASM-Code mit C kombinieren willst, musst du in jedem Fall linken. Beim Linken werden die Objektdateien an eine feste Adresse ausgerichtet und alle Labels durch feste Adressen ersetzt. btw: ELF gibt es sowohl als relocatable als auch als executable. Images kannst du mit dd zusammensetzen.

Im Linker-Script (einbinden mit -T) stehen sowohl Ausgabeformat, Startadressen der einzelnen Sections, als auch das Label des Einstiegspunkts.

Tutorial im Wiki: http://www.lowlevel.eu/wiki/C-Kernel_mit_GRUB

134

OS-Design / Re: Bootbarer Mikrokernel mit Hypervisor für Semantischen Code

« am: 26. December 2011, 15:23 »

Ich konnte die letzten Tage dazu nutzen, den Opcode-Assembler zu erweitern und einen Wrapper für die Strukturen der diversen x86-Speicherverwaltungs-Tabellen zu schreiben. Bei den Strukturen brauche ich aber noch eine Rückmeldung, da ich mir nicht sicher bin, ob alle Felder richtig übersetzt wurden (Adressierungsarten, Little Endian). Die Instruktionen aus ExportOpcode.java habe ich testweise in eine Binärdatei geschrieben, disassembliert und das Ergebnis in den Listings hochgeladen.

Wer nicht gerade Ski fahren, Geschenke auspacken oder Feuerwerk zünden muss, kann sich das ja mal ansehen: http://forum.lowlevel.eu/index.php?topic=2948.msg34275#msg34275

Edit: Für das Listing der FPU Speicherzugriffe (misc) habe ich versehentlich 2x storeFloat(true) für Integer-Werte verwendet, was in FIST resultiert, die Option für Float-Werte fehlt dort im Listing.
Btw: In meinem Buch konnte ich keinen Opcode zur Instruktion FST mit 80-Bit Registern finden, weshalb ich auf FSTP ausweichen musste.

135

OS-Design / Re: Verrückte Idee

« am: 23. December 2011, 01:15 »

Es wäre definitiv interessant zu erfahren, ob deine Versuche Aussicht auf Erfolg zeigen. Ich habe bisher immer gelesen, dass das BIOS vom Protected Mode nur noch über VM86 zu erreichen ist. Bei genauerem Überlegen scheint es sich dabei aber vermutlich nur um eine Emulation zu handeln.

136

OS-Design / Re: Aufbau eines nicht pollenden Keyboardtreiber (mit Shell)

« am: 22. December 2011, 13:42 »

Sorry hab nicht richtig gelesen/nachgedacht. Für eine Shell brauchst du logischerweise jedes einzelne Zeichen sofort. Leg einfach den Task schlafen, bis ein Zeichen gelesen wurde (Interrupt), wecke den Task auf und gib das Zeichen im nächsten timeslot dann an den Task zurück (auf den stack), wie taljeth bereits sagte.
Für eine Shell kannst du dir dann auch ein Timeout sparen. Wenn du mehrere Shells offen hast, musst du halt immer die aktive auswählen.

137

Offtopic / Re: Hostingangebot

« am: 21. December 2011, 21:44 »

Hi,

Habe mal irgendwo eine Sandbox für C auf einem Webserver gesehen. (halb OT)

138

Offtopic / Re: Hostingangebot

« am: 21. December 2011, 13:51 »

Hi,

Deine Großzügigkeit in Ehren.

Technische Frage: Nutzt du virtual machines, oder läuft das über ein einziges System. (Linux/Apache nehm iich mal an).
Dir ist doch sicher bewusst, dass du für einen lokalen Server zuhause neben den Einrichtungskosten auch Traffic und Strom bezahlen musst...?

139

OS-Design / Re: Wie geht ihr an die Entwicklung eures OS heran?

« am: 19. December 2011, 12:46 »

Du brauchst:
-einen Bootloader, ich empfehle GRUB. Für GRUB brauchst du meines Wissens aber ein filesystem. Ansonsten geht ein Bootloader mit ein paar Zeilen Assembler und INT 13h, das Bootdevice sollte in dl liegen. Abgesehen davon stellt GRUB eine Menge nützlicher Informationen bereit, welche erst mühsam aus dem BIOS gelesen werden müssen.
-Interrupt-Handler
-Paging/Segmetierung
-Protected Mode
-Tasks
-Hardware-Zugriff, möglicherweise eine Abstraktionsschicht (HAL)
-Einen Überblick über das Speicherlayout im RAM (memory map)
-Speicherverwaltung (malloc)

Um die Feinheiten ausarbeiten zu können, solltest du das möglichst einfachste System zum laufen bekommen, das deinen Vorstellungen entspricht. Ob du im Kernel mit C++ arbeiten willst/kannst entscheidest du voraussichtlich beim design der Speicherverwaltung. Ob du den Bootloader universell verwendbar haben willst entscheidest du voraussichtlich beim Design deiner HAL, oder du nimmst GRUB.

Du bist mit den Eigenheiten von x86/IBM-PC bereits vertraut? Wenn nicht, brauchst du viel Geduld und starke Nerven.

140

OS-Design / Re: Bootbarer Mikrokernel mit Hypervisor für Semantischen Code

« am: 13. December 2011, 16:20 »

@taljeth:
Ich habe eben deinen früheren Post gelesen und will noch mal darauf eingehen.

Wenn du sowieso nur x86 nachbaust, wäre es nicht vielleicht eine Option, die heutige Hardwarevirtualisierung (SVM/VMX) für deine VM zu nutzen? Was gewinnst du damit, überhaupt eine VM zu haben, im Vergleich dazu, den Code direkt auf der Hardware laufen zu lassen?

In der Tat habe ich bereits darüber nachgedacht, VTx für die Virtualisierung einzelner Prozesse zu verwenden. Allerdings mehr als (redundante) Sicherheitsvorkehrung. Irgendwie muss ich Treibern (im Usermode-Prozess in Ring 3) gestatten auf Speicher, I/O Ports (bzw. Ring-0 Instruktionen ?) zuzugreifen. Da das mit einer White-List geschehen soll, müsste ich hier eine art Abstraktionsschicht vorsehen, welche jedoch für die Treiber transparent und auf x86 spezialisiert bleibt. Die Idee, VTx zu nutzen habe ich zurückgestellt, da mir dort die Kosten (Komplexität, Mehraufwand) im Vergleich zum Nutzen (Sicherheit) zu hoch sind. Abgesehen davon werde ich natürlich das fertige Image in einer VM testen und, so bald es möglich ist, darin einen Editor starten und von da an innerhalb des neuen Systems entwickeln.

Aber gut, wenn ich mich mal an das hier gepostete halte, an welcher Stelle kommt der x86-Mikrokernel ins Spiel? Willst du den Userspace auf deiner Architektur x86-kompatibel halten, dass du das ganze auf x86 probelaufen lassen kannst oder wie?

Die Software, die in den Prozessen läuft kommt ausschließlich aus Semantic Code, dieser wiederum wird entweder von Java/C++ importiert und/oder im semantischen Editor geschrieben. D.h. Software kommt ausschließlich als source code. Beschreibung gibts im Brainstorm zu Semantic Code (siehe meinen Post weiter oben).

Ich kenne RISC bisher nur aus Dokumenten/Spezifikationen (IBM Power, Sun SPARC, HP PA-RISC), fühle mich jedoch definitiv von den Eigenschaften überzeugt. Speziell die Many-Core-Varianten (60+) haben es mir angetan.

Die haben aber eher viele Register und nicht gar keine.

Das ist richtig. Mir gefällt dieses Prinzip, will aber noch weiter gehen. Ein Register ist ja quasi nur ein Speicherplatz für temporäre Werte, welcher sich durch seine schnelle Verfügbarkeit auszeichnet. Was wäre, wenn nun der gesamte RAM quasi als Register funktioniert. Damit wäre die Integrität der Daten bei einem Taskwechsel immer gewährleistet, auch ohne Zurückschreiben. Jeder Prozess könnte seinen eigenen Cache bekommen, in dem er seine häufig verwendeten Daten speichert. Der Vorteil von Semantic Code ist hierbei, dass die Abhängigkeiten von Daten über mehrere Prozesse/Threads statisch analysiert werden können.

Ich bin mir im Klaren darüber, dass es bezüglich der Zugriffszeit eine große Diskrepanz zwischen Zugriffen auf ein Register, respektive den RAM gibt.

Hierzu noch 2 Dinge:
Speicherinhalt, Datenobjekt: z.B. Int32, String, Vektor, Klassenobjekt, ... . Diese werden anhand ihrer Speicherklasse (Größe, power of 2) in fixed size Arrays gehalten. Jeweils eine Speicherklasse verwendet pro Prozess ein oder mehrere Pages. Somit enthält eine Page nur Objekte einer Speicherklasse. Zu jedem Datenobjekt gehört eine eindeutige (lineare?) Adresse.
Klassenobjekt, Liste, Speicherstruktur: Die Properties in Klassenobjekten sind Verweise auf andere Datenobjekte. Ein Identifier.Properity wird beim Zugriff von der Speicherwaltung zu einer (linearen?) Adresse aufgelöst. Dies geschieht durch Hash Tables. Jede Speicherstruktur basiert auf Hash Tables, wobei jede Struktur eine eigene Hash Table besitzt. Identifier.Property sind nur für eine Struktur eindeutig. Es gibt allerdings noch einige Vorkehrungen zu treffen bezüglich der Organisation von Strukturen und Hash Tables, weswegen ich mich zuerst auf fixed Export, also feste Adressen konzentrieren werde.
Edit: werde das erst in Java testen


@erik, Svenska: Eure Posts werde ich wohl noch mal gründlich lesen, vielen Dank dafür. Ich werde doch einen relativ flachen Stack anlegen, für Interrupts und 2 Tasks. Usermode in Ring 0 ist leider keine Option. Ich werde mich nun erstmal wieder mit dem Opcode-Assembler beschäftigen, vielleicht ein paar Operationen implementieren und mich dann wieder melden.