Nachrichten

61

Lowlevel-Coding / ASMler gesucht

« am: 27. December 2005, 22:24 »

Präfixe sind mir klar. Opcode an sich auch. ModR/M-Byte ist mein Hauptproblem. Ich verstehe nicht, wie das zusammengesetzt wird. SIB ist wieder kein Problem. Und Displacement und Konstante auch nicht.

62

Lowlevel-Coding / ASMler gesucht

« am: 27. December 2005, 09:08 »

Ah, gut. Dann kannst du uns ja indirekt auch unterstützen. Mein Hauptproblem ist die Opcode-Generierung. Schick mir bitte mal alles, was du über Assembler-Bau hast per eMail. Währe sehr froh drüber.

63

Das Wiki / Ausgabe 8

« am: 27. December 2005, 09:04 »

Ah, danke für die Infos!

64

Lowlevel-Coding / Treiber, aber wie?

« am: 26. December 2005, 13:05 »

Hallo,

Ich werde meine Treiber wie normale Tasks behandeln und in Ring3 laufen lassen. Grundlegende Geräte wie DMA/FDD/HDD werden von nativen Kerneltreibern übernommen, die in Ring0 laufen.
Außerdem überlege ich, Schnittstellentreiber (COM/...) ebenso nativ im Kernel einzubauen und auf Ring0 laufen zu lassen. Neue Treiber, beispielsweise für Drucker, müssten dann nichtmehr direkt die Ports ansprechen (was sie auch nicht können), sondern nurnoch mit den Schnittstellen-Treibern arbeiten, genauso wie FS-Treiber mit den nativen Medientreibern (FDD/HDD/...) laufen.
Sollte trotzdem ein Gerät/Treiber direkt über einen Port kommunizieren, so muss dies über die API und den Kernel abgehandelt werden, wobei ich auch dort Mechanismen einbauen will, die das Übertragen vereinfachen.

Gruß,

Joachim

65

Das Wiki / Ausgabe 8

« am: 25. December 2005, 20:05 »

Sind eigendlich ext(/1) und ext/3 nach dem selben System aufgebaut oder gibt es da noch markante Unterschiede?

66

Das Wiki / Ausgabe 8

« am: 25. December 2005, 12:47 »

Hallo,

Die Kategorie, in die dein ext/2-Tutorial fällt, wurde kurzfristig anderst besetzt, da man an dem Tutorial noch einige Änderungen hätte machen müssen, um es besser verständlich zu machen.
(Warum sollte man die Blockgröße nicht ändern? In welchen Datentypen sind die Angaben gemacht? ...)
Ich hoffe du verstehst die Entscheidung und schreibst weiterhin Artikel für Lowlevel. Außerdem würde ich mich sehr freuen, wenn du deinen Artikel über ext/2 noch ein wenig ergänzen und ausbauen würdest, denn ich denke viele von uns interessiert, wie die ext-Reihe aufgebaut ist.

Gruß,

Joachim

67

Lowlevel-Coding / ASMler gesucht

« am: 25. December 2005, 12:08 »

Die Prozessoren haben aber einen ganz anderen Befehlssatz. Das kann man nicht einfach 1 zu 1 portieren, es sei denn man baut verschiedene Befehlssätze ein. Aber ich denke für den Anfang sollte x86 reichen.

68

Lowlevel-Coding / DMA

« am: 25. December 2005, 11:14 »

Hi,

Ich hab mir das Buch (gleiche Auflage) erst aus der Bücherei ausgeliehen. Wünsche ich mir zum Geburtstag, das Buch ist einfach genial. Da steht fast alles drin.

Gruß,

Joachim

69

Lowlevel-Coding / ASMler gesucht

« am: 24. December 2005, 16:09 »

Assembler
   \/
Interne API
   \/
API des jeweiligen Systems

,

Exakt so ist es gedacht. Das vereinfacht das Portieren enorm.

"mit Optimierung"? Heisst das, dass der Assembler den Assembler-Code optimiert? Verliert man da nicht gerade die Vorteile von Assember, wie "1 zu 1 Übersetzung" also die absolute Kontrolle über den vollständigen Code?

Doch. Aber man könnte ja eine Option einbauen, ob optimiert werden soll oder nicht.

Ich hätte Interesse daran  
Vor allem weil ich die ganze Zeit in Assembler programmiere und einen Assembler selbst für mein OS brauchen könnte.

Gut, ich schließe mich mal mit dir kurz!

Das erste was man machen muss ist wohl die festlegung eines Syntaxes. Bzw. soll man diesen von NASM, FASM, AT&T... übernehmen? Soll man gleich was ganz neues entwickeln?
In welchem Assembler er dann geschrieben wird sollte klar sein, da er ja mit sich selber assembliert werden soll.

Als Syntax würde ich den von NASM eins zu eins übernehmen. Dann können wir den Assembler mit NASM schreiben und er kann sich gleich selbst assemblieren.

70

Das Wiki / Ausgabe 8

« am: 24. December 2005, 00:14 »

Juhu! Heute ist endlich Weihnachten! Und natürlich hat das Christkind auch für die Lowleveler (obwohl sie nicht immer so artig waren...) ein Geschenk dagelassen! Viel Spaß mit Ausgabe 8, frohe Weihnachten, geruhsame Weihnachtstage (Stoff ist ja jetzt wieder da ) und einen guten Rutsch ins hoffentlich erfolgreiche Jahr 2006 wünsche ich euch!

