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 - DDR-RAM

Seiten: 1 ... 4 5 [6] 7 8 ... 10
101
Offtopic / Kleine Programmierspäße Teil 2 lol
« am: 26. May 2005, 18:22 »
Zitat von: Roshl
Sowas kann man extrem weit treiben, man fängt bei einfachen sachen an z.B. 1=1 und ersetzt dann immer wieder durch komplizierteres kann lustig werden und sehr undurchschaubar^^
(5*9^(cos(60°))*x)/(15*x)
sieht glaub ich keiner auf den ersten blick, dass das =1 ist^^


Das liegt an der Klammerung :D
Außerdem gilt das nur für x != 0 ;-)
Ich habe übrigens nicht bei 1 = 1 angefangen, aber ich bin noch auf der Suche nach der Erweiterung von natürliche auf positive rationale Zahlen.

MfG
DDR-RAM
102
Lowlevel-Coding / RISC CPU
« am: 26. May 2005, 18:17 »
Das mit den mehr Registern, gehört eigentlich nicht zur RISC-Architektur dazu, es die RISC's sind nur neuer und haben deshalb mehr Register. ;-)

die x86er sind ja abwärtskompatibel und viele weitere Register passen da nicht so richtig mit den Opcodes zusammen.

MfG
DDR-RAM
103
OS-Design / Zum Thema Mikrokernel
« am: 26. May 2005, 18:09 »
BOUND-Befehl? Verstehe nicht so ganz was der macht, irgendwas mit arraygrenzen checken? Ich raff den Befehl nicht ganz, kann mir den mal wer erklären, vielleicht mit Beispiel :D

Man könnte sich auch schützten, indem man nicht segmentierung "ausschaltet", sondern mit günstigen limits und bases fürs cs-segment.

Aber segmentierung ist fürn Ar***.

MfG
DDR-RAM
104
OS-Design / Zum Thema Mikrokernel
« am: 26. May 2005, 12:23 »
Zitat von: Legend
Ich sag nur Buffer Overflow. So startet sich ein Programm selber. Und dann ist ohne Speicherschutz direkt alles verloren. Mit Speicherschutz erstmal nur das, was das Programm tun könnte (was bei guten System SEHR viel weniger sein sollte).

Lösung -> Eine Technik nehmen die Buffer Overflow Angriffe gar nicht erst ermöglicht.


dieses göttliche gibt es mit dem amd64 :-)

MfG
DDR-RAM
105
Offtopic / Kleine Programmierspäße Teil 2 lol
« am: 25. May 2005, 17:28 »
ist kein Programmierspaß, aber nen Mathespaß, bin gerade auf folgendes gestoßen:

sin(nx) = 2^(n-1) * produkt(i=0 bis n-1; sin(x+i*pi/n) )

also z.B.:

sin(10x) = 512 * sin(x) * sin(x+1*pi/10) * sin(x+2*pi/10) * sin(x+3*pi/10) * sin(x+4*pi/10) * sin(x+5*pi/10) * sin(x+6*pi/10) * sin(x+7*pi/10) * sin(x+8*pi/10) * sin(x+9*pi/10)

hm,
106
Lowlevel-Coding / NASM Preprozessor
« am: 24. May 2005, 18:28 »
naja, liegt daran, das Isr0 keine Zahl ist, sondern wahrscheinlich eine Adresse. Die adresse ist allerdings zur assemble-time (so wie compile-time) noch nicht bekannt. die absolute adresse ist erst zur link-time bekannt. Ich weiß auch nicht, wie man das macht.
Man könnte das zur run-time machen, aber wäre nicht elegant.

Bin auch interessiert, ob jemand die Antwort kennt. :D

MfG
DDR-RAM
107
OS-Design / Kernel an virtuelle Adresse laden
« am: 22. May 2005, 18:45 »
nein, es wird eip gespeichert.
Dieser ist absolut ja.
Wenn man den Speicher an diesem EIP verändert bzw. paging einschaltet und da was falsch macht, dann hat man Probleme, sonst nicht.

MfG
DDR-RAM
108
OS-Design / Kernel an virtuelle Adresse laden
« am: 22. May 2005, 18:12 »
Zitat von: Roshl
Eigentlich nicht, da bei C ja Call benutzt wird und das gibt es soweit ich weiss nicht mit relativen Adressen


near calls sind eip-relativ, genauso wie near jumps.

MfG
DDR-RAM
109
tyndur / [KERNEL] Aufgaben/Verteilung
« am: 21. May 2005, 18:32 »
nein, feststehen tut nichts.
Aber T0ast3r beschäftigt sich damit im Moment.

