[PCN] Project Carpe Noctem - Das wohl verrueckteste Projekt des Programmierforums

Aloa liebe Freunde der LowLevel Programmierung.

Um unser allseits geliebtes Progforum ein wenig zu beleben, und euch mal wieder etwas zu foerdern und zu fordern, habe ich mich dazu entschlossen, das Carpe Noctem* Projekt ins Leben zu rufen.

Carpe Noctem ist ein projekt, bei dem wir alle sehr viel lernen koennen, und nicht nur ueber das Programmieren, sondern ueber die Funktionsweise von Computern im Allgemeinen. Auch diejenigen unter euch, die denken, dass sie bereits erschoepfend ueber dieses Thema bescheid wissen, werden feststellen, dass sie durch dieses Projekt schnell an ihre Ggrenzen stossen werden, und auch diejenigen, die sich noch nie mit der Thematik der LowLevel Programmierung befasst haben, koennen nicht nur eine Menge lernen, sondern sich genau so daran beteiligen, wie die Profis.

Doch genug der langen Vorrede, worum geht es bei Carpe Noctem ?
Ziel dieses Projektes ist es, uns einen eigenen Computer zu bauen. Allerdings nicht einen aus Transistoren, Wiederstaenden und Kabeln, sondern einen virtuellen Computer in unserem Rechner, und das ganze auch noch plattformunabhaengig.

Das, was VMWare fuer einen ganz normalen x86 ist, wollen wir im Capre Noctem Projekt fuer unsere ganz eigene Rechnerarchitektur bauen. Angefangen bei der Entwicklung des Prozessors, der unseren ganz eigenen Befehlssatz und Assemblercode verstehen wird, arbeiten wir uns weiter ueber Ein- und Ausgabeports bis hin zu Graphikkarte und grundlegenden Biosroutinen. Fuer die ganz Hartgesottenen unter uns, koennte man eventuell sogar (in ferner Zukunft) einen C-Compiler bauen und die gcc cross compilieren. Wie ihr seht, bietet dieses Projekt fuer jeden in jedem Schwierigkeitsgrad eine Herausforderung.

Natuerlich koennte man sich fragen, was einem ein solches System jenseits des didaktischen Nutzens bringt. Natuerlich steht der didaktische Nutzen im Vordergrund, und der Spass an der Aufgabe selbst, aber man kann auch weiter denken. Unser wirtueller Computer koennte fuer uns eine Art VM sein, die unsere Programme in einer sicheren Umgebung aehnlich der Java-VM als bytecode ausfuehrt. Und wer weiss, vielleicht stossen wir bei unserer Umsetzung ja auf Sichtweisen, die uns irgendwann einmal in die Lage versetzen, ein reales Computersystem auf dieser Basis zu bauen, ohne auf Kompatibilitaet zu proprietaeren Loesungen achten zu muessen.

****************************************************************

In diesem Thread wuerde ich gerne eure Meinung und euer Interesse an diesem Projekt hoehren und Anfangen, die allgemeinen Probleme dabei auf theoretischer Ebene zu diskutieren. Mir ist klar, dass dieses Projekt sehr sehr komplex und gross ist. Allerdings gehe ich auch nicht davon aus, das wir es in den naechsten Jahren abschliessen, sondern als gemeinschaftliches Proforumprojekt schrittweise und in lockerer Athmosphaere ausbauen.

Die einzelnen separaten und konkreteren Aspekte des Projektes koennen dann in separaten Threads fortgefuehrt werden, z.B. ein Thread, der sich mit den Notwendigkeiten unseres Prozessors und seiner Maschinensprache auseinander setzt.

Die Diskussion ist freigegeben.

Gruss Ineluki

* Das Projekt hiess urspruenglich "Carpe Diem", wurde aber auf vielfachen Wunsch in "Carpe Noctem" umbenannt.

Warum nicht?

*terminkalenderanschau* Hm... ziemlich voll. EGAL!!! *allesstreich* Super Idee, ich bin dabei.

