Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: hannibal am 12. April 2005, 12:25
-
hallo,
durch meinen extrem engagierten und sehr foerdernden projekt-engineering lehrer, hab ich mit einem mitschueler die moeglichkeit um guenstiges geld (5€ fuer den fpga-chip + kosten fuer entwicklungsplatine) einen prozessor zu entwerfen! total geile sache, und nebenbei auch matura-projekt-anwaerter :D .
jetzt mach ich mich dann daran VHDL zu lernen und dann wird gecoded was das zeug haellt!
was der grund ist warum ich euch das erzaehle? ich haette den vorschlag gehabt, das ganze dann im magazin zu veroeffentlichen und eine art tagebuch darueber zu schreiben - eine sachliche kolumne, wenn man so will ;) .
auch interessant waere von euch ein paar vorschlaege zu hoeren, was eurer meinung nach die cpu koennen soll, was drin sein soll, usw. .. kommt sicher was interessantes dabei raus! werde dann meine planungen hier ins forum stellen und auf kritik hoffen.
lg, hannibal
-
was sollte ne CPU können? ich würd sagen register haben, rechnen können mit diesen und ports sowie speicher ansteuern. fertig.
ein paar tipps von mir, wie ich es machen würde, wenn ich könnte (sorry, wenn ich total maßloses verlange, aber ich hab kA, was möglich ist, und was nicht, deswegen spreche ich nur meine träume aus.) und muss man dafür nicht einen eigenen assembler schreiben?
1. register, die sich vollständig bis hin zu bytes oder gar bits aufteilen lassen (EAX ist normalerweise in AX und das in AL und AH aufteilen lassen). z.B. EAX = AX1 (= AL1 & AH1) & = AX2 (= AL1 & AH2). und ggf. auch adressieren von einzellnen bits: (AL1 = AL10 | AL11 | AL12 ... | AL17).
2. mehrparametrige verarbeitung wie bei "mul": "add eax,ebx,ecx" addiert ebx zu ecx und schreibt es in eax. würde vorallem das schreiben von compilern erleichtern ;)
3. die möglichkeit mehrere speicherzugriffe durch ein buffer-konzept zu machen, sodass auch "add byte [0x01],[0x02],[0x03]" gehen würde.
J!N
-
Mein Tip zu den Registern: alle gleich gross! nicht erschwert dem Programmierer die Sache mehr als die Abwärtskompatibilität von Intels x86 (z.B.). Punkt 2 von JN finde ich auch gut. Die Frage ist ausserdem, was man alles realisieren kann, man bedenke mal das Budget von Intel, ich glaube nicht, dass deine CPU noch mehr Sachen unterstützen wird...aber viel Spass trotzdem ;)
-
Ich find so Sachen immer cool, auch wenn ich keine genaue Vorstellung hab wie ihr das macht. Also bei joachim schleimen und das Tagebuch ins Magazin schreiben.
Wenn man sich bei den Befehlen an Intel-Kompatible CPUs hält, muss man sich keinen eigenen Assembler schreiben (man muss ja nur die Grundbefehle einbauen und den Rest einfach nicht verwenden).
-
was sollte ne CPU können? ich würd sagen register haben, rechnen können mit diesen und ports sowie speicher ansteuern. fertig.
ein paar tipps von mir, wie ich es machen würde, wenn ich könnte (sorry, wenn ich total maßloses verlange, aber ich hab kA, was möglich ist, und was nicht, deswegen spreche ich nur meine träume aus.) und muss man dafür nicht einen eigenen assembler schreiben?
1. register, die sich vollständig bis hin zu bytes oder gar bits aufteilen lassen (EAX ist normalerweise in AX und das in AL und AH aufteilen lassen). z.B. EAX = AX1 (= AL1 & AH1) & = AX2 (= AL1 & AH2). und ggf. auch adressieren von einzellnen bits: (AL1 = AL10 | AL11 | AL12 ... | AL17).
2. mehrparametrige verarbeitung wie bei "mul": "add eax,ebx,ecx" addiert ebx zu ecx und schreibt es in eax. würde vorallem das schreiben von compilern erleichtern ;)
3. die möglichkeit mehrere speicherzugriffe durch ein buffer-konzept zu machen, sodass auch "add byte [0x01],[0x02],[0x03]" gehen würde.
J!N
ad 1: sollte eigentlich kein problem sein..man muss eigentlich nur die adressleitungen durch einen multiplexer jagen..kommt auf meine todo-liste ;)
ad 2: das wird dann vielleicht ueber den assembler gemacht, aber ich denke nicht, dass wir das direkt als opcode zur verfuegung stellen..oder vielleicht doch, ich weiss noch nicht - so weit sind wir ja noch gar nicht :)
ad 3: was ja eigentlich das selbe sein sollte, wie mehrere add-zeilen mit je einem parameter, oder? (siehe ad 2)
danke fuer eure kommentare..und nicht schuechtern sein, ich will das ding so gut, wie das meine kenntnisse erlauben, machen!
lg, hannibal
-
Ich find so Sachen immer cool, auch wenn ich keine genaue Vorstellung hab wie ihr das macht. Also bei joachim schleimen und das Tagebuch ins Magazin schreiben.
Wenn man sich bei den Befehlen an Intel-Kompatible CPUs hält, muss man sich keinen eigenen Assembler schreiben (man muss ja nur die Grundbefehle einbauen und den Rest einfach nicht verwenden).
1. wieso schleimen? ;)
2. dann bräuchte man auch keinen neuen, weil man die Opcodes so lassen muss, dann kann man auch nix neues machen.
J!N
-
Irgendwie schon richtig aber man könnte sich etwas Arbeit sparen.
Machen wir mal ne Pro & Contra Liste: ^^
Pro ist für Intel-Kompatible Befehle und Contra dagegen
Pro:
o Kein neuer Assembler
o Hört sich professionell an ;)
Contra:
o Man lernt weniger dabei
o Ist fast komplizierter als nen eigenen Befehlssatz
Wenn ich mir das so ansehe: Mach nen eigenen Beehlsatz :D
-
Tu mir einfach einen gefallen ... schau dir auch die mac prozi's an. Jaja ich höre schon von überall das Buhen ... :cry: Aber mac is einfach 1000 fach besser als win und die Hardware auch :twisted: Vorallem (so wie ich das gehört hat) haben die mac prozis (Die G reihen) ziemlich komplexe und grosse "pipes" um alles aus der Hardware heraus zu kriegen. Hört sich doch kopierbar an :wink:
-
Ein paar Sachen auch von mir.
1. Versuche, jeden Befehl so schnell wie möglich ausfuehren zu lassen (1 Tick wird schwerlich möglich sein, aber vielleicht...)
2. Mache nur einen Mindestsatz an Befehlen (Registerbefehle, Speicherbefehle, Rechenbefehle reicht aus, oder vergess ich was?) Der Mac 6800 soll nur 35 oder so gehabt haben.
3. Mache den Prozessor nach aussen hin so einfach wie möglich (s.3), damit er nichts einfacher und nichts schwieriger macht.
4. Wie gross sollen die Register denn werden? 8 Bit ist fuer ne Selbstbau-CPU gut, 16 oder 32 Bit prima. 64 wäre dann ein guter Scherz :)
5. ist ein Link: http://mycpu.mikrocontroller.net/index2.htm
Und kuemmere dich nicht um irgendwelche Kompatiblität, da du die ja eh in die Tonne treten darfst :) :) :)
Aber der FPGA ist ein programmierbarer Chip, oder? Wenn die CPU komplett läuft, kannst du alles ja festverdrahten und es noch schneller machen :) Je kleiner die CPU ist, umso höheren Takt kannst du reinjagen (s.5 ^^)
Viel Spaß & Erfolg!
Svenska
-
Takt frequenz is ned alles! Deine Buse und CO müssen auch das standhalten ... sonst kannst du dir das in die haare schmieren :P
PS: Der G5 von Apple is nen 64 bit Prozi... dazu besitz er noch ne methode die dazu sorgt das er IMMER gebraucht wird. Sprich er verscuht vorauszurechnen und kann damit schon zeit sparen ... was wiederrum wenig mit dem Prozi zu tun hat :P
-
Tu mir einfach einen gefallen ... schau dir auch die mac prozi's an. Jaja ich höre schon von überall das Buhen ... :cry: Aber mac is einfach 1000 fach besser als win und die Hardware auch :twisted: Vorallem (so wie ich das gehört hat) haben die mac prozis (Die G reihen) ziemlich komplexe und grosse "pipes" um alles aus der Hardware heraus zu kriegen. Hört sich doch kopierbar an :wink:
ach, schön, nur soweit ich weiß ist Mac-OS ein betriebssystem und hat rein garnix zu tun und die hardware hat rein garnix mit win zu tun. ist das normal unter macern, dass sie immer alles vermischen, oder liegt es daran, dass man diese rechner, die gerne in sachen standarts aus der reihe tanzen, so ziemlich nur in komplettsystemen bekommt, weil sie größtenteils inkompatibel sind?
-
dass man diese rechner, die gerne in sachen standarts aus der reihe tanzen, so ziemlich nur in komplettsystemen bekommt, weil sie größtenteils inkompatibel sind?
Deine Sichtweise ist ein wenig einseitig... der Apple Macintosh ist eine andere Plattform, da ist es wohl normal, dass da eigene Standarts gemacht werden...
Versteh mich nicht falsch, ich bin selber ein x86er, aber deine Sicht ist nicht ganz richtig.
-
Wie hast du heraus gefunden das ich ne macianer bin :lol:
Ein "Mac" kernel braucht auch nen Mac prozi is doch klar. Sonst würde ja xp auf meinem iMac gehen :wink: Also is es DOCH hardware bestimmt. Oder wenigstens stückweise ^^ nun mac is nicht inkompatibel weil ich bezweifle das dein IBM rechner mit meinem G4 zockt :roll: das is so wie wenn man versucht ein auto mit einem Velo dinamo zu speisen...
-
kinder kinder, ich will jetzt nicht, dass das in einen mac-linux-windows-hard-und-betriebssystem-undsoftware-krieg ausartet .. ;)
vorerst wird es mal ein 8bit prozessor mit einem kleinen befehlssatz, der nicht ueber mov, add, sub, shl, shr, mul hinausgeht. vielleicht noch out und in fuer die aussenwelt. wenn das funktioniert, dann werd ich ueber weitere dinge, wie zb. 16/32 bit, nachdenken ;) .
lg, hannibal
-
Wirklich wichtg sind Sprungbefehle. Vor allem beim cmp Befehl braucht man die. Ich glaube das 2/3 aller Befehle von 486er Sprungbefehle sind, aber 2-3 sollten reichen.
-
Und vergiss nicht Register und Speicheraddressierung! :D
Ach ja, wieviele Register willst du denn machen?
Takt frequenz is ned alles! Deine Buse und CO müssen auch das
standhalten ... sonst kannst du dir das in die haare schmieren :p
Wenn jeder Prozessorbefehl in einem Takt ausgefuehrt wird, ist es schon
abhängig von der Taktfrequenz. Ausserdem schrieb ich kann... du
kannst in nen 8-Mhz-Rechner keine 2 Ghz-CPU reinstopfen. :p
Aber es bleibt bei sowas immernoch "Luft" zum Optimieren, wenn du zu
knapp kalkulierst, ist er nach paar Mhz am Ende. Vergleiche Punkt 5 :p
Fuer Macianer sind Hard- und Software identisch, da fuer den nicht zu
trennen :p :p Auch wenn man da mit Mueh und Not Linux raufkriegt.
Svenska
-
Fuer Macianer sind Hard- und Software identisch, da fuer den nicht zu
trennen :p :p Auch wenn man da mit Mueh und Not Linux raufkriegt.
doch schon nur is es ziemlich egal was für ne garfik karte drin hast. Laufen tuts so oder so sehr gut :P und wegen linux *hust* ich hatte mal win200 und 9.1 drauf und Yellow Dog is soviel ich weiss noch jetzt installiert. Wenn man weiss wie is alles einfach ;)
PS: Sorry bin schon wieder vom thema ....
-
Also, ich wünsche euch viel Glück bei dem Projekt, alles was ich vorgeschlagen hätte, wurde schon gesagt :)
bzg. Mac: Es gibt keine Mac-Prozessoren, in einem Mac sind ganz normale PowerPCs soweit ich informiert bin. Achja zu Standards sollten wir x86er doch eigentlich überhaupt nichts sagen :D
-
jo stimmt, weitere infos hier http://www.apple.com/de/g5processor/
-
Habt ihr euch schon über die Grundarchitektur geeinigt?
RISC oder CISC? Ich wüde RISC empfehlen, kein Overhead mit Microcode. Ein gutes, aber sehr altes Buch zum Thema ist Mikroprozessorlehre oder auch so ein von MITP, hab vbergessen wie es heißt. Man müsste sich auch überlegen, wie viele Register die CPU haben soll und ob solche Mechanismen wie caching oder virtuelle Adressierung (vorausgesetzt Multitasking) eingesetzt werden, aber davon kann ich nur abraten......
-
Habt ihr euch schon über die Grundarchitektur geeinigt?
RISC oder CISC? Ich wüde RISC empfehlen, kein Overhead mit Microcode. Ein gutes, aber sehr altes Buch zum Thema ist Mikroprozessorlehre oder auch so ein von MITP, hab vbergessen wie es heißt. Man müsste sich auch überlegen, wie viele Register die CPU haben soll und ob solche Mechanismen wie caching oder virtuelle Adressierung (vorausgesetzt Multitasking) eingesetzt werden, aber davon kann ich nur abraten......
um ehrlich zu sein haben wir uns darueber noch nicht wirklich gedanken gemacht..wir sind grade dabei eine prototyp-platine fuer den sockel und den fpga-programmer aetzen zu lassen um dann zu schaun ob die layouts passen....naeheres erfahrt ihr dann spaeter in meinem 'tagebuch' ;) .
lg, hannibal
-
na, wie läuft's?
-
na, wie läuft's?
na, wie läuft's?
Naechste Woche ist vorraussichtlich das Board fertig, damit wir die FPGA's beschreiben koennen. Vom Code her steht bis jetzt nur ein paralleladder.
Aber wir haben uns auch nicht abgehetzt, bis wir fertig sein muessen haben wir noch ueber ein Jahr ;)
-
wir haben noch eineinhalb jahre um genau zu sein ;)
-
lol,
fein, ihr liefert ja sicher genaue beschreibungen ;) und natürlich sämtliche pläne. fangt, wenn ihr was beschreibt am besten bei 0 an, damit auch leute, die nichmals die diagramme lesen können, das verstehen. danke! kommt natürlich ins maga :D
-
Uhh, Addierer und Multiplizierer ... erinnert mich so sehr an Technische Informatik ...
-
Dann bauen wir das alle nach :D
-
Halbaddierer und Volladdierer sollte man auch unterscheiden^^
-
lol,
fein, ihr liefert ja sicher genaue beschreibungen ;) und natürlich sämtliche pläne. fangt, wenn ihr was beschreibt am besten bei 0 an, damit auch leute, die nichmals die diagramme lesen können, das verstehen. danke! kommt natürlich ins maga :D
Rate mal warum ich gerade fuer die Seite eine Digitaltechnik Einfuehrung schreibe. :P
Mit dem sollte das schon fuer jedermann verstaendlich sein.
Halbaddierer und Volladdierer sollte man auch unterscheiden^^
Na ja, ein Paralleladierer ist ja klar was man da hat - spaetestens wenn man weiss, wie gross ein Wort sen soll. ^^;
-
Na ja, ein Paralleladierer ist ja klar was man da hat - spaetestens wenn man weiss, wie gross ein Wort sen soll. ^^;
Macht doch ein Byte á 10 Bit und ein Wort demnach 20 Bit (dw 40, qw 80). Rechnet sich dann im Hirn leichter :)
Gab glaube auch mal cpu's (lange vor dem 8086), welche Bytes mit anderen Bitzahlen verwendeten...
*lach*
-
lol, 8bit sind gewohnter und logischer :D
-
Ich fände 10bit cool ;D
oder auch 5 ;D
-
Halbaddierer und Volladdierer sollte man auch unterscheiden^^
Na ja, ein Paralleladierer ist ja klar was man da hat - spaetestens wenn man weiss, wie gross ein Wort sen soll. ^^;
Mir fallen direkt zwei Addierer ein mit denen man in gewisser Weise Parallel addiert - ein guter (Von Neumann) und ein schlechter (Carry-Ripple).
-
Ich bin mir gar nicht mal so sicher, ob nicht sogar der Cray mit einer etwas ungewohnteren BItanzahl arbeitete (Das hoerte ich neulich, aber ich glaube nicht ganz daran.)... aber aus dem Kopf kann ich das nicht sagen^^
Mir faellt mindestens noch der Carry-Look-Ahead-Addierer, und der Rarry Ripple ein ... und natuerlich die 'Erweiterung' auf Carry-Skip-Addierer. Der ist von der Worst-Case-Laufzeit her nicht so schlecht, und braucht sehr wenige Teile (Na ja, es gibt ja genug Schaltnetze mit Rückkopplungen und Delays .... aber der Neumann, und einige Carry-Varianten sind schon wichtig zu kennen)
-
Es gab mal 7 Bit-Bytes aber logisch ist es nur wenn ein Byte auch aus einer zweierpotenz an bits aufgebaut ist. also 1,2,4,8,16,32... da es ja binärsystem ist, wäre sowas das einzig sinnvolle
-
Erstens das, und sonst bekommste noch die Probleme, nichtmals nen Assembler auf einem anderen OS schön aufbauen zu können, weil man mit denen nur bytes lesen und schreiben kann. Außerdem währe dann auch der Zeichencode anderst. Da würde ich mich an das übliche halten...
-
...und zum anderen währen dann plötzlich alle so schön aus- und umgerechneten Zahlenangaben weg :)
10 Bit / Byte hat auch was fuer sich, zum einen bräuchte man sich (sofern man auf lateinischem Alphabet aufsetzt) keine Sorgen um Zeichencodierung mehr machen (10 Bit reichen, 8 nicht). Nun gut, Konpatiblität hin oder her, ist auch egal :) Wird eh zu nichts kompatibel und wer die Bits nicht braucht, setzt das Sys dann in einen 8-Bit-Kompatiblitätsmodus ;)
Aber käme schon cool, mal ein bisschen an den Grundfesten der Elektrorechner ruetteln :)
-
Naaa, 16 Bit Unicode würde beim Zeichensatz sogar in asiatischen Gebieten helfen. Andere möglichkeit wäre bei Java UTF-8, das ist dann kleiner als Unicode, aber auch komplizierter zu benutzen für den Programmierer (ausser natürlich er hat ne Klasse die sich intern darum kümmert ;) ).
-
man kann doch nicht einfach eine einheit der informatik, die eine bestimmte groesse hat, einfach so umaendern o_O
man kann sagen, dass der prozessor 10bit auf einmal verarbeitet und nicht 8, aber an sich ist ein byte nun mal 8 bit gross :p
-
ch hatte mal win200 und 9.1 drauf und Yellow Dog is soviel ich weiss noch jetzt installiert.
9.1 von was :D
Wir önnten ja CommOS für deine CPU portieren :wink: obwohl ich glaube das der Kernel im moment sehr an x86 fixiert ist 8)
-
man kann doch nicht einfach eine einheit der informatik, die eine bestimmte groesse hat, einfach so umaendern o_O
Gerade _das_ ist doch der Witz dabei :)
-
Ein Byte ist nicht standardisiert auf 8Bit :lol: es war halt mal so, dass man mit Byte 7 Bit meinte. Warum nicht also 10 draus machen?