MfG
DDR-RAM
110
tyndur / [KERNEL] Aufgaben/Verteilung
« am: 21. May 2005, 01:25 »
Wenn sonst keiner Lust hat, mach ich noch die Prozessverwaltung.

MfG
DDR-RAM
111
tyndur / [KERNEL] Aufgaben/Verteilung
« am: 20. May 2005, 12:24 »
Ich weiß zwar nicht genau, wie du dir das vorstellst, aber du kannst ja nen Vorschlag ausarbeiten, wenn es dir Freude macht :-)

MfG
DDR-RAM
112
tyndur / Re: GUI: Technische umsetzung
« am: 19. May 2005, 15:49 »
Zitat von: Golum
Was vielleicht noch zu ändern wäre ist das die GUI eingaben direkt abfragt aber dann müsste sie als Kernel-modul laufen.


Ich persönlich nehme sowieso immer weiter Abstand von einem echten Microkernel. Aber ich steh recht alleine da :-(
113
tyndur / GUI-Team
« am: 18. May 2005, 19:52 »
Also ich bin ja für möglichst flexibles Design,
also möglichst viel variabel einstellbar.

Und um den Windowsuser den Umstieg zu erleichtern :twisted:,

sollte auch Windowsartiges-Design angeboten werden.

MfG
DDR-RAM
114
tyndur / [KERNEL] Aufgaben/Verteilung
« am: 18. May 2005, 15:18 »
Hat niemand Lust?
Wenn ihr irgendwelche Fragen habt, könnt ihr mich via ICQ anquatschen.

Von folgenden Membern wird noch auf eine Meldung gewartet:
- maumo
- Stephan E.
- GhostCoder

(liste aus dem Thread KERNEL-Team, wer aus irgendeinem Grund nicht aufgeführt ist, aber trotzdem gerne mitmachen will, er ist hiermit autorisiert sich zu melden :D)

Ich hoffe auf wachsende Aktivität ;)

MfG
DDR-RAM
115
tyndur / Fragen zu: SDK Release Milestone 0
« am: 18. May 2005, 10:14 »
Zitat von: hannibal
das hilft mir schon ein bisschen weiter, danke!

(achja..waers vielleicht nicht von vorteil gleich ein wenig dokumentation in den src zu packen?)


Ich überarbeitete gerade x86.h, mit bisschen mehr doku ;-)

MfG
DDR-RAM
116
tyndur / Fragen zu: SDK Release Milestone 0
« am: 18. May 2005, 09:35 »
Hallo,

Zitat von: hannibal
ich hab mich mal versucht durch den schon vorhanden source-code durchzuwuehlen..(ich dachte immer ich koennte c++ ziemlich gut *hust!).. nur irgendwie hat mir das auch nicht viel gebracht..koenntet ihr mal irgendwie so ein kleines 'statement' abgeben zu den schon vorhandenen klassen:


// Descriptors

class CDescriptor;
class CSegmentDescriptor;
class CCodeSegmentDescriptor;
class CDataSegmentDescriptor;
class CTSSegmentDescriptor;
class CLDTSegmentDescriptor;
class CGateDescriptor;
class CCallGateDescriptor;
class CTaskGateDescriptor;
class CTrapGateDescriptor;
class CInterruptGateDescriptor;

template <int>
class CDescriptorTable;
class CLDT;
class CGDT;
class CIDT;

// Paging

class CPageTableEntry;
class CPageDirectory;
class CPageTable;

// Segments

class CTaskStateSegment;


waere vielleicht hilfreich..vor allem interessant waere fuer mich die CIDT-klasse...nur blick ich da nicht ganz durch, was da jetzt noch zu machen ist bzw was schon da ist.

lg, hannibal


Die CDescriptor-Klassen wrappen Deskriptoren in IDT, GDT und LDT(die wir allerdings nicht verwendent, die LDT).
Der Name verrät eigentlich schon sehr viel, welche Deskriptoren das sind.
Die Basisklasse CDescriptor bietet Funktionen, die für alle Deskriptoren verfügbar sind, z.B. GetPrivilege(), welches das im Deskriptor festgelegte Privileglevel zurückgibt.
Dann sind in der Klasse noch protected-Funktionen, diese stehen nur den Ableitungen zur Verfügung.
Das ganze spaltet sich dann in 2 Klassen, CSegmentDescriptor und CGateDescriptor. Ist eigentlich auch recht selbst erklärend. Auch diese Klassen stellen wieder Funktionen bereit, die für alle Ableitungen vorhanden sein sollen. Bei den Gatedeskriptoren ist noch zu beachten, das einige Ableitungen dann diese Funktionen doch nicht brauchen, z.B.
CTaskGateDescriptor braucht kein Offset, deshalb ist die Funktion als private deklariert, damit man nicht drauf zugreifen kann.

