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.
Mir gehts ähnlich - zwar kenn ich die ganz ganz grundlegensten Dinge was den Aufbau und die Funktionsweise eines Prozessors und PCs angeht - aber bei fehlen der Dikussionen die hier schon geführt wurden, würd mir doch noch ein größerer Happen Know How fehlen, um mich dazu äußern zu können.Zitat:
Zitat von o_O
V.A. was die Befehlssätze angeht (da ich mich mit ASM selbst noch nie wirklich beschäftigt hab)..
deswegen sollte man mir verzeihen, wenn die Frage vielleicht absolut schwachsinnig ist :D :
Müsste es nicht neben den Speicherzugriffbefehlen "Store" und "Load" nicht theoretisch auch einen zum Freigeben des Speichers geben ("Delete" oder so)?
Ich glaub also net unbedingt, dass ich hierfür geeignet bin - aber werdet ihr euer Projekt, eure Gespräche und eure Resultate regelmäßig im Forum veröffentlichen, damit sich auch andere dran erfreuen und vielleicht doch zumindest ein BISSCHEN dazulernen können? ;)
Inwiefern freigeben?Zitat:
Zitat von BeyondTheTruth
Es ist so: Der Prozessor hat einfach nur den RAM und seinen internen Speicher (Cache und Register, allerdings wird auf den Cache nicht direkt zugegriffen). Was im RAM ist ist dem Prozessor egal und mit Dingen wie diskreten Speicherbereichen kann er gar nichts anfangen; das ist eine Sache, die auf Betriebssystemebene und höher stattfindet. Der Prozessor kennt lediglich Befehle, die aus einer bestimmten Speicherzelle etwas in ein Register laden (LOAD) und welche, die etwas in den RAM schreiben (STORE). Das ist alles, was der Prozessor in Bezug auf den Speicher können muß. Welchem Prozeß ein Speicherbereich gehört weil der Prozessor nicht - er weiß nicht mal, was ein Prozeß ist. Er arbeitet stumpf sein Programm ab.
Daß Speichermanagement außerhalb des Prozessors stattfindet kann man ganz gut erkennen, indem man das Speichermanagement verschiedener Betriebssysteme betrachtet:
- MS-DOS hatte nur den Speicher, der auch im Rechner verbaut war. Wenn man mehr RAM brauchte als man hatte dann hatte man Pech gehabt. MS-DOS hatte kein großartiges Speichermanagement. Der Prozessor bietet sowas nicht und bei MS-DOS war noch nichts dafür geschrieben.
- Windows bis einschließlich Me hatte virtuellen Speicher: Das Betriebssystem tut so, als wäre mehr Speicher da, als es tatsächlich gibt. Wenn der Speicher nicht reicht wird einfach was auf die Festplatte verschoben (Swapping). Allerdings waren die einzelnen Speicherbereiche nicht voneinander getrennt; ein Programm konnte im Speicherbereich eines anderen Programms herumschreiben. Hier hatten die Programmierer die Möglichkeiten bereits stark erweitert - aber der Prozessor wußte davon nichts.
- Windows nach Me und praktisch alle Unixartigen der letzten zehn Jahre haben virtuellen Speicher, in dem zusätzlich die einzelnen Programme voneinander isoliert sind. Moderne Speicherverwaltung ist sehr weit vom Prozessor entfernt - der hat immer noch gar kein Problem damit, wild im RAM herumzuschreiben, aber das Betriebssystem verhindert das.
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:
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.Zitat:
Zitat von jeeeeez!
* Damit meine ich natürlich unsere virtuelle Prozessorhardware.
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 ...Zitat:
Ich glaub also net unbedingt, dass ich hierfür geeignet bin - aber werdet ihr euer Projekt, eure Gespräche und eure Resultate regelmäßig im Forum veröffentlichen, damit sich auch andere dran erfreuen und vielleicht doch zumindest ein BISSCHEN dazulernen können?
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.Zitat:
Zitat von Ineluki
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).Zitat:
Zum anderen waere es Malware praktisch unmoeglich irgendwelchen Bloedsinn zu treiben, solange es ein anderer Prozess nicht gestattet.
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).
Ihr wollt verrückt? Ich gebe euch verrückt. Hier ist eine Idee, die ich gerade mit Ineluki per Jabber diskutiert habe:
Habt ihr schon mal was von UFS gehört? UFS ist das Unix File System, ein uraltes Dateisystem für System V-Unix. UFS ist der Archetyp für Unix-Dateisysteme: An der Uni habe ich UFS gelehrt bekommen und ext2 basiert auf den gleichen Prinzipien.
Das (für uns) Interessante am UFS ist, daß man es benutzen kann, um den Hauptspeicher zu verwalten. Luki und ich haben darüber gesprochen, Metadaten im Hauptspeicher abzulegen; bestimmte Speicherbereiche würden dann einen Eigentümer und Zugriffsberechtigungen haben, womit man Zugriffsschutz realisieren könnte. Beim UFS wird das über die traditionellen Unix-Dateiattribute gemacht.
Die Prozeßstruktur des Systems (Luki überlegt ja, daß der Prozessor oder das BIOS interne Unterstützung für Prozeßmanagement kriegen soll) läßt sich problemlos auf ein Dateisystem abbilden: Prozesse sind Mountpunkte, Threads sind Verzeichnisse und die von diesen Threads reservierten Speicherbereiche sind Dateien. Für jeden Speicherbereich wird in der Dateitabelle (genauer gesagt in einem Inode) abgelegt, welche Bereiche im RAM er belegt, wem er gehört, wer Zugriff darauf hat...
Zugegeben, es ist ein bißchen wahnsinnig und fies für die Performance, aber es funktioniert und ist irgendwie cool...
Verbinde das ganze mit Nanospeichern aus Metalloxiden und du hast einen Supercomputer, der sogar funktionieren würde.
Also ich bin dagegen, vor allem, weil das nach irre viel Zusatzaufwand aussieht. Wenn es schon jetzt "das wohl verrückteste Projekt des Programmierforums" ist, muss es nicht noch auch noch wahnsinnig werden. o_O Nachdem nicht sehr viele Projekte hier tatsächlich fertiggestellt werden, sollten wir nicht gleich am Anfang größenwahnsinnig werden.
Wobei das ja leider so aussieht, als könnte man's auch nur schwer hinterher hinzufügen. ("Sieht so aus" in beiden Fällen, da ich keine Ahnung habe. http://www.multimediaxis.de/images/s.../old/szuck.gif)
Aber eigentlich wollte ich fragen, wann es denn (mit Threads zu anderen Komponenten) weitergehen soll, bzw. wie letztendlich die Entscheidung getroffen wird. Ich meine, im Moment sieht's so aus, dass sich hier ziemlich genau zwei Leute wirklich auskennen, und die anderen nur - qualitativ unterschiedliche - Laien-Meinungen abgeben können. Was natürlich zu erwarten war, da das Projekt ja vor allem diktatischen Nutzen haben soll (ich für meinen Teil habe schon jetzt mein Hardware-Wissen verdreifacht o_O'), aber wie (und wann) wird nun die endgültige Entscheidung bei den einzelnen Komponenten getroffen? Z.B. jetzt beim Prozessor?
Zwar ist es ja nicht wirklich dringend, wir haben schließlich keinen Zeitplan, aber ich glaube nicht, dass da noch irgendwelche größeren Vorschläge kommen könnten und die meisten grundlegenden Sachen wie Bitigkeit, Registerbreite, etc, wurden ja schon diskutiert und halbwegs eingegrenzt.
Ich wusste nur nicht, ob der Post eher hierhin oder in den Prozessor-Thread gehört. http://www.multimediaxis.de/images/s.../old/szuck.gif
Och, das hätte ich jetzt eh nicht umgesetzt. Aber man kann sich die Idee für ein alternatives BIOS merken.Zitat:
Zitat von drunken monkey
AFAIK ist es so geplant, daß wir erst mal Brainstorming machen und Ideen, bzw. Konzepte sammeln. Später machen wir uns dann daran, die Designziele und -methoden festzulegen und dann kommt die Implementationsphase.Zitat:
Aber eigentlich wollte ich fragen, wann es denn (mit Threads zu anderen Komponenten) weitergehen soll, bzw. wie letztendlich die Entscheidung getroffen wird.
BTW, ich habe als einen der Kurse in diesem Semester Programmierbare Digitallogik und VHDL-Synthese, wo es im Wesentlichen darum geht, integrierte Schaltungen zu entwickeln. Erwartet also, daß ich am Rande inkonsequentielle Hardwarekommentare fallen lasse.
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.