Hallo Um den Stoff in Technische Informatik etwas zu vertiefen und auch etwas vertrauter zu werden mit programmierbaren Logikbausteinen, möchte ich einen kleinen Prozessor entwerfen. Irgendwie habe ich aber keine Lust, Compiler/Assembler dafür zu schreiben - daher kam ich auf die Idee, einfach einen bestehenden Instruktionssatz zu implementieren. 1. Gibt es da irgendwelche Stolpersteine, die ich übersehe? 2. Welcher Instruktionssatz würde sich besonders eignen? (Einfach und sauber sollte er sein, ich denke z.B. an MIPS) Gruss Michael
:
Gesperrt durch User
sowas etwa: http://www.homebrewcpu.com Hier gabs dazu auch schon Beiträge: Beitrag "Prozessor basteln!"
So etwas haben wir an der Uni im Digital Elektronischem Praktium gemacht. Das Script kann ich leider nicht rausgeben, aber der Befehlssazt sieht wie folgt aus (links der Opcode, dazu jeweils ein operand): 0x80 STA 0xA0 STAX doppelt indirekt speichern 0x40 LDA lade das, wass im RAM an der Oprandenadresse steht. 0x48 LDAI lade Operand 0x28 BCS Springe wenn zero Flag gesetzt 0x18 BEQ ... carry Flag ... 0x30 JMP springe dahin, wass im RAM an der Operandenadresse steht. 0x38 JMPI Springe 0x50 IN lade von Adressen 0x90 OUT ...schreiben 0x41 ADD 0x42 OR 0x43 SBC 0x44 XOR 0x45 ADC 0x46 AND 0x47 SETF Setze carry und zero Flag aus RAM mit Operand als RAM Adresse 0x49 ADDI addiere operand 0x4A ORI 0x4B SBCI subtrahiere Operand mit carry 0x4C XORI 0x4D ADCI addiere Operand mit carry 0x4E ANDI 0x4F SETFI Die CPU besitzt 256 Byte RAM, 256 Byte Programspeicher, hat 8 Bit und zwei Flags. Je nach Befehl werden 3 oder 4 Takte benötigt. Die OPcodes sind recht geschickt gewählt, so dass die interen 3 Byte nur für die ALU relevant sind und die oberen 5 nur für den Decoder. Die CPU hat ein Register A. Den STAX Befehl betrachte ich als recht sinnlos, da es kein LDAX Gegenstück gibt. Ich selbst hab dafür an einem Abend einen Quick & Dirty Assembler (C Code, Linux) zusammengebstelt, den ich bei weiteren Interesse veröffentlichen könnte.
und wieder ein Geheimagent: >So etwas haben wir an der Uni im Digital Elektronischem Praktium >gemacht. >Das Script kann ich leider nicht rausgeben Bring mal bitte einen ADC und eine RS232 in deinen Chip ein! Mach mal so einen Chip mit dem Befehlssatz von einem AVR Tiny, ich kann mir vor lachen den Bauch nicht mehr halten.
@Carsten: Das, was TTL da gelistet hat, erinnert mich zuerst an 6502. Und daß Uni-Skripte nicht einfach gepostet werden dürfen, sollte dir nach kurzem Nachdenken auch einleuchten. Gruß Jadeclaw.
> Und daß Uni-Skripte nicht einfach gepostet werden dürfen, sollte dir > nach kurzem Nachdenken auch einleuchten. Die sind schliesslich auch von meinen Steuern bezahlt. Also warum nicht?
Jadeclaw Dinosaur wrote: > @Carsten: Das, was TTL da gelistet hat, erinnert mich zuerst an 6502. > Und daß Uni-Skripte nicht einfach gepostet werden dürfen, sollte dir > nach kurzem Nachdenken auch einleuchten. Ist aber kein 6502, die Opcodes sind falsch. ...netter Versuch... Grüße Björn
der hier wäre besonders einfach ;) http://de.wikipedia.org/wiki/Brainfxck x bitte gegen u ersetzen !!!!!!!!!!! Gruß, siliCAT
Alter Fuchs wrote: > Die sind schliesslich auch von meinen Steuern bezahlt. > Also warum nicht? Ganz einfach, weil diese häufig genug urheberrechtlich geschütztes Material enthalten, welches eben nur innerhalb des Institutes weitergegeben werden darf. Einfach ins Internet einstellen ist von der Ausnahmeregelung des Urheberrechts nicht mehr gedeckt. Und damit nicht zulässig. Eigentlich nicht schwer zu verstehen. Oder? Gruß Jadeclaw.
Björn Wieck wrote: > Gerd B. wrote: > >> http://de.wikipedia.org/wiki/Brainfxck > > Das ist schon viel zu hoch!!! > > Grüße > Björn das ist RISC 2.0 :D
Wenn du mir nicht glaubst: http://www.ti.uni-bielefeld.de/html/teaching/SS06/dep/index.html#skript Ist halt Passwortgeschützt. Die Verantwortlichen wollen vorallem nicht dass das Script über Google gefunden wird.
Hi Als Du "Technische Informatik" gesagt, da habe ich spontan daran gedacht,ob Du vieleicht schon mal überlegt hast eine Turingmaschine in Silikon zu gießen ? Da ergibt sich dann der Befehlsatz von alleine. Ok. war nur eine Idee :-) Grüße und viel Erfolg bei Deinem Projekt. McGandolf
Ok, weil die Verantwortlichen doch einen kleinen Teil ohne Passwort ins Netz gestellt haben (und es sich wohl nicht um ein Versehen handelt), denke ich kann ich den Link posten: http://www.ti.uni-bielefeld.de/html/teaching/WS0304/DEP/DEP_INTRO_WS0304/99.html Da gibts auch eine schematische Übersicht über die CPU.
Hi Tief beeindruckt war ich von dem Projekt mycpy von Dennis Kuschel (www.mycpu.de). Es ist eine CPU die rein aus TTL Bausteinen zusammengebaut ist. Ein Betriebssystem hat er in Assembler geschrieben. Das ganze ist OpenSource und sehr ausführlich dokumentiert. Wenn Du Dir dieses Projekt noch nicht angsehen hast, dann empfehle ich Dir da mal reinzusehen. Vielleicht findest Du einige Anregungen zu Deine Frage. Grüße McGandolf
>Um den Stoff in Technische Informatik etwas zu vertiefen und auch etwas >vertrauter zu werden mit programmierbaren Logikbausteinen, möchte ich >einen kleinen Prozessor entwerfen. Irgendwie habe ich aber keine Lust, >Compiler/Assembler dafür zu schreiben. Hallo Mr.Chip, vielleicht ist es gar nicht so schlecht, sich erst mal einen Simulator zu schreiben. Weil ich mich gerade tiefer in Java einarbeiten will, schreibe ich zur Übung einen AVR-Simulator: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=20 Es sind im Moment nur en paar Befehle implementiert. Wenn Du einen Prozessor entwerfen willst, ist es vielleicht sehr nützlich, die Befehle erst einmal in einem Simulaotr zu testen. Die Befehlsklasse beim Simulator heisen z.b. Instr_NOP.java Man kann ganz einfach eigene Befehlsklassen machen und in InstructionSet.java einbinden. Gruß, chris
mr.chip wrote: > Um den Stoff in Technische Informatik etwas zu vertiefen und auch etwas > vertrauter zu werden mit programmierbaren Logikbausteinen, möchte ich > einen kleinen Prozessor entwerfen. Irgendwie habe ich aber keine Lust, > Compiler/Assembler dafür zu schreiben - daher kam ich auf die Idee, > einfach einen bestehenden Instruktionssatz zu implementieren. da du programmierbare logikbausteine verwenden möchtest schließe ich mal aus, dass du das ganze dann mit ttl/cmos-ics aufbauen willst. aus diesem grund würde ich dir ein fpga empfehlen. an der uni habe ich sowas mal in einem proseminar (im laufe eines semester) gemacht - das war ein einfacher 8bit-risc-prozessor, der auf einem spartan2e-evalboard von xilinx lief. ein blockdiagramm und den befehlssatz hätte ich noch irgendwo herumliegen, die unterlagen leider nur mehr in analoger form...
Oder bau einen mikroprogrammierten Prozessor. Dann bist du in der Wahl des Befehlssatzes etwas flexibler und kannst ihn ggf. hinterher noch anpassen, ohne die Hardware neu zu machen.
>das war ein einfacher 8bit-risc-prozessor, der auf >einem spartan2e-evalboard von xilinx lief. LDIH u. LDIL ? War es vielleicht doch ein 16 Bit Prozessor? Gruß, chris
stimmt, es waren 16 bit - mit den 8 bit hatte ich dann bei meiner uart-erweiterung zu tun (8 und 16-bit modus, 16 bit muss aus zwei übertragenen bytes zusammengesetzt werden). ausserdem ist das ganze schon eine weile (4 jahre) her ;-)
Tja, wie die Zeit vergeht. Weist Du noch, ob der Prozessorkern einen bestimmten Namen hatte? Gibt es eventuell sogar einige Programmbeispiele? Die Struktur sieht recht einfach aus und viele Befehel gibt es ja auch nicht. Deshalb habe ich zur Übung mal einen Simulator dafür geschrieben, hier der Simulations-Dump: FPGA MC Simulator V0.001 test code 0000: A707 LDIL R7,7 load constant low byte RxL= 8bit constant 0001: A604 LDIL R6,4 load constant low byte RxL= 8bit constant 0002: A005 LDIL R0,5 load constant low byte RxL= 8bit constant 0003: A101 LDIL R1,1 load constant low byte RxL= 8bit constant 0004: 0804 SUB R0,R0,R1 sub destination,source1,source2 Rx=Ry-Rz 0005: D0E0 JZ R7,R0 jump if Rz=zero if(Rz==0) pc=Ry 0006: C0C0 JMP R6 jump pc=Ry 0007: E000 NOP no operation 0008: E000 NOP no operation simulator run 0 :LDIL R7,7 0000 0000 0000 0000 0000 0000 0000 0007 1 :LDIL R6,4 0000 0000 0000 0000 0000 0000 0004 0007 2 :LDIL R0,5 0005 0000 0000 0000 0000 0000 0004 0007 3 :LDIL R1,1 0005 0001 0000 0000 0000 0000 0004 0007 4 :SUB R0,R0,R1 0004 0001 0000 0000 0000 0000 0004 0007 5 :JZ R7,R0 0004 0001 0000 0000 0000 0000 0004 0007 6 :JMP R6 0004 0001 0000 0000 0000 0000 0004 0007 4 :SUB R0,R0,R1 0003 0001 0000 0000 0000 0000 0004 0007 5 :JZ R7,R0 0003 0001 0000 0000 0000 0000 0004 0007 6 :JMP R6 0003 0001 0000 0000 0000 0000 0004 0007 4 :SUB R0,R0,R1 0002 0001 0000 0000 0000 0000 0004 0007 5 :JZ R7,R0 0002 0001 0000 0000 0000 0000 0004 0007 6 :JMP R6 0002 0001 0000 0000 0000 0000 0004 0007 4 :SUB R0,R0,R1 0001 0001 0000 0000 0000 0000 0004 0007 5 :JZ R7,R0 0001 0001 0000 0000 0000 0000 0004 0007 6 :JMP R6 0001 0001 0000 0000 0000 0000 0004 0007 4 :SUB R0,R0,R1 0000 0001 0000 0000 0000 0000 0004 0007 5 :JZ R7,R0 0000 0001 0000 0000 0000 0000 0004 0007 7 :NOP 0000 0001 0000 0000 0000 0000 0004 0007 8 :NOP 0000 0001 0000 0000 0000 0000 0004 0007
nein, der kern hatte keinen eigenen namen. ursprünglich wurde das programm direkt in den speicher geschrieben (binär/hex) und mit dem prozessor ins fpga übertragen. ein assembler für die cpu wurde von einem studenten als bakkarbeit geschrieben, ich habe das design um eine firmware und ein bisschen zubehör erweitert - in der letzten version wurde das programm dann über rs232 von einem pc gebootet. als beispielprogramm hätte ich z.b. die firmware im angebot (anhang). ich werde mal schauen, ob ich noch unterlagen und vhdl-codes für das teil finde.
Sehr schön, das ist schon mal ein gutes Beispiel. Wenn Du noch mehr davon hättest ... Interessant finde ich, dass beim Assembler die Befehle LDIL und LDIH zu einem Befehl zussammegefasst wurden. Ebenfalls ist bemerkenswert, dass das laden der Register für die Sprünge gleich an den Sprungbefehl angebunden ist.
der assemblerbefehl ldi ist ein pseudobefehl, der in ldil und ldih aufgeteilt wird. ich habe die unterlagen mittlerweile gefunden und werde sie heute abend ein bisschen sortieren, zusammenfassen und hier reinstellen. dann kann jeder interessierte probieren, das teil nachzubauen ;-)
Im Anhang die Übungsblätter aus der Übung an der Uni. In der zip-Datei befindet sich auch eine "periferie.vhd", die zur Simulation des Speichers benutzt werden kann (und für die ersten Programmierversuche vor es die serielle Schnittstellenanbindung gab benutzt wurde)
32 Bit? Mit Pipeline? Einigermaßen bekannt? Dann nimm den DLX-Instruktionssatz: http://de.wikipedia.org/wiki/DLX-Mikroprozessor
Hallo Daniel,
>Im Anhang die Übungsblätter aus der Übung
sieht ja extrem umfangreich aus. Wieviel Zeitaufwand hattet Ihr denn für
das ganze Seminar?
( und hoffentlich sind die Herren Lampacher/ Ploner nicht so streng mit
den Coypright's ;-)
das proseminar waren 3 stunden wöchentlich in der uni, in denen der
größte teil der aufgaben bearbeitet wurden.
zusätzlich gab es noch hausübungen, die aber i.a. recht schnell erledigt
waren (die mit -.-.- eingerahmten teile). teilw. habe ich die
hausübungen während anderen vorlesungen oder in vorlesungspausen gelöst
;-)
als herr ploner noch an der uni war hatte er kein problem damit, wenn
man unterlagen für andere sachen verwendet hat ("hauptsache der name
bleibt dabei"), mittlerweile sind beide nicht mehr am institut tätig.
Auf der Altera Seite findest du in den Tutorals zum DE2 Board auch einiges, letzte Aufgabe ist ein 32bit RISC mit Pipelining. So schwierig ist es garnet eine Minimal-CPU zu bauen... das ist im Gegenteil sogar recht einfach. Schwierig wird's erst, wenn man dann etwas mehr will.
Wenn man einen eigenen Prozessor zusammenlöten will, ist dieser Instruktionssatz vielleicht sehr gut geeignet: http://e4004.szyc.org/iset.html Der Intel4004 4 Bit Prozzessor. Da läst sich auf jeden Fall viel lernen.
Nämlich wie man heute Prozessoren (aus gutem Grund) nicht mehr entwirft ;-)
Das ist auch das einzige, was man dem 4004 abgewinnen kann. Damals waren Transistoren kostbar. Die Leute hatten haufenweise Ideen, die sie nicht realisieren konnten, weil der Platz einfach nicht da war. Will man wirklich mit wenig Transistoren auskommen, ist das schon ok. Heute allerdings hat man Transistoren im Überfluss, und keiner weis so recht wofür man die alle benutzen soll. Heutige CPUs bestehen zu über 50% aus Cache, und Cachegrößen jenseits von 1MB bringen nur noch in sehr wenig Fällen einen wirklichen Zuwachs (im Desktop Bereich). Der Kern vom Opteron besteht aus etwa 20Mio Transistoren ohne L1 und L2. Mit L1 und L2 kommt die 1MB L2 Version auf 100Mio Transistoren. Heute braucht man gute Ideen, keine sparsamen Ideen. Und die Ausführungszeiten vom 4004 sind heute indiskutabel.
Alter Fuchs wrote: >> Und daß Uni-Skripte nicht einfach gepostet werden dürfen, sollte dir >> nach kurzem Nachdenken auch einleuchten. > > Die sind schliesslich auch von meinen Steuern bezahlt. > Also warum nicht? Ja, auch von deinen Steuern. So wie der Wagen vom Bürgermeister. Trotzdem darfst du den nicht einfach so fahren. Und der BND wird dir auch nicht alles, was indirekt von deinen Steuern bezahlt ist, rausrücken ;)
>> Die sind schliesslich auch von meinen Steuern bezahlt. >> Also warum nicht? >Ja, auch von deinen Steuern. So wie der Wagen vom Bürgermeister. >Trotzdem darfst du den nicht einfach so fahren. Und der BND wird dir >auch nicht alles, was indirekt von deinen Steuern bezahlt ist, >rausrücken ;) Das heutzutage vieles was an der Uni mit Steuergeldern erforscht wird mit Patenten belegt ist oder sonstigen Urheberrechten, ist zwar eine übliche, aber trotzdem eine sehr fragliche Praktik. Ich persöhnlich halte es für eine Unverschämtheit und für eine Fehlentwicklung des Systems.
>Heute braucht man gute Ideen, keine sparsamen Ideen. Ich glaube, Du bringst da etwas durcheinander. Um eine Aufgabe möglichst sparsam zu erfüllen, braucht man im Gegenteil, sogar extrem gute Ideen und viel Gehirnschmalz. ( siehe z.B. http://www.linusakesson.net/scene/craft/index.php ) Wenn man eine CPU für eine Ablaufsteuerung in einem CPLD braucht und die CPU schon 80% des Platzes belegt, ist das auf jeden Fall ein Problem. ( siehe http://direct.xilinx.com/bvdocs/appnotes/xapp387.pdf S.14) > Und die Ausführungszeiten vom 4004 sind heute indiskutabel. Kleine Übungsaufgabe für Dich: Wieviel mal höher kann ein durchschnittliche gebräuchliches CPLD heutztage höher als eine 4004 getaktet werden?
CPUs in CPLDs sind die absolute Ausnahme. Schon in durchschnittlichen FPGAs hast du sehr viel Platz für die CPU.
> Schon in durchschnittlichen FPGAs hast du sehr viel Platz für die CPU. Naja, die Diskussion entwickelt sich mal wieder in Richtung Äpfel-Birnen-Vergleich. Ob und wo man sparsam sein soll, ist eine Frage der Anforderung, nicht der Philosophie. Wenn ich eine CPU für einen CPLD bauen will, dann muss ich eben extrem sparsam sein. Wenn ich hingegen eine CPU für einen FPGA oder einen integrierten digitalen Schaltkreis entwerfe, dann fallen die Designentscheidungen sicherlich nicht auf Transistorebene. Da will man einen gewissen Instruktionssatz und eine gewisse gewisse Geschwindigkeit - einzelne Bauelemente zu sparen, interessiert kaum.
>Naja, die Diskussion entwickelt sich mal wieder in Richtung >Äpfel-Birnen-Vergleich. ... >Wenn ich eine CPU für einen CPLD >bauen will, dann muss ich eben extrem sparsam sein. Na, am Beginn des Post wolltest Du ja einen Instruktionssatz für eine Selbstbau CPU. Und diese CPU wollt Ihr ja mit diskreten Bauteilen aufbauen. Da bin ich mal davon ausgegangen, es eher was kleineres werden soll, sonst werdet Ihr mit den Lötarbeiten nie fertig. Ich habe mittlerweile noch einen Assembler für die von Daniel gepostete CPU gebaut, damit ist alles beisamen: Assebler, Disassemlber und Simulator. Hier der Bildschirmdump: C:\Dokumente und Einstellungen\chris\Desktop\test.txt
1 | // simples test Programm
|
2 | //
|
3 | // zaehlt das Register R0 von 3 auf 0
|
4 | // und verbleibt dann in einer Schleife
|
5 | //
|
6 | // CPU: lapoco ( lampacher-poner-core )
|
7 | //
|
8 | // author: chris, august 2008
|
9 | //
|
10 | |
11 | .equ stopcount 3 |
12 | |
13 | start: |
14 | ldil r7,stop // r7 mit Sprunglabel f�r Stopschleife laden |
15 | ldil r6,loop // r6 mit loop adresse laden |
16 | |
17 | nop
|
18 | |
19 | ldil r4,1 |
20 | ldil r5,stopcount |
21 | loop: |
22 | sub r5,r5,r4 // decrement R5 |
23 | jz r7,r5 |
24 | jmp r6 |
25 | |
26 | stop: |
27 | jmp r7 // infinte loop |
28 | |
29 | |
30 | labels : |
31 | stopcount 3 |
32 | start 0 |
33 | loop 5 |
34 | stop 8 |
35 | |
36 | parse with jump labels : |
37 | 0 0000 noType source: // simples test Programm |
38 | 1 0000 noType source: // |
39 | 2 0000 noType source: // zaehlt das Register R0 von 3 auf 0 |
40 | 3 0000 noType source: // und verbleibt dann in einer Schleife |
41 | 4 0000 noType source: // |
42 | 5 0000 noType source: // CPU: lapoco ( lampacher-poner-core ) |
43 | 6 0000 noType source: // |
44 | 7 0000 noType source: // author: chris, august 2008 |
45 | 8 0000 noType source: // |
46 | 9 0000 noType source: |
47 | 10 0000 LABEL .equ stopcount 3 source: .equ stopcount 3 |
48 | 11 0000 noType source: |
49 | 12 0000 LABEL start: source: start: |
50 | 13 0000 CODE: A708 ldil r7,stop source: ldil r7,stop // r7 mit Sprunglabel f�r Stopschleife laden |
51 | 14 0001 CODE: A605 ldil r6,loop source: ldil r6,loop // r6 mit loop adresse laden |
52 | 15 0002 noType source: |
53 | 16 0002 CODE: E000 nop source: nop |
54 | 17 0003 noType source: |
55 | 18 0003 CODE: A401 ldil r4,1 source: ldil r4,1 |
56 | 19 0004 CODE: A503 ldil r5,stopcount source: ldil r5,stopcount |
57 | 20 0005 LABEL loop: source: loop: |
58 | 21 0005 CODE: 0DB0 sub r5,r5,r4 source: sub r5,r5,r4 // decrement R5 |
59 | 22 0006 CODE: D0F4 jz r7,r5 source: jz r7,r5 |
60 | 23 0007 CODE: C0C0 jmp r6 source: jmp r6 |
61 | 24 0008 noType source: |
62 | 25 0008 LABEL stop: source: stop: |
63 | 26 0008 CODE: C0E0 jmp r7 source: jmp r7 // infinte loop |
64 | |
65 | resulting code |
66 | A708 A605 E000 A401 A503 0DB0 D0F4 C0C0 C0E0 |
67 | |
68 | disassembled code |
69 | 0000: A708 LDIL R7,8 load constant low byte RxL= 8bit constant |
70 | 0001: A605 LDIL R6,5 load constant low byte RxL= 8bit constant |
71 | 0002: E000 NOP no operation |
72 | 0003: A401 LDIL R4,1 load constant low byte RxL= 8bit constant |
73 | 0004: A503 LDIL R5,3 load constant low byte RxL= 8bit constant |
74 | 0005: 0DB0 SUB R5,R5,R4 sub destination,source1,source2 Rx=Ry-Rz |
75 | 0006: D0F4 JZ R7,R5 ( jump if zero ) JZ destinationRegister,testRegister |
76 | 0007: C0C0 JMP R6 jump pc=Ry |
77 | 0008: C0E0 JMP R7 jump pc=Ry |
78 | |
79 | simulator run |
80 | 0 :LDIL R7,8 0000 0000 0000 0000 0000 0000 0000 0008 |
81 | 1 :LDIL R6,5 0000 0000 0000 0000 0000 0000 0005 0008 |
82 | 2 :NOP 0000 0000 0000 0000 0000 0000 0005 0008 |
83 | 3 :LDIL R4,1 0000 0000 0000 0000 0001 0000 0005 0008 |
84 | 4 :LDIL R5,3 0000 0000 0000 0000 0001 0003 0005 0008 |
85 | 5 :SUB R5,R5,R4 0000 0000 0000 0000 0001 0002 0005 0008 |
86 | 6 :JZ R7,R5 0000 0000 0000 0000 0001 0002 0005 0008 |
87 | 7 :JMP R6 0000 0000 0000 0000 0001 0002 0005 0008 |
88 | 5 :SUB R5,R5,R4 0000 0000 0000 0000 0001 0001 0005 0008 |
89 | 6 :JZ R7,R5 0000 0000 0000 0000 0001 0001 0005 0008 |
90 | 7 :JMP R6 0000 0000 0000 0000 0001 0001 0005 0008 |
91 | 5 :SUB R5,R5,R4 0000 0000 0000 0000 0001 0000 0005 0008 |
92 | 6 :JZ R7,R5 0000 0000 0000 0000 0001 0000 0005 0008 |
93 | 8 :JMP R7 0000 0000 0000 0000 0001 0000 0005 0008 |
94 | 8 :JMP R7 0000 0000 0000 0000 0001 0000 0005 0008 |
95 | 8 :JMP R7 0000 0000 0000 0000 0001 0000 0005 0008 |
96 | 8 :JMP R7 0000 0000 0000 0000 0001 0000 0005 0008 |
Was ist jetzt im einzelnen Dein Problem mit Chris' Beitrag?
Ich möchte die Ausgangsfrage nochmals etwas ins Zentrum rücken: Die Frage, ob es sinnvoll ist, einen bestehenden Instruktionssatz zu implementieren und wo allfällige Probleme liegen könnten. So hätte man nämlich bereits eine vollständige Toolchain, auf die man zurückgreifen kann. Andererseits: Einen Assembler zu schreiben ist das eine, einen C-Compiler schon was ganz anderes. Wäre es denkbar, basierend auf GCC etwas zu entwickeln?
>Andererseits: Einen Assembler zu schreiben ist das eine, einen >C-Compiler schon was ganz anderes. Einen Assembler zu schreiben ist natürlich eine eher einfache Aufgabe und einen C-Compiler zu haben, wäre eine sehr schöne Sache. Vielleicht gibt es ja einen Spezialisten hier im Forum, der so einen C-Compiler schreiben könnte. Könntest Du mir sagen, ob ich das Projekt von Dir und Deinen Freunden richtig verstanden haben: 1. Ihr habt einen Haufen TTL-ICs 2. Ihr möchtet eine Prozessor daraus bauen 3. Der Instruktionssatz soll modern sein, eventuel an MIPS angelehnt 4. Es soll einen C-Compiler dafür erstellt werden, oder schon vorhanden sein Gruß, chris
> 2. Welcher Instruktionssatz würde sich besonders eignen? (Einfach und > sauber sollte er sein, ich denke z.B. an MIPS) Mögliche Alternative: SPARC. Wirds ein 32- oder 64- Bitter? Wenns etwas kleiner sein soll: MSP430-Befehlssatz. Hat nur 27 Befehle, sehr orthogonale Architektur, sollte leicht(er) zu implementieren sein. Viel Erfolg wuenscht Иван
> 1. Ihr habt einen Haufen TTL-ICs Ja. > 2. Ihr möchtet eine Prozessor daraus bauen Eventuell, ja. Mindestens existiert(e) ein entsprechendes Hirngespinnst :-) Allerdings war das ein alter Thread von mir - das Projekt ist seither nicht wirklich vorangekommen. Da ich aber weiterhin Interesse am Thema habe und mittlerweile ein FPGA-Experimentierboard besitze, möchte ich dort drin mal einen Prozessor implementieren. Die Idee mit dem TTL-Prozessor ist natürlich nicht definitiv gestorben. > 3. Der Instruktionssatz soll modern sein, eventuel an MIPS angelehnt > 4. Es soll einen C-Compiler dafür erstellt werden, oder schon vorhanden > sein Diese Frage dreht sich explizit um einen Eigenbau-Prozessor _in einem FPGA_. Die Idee ist, einen bestehenden Instruktionssatz zu implementieren, so, dass man im Prinzip existierende Toolchains für diesen Prozessor verwenden kann. Also so, als würd ich mir meinen eigenen Pentium basteln um darauf dann Windows laufen zu lassen :-) Einen existierenden Instruktionssatz zu implementieren, halte ich für machbar. Ich sehe dann auch nicht wirklich Probleme, darauf ein Programm, das irgendwann für diesen Instruktionssatz compiliert wurde, laufen zu lassen. Und die Frage ist nun: Ist das so einfach wie es klingt? Und sekundär: Welcher Instruktionssatz haltet ihr für geeignet? Und wie sieht es eigentlich rechtlich aus? (Verkaufen wird man das Ding ja nicht, aber vielleicht im Internet veröffentlichen.)
Angehängte Dateien:
-
lapocoCPU.jpg
61 KB
>Da ich aber weiterhin Interesse am Thema habe und mittlerweile ein >FPGA-Experimentierboard besitze Das Board würde mich auch interessieren. Was ist da für ein FPGA drauf? Ich interessiere mich auch für das Thema FPGA/CPLD und möchte mir eventuell dieses CPLD Starterkit besorgen: http://www.xilinx.com/products/devkits/SK-CRII-L-G.htm Dafür gibt es schon ein CPU Referenzdesign. Damit kann man gut abschätzen, wieviel Platz so eine CPU braucht. >das Projekt ist seither nicht wirklich vorangekommen. Am Anfang, wenn man sich mit einer Idee beschäftigt, ist man ganz fasziniert und erst mit der Zeit stellt man fest, wie groß doch der Aufwand ist. Mir passiert das auch oft, und dann stampft man die Sache halt wieder ein. Meiner Einschätzung nach ist der Aufwand, einen TTL-Prozessor aufzubauen, mindestens die Lötarbeit von einem Mannjahr. Also, wenn Ihr genügend Zeit übrig habt .... Ich glaube, dass Du den Aufwand für so eine Sache im Moment noch unterschätzt, dass sich aber mit der Zeit bestimmt eine Lösung ergeben wird. Im Moment bin ich von der Idee, eine CPU selbst zu entwickeln, begeistert. Daher habe ich die "lapoco" CPU von oben mal "quasi in Silizium gegossen" und damit ein paar LEDs blinken lassen, damit es nicht so virtuell bleibt. ( siehe Bild )
> Das Board würde mich auch interessieren. Digilent Nexys 2 mit einem Spartan 3E. VGA, Buttons, LED, USB 2.0, PS/2, 16 MB RAM, 128 MB Flash onboard, bequem per USB programmierbar. Sehr empfehlenswert. > Am Anfang, wenn man sich mit einer Idee beschäftigt, ist man ganz > fasziniert und erst mit der Zeit stellt man fest, wie groß doch der > Aufwand ist. Hehe - so ist's leider. Aber eine faszinierende Idee ist eben noch lange kein gutes Projekt, sondern muss sich zuerst entwickeln - Kreativität und die Fähigkeit, Anforderungen genau abzuschätzen, sind gefragt. Deshalb sind gerade solche Threads oder Diskussionen auch immer recht interessant. > Meiner Einschätzung nach ist der Aufwand, einen TTL-Prozessor > aufzubauen, mindestens die Lötarbeit von einem Mannjahr. Aus einzelnen Transistoren und auf Loch-/Streifenraster wohl schon, ja. Wenn man hingegen ICs auf eine geätzte Platine löten kann, so halte ich ein einfaches Design doch für in vernünftiger Zeit machbar. Indem man beispielsweise die ALU in einem parallelen EEPROM implementiert, spart man sich auch einige Arbeit. Ganz 'true TTL' ist das dann natürlich nicht mehr.
Hat sich eigentlich jemand meinen Link angeguckt? Da hat jemand eine CPU aus TTL Bausteinen gebaut... Bei 'nem intelligenten Design kann man sehr viel mit sehr wenig Bauteilen machen. Ich designe schon eine ganze Weile an einer TTL CPU rum, Ziel der Sache ist es so viel Leistung mit so wenig Aufwand wie möglich rauszukitzeln. Vielleicht reicht's ja sogar für einen 8086er.
>Hat sich eigentlich jemand meinen Link angeguckt? Da hat jemand eine CPU >aus TTL Bausteinen gebaut... Der Link wurde bereits in der 2.ten Nachricht gepostet ( ganz oben ). > .... Anforderungen genau abzuschätzen, sind gefragt ... Da scheint mir noch etwas handlungsbedarf, wenn man nach dem optimalen Befehlssatz fragt und dabei an eine MIPS-CPU denkt. Ob sich etwas technisch machen lässt, hängt immer von Einschätzungen von Größenordnungen zusammen. Ich werfe hier mal ein paar Zahlen in den Raum: 1 Gater ~ 4 Transistoren 1 TTL Baustein ~ 4 .. 16 Gatter ( nehmen wir mal 8 als Mittelwert ) Intel 4004 CPU = 2300 Transistoren ==> Intel 4004 CPU ~ 70 TTL Bausteine ===================================== ARM CPU ( dürfte Deiner MIPS am nächsten kommen ) ~ 30000 Transistoren ==> ARM CPU ~ 1000 TTL-Bausteine ===================================== Diese Zahlen sind der Grund, warum ich Dir oben die 4004 als TTL-Projekt vorgeschlagen habe, weil es sonst deterministisch ein Schubladenprojekt wird. des weiteren Spartan 3e = 1.6 Millionen Gatter ~ 6.4 Mio Transistoren klar, damit lässt sich ein 32 Prozessor machen. Wenn Du die TTL ICs mit einem Spartan 3e vergleichst ist das so wie der Unterschied zwischen Stubenfliege und A380: völlig andere Dimension. Gruß, chris
Der 4004 ist 'n 4-Bitter, die myCPU ist immerhin ein 8-Bitter. Mit einem EPROM kannst du relativ viele Transistoren ersetzen. PS Nachdem ich jetzt extra gesucht hab - der Link steht nicht im 2. Beitrag, sondern irgendwo im 10.
I_ H. wrote: > Der 4004 ist 'n 4-Bitter, die myCPU ist immerhin ein 8-Bitter. Mit einem > EPROM kannst du relativ viele Transistoren ersetzen. Wenn man einen Computer ohne Einsatz programmierbarer Logikbausteine aufbauen will, dann sollte man sich darüber im Klaren sein, dass EPROMs als Logikersatz ungefähr kombinatorischen PALs/GALs entsprechen (aber langsamer sind). Man belügt sich also ein bischen selbst. Wenn man freilich wie hier explizit Erfahrung mit programmierbarer Logik sammeln will, warum dann Gatter+EPROM?
EEPROMs als Mikrocodespeicher sind nix neues, und als ALU Tabelle... das als Gatter zu realisieren ist kein großes Ding. Für mehr kannst du die eh nicht benutzen, weil EEPROMs rein kombinatorisch sind. GALs sind übrigens sehr wohl getaktet (haben ein FF am Ausgang).
I_ H. wrote:
> GALs sind übrigens sehr wohl getaktet (haben ein FF am Ausgang).
Optional getaktet wohlgemerkt. Ich bezog mich ja auch explizit auf
kombinatorischen Einsatz kompatibel zu rein kombinatorischen PAL-Typen.
Ja ok... in der ALU kann man es imho halt schon benutzen. Die einzelnen Operationen sind ja nun nicht so schwer umzusetzen, vor allem in dem Zeitrahmen vom EEPROM. 4bit Adder gibt's als 74er Bausteine.
> Da scheint mir noch etwas handlungsbedarf, wenn man nach dem optimalen > Befehlssatz fragt und dabei an eine MIPS-CPU denkt. Das mit MIPS oder einem anderen Instruktionssatz bezog sich ausdrücklich auf das FPGA-Projekt - so wie eigentlich der ganze Thread hier. Die Idee mit TTL wurde von einem alten Thread ausgegraben, der (zufällig) auch von mir stammt. Ich glaube, niemand kommt auf die Idee, einen MIPS-Instruktionssatz in TTL zu implementieren, allein schon seiner 32-Bit-Breite.
mr.chip wrote: > Ich glaube, niemand kommt auf die Idee, einen MIPS-Instruktionssatz in > TTL zu implementieren, allein schon seiner 32-Bit-Breite. Och schade ;-). Immerhin sind schon 60 Bit breite Kisten aus Einzeltransistoren aufgebaut worden.
I_H wrote: >PS Nachdem ich jetzt extra gesucht hab - der Link steht nicht im 2. >Beitrag, sondern irgendwo im 10. Tschuldigung, ich habe nachlääsigerweise gedacht, die homebrew-cpu wäre gleich der mycpu ( die ist schon länger bekannt und war auch schon mal auf der Hobby-Elektronik in Stuttgart ausgestellt ). Wie ich finde, sieht man bei beiden Projekten sehr gut, welcher Aufwand es darstellt, eine 8 bit CPU mit TTL-Bausteinen zu realisieren: http://www.homebrewcpu.com/Pictures/cage_1.jpg http://www.cc86.org/~dkuschel/pic_mycpu21s.jpg >4bit Adder gibt's als 74er Bausteine. Naja, man könnte ja auch eine 74181 nehmen ( http://en.wikipedia.org/wiki/74181 ) oder ein CPLD oder ein FPGA oder vielleicht doch eine ARM CPU für 2,30 bei Reichelt kaufen ;-) Aber ok, vielleicht ist ein 4-Bit addierer noch erlaubt, um von einer eigenen CPU zu sprechen. Anrdreas Kaiser wrote: >Wenn man einen Computer ohne Einsatz programmierbarer Logikbausteine >aufbauen will, dann sollte man sich darüber im Klaren sein, dass EPROMs >als Logikersatz ungefähr kombinatorischen PALs/GALs entsprechen (aber >langsamer sind). Den Einsatz von EPROMs bei myAVR habe ich am Anfang auch etwas kritisch gesehen, weil EPROMs den Aufwand extrem verringern. Mit einem EPROM und einem D-FlipFlop lässt sich ja schon eine State-Machine aufbauen. Und wer weiss, vielleicht kann man daraus schon eine 4-Bit CPU machen.
Hier noch ein sehr schönes Beispiel für einen Selbstbau Computer http://www.diycalculator.com/sp-hrrgcomp.shtml Sehr schön bildlich dargestellt sind die Ideen, wie man einen Speicher bauen kann.
> Den Einsatz von EPROMs bei myAVR habe ich am Anfang auch etwas kritisch > gesehen, weil EPROMs den Aufwand extrem verringern. Natürlich. Da muss man sich halt fragen, worauf man beim eigenen Projekt Wert legt. TTL-Masochismus oder bloss die Entwicklung einer eigenen CPU aus Standardbauteilen?
Mikrocode auf Mikromaschienen sind keine neue Erfindung, im Gegenteil. Jede ältere CPU hat sowas, und der Mikrocode ist nicht mit Gattern implementiert.
Der Prozessor (nicht zu verwechseln mit dem Professor) ist die zentrale Recheneinheit im Computer. Neben den Prozessoren gibt es noch viele andere Arten die eine zentrale Recheneinheit darstellen. Die Urform war der sog. "Zessor". Der Mensch nennt seinen Zessor (und den von anderen Lebewesen) auch gerne Gehirn da dies für Laien und Zessorlose verständlicher ist. Die Vorläufer der Prozessoren nannte man Zessoren. Zessoren gibt es nachweislich schon seit ca. 8'463'924'518'945'376 Jahren. Sie haben sich mit jeder Generation weiterentwickelt und wurden zu dem was wir heute als "Gehirn" bezeichnen. Sie sind in der Lage ohne Verluste einfache Instruktionen auszuführen. Schon etwa 18'000 vor Christus entwarf eine Firma eine Methode um an noch mehr Denkleistung heranzukommen als bisher möglich war, man erfand erst den relativ sinnlosen Contrazessor der nur Hitze produzierte, und später einen leistungsfähigeren Prozessor wie er heute hauptsächlich in Computern verwendet wird. Die Leistung war allerdings immer noch nicht genügend um einen Menschen damit zu betreiben, also vereinte man beide Zessoren. So wurden die ersten Yetizessoren gezüchtet. Sie wurden in etwa 300 Affenartigen Wesen gezüchtet und getestet, welche schliesslich aufgrund ihrer Intelligenz aus dem Forschungslabor ausgebrochen und davongelaufen sind und nur selten wiedergesehen wurden. Deshalb züchtete man weiter bis man den ersten Jedizessor erfunden hatte, dieser neuartige Zessor war erstmals auch auf einem Menschen lauffähig und gab ihm von klein auf schon recht beeindruckende Fähigkeiten, leider sind die sogenannten "Jedi" (so nannte man Menschen mit solch einem Zessor) heute recht rar, weil sie sich meist mit normalen Menschen vermehrten und so die besonderen Fähigkeiten nach und nach verloren gingen.
Wir unterscheiden grundsätzlich den Prozessor, Contrazessor, Yetizessor, Berufszessor und den Jedizessor, des Weiteren wird unterschieden wieviele Prozessorkerne zu einem Zessor vereinigt wurden, wir sprechen vom Einkern-, Zweikern-, Vierkern- oder Mehrkernzessor. Ausserdem gibt es heute auch noch andere abartige Zessoren wie Grafik- und Soundzessoren. DualCore-Prozessoren DualCore-Prozessoren (nicht zu verwechseln mit Zweitaktern) haben zwei Prozessorkerne, man muss also die doppelte Menge Menschen darin einsperren! Eigentlich müssten sie doppelt so schnell sein. Es gibt aber nicht genug Professoren, deswegen sind sie nicht so schnell. Intel hat schon einen Prozessor mit 80 Kernen hergestellt, dieser wird den Mangel an intelligenten Leuten vorrantreiben, weil sie alle entführt und eingesperrt werden. Desweiteren weiß niemand, ob in DualCore-Prozessoren auch doppelt so viele Hühner und Rinder sind. Nähere Infos siehe: Dual-Core Prozessor Bearbeiten HardCore-Prozessoren Die HardCore Prozessoren sind die neueste Erfindung der Po-rnoindustrie. In diesen Modellen werden nur ausgesuchte Profidarsteller eingesetzt. Dadurch sind diese Prozessoren in der Lage sexs Tasks parallel zu bedienen. Hersteller dieser Prozessoren ist ein neues Unternehmen namens GTD (GanzTiefDrin).
oh Schreck. So ne alte Leiche ausgegraben und das nur wegen so dummem Geschwätz.
Thread beobachten
Seitenaufteilung abschalten