Interessiert mich schon ein wenig (auch wenn's Low Level ist). Wobei ich mal vermute, dass ich bei vielen Bereichen (z.B. Entwurf des Befehlssatzes) Aufgrund nicht vorhandener Erfahrung nicht mithelfen könnte.
Mal sehen, was draus wird.

Jeez ... kennst du vielleicht noch jemanden an der Uni, den das interessieren wuerde ?
Frisches und kompetentes Blut ist doch was feines fuer uns Programmiervampire ...

Interesse hab ich schon, aber eigentlich genug zu tun. :'(

Intresse Ja, aber
Fähigkeiten:

Code:

---

Piep - UserNotQualifiedException

---

Was genau meinst du mit Low Level Programmierung? Ich finde das klingt alles relativ High...^^

edit:
k, frage beantwortet^^

Zitat:

---

|16:53:54| • |![ASV-TSC]Ineluki| low level wird i.A. systemnahe Programmierung bezeichnet, also das erstellen von Betriebssystemen und Assemblercode
|16:54:04| • |![ASV-TSC]Ineluki| oder das schreiben von Treibern

---

Interesse: Ja, mehr als genug
Zeit: Hm, ja, doch, sollte ich haben
Motivation: Naja, das is so ne Sache. Aber hey, ich hab auch nicht weniger Motivation hier mitzumachen, als was anderes zu machen ^^
Kenntnisse: Absolut 0. Ich weiß gerade mal so, was low level ist. ^^

Im offiziellen Progforum IRC Channel wurde soeben der Antrag gestellt, das Projekt in Carpe Noctem umzubenennen. Schließlich nutzen wir als Programmierer den Tag hauptsächlich zum Schlafen.

Mhm fände es zwar interessant, aber wäre mehr daran interessiert Software sprich ein Betriebssystem für das System zu entwickeln. Dazu müssten aber dann auch entsprechende Datenbläter existieren. Bzw. man müsste ein Team für ein BIOS zusammenstellen. So etwas ind er Art würde ich lieber machen, da ich mit mit Platformunabhängigkeit usw. nicht alzusehr auskenne.

Hm .. dann laesst sich aber das Akronym von Project Carpe Diem (PCD) nicht mehr als Backronym von Personal Computer Decompiled benutzen ...

Aber wenn ihr unbedingt wollt ... Carpe Noctem hatte ich als zweite Alternative ohnehin im Sinn.

Klingt nett und nach viel Arbeit. Vielleicht zu viel Arbeit für normalsterbliche, faule Programmierer. Aber mir ist auch noch nicht ganz klar, wie das ganze funktionieren soll. Wird der virtuelle Computer dann sowas wie ein Vermittler zwischen dem PCN und dem echten PC, d.h. der Maschinencode wird nur übersetzt? Oder wird der Maschinencode des PCN durch Hochsprachfunktionen des PCs verarbeitet, d.h. es werden auch vorhandene Gerätetreiber bzw. Schnittstellen genutzt? Ersteres wäre unheimlich viel Arbeit und Zweiteres wäre später unheimlich langsam.
Also ich hätte vielleicht auch Spaß daran, falls es sich nicht als zu zeitaufwendig herausstellt.

freundliche Grüße, Rolus

Genau solche Fragen werden wir Gemeinschaftlich besprechen ...
Schliesslich liegt das Hauptaugenmerk auf dem didaktischen Wert, insbesondere sich um solche Dinge auch mal gedanken zu machen. ^^

Fuer den Anfang sollte eine Interpretation des Maschinencodes und die Emulation von Ports etc durch Streams ausreichend sein ... Wie gesagt, das ganze soll Schritt fuer Schritt erfolgen und mehr auf der Theoretischen als auf der Implementativen Seite liegen.

Am Ende werden wir wohl eine gut dokumentierte Spezifikation haben mit einem Beispielinterpreter, wo natuerlich jedem freisteht, selber einen effizienteren eigenen Interpreter zu bauen ^^

Ich würde auch mirmachen, bloß muss ich mich meinen Vorrednern anschließen - meine Erfahrung in LowLevel Kram besteht darin, dass ich mal ein paar ASM-Progs kopiert und kompiliert habe :P

Passt doch gut, wir sind ein Haufen interessierter Coder, von denen keiner ne Ahnung vom Thema hat. Ich würde mal sagen, auch wenn wir das Rad neu erfinden, führt uns das vielleicht genau zu dem, was keiner erwarten würde: zu einem genialen Ergebnis, bei dem sich jeder Fragt, warum da noch keiner drauf gekommen is.

Zitat:

---

Zitat von dead_orc

Interesse: Ja, mehr als genug
Zeit: Hm, ja, doch, sollte ich haben
Motivation: Naja, das is so ne Sache. Aber hey, ich hab auch nicht weniger Motivation hier mitzumachen, als was anderes zu machen ^^
Kenntnisse: Absolut 0. Ich weiß gerade mal so, was low level ist. ^^

---

Absolutes und uneingeschränktes "Dito"! :A Wann geht's los? :D

Und "Carpe Noctem" ist wirklich passender! ^^ Fehlt nur noch ein richtig nerdiges rekursives Akronym...§shifty

macht nicht wieder ein externes forum, wenn ich das mal so einwerfen dürfte.
nur son gedanke.
gute idee, btw. mal sehen wie sich das ganze entwickelt^^

Ein externes Forum halt ich in dem Fall für kontraproduktiv. Das Projekt soll hier ja etwas Leben in die Bude bringen.

Das mit dem nicht-externen Forum hab ich schon lange vorgeschlagen gehabt. :O Okay, nicht im Forum, aber das ist ja egal...

Zitat:

---

Zitat von Manni

Ich würde auch mirmachen, bloß muss ich mich meinen Vorrednern anschließen - meine Erfahrung in LowLevel Kram besteht darin, dass ich mal ein paar ASM-Progs kopiert und kompiliert habe :P

---

Bei mir ist es noch schlimmer, ich hab' noch nie was im LowLevel-Bereich erstellt^^... Außerdem habe ich (noch?) nicht das Glück gehabt, mich irgendwie in einer "Schulung" o.Ä. in dem Bereich weiterzuentwickeln. Meine Programmierkenntnisse beruhen ausschließlich auf Try&Error-Grundlagen^^...

Das Projekt werde ich wahrscheinlich mitverfolgen, aber direkt mitmachen werd' ich wohl nicht, dafür habe ich zuwenig Ahnung von der Sache^^...

naja ich hab zwar einwenig ahnung in low level programmierung. Aber das nur auf dem 8085 mit Assambler. Daher ist mein wisen nicht ganz umfang reich. Aber kann zur not immer noch mal meinen ehemaligen Lehrer Fragen bei dem ich 2 jahre Assambler hatte.

Also es ist sehr interessant, mal sehen was daraus wird.

Meine Lowlevel-Erfahrungen beschränken sich im Wesentlichen darauf, daß ich mich mal oberflächlich mit Prozessortechnologie befaßt habe - Befehlspipelines, Branch Prediction, etc. Oh, und natürlich Technische Informatik 1, wo Kram die die Von Neumann-Architektur und der grundlegende Aufbau eines Prozessors drankamen.


Was die Uni angeht, da könnte ich u.U. mal rumfragen. Den passenden Kurs gibt's leider erst im Hauptstudium.

Ok, das Interesse ist schon einmal vielversprechend. Hoffen wir auch, dass sich auch rege an dem Projekt beteiligt wird.

Fuer jeden Teil des Projektes wird ein eigener thread aufgemacht. Dieser Thread hier dient als allgemeiner Diskussionsthread, in dem man das besprechen kann, was nicht in die anderen threads gehoehrt.

Doch nun zu meiner Vorstellung, wie das Projekt geplant wird.

Jede Planung eines Teilaspektes des Projektes erfolgt im Prinzip in drei Schritten
1.) Sammeln von Informationen
2.) Definieren unserer Spezifikation
3.) Implementation