Die CDescriptorTable-Klassen, wrappen wie der Name schon sagt, verschiedene Deskriptortabellen, dieser gibt es 3,
die Interrupt Deskriptor Tabelle (IDT),
die Globale Deskriptor Tabelle (GDT),
die Lokale Deskriptor Tabelle (LDT)

CDescriptorTable ist als Template angelegt, mit einem Template-Parameter für die Größe der Tabelle.
IDT hat maximal 256 Einträge, GDT und LDT jeweils maximal 8192.
Auf die einzelnen Deskriptor zugreifen tut man über GetAt kann man auf einen Deskriptor an einer bestimmten position zugreifen.
IDT, GDT und LDT wrappen jetzt noch Deskriptortabellenspezifische Sachen.
z.B. CIDT::SetIDT, welches einen Parameter für die Anzahl der Einträge übernimmt. SetIDT selber, verwendet den asm-Befehl, lidt.
Ebenso GetIDT, du musst eigentlich keinen Pointer auf die IDT speichern.
CIDT::GetIDT() und du hast einen Zeiger auf die aktuelle IDT.

CPageDirectory wrappt ein PageDirectory, CPageTable wrappt eine Pagetable und CPageTableEntry wrappt PageDirectory sowie PageTable Einträge.

CTaskStateSegment wrappt letztendlich ein TaskStateSegment ;-)

Also beim nochmal drüberschauen, über x86.h fällt mir auf, das die Namensgebung teilweise recht grob ist, z.B. CGDT::SetGDT(WORD woSize), könnte einen Veranlassen, zu denken, das man die Größe der GDT in Bytes übergeben muss, es müssen aber nur die Anzahl der GDT-Einträge übergeben werden.

Für Beispiele, lohnt ein Blick in exception.cpp und paging.cpp

MfG
DDR-RAM
117
tyndur / [KERNEL] Aufgaben/Verteilung
« am: 18. May 2005, 09:00 »
das hier ist dafür der falsche Thread, ich beantworte dir die Frage im Thread Fragen zu: SDK Release Milestone 0

Hier bitte nur Implementationsvorschläge und Meldungen zum mitmachen an den Teilbereichen.
Du wolltest auf jeden Fall schonmal IDT-Management mitmachen?

MfG
DDR-RAM
118
tyndur / [KERNEL] Aufgaben/Verteilung
« am: 17. May 2005, 22:28 »
Hallo,

ich liste mal die zu verteilenden Aufgaben auf und was dazu gehört und wer sich wofür angemeldet hat:
  • Verwaltung von IDT, aufsetzen einer IDT, Interrupts und IRQ andordern/freigeben - hannibal
  • Verwaltung von GDT, aufsetzen einer GDT, Deskriptoren anfordern/freigeben - urx_
  • Die physische Speicherverwaltung, Anforderung und Freigabe von physischen Speicherseiten - n3Ro
  • Die virtuelle Speicherverwaltung, spielt in die Prozessverwaltung mit rein, reservierung und Freigabe von Speicherbereichen im virtuellen Adressraum eines Prozesses, ändern von Flags
  • Der Heap, brauch ich nit erklären da bereits erledigt - DDR-RAM
  • Pager, einklinken in Interrupt 14, bereitstellen von zuvor reserviertem Speicher, Access Violation/Segmention Fault auslösen
  • Die Prozessverwaltung, Prozesse, Threads, Scheduling, einklinken in IRQ 0, Dispatching - DDR-RAM
  • Überprüfen der CPU-Features, Verfügbarkeit von PSE,RDTSC etc. - Roshl
    [/list:u]Zusatz:
    T0ast3r arbeitet nen Vorschlag für die Api aus.

    Diese Liste basiert auf dem Dokument "Kerneldesign Milestone 1" und dem SDK von mastermesh.
    So, wer Intresse daran hat an irgenwelchen Bereichen mitzuwirken, der sollte sich in diesem Thread dafür melden.
    Auch Implementationsvorschläge können in diesem Thread diskutiert werden.

    MfG
    DDR-RAM
119
tyndur / [KERNEL] SDK Release Milestone 0
« am: 17. May 2005, 21:29 »
ist irgendson komischer Fehler, du musst evtl. die kernel.elf nachkopieren
(nach A:\system\kernel.elf).
Kann sein, das es dein Fehler ist, vielleicht auch nicht ^^,
aber das nachträgliche kopieren sollte helfen.

MfG
DDR-RAM
120
tyndur / [KERNEL] SDK Release Milestone 0
« am: 17. May 2005, 21:14 »
Zitat von: sov21
Jetzt gehts :-)


auf all deinen PC's?
Seiten: 1 ... 4 5 [6] 7 8 ... 10

Einloggen