Ich bin absolut Lukis Meinung und wenns sein muss, übersetz ich seinen Post gerne nochmal für euch:
Wie die Architektur letztendlich aussieht, ist für das Projekt relativ egal. Die Hauptsache ist, wir lernen alle etwas mehr über das Thema und haben unseren Spaß dabei.
--
Hm.. jo.. dass das Speichermanagement (als eigener komplexer Prozess) nicht vom Prozessor durchgeführt wird, ist mir gerade noch klar (so viel Know how hab ich grad noch *g*)..
aber was passiert denn, wenn ich wieder RAM freigebe? Ich hab mir das so vorgestellt, dass dann eben ein ein Maschinenbefehl durchgeführt wird der das löscht, was an entsprechender Stelle im Speicher steht (eben sowas wie ein "Delete") oder wird das, was da drinsteht tatsächlich nur freigegeben und quasi überschrieben, wenn ein neuer Prozess auf diesen Bereich des Hauptspeichers zugreift?
Exakt.Zitat von BeyondTheTruth
Deswegen ist es in C zum Beispiel wichtig Variablen mit dem Programmierer bekannten Werten zu initialisieren da sie andernfalls den Wert haben, der vorher da im Speicher stand an dem jetzt die Variable ist. Das kann "lustige" Ergebnisse haben.
Mmh. Wobei hier die Frage aufkommt, ob wir unserem Prozessor nicht schon "hardware*"-seitiges Multitasking und damit verbunden auch Speicherschutz beibringen könnten.
* Damit meine ich natürlich unsere virtuelle Prozessorhardware.
--Abwesend.
Genau an das, was Dingsi anspricht, habe ich auch bereits gedacht. Und so weit hergeholt ist das Konzept auch nicht. Wenn ich mich richtig erinnere, wollte bzw will doch Intel und andere prozessorhersstellen systeme in den prozessor integrieren, die nur die ausfuehrung verifizierten Codes zulassen und den Ram von Prozessen strikt trennen.
Jedenfalls gabs gegen dieses Vorhaben mal starke Proteste, weil man damit der Industrie komplett ausgeliefert worden waere. Andererseits koennten solche Konzepte auf unabhaengiger Basis, wie bei uns im Projekt, dem Programmierer viel Arbeit abnehmen. Eine CISC Funktion, die einem eine Addresse zu einem genuegend grossen Block im Speicherraum des aktiven Prozesses gibt oder wenn die Prozesskapselung bereits auf "Hardwareebene" durchgefuehrt wird, haette viele Vorteile. So waere es moeglich bei dem Wechsel des Betriebssystems solange Binaerkompatibilitaet zu wahren, wie nicht Betriebssystemspezifische bibliotheken verwendet werden. Zum anderen waere es Malware praktisch unmoeglich irgendwelchen Bloedsinn zu treiben, solange es ein anderer Prozess nicht gestattet.
Aber solche Konzepte kommen erst spaeter und sin d noch lange Zukunftsmusik ...
Genau darum soll es doch in diesem Projekt gehen. Dass wir uns gegenseitig etwas beibringen und uns gegenseitig neue Blickpunkte aufzeigen. Ausserdem haben wir ja noch gar nicht richtig abgefangen mit den Details. Das momentan viele Fachbegriffe um die Ohren fliegen, liegt nur daran, dass wir schon der ganzen sache etwas vorgreifen um eine grobe route abstecken zu koennen, und den anderen zu vermitteln, was unsere wuensche und vorstellungen an das Projekt sind. Ich denke, das ganze wird sich noch auf einem tieferen und vor allem erklaehrenderen Niveau einspielen ...
Und Fragen sind jederzeit erwuenscht.
--
Wollen sie immer noch. Trusted Computing gibt es immer noch - vor Allem jetzt, wo sich die Öffentlichkeit nicht mehr dafür interessiert.
BTW, in vielen Bereichen des Rechners sind CPU und RAM bereits getrennt. "DMA" heißt das Zauberwort.
Wird es mit einem halbwegs modernen Betriebssystem auch nicht. Ich persönlich halte Prozeßmanagement ohne Betriebssystem für Overkill (zumal wir für brauchbares Prozeßmanagement auch Kram wie Speichermanagement, Prozeß- und IO-Scheduler im Metall implementieren müßten - effektiv also ein Betriebssystem).
Was das prozessorinterne Multitasking und Speichermannagement angeht, so haette man mit einer so hohen Addressbreite von 96bit auch vorteile. Da man mit 96bit immerhin 2^36 EXAByte addressieren koennte, und es nicht abzusehen ist, dass soviel speicherplatz in den naechsten Jahrzehnten einem Rechner zur verfuegung steht (selbst wenn ich 1 bit in einem einzigen Wasserstoffatom speichern koennte, wuerde ich fuer diese menge Speicherplatz immer noch 132 kg Wasserstoff brauchen), waere es ja Platzverschwendung, den davon unbenutzten Addressraum ohne Information zu lassen. So koennte man den z.B. dafuer verwenden, jeden pointer mit der zugehoehrigen Prozess-/Threadnummer zu versehen und aehnlich wie bei Dateien Nutzerprivilegien fuer read, write und execute einzufuehren, sowohl fuer sich selbst, als auch fuer eine Prozessgruppe als auch fuer Fremdprozesse. Damit dann aber nicht jeder Prozess die Flags beliebig setzen kann, und den schutz damit aus den Angeln heben, wuerde man noch eine Checksumme in den Pointer einbauen. Ein Programm wuerde dann vom System ueber einen CISC Befehl einen Pointer auf einen Speicherbereich anfordern, analog zu dem, was in der C Runtimelib (m)alloc macht.
Eventuell koennte man also einige Probleme, die sich auf Betriebssystemebene stellen durch hardwarenahe Loesungen umschiffen. Natuerlich waere das ganze selbst fuer ein CISC System viel zu aufwendig, aber wozu gibt es denn noch das Bios ? Der prozessor braucht ja im Grunde nur das Addressierungsmodell und die elementaren Befehle fuer Multithreading unterstuetzen und kann dem Rest dem Bios ueberlassen.
--
Wenn wir Prozeßmanagement zur Verfügung stellen dann stellen wir per definitionem auch das Betriebssystem - weil unser BIOS dann nämlich so ziemlich alle Anforderungen erfüllt, um "Betriebssystem" genannt zu werden. IMO kann man den Kram dann auch gleich entkoppeln und lediglch ein Referenz-OS schreiben. Das sich vom von dir vorgeschlagenen BIOS nur marginal unterscheiden würde, aber nicht den Overhead eines kompletten Kernels erzwingen würde (beispielsweise, wenn man ein anderes Betriebssystem ausführen möchte).
Ich habe auf jeden Fall wenig Lust, den halben Unix-Kern nachzubauen (und Unix ist das einzige Betriebssystem, bei dem ich halbwegs weiß, wie die Prozeß- und Ressourcenverwaltung funktioniert).
Bei mir geht es momentan von Studium ehr drunter und drueber, weswegen ich keine Zeit habe, voranzupreschen. Ich Hatte das ganze auch nicht so kurzfristig geplant, sondern ehr so nebenherlaufend, das heisst, dass ich versuche, jede Woche ein paar neue Impulse zu geben und ein paar Dinge zu (er)klaehren versuche.
Der Thread ist ja auch dazu da, dass Fragen gestellt werden koennen, etc. Ich wollte eigentlich nicht gleich so hoch einsteigen, aber Jeez und DFYX haben schon die wichtigsten Prozessorbefehle aufgelistet. Ich denke, das Niveau wird sich schon noch einpegeln. Und es ist natuerlich jedem freigestellt, neue Anregungen und Erklaehrungen auszufuehren ...
--
Wenn es recht ist, würde ich gern eine kleine Einführung über die Speicherung von negativen Zahlen und Kommazahlen in den Tutorialthread schreiben.
Ich erwähne das weil ich a) keine Lust habe, da lang dran rumzutippen wenn mir dann einer fünf Minuten zuvorkommt und b) für so eine Mühe zumindest zwei Posts bekommen will! XD
Aber wenn's passt dann werde ich's morgen irgendwann posten.
Berechtigungen
Zitieren