Im 1.) Schritt kann im Grunde jeder mit machen, auch wenn er keine Ahnung von Programmierung hat. Dieser Schritt ist in der Regel der groesste und wichtigste Teil jedes Abschnittes. In einer Art Dialog werden wir uns allgemeine und speziellere Fragen stellen und diese in Informations- und Tutoriensammlungen beantworten. Hier kann jeder etwas beitragen. Ob es nun das Heraussuchen von Definitionen aus der Wikipedia oder der Wunsch bzw eine Idee zur Implementierung eines bestimmten Features ist. Hierbei ist der Weg das Ziel. Wir versuchen also zu erreichen, auch denen, die sich noch nicht mit dem Thema beschaeftigt haben, einen Ueberblick ueber das Thema zu verschaffen und eine Datensammlung aufzubauen, auf die wir auch spaeter noch einmal zurueck greifen koennen. Die wichtigsten Daten, Definitionen und Entscheidungen sollten im Anfangspost des Threads festgehalten und jeweils ergaenzt werden.

In Schritt 2.), der teilweise bereits zwaehrend Schritt 1.) stattfinden kann, greifen wir aus unserer Diskussion die Features heraus, die wir im dritten Schritt implementieren wollen, und definieren genau, wie und mit welchen Mitteln das zu erfolgen hat. In diesem Schritt schreiben wir also die Dokumentation und Spezifikation unseres Systems.

Im letzten Abschnitt geht es schliesslich um die konkrete Realisierung dessen, was wir im Abschnitt 1.) und 2.) besprochen und festgelegt haben. Hier ist der Raum, um kleine Codesniplets und Implementierungsvorschlaege zu posten und eventuell geschriebenen Sourcecode zum Download anzubieten.

