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
--
Geändert von Ineluki (12.04.2006 um 03:58 Uhr)
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.
--A human is a system for converting dust billions of years ago into dust billions of years from now via a roundabout process which involves checking email a lot.
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.
--
Geändert von Ineluki (13.04.2006 um 00:29 Uhr)
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 notTherefore 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.
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
.. 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.
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
--Abwesend.
Geändert von Jesus_666 (13.04.2006 um 00:14 Uhr)
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.Zitat von drunken monkey
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.
--
Geändert von Ineluki (13.04.2006 um 00:29 Uhr)
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.
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
--Abwesend.
Geändert von Jesus_666 (13.04.2006 um 00:45 Uhr)
[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 ...
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.
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 ...
--
Geändert von Ineluki (13.04.2006 um 00:51 Uhr)
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.
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
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.
--
cats are not characteristically disposed toward voluntary aerobic exercise
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.
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)
--
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.
Berechtigungen
Zitieren