71

OS-Design / Kommunikation zwischen Modulen

« am: 23. December 2005, 22:52 »

Ich bin mir nicht sicher, aber ist es nicht so?:

Java Quellcode -> Java Bytecode -> Maschinencode

Den ersten Schritt macht der "Compiler", den zweiten Schritt die "Virtual Machine"...

72

Lowlevel-Coding / ASMler gesucht

« am: 23. December 2005, 22:51 »

Hallo,

Ich wollte mal fragen, ob es hier in der Community jemanden gibt, der Lust hätte, mit mir zusammen einen Assembler in Assembler zu schreiben.
Ziel ist es, einen guten Assembler (ggf. auch mit Optimierung) zu programmieren, der leicht portabel ist.

Warum einen neuen Assembler schreiben? Und warum auch noch in Assembler? Nun, Assembler "ist" Maschinencode (gut, der Maschinencode sieht etwas anderst aus, aber im Prinzip wird das 1 zu 1 übersetzt). Das heißt mit Assembler hat man die volle "Macht" über den PC. Warum also nicht einen Assembler als erstes Programm in das System integrieren? So währe das System recht schnell freestanding und man könnte es mit sich selbst weiterentwickeln. Außerdem könnte man dann den Assembler mit sich selbst weiterentwickeln/debuggen. Und dadurch, dass der Assembler sehr portabel ist, könnte man ihn durch das Austauschen von wenigen grundlegenden Funktionen auf ein anderes System übertragen.

Bei Interesse bitte hier posten oder über ICQ (247390343) oder eMail (joachim_neu@web.de) melden.

Gruß,

Joachim

73

OS-Design / Dinge, Namen, usw.

« am: 23. December 2005, 22:39 »

Oder man macht eine recht überschaubare Klassifizierung wie "Input, Output, Speichermedium, Verarbeitung". Damit müsste man _etwa_ alle irgendwie unter einen Hut bringen. Der Anwender bekommt dann beim ersten Start des Mediaplayers einen Dialog gezeigt, in dem er ein Gerät aussuchen kann, dass der groben Klassifizierung (input, output, speicher, verarbeitung) entspricht und dann gehts los. So entsteht nie das Problem, dass ich für jede Geräteklasse den Kernel (und die Erkennungsmethoden) nachrüsten muss.

EDIT: Und der User wird wohl kaum das Gerät "Drucker" als Ausgabegerät nehmen, wenn drunter "Lautsprecher" oder "Soundkarte" steht. (Hoffe ich jedenfalls )

74

OS-Design / Kommunikation zwischen Modulen

« am: 23. December 2005, 22:35 »

Stimmt. Obwohl ich warscheinlich bei der wohl doch eher konventionellen Methode bleiben werde.
Sind die nachcompilierten Anwendungen von der Performance dann mit echtem Maschinencode gleich auf oder gibt es dort immernoch Nachteile?

75

OS-Design / Dinge, Namen, usw.

« am: 23. December 2005, 16:07 »

Wieso muss man klassifizieren?

76

OS-Design / Kommunikation zwischen Modulen

« am: 23. December 2005, 16:06 »

Ich habe bisher noch kein SharedMemory. Aber die Unsicherheit der anderen Mittel "rechtfertigt" nicht die Unsicherheit des eigenen Mittels, oder? Ist so ein Compiler nicht irre aufwendig?

77

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 16:03 »

Na ja - um ein Programm zu testen entwickel ich es, kompilier es dann, muss dann Administrator werden um es zu installieren und kann es dann erst ausführen? Und das für jeden einzelnen Build?

Achso, ich dachte man müsste das Teil dann beim Entwickler des OS "registrieren", damit der das in seine Tabelle aufnimmt...

78

Lowlevel-Coding / Diskette: int 13h im PM

« am: 23. December 2005, 16:02 »

Wenn du schon DMA machst, dann auch richtig ausführlich. Du kannst es ja 2teilig machen, wenn du Lust hast. Erst DMA und dann FDC mit Benutzung von DMA.

79

OS-Design / Theorie: Mögliche Benutzerreaktion auf Dateisystem-Idee

« am: 23. December 2005, 12:23 »

Das Nachteil ist klar: jedes noch so kleine Programm (auch selbstgeschrieben) muss beim Betriebssystem registriert werden. Der Vorteil wenn nur registrierte Programme ausgeführt werden können: Maximale Sicherheit und leichtes Management (u.A. Rechteverwaltung durch Root).

Sehr unpraktisch, finde ich... Das garantiert zwar fast 100%ige Sicherheit vor Viren, allerdings wird so auch niemand für dein System entwickeln, vorallem keine Hobby-Coder oder so. Und du musst ständig dein OS updaten. Oder zumindest die Tabelle, in der alle registrierten Programme stehen. Das bremst die Entwicklung/Benutzung eines OS enorm. Sollte es aber trotzdem "groß" werden, so wird man schnell Hacks finden, die die Tabelle entsprechend manipulieren um neue Programme installieren zu können.

80

Lowlevel-Coding / Diskette: int 13h im PM

« am: 23. December 2005, 12:18 »

*denktübereingroßestuorialnach*

Das wäre echt super.

So eins habe ich vor längerer Zeit einmal angefangen, mal sehen, ob ich das weitermache. Wenn jemand ein Tut schreiben will, kann ich ihm gerne meine Anfänge als Stütze geben.