Waehrend Abschnitt 1.) eine kunterbunte und oftmals undurchsichtige Diskussion sein wird, sprich der Teil, mit dem wir Arbeiten, stellen 2.) und 3.) die gefilterten und auskristallisierten Gedanken und Ergebnisse unserer Arbeit dar.

Als erstes denke ich, wird es von Nutzem sein, sich mit dem Prozessor unseres Systems zu beschaeftigen ... denn er bildet das Kernstueck des gesamten Projektes ...

Zum Prozessor Diskussions Thread

Wichtige Frage!

Planen wir eine real umsetzare Architektur oder eine reine VM?

Ich diskutiere gerade mit Luki über genau dieses Thema, denn die beiden Ansätze führen zu radikal unterschiedlichen Vorgehensweisen:

Wenn wir eine reale Architektur planen müssen wir darauf achten, daß das Geplante auch umsetzbar ist - einen 32bittigen RISC-Prozessor könnte man mit einem PGA noch selbst konstruieren, aber ein 96bittiger CISCer mit 256 Registern wäre völlig absurd. Außerdem müßten wir uns über Implementierungsdetails Gedanken machen, die man in einer VM nicht braucht: Kriegt der Prozessor Branch Prediction? Über wie viele Pins ist er mit dem Mainboard verbunden? Northbridge: Ja oder nein? Wie viele Pins muß dieser Port haben und ist et parallel oder seriell? Et cetera.
Andererseits könnte es uns hinterher tatsächlich gelingen, einen real funktionierenden Computer mit unserer Architektur zu bauen.

Wenn wir eine reine VM planen kann es uns egal sein, ob der Prozessor so kompliziert ist, daß selbst Intel ihn nicht bauen könnte. Solange der Kram sich in Software emulieren läßt können wir ihn auch umsetzen.
Das hat den Vorteil, daß wir uns viele Implementierungsdetails sparen. Die Arbeit findet auf einer viel höheren Ebene statt. Allerdings können wir dann natürlich keinen realen Computer draus machen.

Also ich bin doch eindeutig für zweiteres, wusste gar nicht, dass das zur Debatte steht. o_O
Selbst wenn wir eine reale Architektur planen würden, wir würden sie doch wohl niemals bauen (können), oder? Das ginge ja auch nicht mehr online.

Inwieweit jetzt aber eine total unrealistische Herangehensweise Sinn macht, vor allem performancetechnisch, ist dann aber auch wieder die Frage. Also ich bin dafür, dass es keineswegs physisch umsetzbar sein muss, aber wir auch nicht übertreiben, mit den ganzen Forderungen. Wie sehr das mit den von Ineluki vorgeschlagenen Registern und Bits da noch rein passt, kann ich nicht sagen, denke aber, dass das schon hart an der Grenze ist.

Also .. so wie ich das ganze Projekt mir vorgestellt habe, meinte ich definitiv die zweite Variante, die Jeez anspricht. Mir ist es idR recht egal, wieviele Pins der Prozessor haben soll, oder wie der Bus mit dem RAM kommuniziert, oder ob welche Teile der Taktrate er benutzt. Das alles ist mMn nicht wirklich wichtig fuer jemanden, der sich mit LowLevel Programmeirung auseinandersetzen will, sondern ehr etwas fuer Bastler, wovon ich absolut keine Ahnung habe.

In diesem Sinne waere ich also definitiv fuer die VM Loesung.

@Drunken Monkey
Fuer eine VM ist es praktisch egal, wieviele Register unser Prozessor hat. Wenn wir nur 16 Register haben, haben wir dafuer ein Array mit 16 eintraegen, wenn wir 65536 Register haben, ist das Array im endeffekt nur groesser. Der grosse Aufwand ist die Implementierung des Rechenkerns. Allerdings muessen wir den in jedem Fall selber schreiben, wenn wir nicht ALLES genau so lassen, wie es bisher ist. Allerdings bietet uns das auch die Freiheit, und mit allem auszutoben, was wir wollen.

Funny, I was about to ask the same thing (was just to lazy to phrase it correctly. Thanks for doing it!)

Well..

I guess in the first place possibilty A) would be the most interesting thing. But I think most of us don't know enough of micro electronics to decide whether something can be implemented or not http://www.multimediaxis.de/images/s.../old/szuck.gif Therefore the simple VM would be more realistic for us.

.. but ..

Possibility B) is a bit boring. If we just create another VM, we are just creating a new interpreted language. We have room to make the VM do anything we want. We could create an object oriented VM. http://www.multimediaxis.de/images/s.../old/szuck.gif
If we restrict the VM intentional to half-realistic and half-as-easy-to-use instructions that may seem a bit.. stupid, doesn't it?

