edit: hust hust Mir ist gerade noch aufgefallen, dass sich bei den letzten beiden Dateien ein kleiner Fehler eingeschlichen hat. Das kommt davon, wenn man lustig Tabellenzeilen hin- und herschiebt... ;-) Wer ihn findet, darf ihn gerne behalten. ------------------------------- Hallo miteinander, ich habe schon seit längerer Zeit ein Projekt vor Augen und habe mich endlich mal damit befassen können. Und zwar geht es darum, dass ich mir gerne eine kleine CPU entwerfen und diese dann auch hardwaremäßig (mit Logikbausteinen) unsetzen würde. Vorweg schon einmal: Ich bein KEIN Profi und beschäftige mich mit Hardware, Mikrocontrollern, (Digital-)elektronik "nur" als Hobby neben dem trockenem Informatikstudium... Habt deswegen bitte ein wenig Nachsicht mit mir. Das Ganze soll natürlich auch einen gewissen Lerneffekt haben, aber an erster Stelle Spaß machen. Aber was will ich denn überhaupt hier? Ich habe mir mal ein paar Gedanken zu einer möglichen Architektur und passenden Komponenten gemacht. Das habe ich mal aufs "Papier" gebracht und angefügt. Vielleicht kann mir jemand von euch sagen, ob das schon mal ganz sinnvoll aussieht, oder ob ich mich da verrannt habe und das so nichts wird? Das Ganze soll eine 8-Bit CPU werden mit eben 8-Bit breiten Daten- und Adressbussen. Ich habe ein Akkumulatorregister, welches immer auf den ersten Eingang der ALU geht und ein Cache-Register als Zwischspeicher. AC, AZ und AN sind Flags für Überlauf, Null (Zero) und Indikator, ob im Akkumulator eine negative Zahl steht. Desweiteren habe ich mir überlegt, dass die Clock den "State counter" treibt, der bei jeder Flanke den nächsten Ausgang schaltet, was zur Folge hat, dass eine der unten rechts im der Zeichnung aufgeführten Befehle abgearbeitet wird. Also (jew. 1 Takt): - Befehl aus Adresse im "CMD_ADDR COUNTER" aus dem RAM holen und an das Register DATA_COMMAND legen - Register DATA_COMMAND setzen - Datenwort aus dem RAM holen und an das Register DATA_WORD legen - Register DATA_WORD setzen - CMD_ADDR um 1 erhöhen - Befehl und Daten an den Command decoder geben, dieser schaltet alles nötige, bzw. führt den Befehl aus und legt die neuen Daten an die restlichen Register an - Die restlichen Register (ACCU, CACHE), die Flags, evtl. R/W am I/O Bus oder /CE am Display werden gesetzt Das ist natürlich nicht sonderlich performant oder optimiert, aber recht simpel wie ich finde. Oder gäbe es da irgendwelche (technischen) Einwände? Ist das evtl. sogar eine total doofe Idee? Habe ich ansonsten noch irgendetwas wichtiges vergessen oder gibt es eurer Meinung nach sonstige Fehler in meinen Überlegungen oder sonstige grobe Schnitzer? Habe mir auch schon mal basierend auf meiner Architektur einen Befehlssatz herausgearbeitet und aufgeschrieben (Anhang). Ist das gut so? Habe ich auch hier evtl. irgendetwas vergessen/übersehen/nicht bedacht/etc.? Hatte mir auch schon einige Logikbausteine rausgesucht (74HCxx Reihe) und auch schon kommen lassen, um damit mal ein wenig zu basteln und zu schauen, was wie geht. Hätte zur Hardware vor allen Dingen mal ein paar (ganz doofe) Fragen: - Für die Register kann ich doch einfach D-FlipFlops (wie 74HC377) nehmen und diese dann einfach bei L->H Taktflanke der Clock setzen wenn im Takt davor die Zuleitungen gesetzt wurden, oder? Weil das Lesen aus dem RAM und die Berechnungen der ALU usw. dauern ja einen Moment, sodass ich nicht gleichzeitig das Register setzen kann. Auf dem Steckbrett funktioniert das mit einem D-FF soweit... - Ich bräuchte natürlich auch einige Multiplexer, habe aber nur den 74HC157 gefunden, das ist ein 4 x 2:1 MUX. Bräuchte für ein Wort dann aber immer schon 2. Gibt es evtl. das Ganze in 8Bit? Also quasi 8 x 2:1 MUX? - Als RAM-Baustein hatte ich mir diesen rausgesucht: http://www.reichelt.de/Drams-Srams/6264-70/3/index.html?;ACTION=3;LA=5;ARTICLE=2676;GROUPID=2954;artnr=6264-70 Dürfte doch gehen, oder? Von der Ansteuerung sieht das ja ganz einfach aus und die 8K bekomme ich ja nie im Leben voll. Also könnte ich von den Adressbits 8 für meine Adressbreite abzweigen und den Rest dann für die Unterscheidung von Befehlsspeicher, Datenspeicher, vielleicht ja sogar auch noch internen RAM...?! - Dann macht mir eine kleine Sache noch Sorgen: Wenn ich das mit dem State counter so mache, lese ich im einen Takt aus meinem RAM und setzte im nächsten das Register. D.h. den Ausgang für das R/W für den RAM muss ich da verODERn mit dem Ausgang für das Register-Setzen. Als State counter habe ich hier einen 74HC4017. Bin allerdings aus dem Datenblatt nicht schlau geworden. Wenn der Output wechselt, habe ich dann eine kurze Zeit, in der an keinem Output was anliegt? Es sieht irgendwie so aus, als ob das gleichzeitig passiert, das kann ich mir aber irgendwie nicht vorstellen. Denn sobald an einem der Outputs nichts mehr anliegt, verliere ich das Signal R/W für das RAM und ich müsste dann im nächsten Takt nochmal auslesen, was dann aber Zeit kostet und das Register aber schon gesetzt wird. Oder wie lange kann maximal das R/W am RAM weg? Versteht jemand, was ich meine? :-) Ansonsten hoffe ich mal, dass ich einigermaßen klarmachen konnte, wie ich mir das vorgestellt habe und dass nicht schon einige vor Lachen auf dem Boden liegen. Wie gesagt: Ich lese viel und habe mein "Wissen" auch nur daher. Bitte seid nicht böse, wenn ich an der ein oder anderen Stelle mal nicht so weiter weiß oder einfach mal auf dem Schlauch stehe. Ich lern' ja noch... ;-) Es würde mich sehr freuen, wenn vllt. jemand auf meine Fragen eingehen könnte, bzw. mir auch sagen könnte, ob das Vorhaben machbar ist (dass das kein Wochenendprojekt ist, ist mir ja auch klar), oder ob ich mich da total übernommen habe und mir das Ganze dann doch zu einfach vorstelle. Ich würde das Projekt wirklich gerne umsetzen. Besten Gruß, Christoph
Man lernt einiges dabei mal seine eigene CPU entwerfen und zumindest auf Register-Transfer-Ebene zu simulieren.
Na klar doch, und weil es schon gefuehlte 5Mio Led-Blinkprogramme fuer uC's gibt braucht ein uC-Einsteiger ja keins mehr zu schreiben.
Na klar doch, Blinkprogramme und eigene CPUs sind ja fast dasselbe :) Josef G. hat wirklich was Perfektes auf die Beine gestellt. Warum soll man darauf nicht zurückgreifen?
Adressbreiten/grössen konnte ich der Beschreibung nicht entnehmen. Geht es um Programme mit maximal 2stelliger Anzahl Operationen? Oder soll es dann doch eine prinzipiell vollständige CPU sein? Denn wie gestalten sich bei dir Unterprogrammaufrufe? Indirekte/berechnete Adressierung, beispielsweise um die Chars in Strings durchzudackeln, erfolgt über selbstmodifizierenden Code? Sonst sehe ich dazu nichts.
Zu der oben erwähnten CPU von Josef gibt es hier einen Artikel: http://www.mikrocontroller.net/articles/8bit-Rechner
Die Entwicklungen anderer Leute einfach nachzubauen beweist nur, dass man lesen und löten oder FPGAs programmieren kann. Darum wird es hier wohl kaum gehen.
Christoph B. schrieb: > - Die restlichen Register (ACCU, CACHE) Wenn du das Verständnis fördern willst, dann vermeide Begriffe, die bereits mit völlig anderer Bedeutung besetzt sind. Wie Cache.
Hallo, vielen Dank zuächst für die zahlreichen Antworten! Abdul K. schrieb: > Was unterscheidet deine CPU von den gefühlten 700 anderen > Versionen? Mops Fidibus schrieb: > Hat doch Josef G. schon fertig entwickelt, ganz modern im FPGA. > Was > willste das Rad neu erfinden? Meine CPU habe ich selbst entworfen und verstanden. Ich möchte ja nicht etwas noch nie dagewesenes machen oder das Rad neu erfinden, aber: Juergen G. schrieb: > Na klar doch, und weil es schon gefuehlte 5Mio Led-Blinkprogramme > fuer > uC's gibt braucht ein uC-Einsteiger ja keins mehr zu schreiben. A. K. schrieb: > Die Entwicklungen anderer Leute einfach nachzubauen beweist nur, > dass > man lesen und löten oder FPGAs programmieren kann. Darum wird es hier > wohl kaum gehen. Boris B. schrieb: > Weil es nicht um das Endergebnis geht, sondern der Weg das Ziel > ist? Genau das! Noch soll es das Nonplusultra werden, sondern als Projekt zum Lernen, Verstehen, Tüfteln, Basteln und Freude dran haben dienen. Ich schaue mir das genannte Projekt sehr gerne an, danke für den Hinweis! foo schrieb: > Man lernt einiges dabei mal seine eigene CPU entwerfen und > zumindest auf > Register-Transfer-Ebene zu simulieren. Ja - mit dem Simulieren habe ich auch schon angefangen. Ist nur ein wenig schwierig, mit den entsprechenden ICs das Ganze zu machen. Ich baue bisher eher Teilkomponenten immer erst auf dem Steckbrett auf und gucke, was rein- und rauskommt. Aber eine schlechte Idee ist das Simulieren sicher nicht! A. K. schrieb: > Christoph B. schrieb: >> - Die restlichen Register (ACCU, CACHE) > > Wenn du das Verständnis fördern willst, dann vermeide Begriffe, die > bereits mit völlig anderer Bedeutung besetzt sind. Wie Cache. Das stimmt natürlich. Ist geändert. Danke! A. K. schrieb: > Adressbreiten/grössen konnte ich der Beschreibung nicht entnehmen. > Geht > es um Programme mit maximal 2stelliger Anzahl Operationen? Oder soll es > dann doch eine prinzipiell vollständige CPU sein? > > Denn wie gestalten sich bei dir Unterprogrammaufrufe? > > Indirekte/berechnete Adressierung, beispielsweise um die Chars in > Strings durchzudackeln, erfolgt über selbstmodifizierenden Code? Sonst > sehe ich dazu nichts. Register- und Busbreiten habe ich jetzt drangeschrieben. Unterprogrammaufrufe kann ich doch über die bedingten und unbedingten Sprungbefehle realisieren, oder? Nur hatte ich nicht beachtet, dass die 'Rücksprungadresse' ja irgendwie gespeichert werden muss. Habe einen entsprechenden Befehl eingefüht, der dann die aktuelle Befehlsadresse holt (,die dann irgendwo hingesetzt werden kann). Danach kann ich ja wieder an die gespeicherte Adresse (+1) springen. Danke für die Hinweise! Bin weiterhin für jede Kritik dankbar...
Lade dir Quartus II von Altera runter. Da kann man simulieren. Die Codeeingabe kann in VHDL oder sonstwas gemacht werden. Es ist auch möglich Symbolisch zu arbeiten mit FlipFlops und Gattern, Tristte und Muxen. Da sind glaube ich auch noch die ganzen 74xxx und so als Bausteine drinne.
Verstehe ich es richtig, dass alle Befehle aus 8-Bit Opcode und 8-Bit Operand bestehen, wobei vom Opcode bisher nur 5 Bits genutzt werden? Der Operand ist je nach Opcode eine Konstante, eine Code/Daten-Adresse oder unbenutzt? Da das RAM anscheindend ausschliesslich per PC adressiert wird, sind alle möglichen Variablen ausserhalb der A/B-Register direkt die Operanden von Befehlen? Interessanter Ansatz, aber mir schwant, dass man damit nicht weit kommt.
Mit 2x 74HC670 beispielsweise an Stelle entweder des A- oder des B-Registers lassen sich dort mit geringstem Aufwand 4 Register realisieren. Was wohl ein paar Probleme lösen könnte, denn dann gibts immerhin ein paar echte adressierbare Variablen.
Uwe schrieb: > Lade dir Quartus II von Altera runter. > Da kann man simulieren. > Die Codeeingabe kann in VHDL oder sonstwas gemacht werden. > Es ist auch möglich Symbolisch zu arbeiten mit FlipFlops und Gattern, > Tristte und Muxen. Da sind glaube ich auch noch die ganzen 74xxx und so > als Bausteine drinne. Lädt! Hatte schon mit der Xilinx ISE versucht, irgendwelche 74xxxx Libs einzubinden, aber das war mehr so ein Topfschlagen... Ich schau mal, was sich damit anstellen lässt. A. K. schrieb: > Verstehe ich es richtig, dass alle Befehle aus 8-Bit Opcode und 8-Bit > Operand bestehen, wobei vom Opcode bisher nur 5 Bits genutzt werden? Der > Operand ist je nach Opcode eine Konstante, eine Code/Daten-Adresse oder > unbenutzt? Ja, bzw. sind die Busse für die CPU Opcodes auch nur 5 Bit breit. A. K. schrieb: > Da das RAM anscheindend ausschliesslich per PC adressiert wird, sind > alle möglichen Variablen ausserhalb der A/B-Register direkt die > Operanden von Befehlen? Interessanter Ansatz, aber mir schwant, dass man > damit nicht weit kommt. Du meinst, dass ich quasi zu wenig Platz habe, um irgendwas zwischenzuspeichern und dass die beiden Register nicht reichen? Ja - das habe ich auch schon gedacht. Generell könnte ich am I/O Bus ja auf ein RAM zugreifen, aber dann ist der auch wieder belegt. Also eigentlich könnte ich Werte ja mit festen Adressen in einen zusätzlichen RAM-Baustein legen... Dann hätte ich 256 adressierbare, zusätzliche Register. Wäre das eine gute Idee? Wenn ich mir noch zwei Befehle biege, um aus der RAM-Adresse x in den ACCU zu schreiben und umgekehrt den Inhalt vom ACCU an die RAM-Adresse x zu schreiben, sollte das ja machbar sein. Oder irre ich mich da? A. K. schrieb: > Mit 2x 74HC670 beispielsweise an Stelle entweder des A- oder des > B-Registers lassen sich dort mit geringstem Aufwand 4 Register > realisieren. Was wohl ein paar Probleme lösen könnte, denn dann gibts > immerhin ein paar echte adressierbare Variablen. Davon habe ich mir auch welche mitbestellt, danke für den Tipp! Würde sich dann aber durch eine Extra-RAM-Lösung auch erledigen, oder?
Christoph B. schrieb: > Abdul K. schrieb: >> Was unterscheidet deine CPU von den gefühlten 700 anderen >> Versionen? > > Mops Fidibus schrieb: >> Hat doch Josef G. schon fertig entwickelt, ganz modern im FPGA. >> Was >> willste das Rad neu erfinden? > > Meine CPU habe ich selbst entworfen und verstanden. Ich möchte ja nicht > etwas noch nie dagewesenes machen oder das Rad neu erfinden, aber: > Dann habe ich das überlesen, daß du das Teil nur zum Lernen entwickelst. Aus der Sicht anderer ist es eben wichtig, zu wissen ob es irgendwelche Mängel anderer Architekturen behebt und damit einen Blick wert ist. Ansonsten schränkt sich der Kreis der Interessierten halt nur auf die Kreise ein, die Freude am CPU-entwickeln haben. Ich schwöre ja auf diesen Mann hier und vermutlich ist seine CPU daher auch nicht gerade schlecht: http://www.holmea.demon.co.uk/GPS/Main.htm
@Christoph B. Ich bin auch gerade beim Aufbau einer eigenen CPU, allerdings auf 4bit und TTL Basis in Anlehnung an einen Schaltplan aus den 80ern. Vielleicht kann man sich ja austauschen. Meine Takteinheit steht schon. Nicht Dolles aber ein erster Schritt. http://www.youtube.com/watch?v=_-bqaRML-e4
Um den Befehlssatz zu optimieren, könnte man sich einen einfachen Simulator schreiben ( z.B. in C oder Assembler ). Vor einiger Zeit habe ich das mal für eine einfache Übungs-CPU gemacht, die ich im Internet gefunden habe. Den Simulator habe ich dann auf einem Atmega8 laufen lassen: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=24
> Ich habe mir mal ein paar Gedanken zu einer möglichen Architektur und > passenden Komponenten gemacht. Wenn man das mit 74HCxx aufbauen will, dann sollte man eine Architektur wählen, bei der das nicht tausende von Bausteinen werden (so wie http://cpuville.com/). Denn das macht nicht nur Mühe im Aufbau, kostet Geld und ist fehler/störungsträchtig, sondern auch das Gegenteil von "egegant". Es gibt schon einige TTL CPUs im Netz, such dir die raus, die die wenigsten (beschaffbaren) Bauteile benötigt, wie http://repository.cmu.edu/cgi/viewcontent.cgi?article=1595&context=compsci&sei-redir=1&referer=http%3A%2F%2Fwww.google.de%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3Dminimal%2520homebrew%2520ttl%2520cpu%26source%3Dweb%26cd%3D6%26ved%3D0CFgQFjAF%26url%3Dhttp%253A%252F%252Frepository.cmu.edu%252Fcgi%252Fviewcontent.cgi%253Farticle%253D1595%2526context%253Dcompsci%26ei%3DG8buUcmXMtDQsgbLy4H4AQ%26usg%3DAFQjCNFJCarYW01FS7ahPOhQMqzRyabnPw#search=%22minimal%20homebrew%20ttl%20cpu%22 Ansonsten fährt man besser mit einem kleinen FPGA (Development Kit) und kann sich die CPU so oft umdefinieren, bis sie einem gefällt. Achsoja: Das zweite Problem: Die Software:: So bald man die Hardware hat, will man auch was laufen lassen. Also sollte man kompatibel zu einer bestehenden CPU mit interessanten Programmen sein, damit man nicht jedes Programm selbst schreiben muss. Es bietet sich CP/M an, das gibt's inzwischen auch in Source. Oder eine Gameboy-kompatible Hardware.
Wenn man bedenkt, dass er sich auf 256 Bytes Code beschränkt, also 128 Befehle, dann scheint es eher ums Prinzip als um reale Programme zu gehen.
Christoph B. schrieb: > Meine CPU habe ich selbst entworfen und verstanden. Ich möchte ja nicht > etwas noch nie dagewesenes machen oder das Rad neu erfinden, aber: ... tja, ABER! Ich hab das ziemlich bestimmte Gefühl, daß du dir da was auflädst, was du nicht tragen können wirst. Das Entwerfen einer CPU ist ja ganz nett und macht bestimmt auch Spaß, aber mit der (hoffentlich) funktionierenden Hardware ist das Rennen ja nicht gewonnen, sondern fängt erst an: Wohin willst du dein Ding bauen? Externer Flash? Externer RAM? Peripherie? Leiterplatte? UND Womit willst du dein Ding dann programmeren? Hast du schon mal nen Assembler selber geschrieben? Das alles ist ne Menge Holz und du solltest dich fragen, ob du es bis zu deiner Verrentung mit (ähem.. 67? 69? 71? ..?) noch zu Ende bekommst, ohne dir einen vorzeitigen Herzinfarkt zuzuziehen. Also, nette Idee, aber bedenke die nervlichen Folgekosten. W.S.
Abdul K. schrieb: > Ich schwöre ja auf diesen Mann hier und vermutlich ist seine CPU daher > auch nicht gerade schlecht: Ja - die Seite zum Mark 1 FORTH Computer hatte ich auch schon beim Stöbern entdeckt... Jörn T. schrieb: > Ich bin auch gerade beim Aufbau einer eigenen CPU, allerdings auf 4bit > und TTL Basis in Anlehnung an einen Schaltplan aus den 80ern. Vielleicht > kann man sich ja austauschen. Meine Takteinheit steht schon. Nicht > Dolles aber ein erster Schritt. Sehr gerne. Hatte dir vor ein paar Tagen auch schon eine Nachricht über YT geschickt, ging um das Video davor... ;-) Wie ist denn deine Planung momentan? chris schrieb: > Um den Befehlssatz zu optimieren, könnte man sich einen einfachen > Simulator schreiben ( z.B. in C oder Assembler ). > > Vor einiger Zeit habe ich das mal für eine einfache Übungs-CPU gemacht, > die ich im Internet gefunden habe. Den Simulator habe ich dann auf einem > Atmega8 laufen lassen: Oh ja - das sieht sehr interessant aus. Werde ich mir morgen (bzw. heute) in aller Ruhe anschauen. Vielen Dank! MaWin schrieb: > [...] Es gibt schon einige TTL CPUs im Netz, such dir die raus, die die > wenigsten (beschaffbaren) Bauteile benötigt [...] MaWin schrieb: > Ansonsten fährt man besser mit einem kleinen FPGA (Development Kit) und > kann sich die CPU so oft umdefinieren, bis sie einem gefällt. Ja - das stimmt generell. Aber ich würde das Projekt gerne auf der Ebene aufbauen, also aus Gattern, FFs, MUXen... So wie eben auch die Architektur ungefähr aussieht. Außerdem... MaWin schrieb: > Also sollte man kompatibel zu > einer bestehenden CPU mit interessanten Programmen sein, damit man nicht > jedes Programm selbst schreiben muss. Es bietet sich CP/M an, das gibt's > inzwischen auch in Source. Oder eine Gameboy-kompatible Hardware. ... soll das Ganze ja kein Brecherding werden und es sollen auch keine Spiele, Klimasimulationen, DNA-Sequenzanalysen oder was auch immer darauf laufen ;-) Das würde den Rahmen eideutig sprengen. A. K. schrieb: > Wenn man bedenkt, dass er sich auf 256 Bytes Code beschränkt, also 128 > Befehle, dann scheint es eher ums Prinzip als um reale Programme zu > gehen. Genau. Wobei ich 256 Opcodes und 256 Datenwörter ansprechen kann, also auf 256 Befehle (inkl. Datenwort) im Programmspeicher kommme. Gut - ist auch nicht die Welt, aber immerhin. W.S. schrieb: > Wohin willst du dein Ding bauen? > Externer Flash? Externer RAM? Peripherie? Leiterplatte? UND Womit > willst du dein Ding dann programmeren? Hast du schon mal nen Assembler > selber geschrieben? > > Das alles ist ne Menge Holz und du solltest dich fragen, ob du es bis zu > deiner Verrentung mit (ähem.. 67? 69? 71? ..?) noch zu Ende bekommst, > ohne dir einen vorzeitigen Herzinfarkt zuzuziehen. Okay, um das mal ein wenig zu entdramatisieren: Ich habe mir das modular vorgestellt: Ich entwerfe/simuliere den Addierer/Subtrahierer, baue ihn auf, gucke, ob alles passt. Falls ja bringe ich das schon mal auf eine Platine und mache mich dann meinetwegen an die ALU. Also Stück für Stück. Das ist zumindest mein Plan. Beschrieben wird der Programmspeicher dann über den Computer mit einem uC als Schnittstelle. Ein entsprechender "Compiler", bzw. "Assembler" (wenn man in dem Ausmaß schon davon sprechen kann), der zumindest mal die Befehle + Daten kodieren kann und dann mit dem RAM spricht, ist ja keine Raketenwissenschaft. Wenn alles am Ende funktioniert, ist der Rest dann Kür. Denkbar ist auch ein Modul mit einem ATmega, einem Display und Anschluss für eine Tastatur zum direkten Progrmmieren. Darüber kann man dann ja nachdenken wenn alles steht ;-) Und ja: Ein kleines Projekt ist das nicht, richtig. Mal zwischendurch eingestreut: Es freut mich wirklich sehr, dass sich hier so viele Leute schon geantwortet haben. Vielen Dank an dieser Stelle dafür! Ich freue mich natürlich auch weiterhin über Tipps, Hinweise, Kritik (auch zur Hardwareumsetzung).
Christoph B. schrieb >> Vor einiger Zeit habe ich das mal für eine einfache Übungs-CPU gemacht, >Oh ja - das sieht sehr interessant aus. Werde ich mir morgen (bzw. >heute) in aller Ruhe anschauen. Vielen Dank! Gerade habe ich die Diskussion im MC-Netz dazu gefunden: Beitrag "aus einer 8 bit CPU eine 16 bit CPU machen" Da gibt es einige nüzliche Tips über historische Entwicklungen.
Christoph B. schrieb: > > Sehr gerne. Hatte dir vor ein paar Tagen auch schon eine Nachricht über > YT geschickt, ging um das Video davor... ;-) > Wie ist denn deine Planung momentan? > Ach Du bist das! Tja, die Welt ist echt klein ;-) Stand der Dinge: Taktgenerator steht. Nächster Schritt ist ein Programmcounter mit Zugriff auf RAM, in dem Programm und Daten stehen. Danach wird auf Diodenmatrix-Ebene der erste Befehl aufgebaut: NOP Ich schicke Dir mal per E-mail meine Unterlagen bzw. einen Link dahin. Ich finde, der Entwurf bringt einen auf viele Idee. Aber Achtung, sind ein paar Fehler drin.
Christoph B. schrieb: > Lädt! Hatte schon mit der Xilinx ISE versucht, irgendwelche 74xxxx Libs > einzubinden, aber das war mehr so ein Topfschlagen... Ich schau mal, was > sich damit anstellen lässt. Ich weiß nicht: wenn du schon was Neues anfängst (FPGA-Design), warum lernst du dann nicht was, was du später auch brauchen kannst? Z.B. Verilog oder VHDL. Siehe dazu den Beitrag "kruder Fehler bei FPGA-Programmierung (ISE WEBpack-Schematic)" Denn noch eine weiter CPU mit handgeschnitzten Transistoren, das ist doch wie ein Fahrrad selber bauen: es wird auf jeden Fall schlechter, sperriger und teurer als etwas Fertiges und lernen kannst du am Fahrradbau eigentlich auch nichts mehr, du baust ja nur was nach, was Andere schon lange untersucht und erfunden haben... Wie wärs, etwas zu machen, was es nicht an jeder Ecke für 1,50€ gibt: z.B. einen Synchronen Indexer für ein paar Schrittmotoren in Hardware
hust hab auch mal so was angefangen, hier ein kleines Teil.. hab noch so einige andere Experimente gehabt. Warum nicht mit Diskreten Logic Gates spielen ? so lernt man wenigstens was, oder eben auch nicht :) manche Leute nehmen ja schon UCs wo es ein paar Gates tun..
Lothar Miller schrieb: > Ich weiß nicht:... Lothar, deine und meine Ansichten sind unterschiedlich und hier merkst du mal, daß es noch ganz andere Leute gibt, deren Ansichten mit deiner eben auch nicht übereinstimmen. Der Grund ist fast immer die völlig unterschiedliche Relation der Leute zum Thema Programmierbare Logik, deren sonstiges Betätigungsfeld usw. Vielleicht relativiert das mal ein bissel deine sonst eher kategorische Art. Abgesehen davon halte ich symbolische Abbilder von real existierenden 74xx Bausteinen nur dann für nutzvoll, wenn man irgend eine alte TTL-Schaltung unter Zeitdruck in ein CPLD quetschen muß, ohne sich Gedanken über die eigentliche Funktionalität zu machen. Mir selbst ist sowas jedoch noch nicht untergekommen. Was das konkrete Vorhaben dieses Threads betrifft, so kommt mir das Gedicht von den 2 Ameisen in den Sinn, die nach Australien reisen wollten: ..in Altona auf der Chaussee da taten ihnen die Füße weh und so verzichteten sie weise auf den letzten Rest der Reise. W.S.
Hei Christoph B.! Cool project. I have also started my own CPU dev but in verilog. The schematic capture of the xilinx webpack provided unstable and difficult to use. Even the old OrCAD was better :/. Regarding your architecture diagrams, what I do normally is to see what every opcode has to do to see what is really needed. Doing multi-cycle opcodes is a lot easier than pipelined designs. An older but sort of working version of one of my designs can you find here: http://forums.parallax.com/showthread.php/146345-A-simpler-COG A cog-inspired 4 clock uP. Depending on how many clocks per opcode you want, you can time the RAM accesses to the opcode execution. And nowadays SRAMs are fast.
Hallo Christoph, las dich von den "lass das sein"-Sagern nicht entmutigen! Auch wenn es heute kein Sinn macht eine CPU selbst zu bauen (Autotuning, Golf-Spielen, Radrennen etc. macht das auch nicht, dennoch ist es ein Gewerbe) finde ich es dennoch hervorragend! Wenn Du die CPU zum laufen gebracht hast, kannst Du später dies bei einer Bewerbung als Referenz angeben. Das kann fasst keiner hier!
@ Alex W. (a20q90) >las dich von den "lass das sein"-Sagern nicht entmutigen! >Auch wenn es heute kein Sinn macht eine CPU selbst zu bauen (Autotuning, >Golf-Spielen, Radrennen etc. macht das auch nicht, dennoch ist es ein >Gewerbe) finde ich es dennoch hervorragend! Sehe ich auch so. Eine CPU baut man nicht, um besser als verfügbare zu sein, dass kann so gut wie niemand. Aber man kann a) viel lernen b) viel Spaß haben Schon mal zwei gute Gründe.
Bezüglich Assembler und sogar Compiler: www.archc.org Damit kann man sich mit wenig Aufwand einen CPU-Simulator entwerfen und kriegt nebenbei noch Assembler, Linker, Debugger und neuerdings sogar nen C-Compiler automatisch erzeugt.
Hei Sam, thanks ! Ich wollte ein neuer C Compiler für mein pdp11 Projekt, archC klingt geignet !
Irgentwie verwirrende Beschreibung. Der TO hat nichtmal beschrieben, wie die genaue OP-Code-Aufteilung (fest, variabel ? , wie viel?) gemacht ist. (OP-Code enthält nicht nur die Commands, sondern alles was die CPU ausm Progr-Speicher liesst (bsp Operanden, Registerpointer, Immed.werte, sonst. ggfs. angehängte Param.). Vielleicht sich wegen Befehlssatz erstmal eine Accu-Masch (bsp HC11,12, STM8) anguggen.
MCUA schrieb: > Irgentwie verwirrende Beschreibung. Besonders leicht verständlich ist sein Enigma nicht geraten. > Der TO hat nichtmal beschrieben, wie die genaue OP-Code-Aufteilung > (fest, variabel ? , wie viel?) gemacht ist. (OP-Code enthält nicht nur > die Commands, sondern alles was die CPU ausm Progr-Speicher liesst (bsp > Operanden, Registerpointer, Immed.werte, sonst. ggfs. angehängte > Param.). Du denkst da mehr rein, als drin ist. 16-Bit Opcode, bestehends aus 5 Bit Opcode und 8 Bit Wert/Adresse. Basta. Betrachte es unter dem Aspekt des Minimalismus, nicht der Effektivität. Wobei man es dabei auch übertreiben kann und bei einer Maschine landet, die wirklich kaum mehr zustande bringt, als eine LED blinken zu lassen.
> Wobei man es dabei auch > übertreiben kann und bei einer Maschine landet, die wirklich kaum mehr > zustande bringt, als eine LED blinken zu lassen. Na ja, Turing-Vollständig sollte sie schon sein (bis auf Speicher), und damit ist sie universell genug.
>16-Bit Opcode, bestehends aus 5 Bit Opcode und 8 Bit Wert/Adresse.
5+8=13 ;-)
Na und? Wenn du auf mehr als 16 Bits gekommen wärst, dann hätte etwas nicht gestimmt. ;-)
Hallo Christoph B., einige Details Deiner Architektur verstehe ich nicht: Welche Bedeutung hat das Flag F_AN ? Wie funktioniert der Befehel SEF ..... ab genau ? Beim "bitweisen Oder" AXO x wird x gar nicht benutzt ? Wie genau soll IOW D funktionieren? Was liegt im IO-Bereich? Gibt es einen RAM Bereich, wie wird darauf zugegriffen ? Gruß, chris
Wie wärs mal mit einem one instruction set computer? Also einer CPU, die nur einen Befehl hat: http://en.wikipedia.org/wiki/One_instruction_set_computer Den kann man ja noch mit einzelnen SMD Transitoren aufbauen :-) Der Assembler sollte dann aber schon Makros unterstützen, um "richtige" Befehle damit nachzubilden. Oder wie wärs mit einer CPU, die nur ein "MOVE" kennt: http://en.wikipedia.org/wiki/Transport_triggered_architecture Alle Berechnungen, Vergleiche etc. werden über in den Speicherbereich eingeblendete Rechenwerke gemacht. Beispiel Addition: an Adresse 1 und 2 stehen die Operanden, die man mit move dort hinschreibt. An Adresse 3 kann man das Ergebnis lesen. Hat sowas schon mal jemand hier im Forum gebaut?
... schrieb: > Oder wie wärs mit einer CPU, die nur ein "MOVE" kennt: klasse idee, wäre sehr interessant
Hallo Christoph B., zum Spass habe ich einige der Befehle Deiner CPU im Assembler/Simulator implementiert. Wenn Du Lust hast, poste ich den Code ( Java ) dort lassen sich relativ einfach die restlichen Befehle hinzufügen. Gruß, chris
1 | CBCPU Assembler/Disassembler/Simulator V01 |
2 | |
3 | instructions implemented in this version: |
4 | END END stop cpu clock |
5 | JMP const jump to direct address |
6 | WRA const write register to accu |
7 | ADI const write register to accu |
8 | JCN const jump if not null to direct address |
9 | SBC a=a-b-carry |
10 | TAB transfer ACC to B_REG |
11 | |
12 | testcode.txt |
13 | // |
14 | // CBCPU test program |
15 | // |
16 | // CBCPU: Christoph B. CPU |
17 | // from http://www.mikrocontroller.net/topic/303279 |
18 | // |
19 | |
20 | wra 1 // write accu with 1 |
21 | tab // transfer accu to b register |
22 | wra 3 // write accu with 3 |
23 | loop: |
24 | sbc // acc=acc-b_reg |
25 | JCN stop // loop until acc=0 |
26 | jmp loop |
27 | |
28 | stop: |
29 | end |
30 | |
31 | labels : |
32 | loop 3 |
33 | stop 6 |
34 | |
35 | resulting code |
36 | 0C01 0A00 0C03 0400 1006 1103 0000 |
37 | |
38 | disassembled code |
39 | 0000: 0C01 WRA 1 write register to accu |
40 | 0001: 0A00 TAB transfer ACC to B_REG |
41 | 0002: 0C03 WRA 3 write register to accu |
42 | 0003: 0400 SBC a=a-b-carry |
43 | 0004: 1006 JCN 6 jump if not null to direct address |
44 | 0005: 1103 JMP 3 jump to direct address |
45 | 0006: 0000 END END stop cpu clock |
46 | |
47 | simulator run |
48 | 0 :WRA 1 0001 0000 0000 0000 0000 0000 0000 0000 |
49 | 1 :TAB 0001 0001 0000 0000 0000 0000 0000 0000 |
50 | 2 :WRA 3 0003 0001 0000 0000 0000 0000 0000 0000 |
51 | 3 :SBC 0002 0001 0000 0000 0000 0000 0000 0000 |
52 | 4 :JCN 6 0002 0001 0000 0000 0000 0000 0000 0000 |
53 | 5 :JMP 3 0002 0001 0000 0000 0000 0000 0000 0000 |
54 | 3 :SBC 0001 0001 0000 0000 0000 0000 0000 0000 |
55 | 4 :JCN 6 0001 0001 0000 0000 0000 0000 0000 0000 |
56 | 5 :JMP 3 0001 0001 0000 0000 0000 0000 0000 0000 |
57 | 3 :SBC 0000 0001 0000 0001 0000 0000 0000 0000 |
58 | 4 :JCN 6 0000 0001 0000 0001 0000 0000 0000 0000 |
59 | 6 :END 0000 0001 0000 0001 0000 0000 0000 0000 |
Da muss ich meine CPU auch noch ein einstreuen: http://opencores.org/project,mcpu 1 Seite VHDL Source, 32 Macrozellen im CPLD...
>Da muss ich meine CPU auch noch ein einstreuen:
Gefällt mir sehr gut :-)
Wie ich aus der Doku sehe, kann man erweiterte Befehle mit Hilfe der 4
Grundbefehle zusammen setzen. Ist der Assembler dafür ein
Makro-Assembler ?
Habe bisher die kostenfreie 8051 Macrocell für FPGA genutzt, aber es gibt wohl inzwischen eine kostenfreie ARM2 Macrocell, muss ich doch mal testen: http://opencores.org/project,amber
Eine Tastemprogrammierbare Steuerung wäre vielleicht auch als Architekur für einen einfachen Prozessor geeignet: http://www.elektronik-labor.de/Projekte/TPS1.html
>>Da muss ich meine CPU auch noch ein einstreuen: > > Gefällt mir sehr gut :-) > Wie ich aus der Doku sehe, kann man erweiterte Befehle mit Hilfe der 4 > Grundbefehle zusammen setzen. Ist der Assembler dafür ein > Makro-Assembler ? Ja. SMAL (der Assembler) ist ziemlich einfach gehalten. Im Prinzip ist alles als Macro implementiert.
Hier noch etwas lesenswerte Lektüre zum Thema: http://mycpu.eu/ Das ist eine komplett mit 74xxx aufgebaute 8-Bit-CPU inkl. Rechner "drumherum".
> Wo findet man den vollständigen Befehlssatz dieser CPU? Zumindest steht hier, dass die CPU ähnlich dem 6502 ist. http://mycpu.selfhost.it/epj03.htm Dieser Spruch am Ende des obigen Artikels gefällt mir. My slogan is: "Others have a model railway in their cellar, I have my CPU instead."
So, nach kurzer Auszeit ein kleines Update: Diverse Teile sind gekommen, und der Schaltplan für die ALU steht schonmal. Werde jetzt erstmal einige Sachen aufbauen und testen. Vielen Dank für die Kritik, aber auch für den Zuspruch und das Interesse an diesem Projekt! Sam P. schrieb: > Bezüglich Assembler und sogar Compiler: www.archc.org Klingt in der Tat interessant, werde ich mir auf jeden Fall auch anschauen, besonders das mit dem Simulieren hört sich sehr brauchbar an! chris schrieb: > Hallo Christoph B., einige Details Deiner Architektur verstehe ich > nicht: > > Welche Bedeutung hat das Flag F_AN ? > Wie funktioniert der Befehel SEF ..... ab genau ? > Beim "bitweisen Oder" AXO x wird x gar nicht benutzt ? > Wie genau soll IOW D funktionieren? Was liegt im IO-Bereich? > Gibt es einen RAM Bereich, wie wird darauf zugegriffen ? - Das Flag F_AN, bzw. F_N gibt an, ob sich im Akkumulator nach einer Subtraktion ein negativer Wert befindet. Ist in diesem Fall natürlich genau das Carry-Flag aber ich brauche ja eh noch ein drittes Flag für die Vergleichsoperationen. - Der Befehl SEF setzt die Flags F_C und F_Z nach den Bits ACCU(6) und ACCU(7) (in den Versionen hier waren das noch die Bits aus dem Datenwort, das habe ich geändert). - Genau. Die bitweisen Operationen verknüpfen die beiden Register ACCU und REG_B. Nicht direkt das Datenwort aus dem Programmspeicher. - IOW legt das Wort D an den I/O Adressbus, den Wert des Akkumulators an den I/O Datenbus und aktiviert die R/W Leitung. - Ja. Habe die CPU und den Befehlssatz entsprechend erweitert. Zugriff erfolgt mit dedizierten Befehlen für das RAM, genau so wie auf I/O Einheit. chris schrieb: > zum Spass habe ich einige der Befehle Deiner CPU im Assembler/Simulator > implementiert. Wenn Du Lust hast, poste ich den Code ( Java ) dort > lassen sich relativ einfach die restlichen Befehle hinzufügen. Wow - vielen Dank für deine Mühe! Bin ja zumindest beruhigt, dass du Spaß daran hattest ;-) Klar, gerne, da wäre ich sehr gespannt! Frank M. schrieb: > Hier noch etwas lesenswerte Lektüre zum Thema: http://mycpu.eu/ Das Ding hatte ich auch schon entdeckt. Ist zwar deutlich professioneller als mein Vorhaben, aber das Durchschauen der Downloads ist auf jeden Fall lohnenswert! Zwischendurch nochmals vielen Dank für die regen Diskussionen und die hilfreichen Kommentare! Ich habe mir bereits einen ALU-Tester aufgebaut und die entsprechende Software geschrieben und werde mit dem Testaufbau der ALU beginnen. Wenn soweit alles funktioniert, kommt diese schonmal auf Platine und ich kann mich an den Befehlsdecoder machen. So viel zu meiner weiteren Planung.
Josef G. schrieb: > Frank M. schrieb: >> ... mycpu.eu/ > > Wo findet man den vollständigen Befehlssatz dieser CPU? Hallo Josef, ich kenne den Entwickler der MyCPU (Dennis Kuschel), ein ehemaliger Mitarbeiter von mir und ein begnadeter Elektroniker. Ich stelle gerne den Kontakt zu ihm her, wenn Du möchtest. Schick mir eine Nachricht. Ich bin mir sicher, er stellt Dir das benötigte Material zur Verfügung, der Captain
Michael Steinbauer schrieb: > er stellt Dir das benötigte Material zur Verfügung, Ich hab's gefunden auf mycpu.eu auf der Seite Downloads im MyCPU Processor Selfbuild-Guide.
Hallo Christoph B. Schön, dass es weiter geht ;-) Könntest Du mal ein kleines Beispiel Programm schreiben ? z.B. 10 mal Test ausgeben? Ich denke, das ist nützlich, um den Aufbau der Befehle zu analysieren und zu verstehen.
>- Ja. Habe die CPU und den Befehlssatz entsprechend erweitert. Zugriff >erfolgt mit dedizierten Befehlen für das RAM, genau so wie auf I/O >Einheit. Könntest Du den neuen Befehlssatz posten ?
Hallo chris, chris schrieb: > Könntest Du mal ein kleines Beispiel Programm schreiben ? Das würde ja ungefähr so aussehen:
1 | 0: WRB 0b00000001 // REG_B = 1 |
2 | 1: WRA 0b00001010 // ACCU = 10 |
3 | 2: DCH 0b01010100 // T |
4 | 3: DCH 0b01000101 // E |
5 | 4: DCH 0b01010011 // S |
6 | 5: DCH 0b01010100 // T |
7 | 6: SBC 0b00000000 // ACCU -= REG_B |
8 | 7: JCZ 0b00000010 // F_Z == 0 ? |
9 | 8: END 0b00000000 |
chris schrieb: > Könntest Du den neuen Befehlssatz posten ? Natürlich - ist angehängt. Besten Gruß!
> Also (jew. 1 Takt): > - Befehl aus Adresse im "CMD_ADDR COUNTER" aus dem RAM holen und an das > Register DATA_COMMAND legen > - Register DATA_COMMAND setzen > - Datenwort aus dem RAM holen und an das Register DATA_WORD legen > - Register DATA_WORD setzen > - CMD_ADDR um 1 erhöhen > - Befehl und Daten an den Command decoder geben, dieser schaltet alles > nötige, bzw. führt den Befehl aus und legt die neuen Daten an die > restlichen Register an Eine Mikrocode Unit wäre vielleicht dafür noch Sinnvoll, oder soll der Decoder genau das darstellen? Du hast dort im Diagramm ALU und davon abgehen XOR,XAND,AND usw... sind gerade diese nicht eigentlich Teil der alu? Arithmetisch-Logische Einheit. Bei dir ist nur der Akkumulator selbst in der ALU drin. http://de.wikipedia.org/wiki/Arithmetisch-logische_Einheit http://upload.wikimedia.org/wikipedia/commons/thumb/1/17/Simplified-ALU.svg/645px-Simplified-ALU.svg.png
Hi Christoph, hier der Assembler/Simulator/Debugger mit ein paar Kommandos ( nicht alle und nicht alle vollständig ): http://hobby-roboter.de/forum/viewtopic.php?f=4&t=144
1 | CBCPU Assembler/Disassembler/Simulator Vxx |
2 | |
3 | instructions implemented in this version: |
4 | END END stop cpu clock |
5 | JMP const jump to direct address |
6 | WRA const write register to accu |
7 | WRB const write register to reg_b |
8 | ADI const write register to accu |
9 | JCN const jump if not null to direct address |
10 | JCZ const jump if null to direct address |
11 | SBC a=a-b-carry |
12 | TAB transfer ACC to B_REG |
13 | DCH const display ascii char |
14 | |
15 | testcode2.txt |
16 | |
17 | WRB 1 // REG_B = 1 |
18 | WRA 0x0A // ACCU = 10 |
19 | |
20 | loop: |
21 | DCH 0x54 //0b01010100 = T |
22 | DCH 0x45 //0b01000101 = E |
23 | DCH 0x53 //0b01010011 = S |
24 | DCH 0x54 //0b01010100 = T |
25 | SBC //ACCU -= REG_B |
26 | JCZ loop // F_Z == 0 ? |
27 | END |
28 | |
29 | |
30 | labels : |
31 | loop 2 |
32 | |
33 | parse with jump labels : |
34 | 0 0000 noType source: |
35 | 1 0000 CODE: 0D01 WRB 1 source: WRB 1 // REG_B = 1 |
36 | 2 0001 CODE: 0C0A WRA 0x0A source: WRA 0x0A // ACCU = 10 |
37 | 3 0002 noType source: |
38 | 4 0002 LABEL loop: source: loop: |
39 | 5 0002 CODE: 1954 DCH 0x54 source: DCH 0x54 //0b01010100 = T |
40 | 6 0003 CODE: 1945 DCH 0x45 source: DCH 0x45 //0b01000101 = E |
41 | 7 0004 CODE: 1953 DCH 0x53 source: DCH 0x53 //0b01010011 = S |
42 | 8 0005 CODE: 1954 DCH 0x54 source: DCH 0x54 //0b01010100 = T |
43 | 9 0006 CODE: 0400 SBC source: SBC //ACCU -= REG_B |
44 | 10 0007 CODE: 1102 JCZ loop source: JCZ loop // F_Z == 0 ? |
45 | 11 0008 CODE: 0000 END source: END |
46 | |
47 | resulting code |
48 | 0D01 0C0A 1954 1945 1953 1954 0400 1102 0000 |
49 | |
50 | disassembled code |
51 | 0000: 0D01 WRB 1 write register to reg_b |
52 | 0001: 0C0A WRA 10 write register to accu |
53 | 0002: 1954 DCH 84 display ascii char |
54 | 0003: 1945 DCH 69 display ascii char |
55 | 0004: 1953 DCH 83 display ascii char |
56 | 0005: 1954 DCH 84 display ascii char |
57 | 0006: 0400 SBC a=a-b-carry |
58 | 0007: 1102 JMP 2 jump to direct address |
59 | 0008: 0000 END END stop cpu clock |
60 | |
61 | simulator run |
62 | 0 :WRB 1 0000 0001 0000 0000 0000 0000 0000 0000 |
63 | 1 :WRA 10 000A 0001 0000 0000 0000 0000 0000 0000 |
64 | 2 :DCH 84 ======= ascii-char: T =================000A 0001 0000 0000 0000 0000 0000 0000 |
65 | 3 :DCH 69 ======= ascii-char: E =================000A 0001 0000 0000 0000 0000 0000 0000 |
66 | 4 :DCH 83 ======= ascii-char: S =================000A 0001 0000 0000 0000 0000 0000 0000 |
67 | 5 :DCH 84 ======= ascii-char: T =================000A 0001 0000 0000 0000 0000 0000 0000 |
68 | 6 :SBC 0009 0001 0000 0000 0000 0000 0000 0000 |
69 | 7 :JMP 2 0009 0001 0000 0000 0000 0000 0000 0000 |
70 | 2 :DCH 84 ======= ascii-char: T =================0009 0001 0000 0000 0000 0000 0000 0000 |
71 | 3 :DCH 69 ======= ascii-char: E =================0009 0001 0000 0000 0000 0000 0000 0000 |
72 | 4 :DCH 83 ======= ascii-char: S =================0009 0001 0000 0000 0000 0000 0000 0000 |
73 | 5 :DCH 84 ======= ascii-char: T =================0009 0001 0000 0000 0000 0000 0000 0000 |
74 | 6 :SBC 0008 0001 0000 0000 0000 0000 0000 0000 |
75 | 7 :JMP 2 0008 0001 0000 0000 0000 0000 0000 0000 |
76 | 2 :DCH 84 ======= ascii-char: T =================0008 0001 0000 0000 0000 0000 0000 0000 |
Vorwarnung: Ich habe nicht den ganzen Thread gelesen.
>DCH const
So high-level ein Befehl ist ziemlich ungewöhnlich. Warum wird der
Buchstabe denn als Const definiert? Wie soll eine dynamische Ausgabe
funktioniert? Durch selbstmanipulierenden code?
>>DCH const >So high-level ein Befehl ist ziemlich ungewöhnlich. Das habe ich mir auch schon gedacht. Wie man im Programm sieht, ist es zwar sehr einfach, DEBUG-Meldungen auszugeben. Ein Algorithmus, der z.B. Groß- in Kleinschreibung umwandelt, ist damit nur schwer realisierbar.
Der Thread scheint ja fast ein wenig eingeschlafen .... Christoph B.: wie weit bist Du mit Deiner CPU? In den Vorlesungen zu technischen Informatik gibt es einige minimal CPU Designs. Hier ein Beispiel, für das es sogar eine Java Applet Simulation gibt: http://tams-www.informatik.uni-hamburg.de/applets/hades/webdemos/50-rtlib/90-prima/chapter.html Vielleicht kann man sich an diesen Designs orientieren.
Kennt jemand ein Design mit der 74LS181 ALU ? http://math.hws.edu/vaughn/cpsc/220/labs/lab04/74LS181.pdf Damit liese sich das Prozessor Design vielleicht vereinfachen.
Erstaunlich, was Google alles zum Vorschein bringt: http://ygg-it.tripod.com/id1.html Die 74LS181 scheint bis 1997 produziert worden zu sein. Bei Mouser ist sie seltsamerweise aber immer noch erhältlich.
Hier noch mal eine idee: Nachdem der kleinste verfügbare CPLD mit 32 Macrozellen für eine CPU ausreicht - schafft es jemand, eine komplette CPU in einem GAL20V8 unterzubringen?
@Chris Wenn Du ein spannendes Projektfür den 74LS181 suchst, dann sieh Dir mal den Lehrcomputer von Conatex an: http://www.conatex.com/mediapool/betriebsanleitungen/BAD_1008145.pdf Daran hocke ich gerade. Aber Achtung, es sind ein paar Fehler drin und der Schaltplan ist etwas ungewöhnlich. Es ist nicht alles nach der reinen Lehre gemacht. Man sollte das Ganze eher als Inspiration nutzen und nicht 1:1 nachbauen wollen. 74LS181 kriegt man übrigens ganz gut über EBay oder bei einem ortsansässigen Elektronikladen. Ich hatte zumindestens noch Glück. Beim SRAM kann man flexibel sein.
>den Lehrcomputer von Conatex an: >http://www.conatex.com/mediapool/betriebsanleitung... Schön erklärt, wenn auch die Seiten krumm eingescannt sind. Schade, dass kein Bild dabei ist .. vielleicht könntest Du eines posten.
>Hier noch mal eine idee: Nachdem der kleinste verfügbare CPLD mit 32 >Macrozellen für eine CPU ausreicht - schafft es jemand, eine komplette >CPU in einem GAL20V8 unterzubringen? Ob man wohl eine Forth-fähige CPU auch in ein CPLD bekommen könnte? ( vielleicht kleiner als die J1: Beitrag "Re: Fragen zu Forth" ) Das wäre eine Herausforderung, und Forth bietet schon mehr Möglichkeiten als die CPU von Connatex
von alten Taschenrechnern lässt sich vielleicht auch noch etwas lernen: http://files.righto.com/calculator/sinclair_scientific_simulator.html Beeindruckend ist hier das Bild des Insturction-Decoder Roms: https://picasaweb.google.com/lh/photo/w52GQHWgId1zKOv_jj47fwj0RFV-rpgKGQkOJvHZ0i8 Man sieht direkt, welche Kontrollsignale bei welchem Befehl gezogen werden.
chris_ schrieb: >>Hier noch mal eine idee: Nachdem der kleinste verfügbare CPLD mit 32 >>Macrozellen für eine CPU ausreicht - schafft es jemand, eine komplette >>CPU in einem GAL20V8 unterzubringen? > Ob man wohl eine Forth-fähige CPU auch in ein CPLD bekommen könnte? > ( vielleicht kleiner als die J1: > Beitrag "Re: Fragen zu Forth" ) > Das wäre eine Herausforderung, und Forth bietet schon mehr Möglichkeiten > als die CPU von Connatex Prinzipiell erste einmal ja, da man mit jeder CPU auch eine Stack-CPU emulieren kann. So richtig effektiv ist so eine Implementierung auf einem CPLD aber nicht, da man recht viele Register + Stack benötigt. Ein FPGA ist da besser geeignet. Minimum wären wohl 4 Register: PC, Stack pointer, TOS, Second on stack, addressregister. Da ist eine Akku-basierte CPU deutlich einfacher.
@Christoph
Also ich find die Idee eine CPU mit TTLs aufzubauen an sich ja schon
ganz interessant, bzw sich aus Spaß an der Freud selbst ne CPU
zusammenzubacken schon echt witzig. Nur weiter so. :-)
Ich selbst bin auch dabei ein paar Ansätze auszuprobieren.
@...
>Oder wie wärs mit einer CPU, die nur ein "MOVE" kennt:
Genau diesen Ansatz verfolge ich gerade :-)
Die Idee das man quasi nur 'einen' Move Befehl hat (wobei das so ja
nicht stimmt, denn es müssen ja mehrere Modi unterstützt werden um
sinnvoll arbeiten zu können, wie z.b. einen Wert in ein Register zu
schreiben, ein Register in ein anderes zu schreiben, Speicherzugriffe
usw, und ein paar zusätzliche Befehle brauchts ja schon noch) hat schon
echt was interessantes.
Bei meiner Idee bzw meiner derzeitigen Bastelimplementation gehe ich
noch einen Schritt weiter und erlaube es das jeder Befehl bedingt
ausgeführt werden kann, wobei die Bedingung durch ein beliebiges Bit in
dem gesamten Registersatz vorgegeben werden kann.
Somit kann dann beispielsweise die Bits des ALU-Statusregister (das ja
auch ganz 'normal' in dem Registersatz eingeblendet ist) oder ein
Register in dem der Vergleich der beiden Operanden dazu genutzt werden
das beispielsweise Sprungbefehle, oder andere MOVE-Befehle ausgeführt
werden oder nicht.
Das bietet schon einige nette Spielereien die tlw auch Sinn machen. Mir
ist schon klar das das ganze eher eine nette Spielerei ist, und
effizienz anders aussieht :-) Aber es geht hierbei ja um den Spaß an der
Freud :-)
Vllt erstell ich zu diesem Design bzw dieser Idee auch mal zu gegebener
Zeit einen Thread. Im Moment bin ich noch in der Bastel und
Findungsphase, simulier ein paar Sachen erstmal mit ISE und schreib mir
einen paar kleine Tools.
Wenn mann nur externe Speciher nutzt man könnte vielleicht ein ganz minimal Forth Prozessor in eine CPLD realizieren...So etwas wie ein 95144 oder 95288... Vielleicht nur 8 bit...
ALE schrieb: > Wenn mann nur externe Speciher nutzt man könnte vielleicht ein ganz > minimal Forth Prozessor in eine CPLD realizieren...So etwas wie ein > 95144 oder 95288... Vielleicht nur 8 bit... Ich habe hier ein Board mit einem 9572XL und 256x8 SRAM. Das muss reichen :) Welche Befehle sollte die Stack-CPU denn unterstützen? Muss sie überhaupt direkte Speicherzugriff ermöglichen, oder reicht es, Konstanten auf den Stack zu schieben?
>Welche Befehle sollte die Stack-CPU denn unterstützen? Der Befehlssatz der F18A CPU von Greenarrays liefert hier einen guten Anhaltspunkt: http://www.greenarraychips.com/home/documents/greg/PB003-110412-F18A.pdf Diese CPU hat nur 18 Befehle. >Muss sie überhaupt direkte Speicherzugriff ermöglichen Ein Forth-Prozessor hat normalerweise 2 Stacks: Einen Datenstack zum rechnen und einen Programmstack für Unterprogrammaufrufe und Schleifen. Neben den Daten auf dem Datenstack gibt es normalerweise auch die Möglichkeit, auf den Speicher zuzurgreifen, da man ja eventuell längere Datenströme irgendwo speichern will.
Eine implementierung mit nur +, -, & und | und push/pop, call und return braucht 126 Slices (Lattice MachXO2) Aber mit 16 bit Werte...
>>Welche Befehle sollte die Stack-CPU denn unterstützen? > Der Befehlssatz der F18A CPU von Greenarrays liefert hier einen guten > Anhaltspunkt: > http://www.greenarraychips.com/home/documents/greg/PB003-110412-F18A.pdf > Diese CPU hat nur 18 Befehle. Ja, das ist DIE klassische Forth-CPU. "each F18A contains 128 words of memory (up to 512 instructions) plus 20 words of stacks and registers;" Das schränkt die Nutzbarkeit aber stark ein. 10 Bit PC? >>Muss sie überhaupt direkte Speicherzugriff ermöglichen > Ein Forth-Prozessor hat normalerweise 2 Stacks: Einen Datenstack zum > rechnen und einen Programmstack für Unterprogrammaufrufe und Schleifen. Den Return-Stack hatte ich oben vergessen. Der macht natürlich wieder alles etwas komplizierter. > Neben den Daten auf dem Datenstack gibt es normalerweise auch die > Möglichkeit, auf den Speicher zuzurgreifen, da man ja eventuell längere > Datenströme irgendwo speichern will. Naja, kommt darauf an, ob es nur um ein proof-of-concept geht, oder man mit der CPU richtig arbeiten will.
ALE schrieb: > Eine implementierung mit nur +, -, & und | und push/pop, call und return > braucht 126 Slices (Lattice MachXO2) Aber mit 16 bit Werte... Das ist aber ein FPGA. Dort gibt es den Speicher für die Stacks geschenkt. Ich vermute, dass ein CPLD nicht die richtige Umgebung für eine Stack-CPU ist.
Tim . schrieb: > "each F18A contains 128 words of memory (up to 512 instructions) plus 20 > words of stacks and registers;" Wobei sich diese 128 Worte weiter auf 64 Worte ROM und 64 Worte RAM aufteilen. Sinn ergibt dieser Minimalismus nur in der Masse. Die Klasse der davon abdeckbaren Probleme und die nötigen Programmiertechniken dürften sehr stark vom üblichen Rahmen abweichen. Man mag da an sowas wie neuronale Netze denken.
Ich habe nicht die Stacks intern gemacht sondern extern... nur die Stack Pointers sind intern (8 bit registers)
Vielleicht ganz interessant. Eine 4-bit CPU mit 7400 Logik. http://www.bigmessowires.com/category/nibbler/
Thacker's Tiny Computer 3 http://www.cl.cam.ac.uk/teaching/1112/ECAD+Arch/background/ttc.html 32 Bit RISC CPU auf zwei Seiten Verilog.
Um die Liste noch etwas zu vervollständigen, hier ein 4 Bit Computer für Lernzwecke: http://www.randelshofer.ch/fhw/gri/holzihelp.html
Wie groß ist der kleinste Befehlssatz, damit ein Prozessor ein vernünftiges Programm ausführen kann? Um das heraus zu finden, habe ich eine virtuelle Maschine programmiert: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=145 Ein paar der Befehle könnte man sich noch sparen z.B. 1+.
chris_ schrieb: > Wie groß ist der kleinste Befehlssatz, damit ein Prozessor ein > vernünftiges Programm ausführen kann? Genau ein Befehl. Maxims MAXQ-Controller wären ein Beispiel für eine Transport-Triggered-Architektur bei der es nur einen Befehl gibt.
1 | move x y -> mem[y] = mem[x]; |
subleq x, y, z wäre eine andere Variante mit einem Befehl
1 | mem[y] = mem[y] - mem[x]; |
2 | if (mem[y] <= 0) goto z; |
>Maxims MAXQ-Controller wären ein Beispiel Hier das Datenblatt: http://www.maximintegrated.com/app-notes/index.mvp/id/4811 Es klingt ganz interessant. Beim überfliegen sehe ich allerdings auch eine Alu. Da stellt sich mir die Frage, ob der Hardwareaufwand kleiner als bei anderen Controllern ist. >subleq x, y, z wäre eine andere Variante mit einem Befehl Das verstehe ich nicht.
Arc Net schrieb: > Maxims MAXQ-Controller wären ein Beispiel für eine > Transport-Triggered-Architektur bei der es nur einen Befehl gibt. Aber in 2 Spielarten: regD = regS regD = const
:
Bearbeitet durch User
chris_ schrieb: > Es klingt ganz interessant. Beim überfliegen sehe ich allerdings auch > eine Alu. Ohne ALU wird schwierig. Nur ist eine ALU nicht unbedingt der Gipfel des Aufwands. > Da stellt sich mir die Frage, ob der Hardwareaufwand kleiner > als bei anderen Controllern ist. Die Dekodierung ist möglicherweise etwas einfacher. >>subleq x, y, z wäre eine andere Variante mit einem Befehl > Das verstehe ich nicht. Ist auch ein eher theoretisches Konstrukt. Die Turing-Maschine pflegt man auch nicht praktisch zu verwenden.
chris_ schrieb: > Da stellt sich mir die Frage, ob der Hardwareaufwand kleiner > als bei anderen Controllern ist. Sollte http://en.wikipedia.org/wiki/Transport_triggered_architecture >>subleq x, y, z wäre eine andere Variante mit einem Befehl > > Das verstehe ich nicht. Das was im C/Pseudocode darunter steht ist ausreichend, damit diese "Maschine" ebenso Turing-vollständig ist wie andere Maschinen und Programmiersprachen auch. A. K. schrieb: > Aber in 2 Spielarten: > regD = regS > regD = const Wahrscheinlich um letztere Operation etwas effizienter zu machen
:
Bearbeitet durch User
Jeder der sich für CPU Architekturen interessiert, sollte mal einen Blick auf http://ootbcomp.com/docs/ werfen. Eine komplett neue Architektur im Vergleich zu herkömlichen Architekturen.
Abdul K. schrieb: > Ich schwöre ja auf diesen Mann hier und vermutlich ist seine CPU daher > auch nicht gerade schlecht: > http://www.holmea.demon.co.uk/GPS/Main.htm wtf? schreibt er irgendwo wie lange er dafür gebraucht hat?! echt krass! hab aber nichtmal die Hälfte verstanden :(
Hier gibt es den Schaltplan für eine Selbstbau 12 Bit CPU aus den 80er Jahren mit 74181er Alus: ftp://ftp.dreesen.ch/ Mit 3 Platinen ist das noch einigermaße überschaubar. Ich habe mir den Befehlssatz angesehen und einen Emulator dazu geschrieben: https://github.com/ChrisMicro/T3_computer_emulation Interessant dabei ist: der Computer hat keinen Festwertspeicher ( ROM ). Das Programm muss über die Schalter vorne am Frontpanel eingegeben werden. Was ich am ganzen aber noch nicht verstehe: Wie kommt man in den Programmiermodus?
chris_ schrieb: > Was ich am ganzen aber noch nicht verstehe: Wie kommt man in den > Programmiermodus? Geraten. Ich schätze mal, das ist die falsche Frage. Denn so etwas wie einen Programmiermodus wird es da gar nicht geben. Mal schauen, was uns die Beschriftungen der restlichen Schalter bzw. Taster verraten. Da gibt es auf der rechten Seite die Taster "BRK", "RUN" und "SST" Ich wette mal, das bedeutet "Break", "Run" und "Single Step". Gemeint ist damit die CPU. Ein Druck auf RUN lässt die CPU laufen, ein Druck auf BRK hält die CPU an und ein Druck auf SST lässt die CPU 1 Instruktion ausführen. Da diese 3 Taster hier alle so schön vereint sind, rate ich mal weiter, dass die Taster direkt den Taktgenerator beeinflussen. Break klaut der CPU den Takt, Run schaltet den Takt wieder an die CPU und SST schaltet genau 1 Taktpuls an die CPU weiter (oder so viele, wie nötig sind um einen Befehl abzuarbeiten) D.h. der Programmiermodus besteht einfach darin, dass die CPU nicht läuft (keinen Takt hat) und der Bediener mit den restlichen Konsolenelementen direkt im Speicher rumfuhrwerkt. Wie macht er das? Die 12 Schalter unter der Anzeige sind recht eindeutig. Das sind die 12 Datenbits. Wie kommen die gegebenenfalls in den Speicher? Dazu nehmen wir die linke Tasterreihe "INC", "DEC", "STR". Ich wette 10 zu 1, dass "STR" ausgeschrieben "Store" bedeutet und den mit den D-Schaltern eingestellten Wert in den Speicher schreibt. An welche Adresse geschrieben wird, kann mit den Tasten INC bzw. DEC verändert werden. INC erhöht die Adresse an die geschrieben wird, DEC verringert sie und Store platziert dann den eingestellten Wert in den Speicher.
:
Bearbeitet durch User
Das hört sich doch schon einmal gut an. Eigentlich müsste sich die Funktion ja auch aus dem Schaltplan ersehen lassen. Die Schalter Inc, Dec, SST, "und der Taster nach unten?" sind an ein UND-Gatter angeschlossen, die einen Puls an einem Monoflop 74121 erzeugen, der dann wiederum D-Flip-Flops zur Schalterübernahmen triggert. Jetzt ist die Frage, was mit den daraus erzeugten Signalen IKF, plpc, und Opc angestellt wird.
Nur um die Sammlung der CPUs etwas zu erweitern.. Hier gibt es die Bauanleitung für eine 1-Bit CPU: http://laughtonelectronics.com/Arcana/One-bit%20computer/One-bit%20computer.html
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.