Lowlevel
Lowlevel => tyndur => Thema gestartet von: T0ast3r am 05. June 2005, 14:03
-
Da man ohne API nicht viel anfangen kan, finde ich ist es jetzt Zeit sich mit ihr zu beschäftigen.
Am Anfang würde ich jeden API Aufruf über Interrupts machen.
(Später eine andere Lösung)
Dabei würde ich die API aber gleich in mehreren Teilen abgrenzen, und jeden Teil ein Interrupt zur Verfügung stellen.
z. B. Interrupt 30 = System Calls
Dann würde ich die Funtkionsnummer in AX oder EAX übergeben, und der Rest maht dan die API.
Es sollte halt bei jedem API Interrupt eine Art Teiler sein, der die API Funktionsnummer liest, und dann zur richtgen Funktion springt.
Zudem würde ich möglichst bald anfangen an ihr zu programmieren.
Schreibt eure Vorschläge hier rein....
-
Vorschlag:
1. API ab 0x30 INT anlegen
2. Aufrufnummer in EAX übergeben
3. API-Ints unterteilen
API0 (0x30) = Taskapi
Funktionen:
0x00000000: Taskwechsel einleiten
0x00000001: Task erzeugen
.
.
.
API1 (0x31) = Treiberapi
Funktionen
.
.
.
;)
J!N
-
da wir ja einen mikrokernel in C++ haben finde ich, dass wir das ganze nicht ueber asm, sondern eher ueber normale C/C++-funktionen angehen sollten.
wie waers mit statischen libs (vorerst), und spaeter mal dynamischen (alà dlls)?
-
jo, aber worauf soll die STDLIB zugreifen? INTs brauchste.
-
Einen großen Teil müssen wir aber in asm mahen, da die API ja eine Schnittstelle zwischen den Computer und dessen Hardware ist, und das in C sehr müsam ist, alle Funktionen die man in asm schreiben muss zu implementieren.
Wobei wie gesagt, es gibt ja eine Unterteilun.
Da würde ich die System Calls eher in asm schreiben, und unwichtigere Teile dann in C.
-
Wäre ich auch dafür, auch in asm...schließlich ist ein C-Wrapper schnell geschrieben...
-
bloede frage, aber was genau soll denn die API beinhalten, was mit C nicht auch moeglich waere?
nicht, dass ich euch was dreinreden koennte bezueglich API in asm, aber mich wuerds hald interessieren ^^
-
Ist egal, womit mans schreibt. Ist eigendlich total egal. Man muss nur eine STDLIB für die API für C schreiben. Die muss dann die INTs und die echte API benutzen. Ich bin dafür, eine komplette STDLIB erstmal zu coden, basierend auf der API, und dann richtig an Konsole und ggf. GUI zu gehen. Dann hat man alles in der Tasche und kann auch Code portieren. ;)
-
Also ihr braucht eigentlich in ASM nur eine Funktion die man syscall nennen könnte zu schreiben. Diese nimmt einen Pointer auf eine Struktur mit den registern (oder die Struktur direkt selber?), lädt die alle, und ruft den Interrupt auf. Danach wird noch das Ergebnis gesichert. Der Rest kann dann in C unter Benutzung dieser Funktion gemacht werden.
-
OK, dann erstellen wir zuerst eine STDLIB.
Wenn dass das ist was ich glaub dann eben eine Art Library die in asm geschrieben wird und dazu dient, den Code in C funtkionen bereit zu stellen, die nur in asm machbar sind.
Wenn's so ist, dann ist es gut. *lol*
Dann schreiben wir eben die eigentliche API in C. *grrrr*
-
Dann schreiben wir eben die eigentliche API in C. *grrrr*
Ist ja eigentlich egal nur musst du dann einen header für C schreiben.
Mann kann ja auch assemblercode zu C dazu linken.
-
Gibt's von eurer Seite irgendwelche Vorschläge wegen der Unterteilung der API?
Also welchen Ints würdets ihr welhce API-Teile zuordnen?
-
Hi,
bei mir implementiere ich Syscalls folgendermaßen:
Assembler funktion "_syscall" wird von einem Int 0x80 aufgerufen, mit den Parametern in eax,ebx,ecx,edx,esi und edi: Diese Funktion pusht alle Werte und ruft die C Funktion
"syscall(int r1,int r2,int r3,int r4,int r5,int r6);" auf. Und in den Werten wird dann über ein beliebiges Register die Funktionsnummer und in dem Rest die Parameter übergeben. Fertig!
Warum mehrere Interrupts nehmen? mit o.g. Methode hast du alles übersichtlich in einer Funktion.
Gruß GhostCoder
-
Wenn man verschiedene Interrupts nimmt hat man mehr Register für Parameter zur Verfügung ;-)
-
Das man mehrere Register hat hab ich gewusst....... :wink:
Ich wollt's halt mit merheren Ints machen, damit alles schön übersichtlich bleibt.
Wobei ich immer die Meinung der Mehrheit unterstütze, also sollten sich jetzt auch mal andere melden. :wink:
Bei mehreren Ints könnte man dann so schön sagen, dass Int 30h Taskapi ist, 31h Systemcalls, 32h .......
-
Ich finde die Lösung mit Interrupts auch besser und als Sprache sollte man ASM nehmen, weil Assembler deutlich schneller und flexibler als C ist. Eine Frage, weiß jemand wie Windows die DLL's verwaltet? Man könnte die API nochmals unterteilen, zu einem die grundliegenden Funktionen mithilfe von Int's implementieren und die GUI- und Zusatzfunktionen mithilfe von dynamischen Bibliotheken(like DLL), die wiedrum auf Grund-Api aufsetzen, so könnte man GUI-Elemente schnell ersetzen, ohne ganze API neu kompilieren zu müssen..... Außerdem sollte man mit der Anzahl der Interrupts nicht übertreiben, nicht so dass jeder Int nur 2-3 Funktionen enthält.....
-
Wenn man verschiedene Interrupts nimmt hat man mehr Register für Parameter zur Verfügung
Klar, wenn man für jeden Systemcall einen INT nimmt, sonst net :)
weil Assembler deutlich schneller und flexibler als C ist.
Ãhm, ja natürlich... :)
Nochwas:
Ich macht doch einen Mikrokernel, oder? Wenn ja, müssen die einzigen Syscalls doch Messaging Funktionen sein.
Gruß, GhostCoder
-
Also ihr solltet per Syscall Möglichkeiten bereitstellen mit einer einheitlichen(!) Abstraktion der Treiber und anderen Funktionen zu arbeiten.
Sowas direkt per Int zu machen -> siehe DOS.
-
Jap, das ist aber das sollte eigentlich kein Problem sein.
Jetzt sollten wir bald mal eine Unterteilung machen...
-
@Legend:
Und Messaging(IPC) ist genau diese Abstraktion. Eigentlich alle Microkernel basieren auf diesem Prinzip
Sowas direkt per Int zu machen -> siehe DOS.
Sorry, wenn das jetzt blöd klingt: Was meinst du damit?
Gruß GhostCoder
-
Ich z.B. sage
PC Speaker Standard Beep - INT 0x54
EAX: 0001
PC Speaker Custom Beep - INT 0x54
EAX: 0002
EBX: Frequenz
Soundkarte öffnen - INT 0x56
EAX: 0001
Sounddaten schreiben - INT 0x56
EAX: 0002
EBX: Pointer auf den Puffer
usw.
das meine ich mit einem schlechtem System. Zwar kann man dahinter dann Treiber hängen, aber eine neue API hinzufügen, wird auch Ãnderungen (oder zumindstens unter mitbenutzung) von Bereichen passieren müssen (IDT und so was).
Wenn man einen Microkernel hat wird man sicher irgendwo IPC benutzen müssen - wie sonst will man vernünftig die Prozessgrenzen überwinden. Aber das sind nur die Primitiven (die auch an anderen Stellen von Programmen direkt benutzt werden, besonders die zur Synchronisatzion).
Die richtige Abstraktion baut man sich dann daraus auf (z.B. Corba, DCOM mit IPC statt TCP/IP).
-
Also ich find das System nicht so schlecht.
Die Libs werden ja auf dem Lafwerk in seperaten dateien gespeichert, was es jeden erlaubt, die alten zu löschen und sie durch neuere zu ersetzen.
-
Also ich finde es ist sehr oft ein Zeichen von schlechtem Design, wenn man etwas macht, um es in einer Lib zu verstecken. Wozu baut ihr das dann so zuerst?