I really don't know... but I suppose B) is the only thing we can afford because we don't have the knowledge to fulfill A) (or are there some processor constructors among us?)

Don't ask why this post is written in english.. xD!


---


Lustig,WAR ich im Begriff, um um die gleiche Sache zu bitten (war zu faulem gerecht, es richtig auszudrücken. Dank für das Tun es!)

Brunnen.

Ich schätze an erster Stelle, das possibilty A) die interessanteste Sache sein würde. Aber ich denke, daß die meisten uns nicht genug von Mikroelektronik wissen, um zu entscheiden, ob etwas eingeführt werden kann, oder nicht http://www.multimediaxis.de/images/s.../old/szuck.gif folglich die einfache VM für uns realistischer sein würde.

.. aber.

Möglichkeit B) ist ein Spitze Bohren. Wenn wir gerade eine andere VM herstellen, sind wir gerecht, eine neue gedeutete Sprache verursachend. Wir haben Raum, die VM zu bilden tun alles, das wir wünschen. Wir könnten eine Gegenstand orientierte VM herstellen. http://www.multimediaxis.de/images/s.../old/szuck.gif, wenn wir die VM einschränken, die zu Hälfte-realistischem absichtlich ist und Anweisungen Hälfte-wie-einfach-zu-verwenden, die eine dumme Spitze scheinen können., nicht es?

Ich wirklich weiß nicht..., aber ich nehme an, daß B) die einzige Sache ist, die wir uns leisten können, weil wir nicht das Wissen haben, zum von von A) zu erfüllen (oder gibt es einige Prozessorerbauer unter uns?)

Fragen Sie nicht, warum dieser Pfosten auf englisch geschrieben wird. xD!

Englischkorrektur durch Ineluki, Übersetzung durch Babelfish, Edit durch Jesus_666

Zitat:

---

Zitat von drunken monkey

Selbst wenn wir eine reale Architektur planen würden, wir würden sie doch wohl niemals bauen (können), oder?

---

Oh, sag' das mal nicht. PCBs sind nicht teuer und sobald man den Schaltplan hat kann man die Dinger schon ätzen. Den Prozessor könnte man über ein PGA umsetzen; Informatikstudenten könnten über die Uni u.U. günstig an welche rankommen. Planungssoftware für solchen Kram gibt es sogar als Freeware. Und wenn wir uns an einige Standards halten könnten wir sogar einen Teil der Hardware mit den gleichen Controllerchips umssetzen, die man auch in x86-Mainboards findet.
Mit einem Budget von unter 500 Euro sollte es schon möglich sein, einen einfachen Computer mit eigener Architektur zu bauen. Wenn mehrere Leute zusammenlegen ist das auch nicht unerschwinglich viel Geld.

Natürlich haben wir es mit einer reinen VM wesentlich einfacher, aber einen eigenen Rechner zu bauen ist definitiv nicht unmöglich.

Ich hab mich das im Laufe des Prozessor-Threads auch schon gefragt, ich bin mehr für ersteres. Einfach aus dem Grund, dass das praktischer anwendbar ist und es später vielleicht wirklich möglich wäre, das zu bauen (nicht wahrscheinlich, aber möglich). Außerdem find ich's irgendwie besser, an etwas "realistischem" zu arbeiten als an einer reinen VM.

Du weisst aber auch, dass wohl keiner von uns die technische Ahnung hat und wir zum anderen dann wesentlich in unseren Moeglichkeiten zurueckstecken muessten.

Ich befuerchte, dass dann gar nichts aus dem Projekt werden wird. Ich habe auch nicht wirklich Ahnung, wie wir das machen wollen. Fuer den Fall 1) waere es dann doch wohl viel effektiver eine Simmulation zu schreiben, die wirklich auf den Hardwareprinzipien aufbaut.

Zudem wuerde sich der Aufwand fuer so ein Projekt (selbst wenn es nicht auf Hardwarebasis simuliert wird) mindestens verzwanzigfachen, da man dann nicht einfach sagen kann, dass der prozessor an stelle so und so schreibt, sondern dann muesste man auch wirklich den Datentransfer einprogrammieren und das Bustiming und das Takten des Prozessors mit aufsteigender und absteigender Phase usw usw usw

Ich halte das Projekt als VM Ansatz schon fuer schwer genug, aber mehr oder weniger realisierbar. Den hardwareorientierten Ansatz halte ich fuer nicht durchfuehrbar, wenn ich mir so ansehe, wie die bisherigen Projekte bei uns so liefen.

Wenn Jeez nicht gefragt haette, waere ich niemals auf die Idee gekommen, das so realisieren zu wollen.

Was die Sinnhaftigkeit, die Leistungsfaehigkeit und den Instruktionssatz der VM angeht ... so legen wir das ja selber fest. und wie ich bereits im eingehenden Post sagte ist der Sinn des Projektes nicht unbedingt am Ende etwas brauchbares zu haben, sondern durch den Weg dorthin etwas zu lernen und den anderen und sich selbst etwas beizubringen. Von daher halte ich den VM Ansatz ganz und gar nicht fuer seltsam und sinnlos.

Ich hab das eigentlich von Anfang an so verstanden, dass wir eine VM bauen wollen, aber für eine Architektur, die man theoretisch auch "in echt" nachbauen könnte.

Zitat:

---

Zitat von Ineluki

Von daher halte ich den VM Ansatz ganz und gar nicht fuer seltsam und sinnlos.

---

I think it's not completely senseless too. Writing a VM is hard stuff, of course. But in my opionen [spelling mistake; correct word: opinion] it is [incorrect form; correct form: it would be] curious [incorrect vocable; correct word: strange] to restrict the VM to stuff like [add, sub, mul, div, mov].

Mh. Okay. As I think about it, it's NOT curious [incorrect vocable; correct word: strange] at all. It's instructive. Okay. You win. It's just that the first post is a bit confusing because of the word 'processor'. That shouldn't be processor, but VM. Or virtual processor. IMHO.

--

Ich denke, daß es nicht auch komplettes senseless ist. Eine VM zu schreiben ist hartes Material selbstverständlich. Aber in meinem opionen es ist neugierig, die VM einzuschränken, um anzufüllen wie [ fügen Sie hinzu, sub, mul, Div., Bewegungen ].

Mh. O.K.. Wie ich an es denke, ist es NICHT senseless. Es ist lehrreich. O.K.. Sie gewinnen. Nur der erste Pfosten ist eine Spitze, die wegen des Wortes ' Prozessor ' verwirrt. Die sollte nicht Prozessor, aber VM sein. Oder virtueller Prozessor. IMHO.

Korrektur und Edit durch Jesus_666; übersetzung durch Babelfish

[English]
I mainly agree with Dingsi, for example in the point that not everyone of us knows what could be implented in a real processor. I also agree with Dingsi in the opinion that we should limit our freedom a bit so that we don't make the processor parse C code or something like that (because C is low level but it's much higher then ASM I think ^^). But probably I don't even know enough of what you are talking to be able to say anything constructive about it ^^

[Deutsch]
Ich bin hauptsächlich dingsis Meinung, zum Beispiel in dem Punkt dass wir nicht alle wissen, was in einem echte Prozessor implentiert werden könnte. Ich bin auch Dingsis Meinung im Bezug darauf dass wir unsere "Freiheit" etwas einschränken sollten, damit wir unseren Prozessor nicht C Code parsen lassen oder sowas (denn C ist zwar low level aber es ist längst nicht so low level wie ASM, glaube ich ^^). Aber wahrscheinlich weiß ich eh nicht genug über das wovon ihr redet um irgendwas konstruktives dazu sagen zu können ^^

Zum einen das, Dingsi, und zum anderen hab ich ja gesagt, dass ich gerne komplexere Befehle im Sinne eines CISCs haben will.

Ich finde es schon recht lustig, dass ihr meint, eine VM zu schreiben sei "langweilig" Vor allem, da mq geschrieben hat, er wuerde sie in Python schreiben wollen ...

Aber da das ganze ja so einfach ist, dass es langweilig ist, habt ihr ja sicherlich schon Einfaelle, wie man auf der Architekturebene Speicherverwaltung und Threadmannagement betreibt ...

Zitat:

---

Ich hab das eigentlich von Anfang an so verstanden, dass wir eine VM bauen wollen, aber für eine Architektur, die man theoretisch auch "in echt" nachbauen könnte.

---

Ich hab nie behauptet, dass wir eine VM bauen, die absolut unrealistisch ist. Nicht Marktfaehig, ja. Praktisch unbezahlbar, ja. In keinem PC-Gehaeuse unterzubringen, ja. Aber Prinzipiell sollte es praktisch umsetzbar sein. Moeglicherweise braeuchte Intel 5 Jahre entwicklungszeit und 12 Mrd US$ und der Chip haette die groesse eines Fussballfeldes ... but who cares ...

Ich wuerde gerne einen Prozessor haben, der genau das kann, was ich als Programmierer gerne haette. Auch wenn er nur virtuell existiert.

Zitat:

---

That shouldn't be processor, but VM. Or virtual processor. IMHO.

---

Ich habe doch immer davon gesprochen, einen Virtuellen Prozessor zu gestalten, und habe sogar explizit in meiner Beschreibung des Prozessors als Schleife und die Kommunikation mit dem Speicher geschrieben, was ich wie meine und wie ichs realisieren will ...

Zitat:

---

Zitat von masterquest

Ich hab das eigentlich von Anfang an so verstanden, dass wir eine VM bauen wollen, aber für eine Architektur, die man theoretisch auch "in echt" nachbauen könnte.

---

Das sehe ich auch so. Natürlich wissen wir nicht hundertprozentig, was machbar ist und was nicht. Das merkt man vermutlich erst, wenn man es umsetzt. Aber wir sollten es IMHO so konzipieren, dass bei einer Umsetzung kleine Änderungen vorgenommen werden müssen - anstatt, dass die ganze Architektur erneuert werden muss.
Natürlich wird so ein PCN nie gebaut werden, aber es sollte doch halbrealistisch sein, finde ich. Und eine einfache Architektur kann man auch später noch erweitern.

Zitat:

---

Zitat von Ineluki

zum anderen hab ich ja gesagt, dass ich gerne komplexere Befehle im Sinne eines CISCs haben will.

---

Vorher müsste doch eh ein RISC entworfen worden sein, oder nicht? Also was spricht degegen, sich erstmal darauf zu konzentrieren?

freundliche Grüße, Rolus

Zitat:

---

Ich hab nie behauptet, dass wir eine VM bauen, die absolut unrealistisch ist. Nicht Marktfaehig, ja. Praktisch unbezahlbar, ja. In keinem PC-Gehaeuse unterzubringen, ja. Aber Prinzipiell sollte es praktisch umsetzbar sein. Moeglicherweise braeuchte Intel 5 Jahre entwicklungszeit und 12 Mrd US$ und der Chip haette die groesse eines Fussballfeldes ... but who cares ...

Ich wuerde gerne einen Prozessor haben, der genau das kann, was ich als Programmierer gerne haette. Auch wenn er nur virtuell existiert.

---

so hab ich das auch verstanden, und mir vorgestellt....
Anstatt sich von sehr begrenztem Wissen über reale Prozessoren stark in seinen Möglichkeiten einschränken zu lassen, kann man so viel mehr von dem umsetzen, was man gerne möchte.

ich würde auch gerne mitmachen, aber ich hab keine Plan wie und was =/ ich progge eigentlich nur ein paar Aplis. mit Delphi und ein paar spiele mit PB mehr hab ich noch nie gemacht. Reicht das oder ist das was völlig neues ?

also das der prozessor theoretisch baubar sein sollte wäre ja machbar aber ihn praktisch umsetzen, nein.

WElche Fachkentnisse brauch man:
1.Elektrotechnik
2.Elektronik
3.Prozssorarchitektur
4.allgemein Informatik

die Probleme sind 1. & 2. denn das können hier wascheinlich nur wenige und wenn dann nur mehr oder minder gut. Denn wenn man einen Prozessor bauen will muss man sich mit dem Thema Stromlaufplan und Taktung und einigen Dingen mehr beschäftigen und das kann man nicht so einfahc hobbymäßig lernen wie Proggen. Dazu brauct man einen guten Lehrmeister.(glaubt mir ET ist höllsich schwer dagegen ist es leichter den C++ Code eines Progamms zu verstehen wenn man noch nie C++ genutzt hat)

soviel zum praktishen umsetzen.

Zitat:

---

Ich wuerde gerne einen Prozessor haben, der genau das kann, was ich als Programmierer gerne haette. Auch wenn er nur virtuell existiert.

---

der Traum eines jeden Programmierers, ein prozessor der alles kann was man brauch.

Ich glaube, einige haben nicht mein Anliegen an das Programm verstanden.
Das PCN soll letztlich soetwas wie ein gemeinschaftlicher und sich selbst schreibender Workshop werden. Der Prozessor, den wir dabei entwickeln, ist eigentlich nur Nebensache. Letztlich sollte am Ende jeder, der mitgemacht hat, das Wissen und die Werkzeuge vermittelt bekommen haben, um seine eigene VM zu basteln.

Es geht mir also vielmehr um das "Wie setze ich es um" als um das "Was setze ich um".
Die meisten Probleme werden genau so bei dem real-Prozessor Ansatz auftreten wie auch bei dem VM Ansatz.

Das PCN soll dazu da sein, dass wir uns gegenseitig erklaehren und von einander lernen, wie man an dieser Thematik arbeitet. Wir sind also im grunde soetwas, wie eine Lerngemeinschaft. Der Weg ist das Ziel. Deswegen ist es letztlich egal, ob unser Prozessor 16 Register oder 65536 Register hat, oder ob es ein reiner RISC ist oder er auch noch CISC Elemente beinhaltet. In jedem Fall hat man zu klaehren, wie man die Arithmetik loest, wie man Speicher addressiert, was Flags sind, wie man einen vollstaendigen Befehlssatz aufbaut, usw usw. Wenn am Ende von uns jeder eine eigene VM bauen kann, jeder nach seinen Vorstellungen, ist es auch in Ordnung.

Wenn wir uns jetzt darueber streiten, dass so ein Prozessor nicht unbedingt zu Hause nachgebaut werden kann, und wir nicht definieren, an welchem Pin welche Spannung anliegt, sondern das ganze eine Ebene hoehr angehen, dann ist das in etwa so, als wuerde man "Don's Adventure" wegen seiner Story kritisieren oder einem fuenfte Klasse Physikbuch vorwerfen keine Tensorrechnung zu verwenden ... Es schiesst einfach am Ziel vorbei.

Vor miraus bleiben wir mit unseren Registern unterhalb von 256 und arbeiten einen minimalistischen reinen RISC Befehlssatz aus, aber (ganz zu schweigen von den Elektrotechnikvoraussetzungen) sich um solchen Kram wie Pinbelegung oder Spannungsgefaelle zu kuemmern, ist weit jenseits von gut und boese. Ich bin Programmierer und werde auch durch dieses Projekt nicht zu einem Arbeiter in Intels Reinstlaboren. Es geht darum zu verstehen, wie ein Computer so funktioniert, und das hier einige ihre Scheu vor Maschinencode verlieren, und nicht darum das Projekt unnoetig zu verkomplizieren, bis alle daran die Lust verloren haben.

(Ich erinnere mich gut an ein anderes projekt, wo damit angefangen wurde, dass alle vier Spezifikationen a etwa 300 Seiten lesen sollten, wo es fast ausschliesslich darum ging, ob in einem Quelltext die oeffnende geschweifte Klammer auf eine neue Zeile kommt, oder nicht. Viel weiter sind wir auch nicht gekommen, bevor keiner mehr lust hatte ... Irgendwie habe ich das Gefuehl, das es hier genau so buerokratisch anfaengt)

Zitat:

---

Zitat von Ineluki

(Ich erinnere mich gut an ein anderes projekt, wo damit angefangen wurde, dass alle vier Spezifikationen a etwa 300 Seiten lesen sollten, wo es fast ausschliesslich darum ging, ob in einem Quelltext die oeffnende geschweifte Klammer auf eine neue Zeile kommt, oder nicht. Viel weiter sind wir auch nicht gekommen, bevor keiner mehr lust hatte ... Irgendwie habe ich das Gefuehl, das es hier genau so buerokratisch anfaengt)

---

Nun, in diesem Fall hatten einige es so verstanden, daß es darum geht, eine Architektur zu schaffen - was eine ganz andere Vorgehensweise erfordert als wenn man lediglich eine VM für eine Architektur schreiben will. Wenn du nicht klargestellt hättest, was das Projekt eigentlich bezweckt (und das habe ich auch erst nach diesem Post mitbekommen) hätten wir eben das Problem gehabt, daß wir zwischen zwei völlig widersprüchlichen Designkonzepten feststecken.

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.

Zitat:

---

Zitat von o_O

ich würde auch gerne mitmachen, aber ich hab keine Plan wie und was =/ ich progge eigentlich nur ein paar Aplis. mit Delphi und ein paar spiele mit PB mehr hab ich noch nie gemacht. Reicht das oder ist das was völlig neues ?

---

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.
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? ;)

Zitat:

---

Zitat von BeyondTheTruth

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)?

---

Inwiefern freigeben?
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?

Zitat:

---

Zitat von BeyondTheTruth

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.
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.

Zitat:

---

Zitat von jeeeeez!

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.

---

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.

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 ...

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?

---

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.

Zitat:

---

Zitat von Ineluki

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.

---

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.

Zitat:

---

Zum anderen waere es Malware praktisch unmoeglich irgendwelchen Bloedsinn zu treiben, solange es ein anderer Prozess nicht gestattet.

---

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).

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

Zitat:

---

Zitat von drunken monkey

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)

---

Och, das hätte ich jetzt eh nicht umgesetzt. Aber man kann sich die Idee für ein alternatives BIOS merken.

Zitat:

---

Aber eigentlich wollte ich fragen, wann es denn (mit Threads zu anderen Komponenten) weitergehen soll, bzw. wie letztendlich die Entscheidung getroffen wird.

---

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.


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.