Lowlevel
Lowlevel => Das Wiki => Thema gestartet von: BigOlly am 12. April 2004, 04:30
-
Hi Leute!
Ich hab hier was interessantes:
Wenn wir bisher vielleicht der Meinung waren wir wären etwas verrückt wenn wir vor haben unser eigenes Betriebssystem zu schreiben... dann kann ich jetzt Entwarnung geben...!
Es gibt noch viel verrücktere !!!
Beispiel gefällig? Okay:
Hier ist jemand der hat sich doch tatsächlich seine eigene CPU gebaut!
http://mycpu.mikrocontroller.net/index2.htm
Hat tatsächlich einen eigenen Prozessor entwickelt. Selbst zusammengelötet inclusive Register, Interupts, Mikrocode usw.
Und das ding läuft sogar! Ich hab ein bisschen auf den Seiten dort gestöbert.. ist echt interessant. ...aber ihr könnt ja selber mal vorbeisehen.
Genau genommen ist der "Typ" noch einen riesigen Schritt "low-leveler" als wir. Noch ne Ebene tiefer geht wohl kaum noch.
Und um den Bogen zu unserem Thema wieder zu bekommen...: Einen Kernal für seinen mit der CPU aufgebauten Rechner hat er natürlich auch geproggt. Kann man zwar nicht unbeding für unsere Zwecke verwenden, aber interessant ist es alle mal! :)
Vielleicht ist es ja sogar eine Erwähnung im nächsten Magazien wert unter der Rubrik "kurruioses" oder "Hardcore-LowLevel"... ;)
-
Man der Typ hat echt nen Schatten. Ich kann nur sagen Respekt.
-
Hehe.
Ist garnicht sooooo schwer.
Ich nehme sowas gerade auch in Digitaltechnik durch.
MIt den richtigen Bausteinen (die Programmierbar sind) kann man eigentlich "recht einfach" einen eigenen Prozessor bauen.
Aber es ist natürlich sehr komplex wenn man etwas wie den Protected Mode darin umsetzen will.
Aber eine coole Sache find ich das schon :)
-
Naja über sowas hat ich auch schonmal nachgedacht aber hm...*hust* egal :P
-
Das Problem ist halt das man dazu auch Programmiergeräte für die Bausteine benötigt. Und die sind halt nicht gerade in jedem Haushalt vorhanden *g* und auch nicht umbedingt günstig.
-
Meinen ersten Computer hatte ich damals auch selber gebaut. Leiterplatten selber mit Lack gemalt, geätzt und gebort, Chips draufgelötet... naja, bis zum Gehäuse.
Aber entworfen hab ich ihn nicht. War also ein Nachbau (der Computer wurde damals in einer Fachzeitschrift vorgestellt).
Und... die CPU war auch gekauft und nicht selbst gebaut. :-) (war ein Z80 von Zilog)
-
Aber ma abgesehen davon kann man sich auch ma so nen schönen AVR Mikrocontroller zulegen is billig und macht riesigen spass damit rum zu experementieren. Und man lernt noch nen bischen asm.
-
Ich darf demnächst GAL Chips programmieren :)
Ich kann dann ja mal dazu einen kleinen Bericht schreiben wenn ich das hinter mir habe.
Das ganze ist aber ein bisschen was anderes. Der Chip wird nämlich dahingehend programmiert, das er dann bei bestimmten signalen die er erhält, bestimmte SIgnale ausgibt.
Sprich man programmiert den Chip so, das er bei einem bestimmten "Befehl" etwas bestimmtes tut :)
-
Es gab mal vom heise-Verlag nen Artikel über Open-Source-CPU-Projekte und Entwicklungsprogramme dafür. Da haben die auch ein Projekt mit 32bit, Multithreading und allem Schnickschnack vorgestellt.
-
Hmm...ich hab mal ne Frage...: Würdet ihr es für möglich halten, in einem halbjährigen Schulprojekt einen einfachen Computer zu bauen???
Wie würdet ihr ihn im Groben machen?? (Arbeitsspeicher, Diskett...blabla)
Nooooooos
-
kommt darauf an was du alles selber machen willst
-
und wie gut du bist.... wenn du dir alles inkl. Speichermedien komplett selber baust, halt ichs für unrealistisch. Aber nur MB-artiges, kleine xyz-CPU, Floppycontroller, Grafik? Könnte gehn ^^
-
jo so etwa...eben vieleicht 6bit, mit flash-speiceher, floppy + grafik...sollte schon selber gemacht sein...und vieleicht noch ein OS mit brainfuck...
-
versteh ich euch richtig dass ihr auch son ding selber bauen wollt?
-
Hmmm ich habe da sone Idee...und jezt will ich von den anderen wissen, ob das in einem halben Jahr möglich sein könnte...
-
nun ja.
der herr hat 2001 damit angefangen. wir schreiben nun das jahr 2006 fast schon 2007 somit ist das projekt schon gut 6 Jahre alt.
Der Herr hat elektrotechnik studiert und sollte sich daher in dem themengebit auskennen.
Für mich ist das eher eine frage der Fachkenntniss und des Zeitaufwandes. Und der vorhandenen Technischen möglichkeiten ( Software wie z.B. Simulationssoftware für analog und / oder digitaltechnik und HW wie Lötkolben, Bohrmaschine, ... )
6 Monate 8 Stunden täglich + ggf freizeit (so wie bei einer Diplomarbeit) da kann gut was geschaft werden. nur wenn nebenher noch der normale schulunterricht läuft ...
-
Ja er soll ja auch nicht nacher "brauchbar" sein...Aber einfach so Zeilen-ausgabe und vieleicht ev. mal VGA sollte sich machen lassen....
@termite: ja also gedacht sind pro woche 3stunden...natürlich könnte man noch ein bissel freizeit aufwende...aber schule haben wir noch :-(
hältst du das für schwierig???
-
Ich halte es nicht für schwierig. Sondern für nicht machbar in dieser Zeit, vor allem, wenn man keine wirklichen Vorkenntnisse hat. Sagen wir mal, mit theoretischen Vorkenntnissen und zehn Stunden pro Woche schaffst du in einem halben Jahr einen einfachen Prozessor.
-
Aha...danke...
Ne frage...der "herr da" hat ja seinen Prozessor in etwa 20 Funktionen aufgeilt...könnte man das theoretisch auch einfacher machen...weil es muss ja wirklich kein supperprozessor werden....
-
Moin
wenn ich das mal überschlagen darf. 3 Stunden die Woche ein halbes schuljahr lang sond dann so ca 60 Arbeitsstunden in summe. Somit das was arbeitendes volk in 1 bis 2 wochen schaffen kann.
Das problem das sich mir auserdem weiter stellt, habt ihr überhaupt passende Messgeräte wie Digitales speicher Osziluskop bzw dital analizer zur hand? denn ohne die werdet ihr sehr viel freude bei der fehlersuche haben.
selbst wenn ich die platinen aufbauen müsste. 60 Stunden für alle 5 platinen die dort allein für den prozessor verwendet werden sind schon recht happig. Mann sollte die Zeit nicht unterschätzen die da draufgeht für entflechten, Platinenfertigung, und bestückung. Auch bei einem lochraster aufbau mit Fädeldraht sollte man sich vorher überlegen wie man aufbaut.
und zum schluss fehlersuche. eine der zeitraubensten aufgaben.
Bei meinem gesellenstück hab ich damals für 3 platinen insgesamt 60h veranschlagt. 16 für den aufbau und 44 für fehlersuche und in betriebnahme. und mit den 44 lag ich total daneben. ( lag aber wohl auch daran das ich mich damit wohl etwas zu schweres ausgesucht hatte. Geschweigeden von den 30 stunden für die Programmsteuerung. die waren sowieso gnadenlos daneben)
gruss.
ps. Geselenstück war ein Dolby Soround decoder auf DSP basis von Philips. Quasi selber zusammengeschnitzt, so direckt als bausatz gab es das damals nur auf analogbaisis.
-
Ich habe vor demnächst mal ne CPU/Computer zu bauen, der in BrainFuck (oder eine an BF angelehnte sprache) programiert wird. Also wirklich nur die Fähigkeit hat, speicher zu adressieren und zu inkrementieren/Dekrementieren. Input wird dann über 8 Taster geregelt (binäre eingabe) ausgabe über ein LCD-Display
Habe mir allerdings noch nicht soo viele gedanken darum gemacht...
-
Hmmm gut danke....aber ne komplexe komplette CPU wird das sicher nicht geben...
-
Muss auch ein risen Teil werden, wenn man ne 64Bit CPU nur mit TTL-Bausteinen und lochrasterplatinen bauen will. Da möchte ich keine Fehler suchen :).
Und winXP mit 100MHz...
Also wer eine PC-CPU bauen möchte hat wirklich irgend wo ne schraube locker...
Ich denke, eine eigene CPU ist ähnlich wie ein eigenes OS. Mann darf sich nicht zu große ziele setzen, und sollte überlegen ob eine 8Bit-Akkuorientierte CPU nicht besser ist als eine 64Bit-Registerorientierte CPU mit FPU kompatibilität zum IA-64 - Befehlssatz.
Möche mich an dieser Stelle auch mal als E-Techniker outen. Mache gerade Ausbildung als "Staatlich geprüften Elektrotechnischen Assistenten", und werde bald Steuerungs- und Regelungstechnik Studieren.
-
hey, was spricht gegen XP mit 100 Mhz? Tiefenrekord was läuft sind 8 :P Aber stimme dir zu, zu große Ziele bringen nix. Lieber klein anfangen, bei bedarf erweitern ^^
-
Ich halte es für unrealistisch, eine allgemeintaugliche CPU in einem halben Jahr aufzubauen. Denn diese will ja auch angesteuert werden, mindestens mit einem Monitor, besser einem Betriebssystem. Dafür muss die CPU an sich aber wieder ausgelegt sein, sprich, die Grundlagen liefern.
Dagegen ist es imho durchaus möglich, eine programmgesteuerte ALU aufzubauen, wenn man nach jedem Einschalten das Programm quasi "eintastet". Solche Projekte wurden viel in der DDR gemacht, besonders im Bereich der theoretischen Informatik / Elektrotechnik.
Ich will auch irgendwann mal eine CPU entwickeln, aber das wird sich wohl eher länger hinziehen... erstmal bastle ich einen TINY (http://hc-ddr.hucki.net/jutecomp_seiten.htm") (auch COMP JU+TER) - die Unterlagen habe ich hier.
Jetzt brauche ich "nur" noch entsprechende kompatible Bauteile. Der UB 8830 D (dort U880/Z80-CPU mit Basic-Interpreter im ROM) ist ein Nachbau vom Zilog Z8671 usw. Wird nicht leicht, da der UB8830 seit 1990 und der Z8671 seit 1998 nicht mehr produziert wird.
Wenn ich erstmal meine Vorabiturprüfungen bestanden habe, werde ich mich näher damit beschäftigen.
Apropros: Auch ich werde voraussichtlich ab WS '07 in die Elektrotechnik gehen (Studiengang Informationstechnologie, Uni Magdeburg).
Gruß,
Svenska
-
Hmm ja danke...
Ne frage: Würdet ihr ein Diskettenlaufwerk anschliessen?? Haltet ihr dies für schwierig??
Wie würdet ihr sonst OS und Software in das System bringen...?
Gruss
Noooooooooos
-
schau dir doch mycpu an ^^ da läuft dateiübertragung mit ner Art "Festplatte" auf vielen Platinen und ner Seriellen Schnittstelle, aka COMx... zum empfang könntest vllt. nen fest programmierten chip einsetzen. oder du baust die Empfangslogik für so ne Schnittstelle mit auf so ne Platte.
andererseits. Ich denk nicht das floppy soooo schwierig ist ;) hatte mal nen link wo ne menge hardwareschnittstellen beschrieben war, kann mal schauen ob da was über Floppys steht
-
Ich würde da etwas eigenes bauen...
Also nen eigenen Datenträger (z.B. aus einfache RAMs & ne 9V-Blockbatterie) und 2 Schnittstellen, wobei eine per rs232 o.ä. mit dem PC und eine mit der eigenen CPU/Computer verbundne ist...
Sowas macht doch mehr spaß, als sich in irgendwelche standards zu zwängen ;)
ist zwar nicht so stylisch wie ne floppy und hat nicht die Kappazität ner DVD, aber ist wesentlich cooler 8-)
-
Joa wär auch ne Idee...also meinst du jetz, dieses ding zeitgleich am pc und am eignenbaucompi anzuschliessen??
EDIT:
Sry, hab dich falsch verstanden. Ich hab eigentlich vor Rs323 auch im eigenbaucompi einzubauen. Den kann ich dann für Tastatur und ev. auch ma für maus benutzen....Oder ist das schwierig??
Anstatt RAM könnte ich doch auch einfachen Flash-speicher z.b. von nem USB stick nehemen??
Andere Frage, wär solcher Flash-Speicher auch als Ram oder/und Festplatte brauchbar. Also gar keine Festplatte, sondern nur beständigen Arbeitsspeicher??
-
Ist das bei den AVR-Contoller nicht so?? also zumindest der Programm-speicher? Da wird das Programm doch direkt aus dem Flash ausgefürt.
Und den Datenspeicher sollte man auch mit Flash realisieren können....
Zumindest ist es bei der Siemens S7 so, das die Daten im "RAM" selbst nach ausschalten der SPS noch erhalten bleiben...
Ich würde es zumindest per Flash machen...
Das ist einfach und und günstig. Lieber mal 2-3 Flash-Speicher zerstören, als sofort ne teure Festplatte...
Als Programmspeicher oder zur Datenübertragung währen aber urzeitliche Speichermedien auch mal interessant. z.B. Lochkarten... Würde zumindest bei mir zum "Turing-Machine-Theming" passen ;)
-
Mein huebscher PDA hier verwendet auch nur Flash Speicher (+ ein paar MiB fluechtigen RAM) sowohl als RAM, als auch als Massenspeicher (neben SD-Karte).
Abgesehen davon, wird Flash so und so in Embeddedsystemen seit (fast) Jahren eingesetzt um nicht fluechtigen Speicher zu liefern.
Lg, Alex
-
Als Programmspeicher oder zur Datenübertragung währen aber urzeitliche Speichermedien auch mal interessant. z.B. Lochkarten... Würde zumindest bei mir zum "Turing-Machine-Theming" passen ;)
Eine anständige Turingmaschine hat aus zwei Rollen Klopapier zu bestehen. (ja, ja, Info I, das waren noch Zeiten... ;))
-
kopf süttel.
ram = flüchiger speicher
rom / flash = nichtflüchtiger speicher.
Arbeitsspeicher besteht zumindest meines wissens immer irgendwie aus ram. ob das nun SRAM SDRAM oder sonstwas für ein RAM ist es bleibt ram. auch wenn er im controller verbaut ist ( meist sram, der braucht keinen aufwendigen speichercontroller für refreschzyklen,... )
ROM gibts auch in verschiedenen versionen. z.B. OTP (one time programabel)
oder z.B. eeprom der ist wiederbeschreibbar. genauso wie flash (nand/ nor mit 1, 2 oder 4 bits je speicherzelle) flash hat aber im gegensatz zu eeproms das problem das er nur blockweise gelöscht werden kann. eeproms brauchen das nicht, sie könnem meist zellenweise direckt überpogramiert werden.
die zukunnft wird vileicht Speicherbausteine auf magnetbasis bringen. die währen so schnell und haltbar wie RAM, und würde ihre daten bei spannungsausfall nicht verliehren. ( so wie füher die rigkernspeicher aus den 50er/60er jahren.
viele controler haben auser dem controler und den IOs zusätzlich noch RAM und/oder Flash und/oder eeprom speicher mit dabei.
AVR hat zumindest den vorteil, das die entwicklungsumgebung mit c-compiler von ATMEL frei erhältich ist.
gruss
-
Arbeitsspeicher muss NICHT unbeding aus RAM bestehen!
Der häufigste grund, warum man häufig RAM nimmt ist die Geschwindigkeit, und weil's billiger ist. Außerdem kann man RAM-Speicher häufiger beschreiben als z.b. eeproms...
Es gibt kein gesetz, das verbietet, einen nicht flüchtigen speicher als Arbeitsspeicher zu nutzen...
-
Hmm...ja danke ich werd dann mal schaun, obs mit flash möglich is...
Und eine serielle Schnittstelle, ist sowas schwierig??
EDIT:
Ähm ne frage, wenn ich jetzt im Flash Speicher ein Byte schreiben will, muss ich dann zuerst den ganzen Sektor in nem eeprom sichern, diesen Sektor löschen und dann das Byte im eeprom löschen und neu schreiben, um schliesslich den Inhalt des EEPROMS wieder in den Flash-Sektor zu schreiben...?? Das ist ja wahnsinnig umständlich?
EDIT:
Ich könnte natürlich auch auf Diskette + Festplatte verzichten und z.B. zwei Speicherkartenslots implementieren...Haltet ihr das für schwierig?
EDIT:
Der Herr da verwendet ja nur 8Bit-Register, aber wären denn nicht auch 16Bit Register machbar? Er spricht ja mit seinem System auch 128KB an.
Wären z.B. auch 18Bit möglich?
-
Klar sind auch 16 Bit machbar.
Allerdings hat man dann wesentlich mehr Kabel/Lötstellen usw. Das Ganze teil wird einfach wesentlich umständlicher...
(das meinte ich bei meinem Erten beitrag mit "nicht zu große ziele setzen")
Man sollte sich fragen, wie groß der Adressraum sein soll. Reichen 8Bit (256 Bytes), oder braucht man mehr (16Bit: 64KB).
---
Ich habe zwar noch nicht viel mit der RS232 gearbeitet, aber das IC "MAX232" von Maxim sollte die Anwendung/Verwendung sehr einfach gestalten
-
Hmm ja...und wenn ich einfach 2 8Bit Register zusammennehm (àla CS:AX), ist das genauso schwierig, weil Dennis hat ja insgeamt auch 130kb.
Und naja 256 bytes sind schon wenig, wenn ich bedenke, dass mein noch recht bescheidenes OS schon 32KB hat...
-
Mit segmentierung währe natürlcih ne lösung...
Aber du darfst dein 32/64 - Bit x86/x86-64 OS nicht mit einen OS auf einer selbstbau-cpu vergleichen.
Allerdings sind 256 Byte wirklich nicht viel.
Man könnte es ja so ähnmlich wie beim PC (80186)
CS,DS und reg
BSP.:
S = Segmentrgister (8 Bit)
I = Offset (8 Bit)
Bit 0..3 von S ist für das Datensegment
Bit 4..7 von S ist für das Codesegment
Addressierung:
Daten: (S & 0x0F : I)
Code: (S >> 4 : I
Dann kan man entseiden, ob daten/code in das selbe segment soll oder nicht ( S = 0xAA oder S = 0xAB).
Dann hat man einen 12 Bit adressraum was 4KB entspricht.
(Und mit 4 KB kann auch eine 16Bit PC-Anwendung einiges leisten)
-
Aha...ist aber jetzt 12Bit-Adressierung mit Segmentierung einfacher zu löten,blabla als eine 12Bit-Adressierung mit 12Bit Registern??
Und wenn ich jetzt vorhätte Arbeitsspeicher + Festplatte zu vereinen, dann müsste ich halt schon eher mehr Speicher adressieren können.
-
Was das RAM betrifft ... es wird immer als RAM verbaut. Egal, wo, wie und womit es beschrieben wird.
Aber EEPROM oder FLASH-Speicher als RAM zu benutzen ... das ist krank. RAM wird i.d.R. mehrere tausend Male pro SEKUNDE(!) geschrieben; FLASH würde dir nach ein paar Tagen was husten. Und ständig umlöten will auch niemand...
Aber um ein anderes Projekt anzusprechen, ebenfalls aus diskreten Bausteinen eine CPU zu basteln => http://www.homebrewcpu.com
Wenn ihr euch da mal die Bilder anschaut (freiverdrahtet), dann erlebt ihr ein Stück des Aufwandes. Die Tagebucheinträge (inkl.Problembeschreibungen & -lösungen) sind auch sehr interessant für jeden, der so ein Projekt in Angriff nehmen möchte.
Gruß,
Svenska
-
Selbst in den mikrigsten systemen die ich kenne PIC 10F200 wird der Arbeitsspeicher als RAM bezeichnet, und wens nur 16 Byte sind ( richtig gelesen 16 Byte, 128 bit. das ist weniger als ein PC alleine in seinen registern unterbringen würde)
Auserdem kenn ich kein controler, an dem ich ein eeprom als sram anschliesen könnte. Das geht allein schon wegen der schreibzyklen nicht. wenn dein system bei jeder variable die es verändert bis zu 100ms warten muss,... schnell ist dann was anderes.
[edit]
mit nem MAX232 oder ähnlich alleine ist es nicht getan. der kümmert sich nur um die pegelanpassung von TTL auf die von der RS232 geforderten werte . die UART brauchst du trozdem noch.
gruss
-
Aha...ist aber jetzt 12Bit-Adressierung mit Segmentierung einfacher zu löten,blabla als eine 12Bit-Adressierung mit 12Bit Registern??
Nein, ist natürlich nicht einfache, ganz im gegenteil, es muss noch eine steuereinheit gebaut werden, die zwischen Code und Datensegment wechseln kann.
Es war nur so ne idee, weil du DS:AX insprachest
@Svenska:
In der regel ist der Arbeitsspeicher RAM (wegen eben deinen genannten gründen)
Aber eine selbstbau-cpu hat nunmal keine 4GHz. Es ist nicht allzu schlimm, wenn ein speicherzugriff mal 100ms dauert. Ganz im gegenteil, das macht die Programierung erst richtig interessant ;)
Und eine selbstbau-cpu (im kleinen maße) wird auch nicht allzuoft auf den speicher zugreifen.
Allerdings währe es evtl mal ne gute überlegung, den flash nicht einzulöten, da er in der tag nicht jahre lang durchhalten wird.
@Termite:
Naja, nur weil nimand eeproms als Arbeitsspeicher nutzt, heißt es nicht, das es schlecht ist. Es ist halt nur für den industriellen einsatz ungeeignet.
Aber wenn man seine CPU anderen menschen vorstellt, und die an dem Punkt weiterarbeitet, an der man sie an vortag ausgeschaltet hat, wird das die Menge schon beeindrucken ;):)
Einfachste möglichkeit, daten vom PC zu übertragen:
2 Steuerleitungen der RS232 an ein Schieberegister klemmen. Zwei weitere für Bestätigungen:
PC -> irgendwas:
-> sreg-clk
-> sreg-data
-> byte übertragen
<- nächste byte kann übertragen werden
code:
for i=0, i<8, i+1
{
clk = 0
data = (byte>>i) & 1
clk = 1
sleep 100
}
byteübertragen = 1
while not nächstesbytekannübertragenwerden
-
Jop danke...eben um den Flash nicht fest einzubauen müssen, hab ich mir gedacht, ich nehm eine Speicherkarte, die ich dann einfach heraus ziehen kann...
Diese könnte ich dann mit einem Tool auch mit dem PC beschreiben...
Also wäre es eigentlich einfacher, wenn ich direkt 12Bit Register einbauen??
-
Wenn du direkt 12Bit register nimmst, brauchst du nicht 2 Register zu kombinieren. Das wird vor allem auch beim decodieren der befehle einfacher.
Das mit den speicherkarten ist ne gute idee...
-
OK danke dann mach ichs so...sofern Speicherkarten nicht zu schwierig werden.
Und wenn ich jetzt ein BYTE in Flash schreiben möchte, muss ich dann immer einen Sektor in nem eeprom sichern und das byte darein schreiben??
-
Ich weiß nicht, wie das Ausfgebaut ist, sooo viele gedanke habe ich mir noch nicht darüber gemacht...
es sollte aber schon irgendwie ne möglichkeit geben, nur 1 Byte zu "verarbeiten", sonst währe es sinnlos.
Ist flash-speicher generell in Sektoren unterteilt, oder nur der,der für PCs verwendet wird (um Dateisystem-freundlich zu sein)??
-
Moin
ein Flash speicher ist als Elektronische festplatte konzipiert. sprich. er ist block weise aufgebaut. ein block ist in der regel 512 Byte gross ( + 4 verwaltungsbyts fürs Flash layer) oder einem vielfachen davon. gelöscht kann normalerweise nur blockweise. je nach hersteller kann es auch möglichsein, nur einzelne byts zu verändern, dies kann aber nur z.B. ca 100 mal gemacht werden, danach muss der ganze sektor komplet gelöscht und wieder geschrieben werden. aber das kann man am besten aus den datenblättern der einzelnen hersteller entnehmen.
zum theman ausschalten und an der gleichen stelle weiterarbeiten. das tut nur effektiv mit Speicherbausteinen auf magnetbasis, ringkernspeicher ( drahtgitter mit vielen kleinen magnetkernen) oder mit den neuen speichergenerationen die gerade in entwicklung sind, die verwenden den gleichen physikalischen effekt, nur um vieles kleiner.
auserdem eeproms sind im schreibzugriff gegenüber ram sehr langsam faktor 1000 bis 10000 wenn nicht sogar grösser. Vom alterungsprozess gar nicht zu reden. ( 1 Million schreiboperationen je zelle). Auserdem was ist mit dem zustand deiner register? die müsten alle auch aus eeproms bestehen. allso ist zumindest der Programmcounter nach 1Million instruktionen fürn arsch.
gruss
-
@Svenska:
In der regel ist der Arbeitsspeicher RAM (wegen eben deinen genannten gründen)
Aber eine selbstbau-cpu hat nunmal keine 4GHz. Es ist nicht allzu schlimm, wenn ein speicherzugriff mal 100ms dauert. Ganz im gegenteil, das macht die Programierung erst richtig interessant ;)
Unterschätze nicht den Aufwand, ein EEPROM brennen zu müssen. Das Timing muss dabei noch eher genau sitzen als bei "normalem" RAM. Außerdem hast du bei RAM den Vorteil, dass du - für äußerst wenig Geld - eine hohe Kapazität und genug Geschwindigkeit bekommst.
Verwechsel nicht Milli- mit Nanosekunden!! Ich habe hier einen 286er stehen mit 16 Mhz, bei dem ich per DIP-Schalter die Waitstates abschalten kann, wenn ich RAM mit einer Zugriffszeit <70ns einbaue. NANOsekunden!
Wenn du - und davon gehe ich aus - deine CPU mit mehr als ein paar Kilohertz takten möchtest (auch ein C64 hatte annähernd 1 MHz), dann wirst du auf immer und ewig auf deinen RAM warten müssen.
100 ms sind sehr viel, denn das bedeutet 10 Lesevorgänge pro Sekunde. Schreibvorgänge sind noch langsamer. Und nun überlege dir, wieviele Register in einer CPU aus diskreten Bausteinen aufgebaut werden müssten, um nicht ständig RAM-Zugriffe zu haben. Viele Registersätze sind heutzutage mehrfach vorhanden, um teure RAM-Zugriffe zu sparen.
Und eine selbstbau-cpu (im kleinen maße) wird auch nicht allzuoft auf den speicher zugreifen.
Oh doch, jeder Zugriff auf eine Variable wird auf den RAM zugreifen; jede Programmausführung läuft aus dem RAM ab, jeder Maschinencodebefehl wird von dort geholt. Allein um 10 Byte aus dem Speicher zu holen, eine Sekunde zu warten, mag angehen, wenn du jedes Byte sehen und verstehen willst. Aber um damit eine serielle Konsole zu befeuern, ist das viel zu wenig. Der UART möchte bitte recht schnell angesteuert werden, um mind. 1200 Baud zu liefern (bei bis zu 300 Bps kann ich locker mitlesen). Deine CPU muss die Daten mindestens doppelt so schnell liefern können.
Allerdings währe es evtl mal ne gute überlegung, den flash nicht einzulöten, da er in der tag nicht jahre lang durchhalten wird.
Wieso willst du Chips da einlöten?? Sowas wird grundsätzlich mit Fassung erledigt, damit du im Falle des Falles (und sei es Überspannung durch falsches Netzteil) etwas gegrilltes austauschen kannst.
@Termite:
Naja, nur weil nimand eeproms als Arbeitsspeicher nutzt, heißt es nicht, das es schlecht ist. Es ist halt nur für den industriellen einsatz ungeeignet.
Ist zwar nicht an mich gerichtet, aber EEPROMs sind dafür nicht nur ungeeignet, sondern sinnlos. Wie gesagt, du möchtest die Register nicht mehr auf dem Papier mitzeichnen können...
Aber wenn man seine CPU anderen menschen vorstellt, und die an dem Punkt weiterarbeitet, an der man sie an vortag ausgeschaltet hat, wird das die Menge schon beeindrucken ;):)
Dazu müsstest du die Register ebenfalls im EEPROM haben, damit das geht (zumindest den Program Counter).
Außerdem erledigt man soetwas eher durch batteriegepufferte SRAM-Bausteine - einfacher, billiger, schneller und besser.
Meine Idee wäre, sich einen primitiven Speicherkontroller für ganz billige 30-pin-SIMMs zu basteln. Die sind zwar dynamisch, aber wenn man eh was damit vorhat, ist es eine einfache Möglichkeit. SIMMs sind billig und haben riesige (für Selbstbau-Projekte) Mengen Bits zum Beschreiben.
Wenn nicht, dann eben DIPs, die kann man auch als SRAM konstruieren. Bei angelegter Spannung nichtflüchtig. Der Monitor (Betriebssystem) sitzt dann in einem EPROM, wie auch - je nach Bedarf - die Maschinencode-Tabelle.
Einfachste möglichkeit, daten vom PC zu übertragen:
2 Steuerleitungen der RS232 an ein Schieberegister klemmen. Zwei weitere für Bestätigungen:
Quatsch. Den PC will ich sehen, der solch ungetimte Bits korrekt empfängt. Du musst dich entweder mit einer festen Baudrate begnügen - üblich sind 1200 oder 9600 Bps - oder einen Baustein (UART) korrekt ansteuern. Das ist nicht mit simplen Registern getan.
Ich will euch ja nicht die Illusion nehmen, aber fangt erstmal klein an, bevor ihr weitermacht. Projekte gibt es genug.
Ach ja - und ehe ihr einen IDE-Controller für Festplatten (oder CompactFlash-IDE-Adapter) oder sogar einen USB-Controller baut (*rofl*), braucht ihr erstmal eine ALU, die entsprechend gesteuert werden muss.
Gruß,
Svenska
-
Oke wenn Speicherkarten schwierig sind, dann nehm ich eben SIMMs.
Ich kann mir ja dann noch ein Gerät basteln, mit welchem ich vom PC aus per Serieller Schnittstelle aus auf den Speicher(aus den SIMMs) zugreifen kann.
Wegen der Segmentierung. Wäre das konstruktionstechnisch denn komplizierter, wenn ich zwei 8Bit Register nehm.
Weil wegen der Decodierung der Befehle hab ich mir da schon ein einfaches System ausgedacht, das wär warscheinlich kein Problem.
-
Wenn du so ein Projekt wirklich in Angriff nehmen willst, dann musst du dir erstmal gewisse Sachen überlegen, die über die CPU hinaus gehen.
Es ist einfacher, die Maschinencodeverarbeitung in ROMs zu legen und nicht in Silizium zu gießen (Bug-Behebung usw.) Das Betriebssystem (oder zumindest eine Art Monitor) sollte dann ebenfalls in ein ROM gebrannt werden (nichtflüchtig, einfach, Ansteuerung wie RAM).
Was die Ausgabe angeht, würde ich eher ein Hitachi-Display ansteuern (z.B. 40x4 Zeichen) und erst später etwas Größeres angehen.
Segmentierung ist imho Blödsinn bei 8-Bit-Systemen... aber ein anderer Ansatz ist vielleicht besser. Und zwar haben die Heimcomputer der 80er (z.B. KC85/4 der DDR) einen anderen Ansatz -> Banks.
Du könntest ein (oder mehrere) 16-Bit-Register zur Addressierung benutzen (ergibt einen Addressraum von 64 KB) und davon die oberen 32 KB quasi austauschen, je nachdem, was du gerade benötigst. Die unteren 32 KB enthalten die elementaren Routinen des Systems (oder das ganze System) inklusive z.B. Framebuffer ; die oberen 32 KB (Bänke) enthalten dann deine Applikationen.
Umtauschen geht dann über spezielle Register, die die einzelnen Addressleitungen dann direkt umtauschen. Oder du lässt die 64 KB komplett wechseln, musst dann aber Sorge tragen, dass dein Programm noch existiert (über einen zweiten Addressraum z.B.)
Schaue dazu auch mal auf SymbOS => www.symbos.de
Das ist ein Bankswitch-Betriebssystem für den Amstrad CPC mit bis zu 576 KB Speicher (in 64 KB Addressraum!)
Dort steht auch einiges über die Technik dahinter (max.Programmgröße 63 KB z.B. und warum das so ist).
Gruß,
Svenska
-
Hmm danke, wobei ich denke, dass dann 64KB auch genügen sollten...
Du könntest ein (oder mehrere) 16-Bit-Register zur Addressierung benutzen
Würdest du dann nicht alle Register 16Bit machen?
Achja: Zum Thema Flash als Arbeitsspeicher: Windows Vista soll ja auch USB-Sticks als Arbeitsspeicher nutzen....Die müssten ja nach einer Stunde Arbeit putt sein??
Gruss
Noooooooooooos
-
Hmm danke, wobei ich denke, dass dann 64KB auch genügen sollten...[/quote
64 KB insgesamt oder mittels Bankswitching auch mehr?
Denke immer an eins - wenn du eine Hardware bastelst und dort drei- oder gar vierstellige Stundenzahlen dran arbeitest, (und das ganze bis zum Ende durchziehst), dann willst du damit nicht nur Pi berechnen lassen oder schicke Zeichentabellen erzeugen. Dann willst du damit auch -arbeiten-.
Und - so meine Vermutung - wenn du soweit bist, dass du deinen Rechner gut programmieren kannst und alles stabil läuft, wird ein TCP/IP-Stack nicht lange auf sich warten (=> uIP von Adam Dunkels, einfach mal suchen). Und DANN wird es mit 64 KB ohne Erweiterungsmöglichkeit sehr eng.
Bankswitching in Hardware ist aber relativ einfach umzusetzen (verglichen mit der CPU als Ganzes). Das wird ohnehin über eine externe Logik geschehen und kann durchaus nachträglich geändert werden (allerdings muss dann sämtliche Software neu geschrieben werden).
Du könntest ein (oder mehrere) 16-Bit-Register zur Addressierung benutzen
Würdest du dann nicht alle Register 16Bit machen?
Ich hatte soetwas mal in Gedanken, mir ein bisschen ausgesponnen.
Die Frage ist nur, wieviel Aufwand ich treiben möchte. Du kommst ohne Programe auch mit 8-Bit-Registern aus, musst nur zusätzliche Arbeit und Rechenzeit aufw[e|ä]nden. Notwendig sind nur die Addressierungsregister in 16 Bit (um ohne Tricks 64 KB Addressraum zu besitzen), der Rest kann gerne 8 Bit haben. Dann solltest du die Addressierungsregister aber in 2 Schritten programmieren können (d.h. oben und unten getrennt füttern können).
Andererseits ist ein konstantes Schema durchaus vertretbar, d.h. alle Register wären 16-Bit breit.
Achja: Zum Thema Flash als Arbeitsspeicher: Windows Vista soll ja auch USB-Sticks als Arbeitsspeicher nutzen....Die müssten ja nach einer Stunde Arbeit putt sein??
Du verwechselst Arbeitsspeicher (RAM) mit virtuellem Speicher (durch MMU zur Verfügung gestellt)...
Windows Vista benutzt den Flash zum Auslagern von nicht benötigtem Speicher auf andere Medien, um damit Arbeitsspeicher(!) für andere Prozesse freimachen zu können.
Das gleiche Prinzip gibt es heute, in Form einer Auslagerungsdatei oder Swap-Partition auch schon. Nur eben nicht auf USB-Geräten und wenn, dann nicht vom Betriebssystem unterstützt.
Vergiss nicht: RAM ist vielfach schneller als Flash. Wenn dein USB-Stick brav seine 50 MB/s liefert, ist das schnell. Aber trotzdem nichts mit den 3,2 GB/s von DDR2-400. Außerdem werden USB-Sticks nach wie vor über verschiedene Instanzen (USB-Host, USB-Hub, evtl. weitere USB-Hubs, Gerät) mit verschiedenen Ideen (USB: Polling! *würg*) angesprochen, RAM hingegen ist - aus Sicht des Prozessors - direkt im Addressraum enthalten. Zugriffsverlängerungen interessieren den Prozessor nicht, weil für ihn die Zeit währenddessen stehenbleibt (READY-Signal).
Gruß,
Svenska
-
Hehe...was auch ne Variante wär: Doppelte Segmentierung (FC:CS:IP)
Damit hätte ich ja 16MB...
CPU technisch wär ja dann das auch nicht weiter schwer....
EDIT: Aus welchen Bausteinen bau ich eingentlich die Register auf?
Und da ja die Kompliziertheit der CPU mit jedem Register wächst, wieviele Register soll ich machen?
Gruss
Nooooooooooooooos
-
Vergiss die Segmentierung. Was du an Hardwareaufwand sparst (und das ist nicht viel!), wird dich in der Software zum Kot*** bringen. Lass es.
Es gibt imho zwei brauchbare Möglichkeiten, den Addressraum zu erweitern. Beides wurde im PC praktiziert.
(a) physikalische Addresserweiterung (PC: XMS)
(b) Bank-Switching (PC: EMS)
Mein Tipp: Orientiere dich nicht am PC, sondern eher an den Heim- und Kleincomputern der 80er Jahre. Die sind vom Konzept her schön einfach und haben gezeigt, was sie können. SymbOS ist das beste Beispiel, was mit primitiver Technik möglich ist, wenn man es nur will. (Beispiel: http://www.symbos.de/videos/trexsymbos1.zip << ein AVI-Video, was die Fähigkeit zeigt; allerdings im Turbo-Modus bei 12 Mhz; Original waren es glaube ich vier).
Register baust du entweder aus Relais (dann kannst du den RAM allerdings auch aus EPROMS basteln...) oder aus Flipflops. Da die Register selbst allerdings mit dem CPU-Takt mithalten müssen, kommt kein RAM dafür in Frage - du musst jedes Register selbst diskret aufbauen.
Die Kompliziertheit der CPU wächst nicht besonders - nur der Aufwand, das alles zu verdrahten.
Also du brauchst mindestens:
-> zwei Akkumulatoren (oder ein Akku und was anderes; das verkompliziert die Programmierung etwas) - da reichen 8 Bit, dann musst du die Register kombinieren können
-> einen Program Counter - der sollte 16 Bit haben
-> möglichst ein oder zwei Allzweckregister, bestenfalls zusammenfassbar 2x8 oder 1x16 Bit (nicht Pflicht, aber vereinfacht die Programmierung)
-> Register für Stackbasis und Stackpointer
Da 64 KB Addressraum nicht viel sind, könntest du (theoretisch) den I/O-Bereich ausklammern (und damit Extrabefehle IN und OUT schaffen) und den Stack ausklammern (einfach 64 KB für PUSH und POP bereitstellen, die vom Hauptspeicher entfernt liegen). In der Form bist du frei.
Gruß,
Svenska
-
Nabend
den primitifsten rechner den ich mal gesehen hab ( war zu schulzeiten als demo system, diskret aufgebaut) war eine sogenante ein addresmaschine mit glaubich weniger als 16 befehlen. ( programm speicher hatte glaubich auch nur für 16 befehle platz aber als demo system gings )
Herz des systems ist die ALU. sie verknüfpt die eingänge A und B zu C
Enthalten waren Additionswerk mit vorschaltwerk, ADD, SUB, INC, DEC,.. waren damit realisierbar. AND, OR und XOR waren zusätzlich dabei.
Bei einer Ein addressmaschine ist C der Accumulator. und wird auf den eingang A geschleift. eingang B wird addresiert.
Bei einer 2 Addressmaschine wird normalerweise A und B addresiert, und das ergebnis wandert in den Accu.
bei einer 3 addessmaschine sind alle ein und ausgänge direckt addressierbar.
Die alu war bei uns dann an den registerspeicher angebunden, der über einen teil der Befehlewortes addresierbar war. Load 5 hab z.B. das Register 5 in den accu geladen. add 7 hat die summe aus dem accu und dem inalt von register 7 gebildet und im acu abgelegt. (daher auch 1 address maschine, da maximal nur eine Addresse im befehl enthalten ist. 80x86 ist eine 2 address maschine)
und nen kleinen rom hatten wir noch, der unsere macrobefehle (assebler konnte man das noch nicht nennen, da CISC systeme einen behfehl aus mehreren solcher befehle zusammensetzen) für die ALU übersetzte. Welche Funktionsblöcke müssen aktiviert werden, z.B. für ein Add oder ein inc.
gruss
-
Mit deiner Variante muss ich ja aber das Allzweckregister auch in BYTEs füllen, und somit kommts auf das selbe heraus, wie mit Segmentierung...
Und soo kompliziert find ich Segmentierung nicht, wenn sich die Segmente nicht gerade wie im RM des 86s überschneiden....
Oder hast du mir gerade ein solches Beispiel...
Was meinen die Andern?? Seid ihr für Banks oder Segmentierung?
-
Nochmal zur RS232:
TxD und RxD sind für solche aktionen natürlich unbrauchbar. Die Sterleitungen sind aber relativ unabhängig von der Baud-Rate (!Getestet!)
---
Habe mich jetzt nicht in Banks "eingelesen" aber so wie ich das Verstande habe hat man für den Adressraum (z.B. 12Bit) nicht nur ein RAM, sondern kann z.B. über ein Kontrollregister auswählen, welches RAM man nutzt (richtig??)
wenn ja, ist das ne gute idee, lies sich auch einfach realisieren, indem man die Bits eines Registers, mit den enable-eingängen der RAM-ICs verbindet.
---
Als Register würde ich ganz normale 74164 TTL-Register nehmen.
---
Mal so ne Frage: Was erwartet ihr von einer Selbstbau-CPU?? Die braucht doch nicht unendliche mengen an Speicher adressieren können, oder Fließkomma-berechnungen innerhalb weniger millisekunden erledigen könne. Und wenn das ausführen einer Opperation mal ne Sekunde dauert, ist das doch nicht gleich der Tot! Man baut nen Computer um was zu lernen, nicht um NFS-Carbon drauf zu zocken.
Wenn sie 4*3 Rechnen kann und das Ergebniss in den Speicher schreibt ist das doch sonmal ne super sache. Wenn man dann noch Sprünge einbaut und nen Stack hat reicht das föllig aus.
-
Habe mich jetzt nicht in Banks "eingelesen" aber so wie ich das Verstande habe hat man für den Adressraum (z.B. 12Bit) nicht nur ein RAM, sondern kann z.B. über ein Kontrollregister auswählen, welches RAM man nutzt (richtig??)
Exakt so ist das. Du kannst über dieses Kontrollregister natürlich auch ein ROM auswählen (Ansteuerung ist ja ähnlich wie bei SRAMs).
wenn ja, ist das ne gute idee, lies sich auch einfach realisieren, indem man die Bits eines Registers, mit den enable-eingängen der RAM-ICs verbindet.
Genau auf das einfache Realisieren kam es mir an und Bankswitching -ist- einfach realisierbar. Wenn du 16 Bit Adressbreite nimmst, brauchst du pro Bank 2 DIP-Riegel; und da schaltest du halt alle 16 Leitungen um auf den jeweiligen Chip.
Mal so ne Frage: Was erwartet ihr von einer Selbstbau-CPU?? Die braucht doch nicht unendliche mengen an Speicher adressieren können, oder Fließkomma-berechnungen innerhalb weniger millisekunden erledigen könne. Und wenn das ausführen einer Opperation mal ne Sekunde dauert, ist das doch nicht gleich der Tot! Man baut nen Computer um was zu lernen, nicht um NFS-Carbon drauf zu zocken.
Du siehst an MyCPU oder an Homebrewcpu, was passiert. Wenn man sieht, dass es funktioniert und man sieht, dass man damit sogar etwas machen kann (was über die Grundrechenarten hinausgeht, siehe auch www.relaiscomputer.de), dann will man das nutzen.
Ich bastel mir (vorerst ^^) noch keine CPU diskret auf, aber ich könnte mir durchaus vorstellen, später, wenn alles läuft, einen Grafikanschluss (persönlich eher CGA-artig weil digital angesteuert) und einen NIC (inkl. IP-Stack, siehe auch uIP und Contiki von Adam Dunkels) dazuzubasteln.
Wenn die Hardware dann die Grundlagen dafür auch noch liefern kann (eben dazu brauchste z.B. einen verschiebbaren Stack - d.h. die Register Stackbasis und Stackpointer und eben den Stack -nicht- hartverlötet), ist das prima. Wenn nicht, endet das bestimmt nur in Frust. :-)
Meiner Meinung nach kann man sich solche (relativ einfachen) Ideen offenhalten und in die Idee und Realisierung mit einbeziehen.
Wenn sie 4*3 Rechnen kann und das Ergebniss in den Speicher schreibt ist das doch sonmal ne super sache. Wenn man dann noch Sprünge einbaut und nen Stack hat reicht das föllig aus.
Ist der Stack verschiebbar, sind mehrere quasi-gleichzeitige Prozesse möglich. Hast du Sprunganweisungen, kannst du aus Plus ein Mal machen und aus Mal ein Hoch. Und so geht es halt weiter. Der 6502 (C64) ist z.B. -nicht- multiprozessfähig, weil der Stack festgelegt ist und so ein Register eingespart wurde.
Man kann einfach bleiben, aber muss sich auch ein Mindestmaß an Flexibilität sichern (können). Finde ich zumindest.
Gruß,
Svenska
-
Find das ganz schön krass, seine eigene CPU zu bauen. :-o
Ich selber habe null-ahnung von den sachen die hier aufgezählt werden, interessiere mich aber dafür.
Da kommt mir doch ganz spontan die Idee ... warum machen wir nicht eine eigene LowLevel-CPU :-D
-
zumindest eine "Anleitung" könnte man in Form eines Community Projektes erstellen, also die Pläne zur CPU, ev. auch bsp - Code und tools, sodass sich jeder interessierte diese nachbauen kann.
-
Joa...dann kriegt wenigstens die Post wieder mal ein bisschen Aufwind^^
Ja aber wenn jemand einfach nur Schaltpläne nachbaut, lernt man nix und Spass machts auch nich...
Aber jetzt backtotopik
Findet ihr einen Stack soo wichtig? Also in meinem OS könnte ich getrost auf ihn verzichten...Oder ist das zwinged für uIP?
Weil wenn ich noch nen Stack mach, dann brauch ich nur für Code + Stack schon 6 Register (wenn ichs mit doppelter Segmentierung mach...), und eben dann wächst der Verkablungsgrad ziemlich an....
-
Da kommt mir doch ganz spontan die Idee ... warum machen wir nicht eine eigene LowLevel-CPU
Wenn noch nichtmal das Betriebssystem aus den Anfängen herauskommt mit einer CPU anfangen?
Außerdem braucht man dazu Lötkolben, Ätzmaterial und wasweißichnichtalles - das hat bestimmt nicht jeder interessierte zuhause. Einen Computer zur Softwareentwicklung dagegen schon eher.
Findet ihr einen Stack soo wichtig? Also in meinem OS könnte ich getrost auf ihn verzichten...Oder ist das zwinged für uIP?
uIP lass erstmal aus dem Spiel.
Aber ein Stack ist äußerst elementar, um Funktionen aufrufen zu können oder sogar rekursiv programmieren zu können. Wie willst du denn Funktionen aufrufen, wenn du keine Rücksprungadresse sichern kannst? Ein Stack ist extrem notwendig. Selbst der Intel 4004 (allererster Intel-Prozi) hatte schon einen (wenn auch in Hardware gegossen und ohne Speicherzugriff). Mit dem 8080 wurde der dann durch Register in den Speicher verlegt.
Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.
Weil wenn ich noch nen Stack mach, dann brauch ich nur für Code + Stack schon 6 Register (wenn ichs mit doppelter Segmentierung mach...), und eben dann wächst der Verkablungsgrad ziemlich an....
Lass die Segmentierung aus dem Spiel (was meinst du überhaupt mit doppelter Segmentierung?), die ist einfach zu kompliziert in Hardware zu gießen.
Und ja, Register sind ein zu lösendes Problem in der Beschaltung und vor allem gilt: je mehr, desto besser. Wenn du genug Register hast, kannst du die Hardware mehr Akku-orientiert basteln, wenn nicht, solltest du mehr auf allgemeingültige Register setzen.
Imho ist es besser, zwei oder drei unbenutzte Register zu haben, um Daten zwischenspeichern zu können (d.h. um Speicherzugriffe zu sparen). Es ist aber alles eine Frage des Aufwandes, den man treiben möchte.
Akku-zentriert => einfach zu bauen, weniger Opcodes, komplizierte Programmierung
Allgemein => komplizierter zu bauen, mehr Opcodes, einfache Programmierung
Gruß,
Svenska
-
Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.
Nöö ich kann Regsiter usw. auch einfach in Variablen sichern...
(was meinst du überhaupt mit doppelter Segmentierung?),
Ja eben früher hatte man ja Segmente und darin Offsets. ( CS:IP )
Ich habe die Idee ein Supersegment noch weiter in Subsegmente einzuteilen und erst dann mit Offsets darin zu arbeiten. ( FS[Firstsegment]:SS[Subsegment]:OF[Offset] = FS:SS:OF)
Ist ja eigentlich wie mit 24bit registern, nur dass ich in der alu mit 8Bit registern rechnen muss... -> Darum find ichs nich so schwierig...
Und ja, Register sind ein zu lösendes Problem...
Das gedenke ich sozulösen, indem ich 8 (3Bit im opcode) verschiedene gleicherechtigte 8bittige Register mache...
Gruss
Nooooooooooooos
-
Wenn noch nichtmal das Betriebssystem aus den Anfängen herauskommt mit einer CPU anfangen?
Naja, bei LOST merkt man schon, daß kaum einer Interesse hat, mitzumachen, weil jeder schon sein eigenes OS hat. Bei der CPU wäre das jedenfalls momentan vermutlich noch nicht der Fall. ;)
(Bitte nicht falsch verstehen, ich bin trotzdem auch der Meinung, daß nichts draus werden würde...)
-
Hehe...und wenn wir dann einen Computer hätten....wer kriegt ihn?...Ich wär dafür, dass wir ihn am Dreiländereck zwischen DE, AU + CH im Bodensee versenken...
-
Australien liegt am Bodensee? :D
-
Meinte wohl AT
und mit dem stack. selbst so poplige controler wie PICs haben nen stack, selbst wenn der nur 2 recursionen speichern kann. Wobei solche controller auch nicht in c programiert werden. dazu haben die einfach zu wenig rescourcen. (pic 10xxx pic 12xxx )
Ich persönlich würde beim CPU Projekt weniger das zusammenbauen als problem sehen. Lötkolben gibts recht günsig im baumakrt. ist dann zwar kein nobel von weller sondern eher ein brateisen mit mit 230v ( daher geringerer strom, darum längere heizzeiten) ginge aber trozdem. lochraster platinen und fädeldrat gibts im versandhaldel oder beim localen dealer um die ecke. Gedruckte platinen wird dann schon schwerer. passende cnc fräs plotmaschine hat sicher keine. und selber ätzen ist ne riesen sauerei (Fe3Cl)
Platine Bohren ist dann das nächste. 1mm löcher sind schon fast scheunentore und Hartmetal bohrer in ner normalen bohrmaschine kanste vergessen.
beim fehlersuchen wirds dann sicher lustig. signalverläufe mit nem multimeter aufzeichnen. ohne oskar / oder digitalanaliser wird dann sicher lustig und frustrierend.
dann doch lieber spice anwerfen und das ganze nur simuliert laufen lassen. da kann man wenigstens wirklich alles überall abreifen und aufzeichnen. und ne fehlverdrahtung läst sich einfach mal um biegen ohne sich gleich brandblasen hohlen zu müssen. auserdem kann da einem einer schneller helfen. is ja nur ne datei die ausgetauscht werden muss.
mal ne frage. wer von euch hat schon mal
a) nen lötkolben in der hand gehabt.
b) eine gedruckte platine mit bedrahteten bauteilen bestückt
c) einen schaltung auf einer Lochrasterplatine aufgebaut
d) eine gedruckte leiterplatte selber gefertigt
e) eine gedruckte leiterplatte selber entworfen
f) sich auf fehlersuche bei einer selbst aufgebauten schaltung gemacht
g) eine schaltung selber entworfen
gruss
-
a) nen lötkolben in der hand gehabt.
ICH
b) eine gedruckte platine mit bedrahteten bauteilen bestückt
Jo, schon 100 mal ;)
c) einen schaltung auf einer Lochrasterplatine aufgebaut
Jo einmal
d) eine gedruckte leiterplatte selber gefertigt
Ja, ca. 20 Geätzt (in der tat recht schmutzig); 3 gefräst (Teuer & langsam aber sauber)
e) eine gedruckte leiterplatte selber entworfen
Jo, ne Digitaluhr (mit nem ATmega32)
f) sich auf fehlersuche bei einer selbst aufgebauten schaltung gemacht
Jo, mindestens 3 mal die Woche in der schule
g) eine schaltung selber entworfen
Jo, ne Digitaluhr, und nen paar kleinere Digitale/Analoge schaltungen
Ich muss Termite recht geben. Wer noch nie etwas mit Elektrotechnik zu tun hatte solte da die Finger von lassen. Und wenn man kein Oszilloskop beherscht, kann man die Fehlersuche vergessen.
Und ich bin mir auch sicher, das es bei einer CPU nicht mit dem einfachen verbinden von ein und ausgängen von TTL-ICs getan ist.
Nur wenn jemand weiß, wie eine CPU funktioniert ist er noch lange nicht in der Lage eine selber zu bauen. Da steckt ne menge Handwerkliches geschick hinter.
-
Ich selber hätte daheim eher das problem woher nen oskar nehmen wen nicht stehlen.
zur not haben wir in der firma ein paar nette rumstehen. und als wheinachtsgeschenk taugt das leider auch nicht, da macht der preis nicht wirklich mit.
gruss
-
Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.
Nöö ich kann Regsiter usw. auch einfach in Variablen sichern...
Na dann viel Spaß, wenn du zum Rücksprung aus einer Prozedur erstmal von "irgendwo" aus dem Speicher, wo du selbst nicht weißt, wo (kein Stack), die Rücksprungadresse raussammeln musst...
(was meinst du überhaupt mit doppelter Segmentierung?),
Ja eben früher hatte man ja Segmente und darin Offsets. ( CS:IP )
Ich habe die Idee ein Supersegment noch weiter in Subsegmente einzuteilen und erst dann mit Offsets darin zu arbeiten. ( FS[Firstsegment]:SS[Subsegment]:OF[Offset] = FS:SS:OF)
Man kann sich die Programmierung auch richtig schwer machen...
Ist ja eigentlich wie mit 24bit registern, nur dass ich in der alu mit 8Bit registern rechnen muss... -> Darum find ichs nich so schwierig...
Dann musst du je drei Register zu einem 24-Bit-Register zusammenführen können, um eine absolute Speicheradresse zu bekommen... oder du quälst dich mit deinen Segmentgrößen rum (8 Bit? 256 Byte pro Segment?)
Und ja, Register sind ein zu lösendes Problem...
Das gedenke ich sozulösen, indem ich 8 (3Bit im opcode) verschiedene gleicherechtigte 8bittige Register mache...
Womit wir bei CISC und einer in EPROMs gespeicherten Tabelle gelandet wären - denn in Hardware kannst du vielleicht 20 Opcodes gießen (pro Platine einen), aber nicht pro Befehl 8 Varianten.
Lötkolben gibt's für 4 im Baumarkt, da geb ich Termite recht (ich hab meinen für 3,95 von Conrad in Berlin). Arbeiten kann man damit auch (heute erst nen Verstärker umgerüstet von Kopfhörerkabel auf Klinkenbuchse :-) ) Und was das Bohren usw. angeht, ohne Standbohrmaschine wird das nix. Zuhause habe ich auch keine, aber bohren könnte ich trotzdem mit einer.
dann doch lieber spice anwerfen und das ganze nur simuliert laufen lassen. da kann man wenigstens wirklich alles überall abreifen und aufzeichnen. und ne fehlverdrahtung läst sich einfach mal um biegen ohne sich gleich brandblasen hohlen zu müssen. auserdem kann da einem einer schneller helfen. is ja nur ne datei die ausgetauscht werden muss.
Wenn man nicht der Meister in E-Technik ist, sollte man das gesamte Teil sowieso erstmal simulieren. Damit erspart man sich kistenweise Arbeit später beim Fehlersuchen. Logische Fehler in der Platine ersetzen stelle ich mir nicht gerade einfach vor...
a) nen lötkolben in der hand gehabt. heute erst wieder
b) eine gedruckte platine mit bedrahteten bauteilen bestückt hab bisher nur selbstgezeichnete Platinen benutzt
c) einen schaltung auf einer Lochrasterplatine aufgebaut bisher nicht
d) eine gedruckte leiterplatte selber gefertigt selbst gezeichnet und geätzt, nicht gedruckt
e) eine gedruckte leiterplatte selber entworfen aus dem Schaltplan, ja, aber nur Kleinigkeiten und handgezeichnet
f) sich auf fehlersuche bei einer selbst aufgebauten schaltung gemacht ja, aber nur 2W-Verstärker =)
g) eine schaltung selber entworfen aus dem Schaltplan
Das Ätzen selbst fand ich garnicht so schlimm. In eine Plastewanne das Eisen-III-Chlorid reintun und einfach abwarten. Schlimmer ist dann nur, den Lack wieder runterzukriegen :) Wie es sich mit zweiseitigen Platinen verhält, weiß ich nicht.
Im Großen und Ganzen habe ich bisher nicht die Ausstattung, eine Platine zu bauen. Aber wenn ich nächsten Winter anfange, E-Technik zu studieren, wird sich das Eine oder Andere nicht vermeiden lassen - und wenn dann der Schaltplan steht, ist die Miete schon halbiert. :-D
Gruß,
Svenska
-
Ohne Stack wirds nix mit Unterprogrammen und Aufrufen.
Nöö ich kann Regsiter usw. auch einfach in Variablen sichern...
Na dann viel Spaß, wenn du zum Rücksprung aus einer Prozedur erstmal von "irgendwo" aus dem Speicher, wo du selbst nicht weißt, wo (kein Stack), die Rücksprungadresse raussammeln musst...
Nööö wenn ich eine feste Speicheradresse dafür festlege nich...
Ist ja eigentlich wie mit 24bit registern, nur dass ich in der alu mit 8Bit registern rechnen muss... -> Darum find ichs nich so schwierig...
Dann musst du je drei Register zu einem 24-Bit-Register zusammenführen können, um eine absolute Speicheradresse zu bekommen... oder du quälst dich mit deinen Segmentgrößen rum (8 Bit? 256 Byte pro Segment?)
Der einzige Unterschied ist, dass bei bst. Operationen keinen Übertrag auf das nächst höhere Register passiert, aber dass kann man ja mit ADC schön umgehen.
Und ja, Register sind ein zu lösendes Problem...
Das gedenke ich sozulösen, indem ich 8 (3Bit im opcode) verschiedene gleicherechtigte 8bittige Register mache...
Womit wir bei CISC und einer in EPROMs gespeicherten Tabelle gelandet wären - denn in Hardware kannst du vielleicht 20 Opcodes gießen (pro Platine einen), aber nicht pro Befehl 8 Varianten.
Ist es nicht realistisch zu denken, dass alle 8 Register Leitungen zu den 3 ALU Ein/Ausgängen haben und dann jeweils von einem Chip nur die benutzten freigeschaltet werden?
Lötkolben gibt's für 4 im Baumarkt, da geb ich Termite recht (ich hab meinen für 3,95 von Conrad in Berlin). Arbeiten kann man damit auch (heute erst nen Verstärker umgerüstet von Kopfhörerkabel auf Klinkenbuchse :-) ) Und was das Bohren usw. angeht, ohne Standbohrmaschine wird das nix. Zuhause habe ich auch keine, aber bohren könnte ich trotzdem mit einer.
dann doch lieber spice anwerfen und das ganze nur simuliert laufen lassen. da kann man wenigstens wirklich alles überall abreifen und aufzeichnen. und ne fehlverdrahtung läst sich einfach mal um biegen ohne sich gleich brandblasen hohlen zu müssen. auserdem kann da einem einer schneller helfen. is ja nur ne datei die ausgetauscht werden muss.
Wenn man nicht der Meister in E-Technik ist, sollte man das gesamte Teil sowieso erstmal simulieren. Damit erspart man sich kistenweise Arbeit später beim Fehlersuchen. Logische Fehler in der Platine ersetzen stelle ich mir nicht gerade einfach vor...
Dann soll ich also zuerst das ganze simulieren??
@Termite: Jo alles ausser d+c, aber der zuständige Lehrer/Betreuer für mein Projekt kann das ja in die Hand nehmen und ne Ätzmaschine suchen...e + f war halt nur bei relativ einfachen Schlatungen (zu ner CPU).
Gruss
Noooooooooooooos
-
Nööö wenn ich eine feste Speicheradresse dafür festlege nich...
Also das ist schon wichtig genug, daß ich dafür ein Register opfern würde.
-
Naja..bei meinem Aufbau wärens denn 3...aber wenn ihr meint...Ich persöhnlich kann gut auf den Stack verzichten...
-
Im Prinzip ist das Sache des Programmierers, solange genug Allzweckregister da sind. Wenn er welche für einen Stack opfern will, kann er das tun, wenn nicht, dann eben nicht.
-
Wie ich bereits schrieb - du kannst den Stack gerne irgendwo in den Speicher festlegen (u.U. sogar auf einen getrennten Adressraum, wenn du so willst). Aber Multiprocessing/Multitasking (präemptiv) setzt einen verschiebbaren Stack voraus. Und genau aus diesem Grund gibt es zwar ein präemptiv-Multitask-Betriebssystem für den Amstrad CPC, nicht aber für den C64.
Die Idee mit den Registern in der ALU stimmt so, allerdings brauchst du trotzdem für jede Kombination einen Opcode. Sonst könntest du ja nicht unterscheiden, welche Register nun z.B. addiert werden sollten.
Und ja, du solltest erst alles simulieren (siehe auch MyCPU). Oder du hast die Gerätschaften (Logic analyzer, Oszilloskop), um Bugs später herauszusammeln und die gesamte Hardware dafür ausgelegt (Fädeltechnik). Mit gezeichneten/gedruckten/gefrästen Platinen wirst du bei Bugs eher Fluchen.
Gruß,
Svenska
(, der zu faul zum Zitieren ist)
-
Ah oke...dann beginn ich denn mal mit der Simulation.
Jaja so ists klar mit den Opcodes...Ich mach glaub ich einen Befehl 16Bit.
Ich kann doch die Register fürs Multitasking auch irgendwo an einem festgelegten Platz im Speicher sichern??
Gruss
Noooooooooooos
-
Währe Multitasking nicht nen bischen viel??
Ich finde Multitasking jedenfalls sehr weit übertrieben, da sowas nicht gerade wenig Arbeitsspeicher in anspruch nimmt.
Wenn man seine CPU so baut/gestaltet, dass man sie später um einige features erweitert ist ja OK, aber ich bin der meinung das ein einfaches Textmode, singletasking, singleuser OS ausreichen sollte.
Außerdem sollte man sich erstmal gedanke über das "benutzen" von Interrupts machen. Dafür ist ja auch einiges an Speicher (und/oder) Register erforderlich.
ps.: Es wird schon gründe dafür geben, warum DOS kein multitasking kann. Mann sollte nicht erwarten, das der Prozessor mehr kann als ein 80186. Mann sollte froh sein, wenn er in der Lage ist ein MFA zu ersetzen...
-
Jojo...dann mach ichs mal ohne Stack usw...
-
Währe Multitasking nicht nen bischen viel??
Warum? Die hardwareseitigen Voraussetzungen sind jedenfalls gering (ein verschiebbarer Stack und diverse Sprungmöglichkeiten sind alles), um präemptives Multitasking hinzukriegen. Für kooperatives MT ist ein verschiebbarer Stack natürlich nicht nötig.
Speicherschutz ist wieder ein anderes Thema, dafür braucht man auch auf Prozessorebene eine Unterstützung. So weit will auch ich nicht gehen.
Ich finde Multitasking jedenfalls sehr weit übertrieben, da sowas nicht gerade wenig Arbeitsspeicher in anspruch nimmt.
Man muss es ja nicht gleich übertreiben. Ein kleiner MT-Kernel lässt sich durchaus effizient programmieren - eine Bank (á 32 KB) sollte dafür schon reichen. Ich verweise nochmals auf SymbOS (http://www.symbos.de). Das unterstützt präemptives MT auf einer CPU, die -definitiv- dafür nicht gebaut wurde.
Wenn man seine CPU so baut/gestaltet, dass man sie später um einige features erweitert ist ja OK, aber ich bin der meinung das ein einfaches Textmode, singletasking, singleuser OS ausreichen sollte.
Später Erweiterungen hinzufügen ist gleichbedeutend mit einem kompletten Neuentwurf, schließlich ist sämtliche Software auf die CPU hin programmiert worden und eher nicht auf Erweiterungen hin optimiert. Je langsamer die CPU, desto mehr muss optimiert werden.
Den Textmode würde ich vorerst streichen - dazu brauchst du schon Peripherie :) Und auf eine MT-fähige CPU kann man durchaus ein ST-OS aufsetzen, ohne Leistung zu verschenken. Andersrum geht das nicht.
Es wird schon gründe dafür geben, warum DOS kein multitasking kann.
Weil MT damals kein Thema war. Den Erfolg siehst du in TSRs. Und in Windows 3.0, welches auch auf einem 8088 noch MT kann.
Mann sollte nicht erwarten, das der Prozessor mehr kann als ein 80186.
Das reicht doch aus :) Man muss sich ja nicht auf das Niveau des Intel 8008 herunterlassen...
Was ist ein MFA?
Jaja so ists klar mit den Opcodes...Ich mach glaub ich einen Befehl 16Bit.
Wow, so viele? Was willst du mit 64k verschiedenen Opcodes? 8 Bit reichen meiner Meinung nach dicke aus für so eine Heimbau-CPU. Nach der Opcodelänge richtet sich dein µCode-EPROM und die Datenleitungen dorthin. 256 CPU-Befehle sollten meiner Meinung nach auch reichen (RISC I hatte 30, glaube ich. Eine PDF dazu habe ich hier.)
Ich kann doch die Register fürs Multitasking auch irgendwo an einem festgelegten Platz im Speicher sichern??
Klar, dagegen spricht ja auch nichts. Aber jede Anwendung (jeder Prozessfaden) braucht einen eigenen Stack, um selbst rekursiv arbeiten zu können.
dann mach ichs mal ohne Stack usw
Ich will dir den Spaß nicht verderben, aber ohne Stack kommst du nicht allzu weit. Das merkst du dann an der Programmierung. Mindestens im Speicher hartcodieren wirst du den müssen.
Übrigens: Die C64-Architektur (hartcodierter Stack im RAM) führte auch dazu, dass kaum rekursive Algorithmen eingesetzt wurden, weil einfach zu schnell ein Stack-Overflow auftrat.
Und schaut euch mal SymbOS (http://www.symbos.de) an (und schreibt was hierzu), falls ihr das noch nicht getan habt. Der Emulator WinAPE taugt auch gut dazu, es mal laufenzulassen und auszuprobieren. So weit muss man es natürlich nicht treiben, aber dieses System zeigt eindrucksvoll, was man anstellen kann, wenn man will.
Die Voraussetzungen dafür sind: 128-576 KB RAM, 4 MHz und 4 EPROMs. So viel solltest du mit deiner CPU schon schaffen können.
Gruß,
Svenska
-
Moin
sind im opcode nicht auch die Addressen der register und speicherzellen mit versteckt? sowpe die datenworte die verwendet werden sollen?
ein PIC hat z.B. 12 bis 14 bit Op-Codes je nach Addressbusbreite. Ist auch irn RISC befehlssatz.
der 8086 hat meines wissens auch nur weniger 8 bit befehler. die meisten benötigen mehr. da Addressen, Register, interruptnummern mit codirt werden müssen. CISC
von ARM möcht ich gar nicht reden. der Befehlssatz ist würcklich übel. mit seinen ganzen vor und randbedingungen die man da noch mit reinkodieren kann. (sowas wie führe den befehl nur aus wenn das Carri flag nicht gesetzt ist. das geht so wie ich das bisher verstanden hab für alle befehle.)
gruss
-
Du hast nicht ganz unrecht...
EIn OPcode könnte z.B. wie folgt aufgebaut sein
für "mov rA, rB"
00111011
0011 = mov
10 = rA
11 = rB
wie man sieht sind die 8Bit doch recht eng:
4 Bit befehle => 15 Befehle (ADD,SUB,AND,OR,XOR,MOV,IN,OUT,MVI,JMP,CMP,JNZ,JZ,CALL,RET) sind nicht viel.
Und dann kan man maximal mit 3 Register Arbeiten (00,01,10,11)
Deshalb sind 16-Bit Befehle schon sinnvoller. Wobei man beachten muss, auch damit zurechnen das ein Befehl 2×16Bit groß sein kann/sollte
z.B. JMP,CALL usw, da dort ja auch eine Adresse drin steckt, die ggf alleine schon 16Bit groß ist
@svenska:
Mit erweiterung meinte ich das so ähnlich wie beim PC RM und PM (nur nicht so extrem); also dass das Programm dieses Feature erst freischalten muss. MAW: Man sollte auch einige Kontrollregister einbauen.
-
Nabend
man kann auch die bits für die befehle dynamisch gestalten.
z.B. ein Jump oder Call mit Addresse hat weniger Befehls bits dafür aber mehr nutzdaten sprich Addresse, als z.B. eine Addition zwischen registern, bei der die Registaradressen zusammen kleiner ausfallen als die Addresse, hat der befehl mehr bits. Aber aufpassen mit der eindeutigen erkennung der befehle.
gruss
-
Am einfachsten:
Befehlsbyte, Datenbyte, Datenbyte, ...
2 Bits im Befehlsbyte geben an, wie viele Datenbytes folgen (0-3 Datenbytes)
und die anderen 6 Bits sind der Befehl selber (63 Befehle)
bsp.:
call 0xAA36
10100000 10101010 00110110
10 - 2 Datenbytes
100000 - call
10101010 00110110 0xAA36
-
Nabend mal wieder,
(Opcodes)
Ich würde alles sehr Akku-orientiert aufbauen, um halt Entwicklungsaufwand zu sparen. Wenn du Mikrokodierte Instruktionen benutzen möchtest, kannst du auch auf allgemeines Zeug hinarbeiten.
Ich hatte zwar schonmal eine Art Architektur entworfen (und viele Gedanken daran verschwendet, wenn auch nichts praktisches bisher), aber viele Überlegungen hier sind da noch nicht drin. In meinem Konzept würde ich jeden Opcode in Hardware gießen, allerdings wahrscheinlich in vielen Platinen (pro Opcode eine, um bei Bugs austauschen zu können). Da reichen dann 8-Bit-Opcodes recht gut aus.
Auch würde ich nicht einfach sagen "8 Bit für alles", sondern einfach sagen "Opcode 00110011 (z.B. JMP) erfordert ein 8-Bit-Argument - bitte einmal Nachladen". In einer größtenteils 8-Bittigen CPU sind 16-Bit-Opcodes sowieso schlecht handhabbar, weil du dann doppelt breite Register anbasteln musst.
@RedEagle: Deine Idee ist zwar schön, enthält aber auch unnützes Zeug (z.B. 00111010 würde mov rA, rA bedeuten). Du kannst auch die Fälle beschränken und z.B. durch 2-3 Bit die Kombination auswählen. Damit hättest du schon 32 Opcodes - für eine einfache CPU ausreichend. Bei mir wird das eher über ne Art 3stufige Pipeline geregelt werden (Decodieren&Einlesen => Ausführen => Ausgeben).
Was die Adressierung usw. angeht - je komplizierter das wird, umso umfangreicher müssen die Opcodes werden. Bei der originalen RISC-Architektur gibt es allerdings nur zwei Opcodes, die auf den Speicher zugreifen (LOAD und STORE) - nur diese haben eine andere Länge.
Dynamische Opcodelängen bringen unheimlichen Dekodieraufwand mit sich.
Mit erweiterung meinte ich das so ähnlich wie beim PC RM und PM (nur nicht so extrem); also dass das Programm dieses Feature erst freischalten muss.
Das führt zu verschiedenen Betriebsmodi innerhalb der CPU, damit zu veränderten Opcodebelegungen usw. Meiner Meinung nach ist das nicht mehr einfach mit wenig Hardwareaufwand realisierbar. Genauso würde ich nicht mehrere Grafikmodi implementieren, weil einfach der Aufwand zu hoch wird.
Wenn du eine Architektur selbst entwickelst - gestalte sie so einfach wie möglich, aber gleichzeitig auch sehr flexibel. Verschiedene Betriebsmodi sind nicht flexibel, schließlich beraubst du dich in mindestens einem deiner Fähigkeiten.
MAW: Man sollte auch einige Kontrollregister einbauen.
Das ist notwendig, aber es müssen nicht viele sein. Carry-, Zero- und Interruptflag sind notwendig, auf den Rest kann man verzichten. (Signflag ist eventuell praktisch, aber mit zusätzlichem Hardwareaufwand verbunden - schließlich braucht man Erweiterungen für die arithmetischen Funktionen und ein Overflow-Flag).
@RedEagle: So hatte ich das gedacht, aber du warst schneller.
Gruß,
Svenska
-
Okei...dann mach ich halt auch noch nen Stack...
Wegen den Opcodes: Ich hab mir das so gedacht, das 16 Befehle reichen. Nacher kommen entweder 2 Register(2x3Bit), 1 Register + ein Direktwert (3+8=11Bit), oder 1 Ziel + 3 Adressregister (12Bit). =>16 Bit (kann man nicht einfach nacheinander 2 Bytes laden?)
Andere Arten sind nicht zulässig, man muss halt zuerst die Sachen in Register laden.
Mikrocode habe ich im Sinn gar nicht zu machen...Die Assemblerbefehle müssen direkt von der ALU interpretierbar sein(Deshalb muss alles immer zuerst in die Register). Wegen dem Mikrocode Verbot gibt es aber ein Problem wegen den pushs und pops...Warscheinlich muss das halt mit ein paar movs usw. getan werden^^
Das Mikrocodeverbot verbraucht zwar viel Speicher, aber davon hab ich ja mit diesem System relativ genug :-P
-
Wegen dem Mikrocode Verbot gibt es aber ein Problem wegen den pushs und pops...Warscheinlich muss das halt mit ein paar movs usw. getan werden^^
Sowas hat eh kein RISC in Hardware, läßt sich ja auch relativ leicht nachbilden.
-
Ah gut.
Eine andere Frage, wegen IO-Registern: Ich kann nicht glauben, dass für das Display 4bit und für eine serielle Schnittstelle nur 8bit benötigt werden. Oder kann das sein??
-
Meiner Meinung nach sind 16 Befehle zuwenig. Ich habe es zwar schon geschafft, eine theoretisch lauffaehige Architektur drauf aufzubauen, aber kein "normaler" Prozessor kam jemals mit so wenigen aus.
Der kleinste mir bekannte Befehlssatz ist RISC I mit 31 Befehlen oder so...
Klar kannst du 16 Bit auf einmal laden, wenn deine Buseinheit dafür ausgelegt ist. Ist sie nur für 8 Bit ausgelegt, kannst du entweder manuell zweimal 8 Bit laden oder das halt transparent von der Software erledigen lassen.
Mir sagt die Idee mit den variablen Opcodelängen nicht zu - du stellst damit eine hohe Anforderung an die Dekodierlogik, die dann mit Bitoperationen auf die Befehle losgeht. Außerdem musst du ohnehin immer an 8/16-Bit-Grenzen deine Speicherzugriffe ansetzen (oder halt 2x laden).
Beim assemblieren kannst du "push" und "pop" ja wie Makros behandeln lassen, dauert dann eben je einen Takt länger.
Je weniger Instruktionen es gibt, desto größer werden die Programme, aber desto schneller werden sie auch ausgeführt.
Find ich aber klasse, dass sich damit jemand mal richtig tiefgründig beschäftigt :) Tiefgründiger/praktischer als ich zumindest. Welche Software benutzt du zum Simulieren eigentlich?
Und mal ne praktische Frage - welche Taktgeschwindigkeit traust du deiner Konstruktion dann zu bzw. würdest du gerne erreichen wollen?
Eine andere Frage, wegen IO-Registern: Ich kann nicht glauben, dass für das Display 4bit und für eine serielle Schnittstelle nur 8bit benötigt werden. Oder kann das sein??
Bei dem Display stimmt das, wobei (20x4) 8-Bit-Ansteuerung besser sein könnte (aber es geht auch mit 4 Bit).
Die serielle Schnittstelle kannst du auch diskret aufbauen, ich würde aber eher einen simplen UART16550 (wie im PC verbaut) benutzen - da kriegst du einen 16 Byte Puffer und eine sehr flexible, PC-kompatible Baudrate dazu. Außerdem kannst du die Baudrate auch ändern (eine Eigenbaulösung würde recht schwierig, finde ich).
Aber ja, eine serielle Schnittstelle kriegst du mit 8 Bit realisiert. Je nachdem, wie einfach du sie gestaltest und wieviel du von der Schnittstellenlogik in Hardware realisierst, kommst du auch mit weniger aus. :)
Gruß,
Svenska
-
Meiner Meinung nach sind 16 Befehle zuwenig. Ich habe es zwar schon geschafft, eine theoretisch lauffaehige Architektur drauf aufzubauen, aber kein "normaler" Prozessor kam jemals mit so wenigen aus.
Der kleinste mir bekannte Befehlssatz ist RISC I mit 31 Befehlen oder so...
Hmm ich finds eigentlich genug. Mit diesen Befehlen kann ich etwa 90% der Befehle einer Asm-Datei direkt übersetzen.
Mir sagt die Idee mit den variablen Opcodelängen nicht zu - du stellst damit eine hohe Anforderung an die Dekodierlogik, die dann mit Bitoperationen auf die Befehle losgeht.
Naja variabel ist die ja nicht wirklich (Ausser bei den speziellen MOV-Befehlen, wo entweder 4-Register oder 1 Register+Direktwert geladen werden können). Die anderen Befehle haben dann nur 10Bit. Der Rest wird mit Nullen aufgefüllt. Allerdings hab ich mir noch gedacht, bei jedem Befehl am Ende mit z.B. 3Bit noch eine Bedingung anzufügen. Dann würde ein Chip bevor der Befehl noch ausgeführt wird zuerst die Flags checken.
Welche Software benutzt du zum Simulieren eigentlich?
Und mal ne praktische Frage - welche Taktgeschwindigkeit traust du deiner Konstruktion dann zu bzw. würdest du gerne erreichen wollen?
Hmm, ich hab noch keine Ahnung...Was würdest du mir empfehlen? Gibt es da was Opensource?
Hmm ich denk so 6MHz...Wäre sowas realistisch?
Die serielle Schnittstelle kannst du auch diskret aufbauen, ich würde aber eher einen simplen UART16550 (wie im PC verbaut) benutzen - da kriegst du einen 16 Byte Puffer und eine sehr flexible, PC-kompatible Baudrate dazu.
Hmm dann soll ich also pro Schnittstelle 16Bit nehmen?
Gruss
Nooooooooooos
-
Wäre es eigentlich auch möglich eine CPU, die nur auf Basis von Registern und ohne RAM arbeitet ?
Bzgl. Taktfrequenz: Braucht man sowas überhaupt unbedingt, ich glaub ARM hat auch mal eine CPU ohne Takt gebaut :roll:
-
Man brauch keinne Takt. Aber eine CPU ohne takt ist sehr viel aufwändiger als mit. Was auch der grund dafür ist, das es so gut wie nur CPUs mit Takt gibt.
...
naja man könnte auf Arbeitsspeicher verzichten, aber dann ist die CPU enorm eingeschränkt, und man müsste jeden befehl einzeln von einem Datenträger lesen was ein enormen geschwindigkeitsverlust darstellt.
-
Meiner Meinung nach sind 16 Befehle zuwenig. Ich habe es zwar schon geschafft, eine theoretisch lauffaehige Architektur drauf aufzubauen, aber kein "normaler" Prozessor kam jemals mit so wenigen aus.
Der kleinste mir bekannte Befehlssatz ist RISC I mit 31 Befehlen oder so...
Hmm ich finds eigentlich genug. Mit diesen Befehlen kann ich etwa 90% der Befehle einer Asm-Datei direkt übersetzen.
Ja stimmt, ich hatte nicht daran gedacht, dass du ja die Register oder Werte noch extra dazunimmst... in meinen ersten Gedanken hatte ich mir 4-Bit-Opcodes ausgedacht, aber das war dann doch zuwenig. Insgesamt brauche ich 20-25 Opcodes, wobei Registerkombinationen schon enthalten sind.
Mir sagt die Idee mit den variablen Opcodelängen nicht zu - du stellst damit eine hohe Anforderung an die Dekodierlogik, die dann mit Bitoperationen auf die Befehle losgeht.
Naja variabel ist die ja nicht wirklich (Ausser bei den speziellen MOV-Befehlen, wo entweder 4-Register oder 1 Register+Direktwert geladen werden können). Die anderen Befehle haben dann nur 10Bit. Der Rest wird mit Nullen aufgefüllt. Allerdings hab ich mir noch gedacht, bei jedem Befehl am Ende mit z.B. 3Bit noch eine Bedingung anzufügen. Dann würde ein Chip bevor der Befehl noch ausgeführt wird zuerst die Flags checken.
Die Variante geht, wie gesagt, ich hatte da etwas übersehen :)
Allerdings würde ich alle Opcodes nach Möglichkeit gleichlang machen (und grundsätzlich zur Basis 2), um mir Bitoperationen zu ersparen. Dann lieber mit Nullen auffüllen und alles ist in Ordnung :)
Welche Software benutzt du zum Simulieren eigentlich?
Und mal ne praktische Frage - welche Taktgeschwindigkeit traust du deiner Konstruktion dann zu bzw. würdest du gerne erreichen wollen?
Hmm, ich hab noch keine Ahnung...Was würdest du mir empfehlen? Gibt es da was Opensource?
Ich habe mal klogic [KDE3] benutzt, allerdings ist das relativ instabil gewesen und hatte auch sonst einige Macken. Schön einfach ist es, man kann es sich mal anschaun, aber für ernsthafte Zwecke ist es nicht zu gebrauchen.
Für Windows gibt es Multimedia Logic, steht unter der GPL und hat u.A. auch RAM-Bausteine usw. dabei. Das gefällt mir, ist aber auch komplizierter zu bedienen als klogic. Eine schöne Symbiose aus beiden (oder ein Bugfree klogic) habe ich aber auch noch nicht gefunden, daher meine Frage.
Hmm ich denk so 6MHz...Wäre sowas realistisch?
Milchmädchenrechnung: Wenn ich alle Gatter in einer 20 MHz-Version benutze und pro Signal maximal 4 Gatter verwende, komme ich auf 5 MHz Maximaltakt. Ob das stimmt, weiß ich nicht, es erschien mir aber logisch :)
Um das etwas auszuschöpfen, wollte ich die CPU halt dreiteilen und so eine Pipeline aufbauen.
Die serielle Schnittstelle kannst du auch diskret aufbauen, ich würde aber eher einen simplen UART16550 (wie im PC verbaut) benutzen - da kriegst du einen 16 Byte Puffer und eine sehr flexible, PC-kompatible Baudrate dazu.
Hmm dann soll ich also pro Schnittstelle 16Bit nehmen?
Feste Längen nicht, bastle dir eher 4, 8 und 16-Bit-Ports. Der PC hat es ja auch so gemacht. Außerdem kannst du dir ja auch überlegen, wie du die Schnittstellen implementieren willst. Mit 8 Bit kannst du sämtliche Leitungen einer seriellen Schnittstelle manuell ansteuern - so hat es der C64 gemacht - aber Hochgeschwindigkeit (9600 Baud o.ä.) wirst du nicht kriegen. Außerdem ist die CPU dann doch schon sehr belastet. Implementierst du das von Hand in Hardware, brauchst du nur 2 Bit (In und Out) plus Kontrollregister; mit einem UART brauchst du 4 oder 8 Bit. Beim Parallelport ist es genauso - 8 Datenbits plus Kontrollregister (für die Hardware) oder 16-32 Bits für Manuellsteuerung. Wie du es machst, bleibt dir überlassen.
Gruß,
Svenska
-
Wegen den Befehlen...Ich hab mir mal die folgenden ausgedacht: mov; mov x,Speicher; mov x,Codereg; mov Codereg,x; in; out; and; or; not; xor; add; shl; shr; bsf; bsr; mov Speicher,x
Was würdet ihr anders machen?
Hmm ich denk so 6MHz...Wäre sowas realistisch?
Milchmädchenrechnung: Wenn ich alle Gatter in einer 20 MHz-Version benutze und pro Signal maximal 4 Gatter verwende, komme ich auf 5 MHz Maximaltakt. Ob das stimmt, weiß ich nicht, es erschien mir aber logisch :)
Um das etwas auszuschöpfen, wollte ich die CPU halt dreiteilen und so eine Pipeline aufbauen.
Hmmm da blick ich jetzt nicht ganz durch...Also gehst du davon aus, dass jeder Befehl 4 Gatter braucht??? Aber dann wären es ja immer noch 20MHz?? Kannst du mir das mal ein bisschen näher erklären??
Die serielle Schnittstelle kannst du auch diskret aufbauen, ich würde aber eher einen simplen UART16550 (wie im PC verbaut) benutzen - da kriegst du einen 16 Byte Puffer und eine sehr flexible, PC-kompatible Baudrate dazu.
Hmm dann soll ich also pro Schnittstelle 16Bit nehmen?
Feste Längen nicht, bastle dir eher 4, 8 und 16-Bit-Ports. Der PC hat es ja auch so gemacht. Außerdem kannst du dir ja auch überlegen, wie du die Schnittstellen implementieren willst. Mit 8 Bit kannst du sämtliche Leitungen einer seriellen Schnittstelle manuell ansteuern - so hat es der C64 gemacht - aber Hochgeschwindigkeit (9600 Baud o.ä.) wirst du nicht kriegen. Außerdem ist die CPU dann doch schon sehr belastet. Implementierst du das von Hand in Hardware, brauchst du nur 2 Bit (In und Out) plus Kontrollregister; mit einem UART brauchst du 4 oder 8 Bit. Beim Parallelport ist es genauso - 8 Datenbits plus Kontrollregister (für die Hardware) oder 16-32 Bits für Manuellsteuerung. Wie du es machst, bleibt dir überlassen.
Also paralell hab ich gar nicht vor zu implementieren. Würdes du für seriell eher einen UART nehmen oder alles von Hand implementieren? Wenn ichs von Hand implementier, dann muss ich halt die Taktrate der CPU genau mit der Baudrate abstimmen, oder??
EDIT: Ich seh grad das du das schon beantwortet hast...
Gruss
Noooooooooooos
-
Wegen den Befehlen...Ich hab mir mal die folgenden ausgedacht: mov, mov Speicher, mov Codereg, mov IOreg, and, or, not, xor, add, shl, shr, ror, bsf, bsr, bs(Bit set), br(Bit resete).
Was ist mov Codereg? Ein Jump? Wenn ja, und du nimmst die Flags zur bedingten Ausführung dazu, dann ist das ein möglicher, wenn auch sicher nicht sehr bequemer Befehlssatz.
Versuch doch mal, folgende Pseudocode-Prozedur in deine Assemblersprache zu übersetzen. Ich bin erstens gespannt, wie das aussieht, und zweitens, ob du den Befehlssatz dann nicht modifizieren willst. ;)
function fakultaet(x) is begin
y := 1;
while (x > 0) do
y := y * x;
x := x - 1
od;
return y
end fakultaet;
-
Hmm ich denk so 6MHz...Wäre sowas realistisch?
Milchmädchenrechnung: Wenn ich alle Gatter in einer 20 MHz-Version benutze und pro Signal maximal 4 Gatter verwende, komme ich auf 5 MHz Maximaltakt. Ob das stimmt, weiß ich nicht, es erschien mir aber logisch :)
Um das etwas auszuschöpfen, wollte ich die CPU halt dreiteilen und so eine Pipeline aufbauen.
datenblätter lesen, könnte ggf helfen. Gatter haben laufzeiten. daraus ergibt sich auch die maximale schaltfrequenz des prozessors. diese muss die längste mögliche gatterlaufzeit eines signalfades abdecken, sonst rechnet der prozessor müll.
Am einfachsten kann man das mit einem volladierer erklähren. Ein volladierer ist gatter das intern aus ein paar Xor or und and's besteht.
Hat 3 eingänge A B C und berechnet bitweise die summe S davon und den überlauf O.
Baut man nun aus 8 solchen Volladirern ein 8 Bit aditionswerk, kommen an A 0 bis A7 und B0 bis B7 die zu addierenden Byts an. Die überläufe werden immer an den nächsthöhere C eingang verkabelt ( On geht an Cn+1). C0 ist low. Der überlauf O7 gibt den überlauf der kompletten summe an.
schautman sich das zeitliche verhalten genauer an, wird man feststellen, das das ergebnis des Höchsten bits erst dan stimmt, wenn die berechnung der darunterliegenden bits abgeschlossen ist.
Zeitgleich wird die summe für bit 0 und 1 berechnet. die berechnung von bit 0 erzeugt einen überlauf, der die berechnung von bit 1 beeinflusst. damit läuft die gatterlaufzeit für das ergebnis von bit 1 von neuem an.
im worst case bedeutet das für einen so einfach aufgebauten 8 bit addirer wie hier insgesamt 8 X die volle laufzeit warten bis das ergebnis am ausgang würklich stimmt. vorher könnte das ergebnis ggf falsch sein.
bei 64 bit ist das natürlich nicht vernünftig, daher gibts auch andere realisierungsmöglichkeiten. nur diskret läst sich sowas nicht mehr aufbauen.
gruss
-
Hmm ich denk so 6MHz...Wäre sowas realistisch?
Milchmädchenrechnung: Wenn ich alle Gatter in einer 20 MHz-Version benutze und pro Signal maximal 4 Gatter verwende, komme ich auf 5 MHz Maximaltakt. Ob das stimmt, weiß ich nicht, es erschien mir aber logisch :)
Um das etwas auszuschöpfen, wollte ich die CPU halt dreiteilen und so eine Pipeline aufbauen.
Hmmm da blick ich jetzt nicht ganz durch...Also gehst du davon aus, dass jeder Befehl 4 Gatter braucht??? Aber dann wären es ja immer noch 20MHz?? Kannst du mir das mal ein bisschen näher erklären??
Wie gesagt, was ich jetzt schreibe, kann durchaus völlig falsch sein...
Wenn ich durchgängig 20 MHz-fähige Bausteine nehme und jedes Signal durch maximal 4 Gatter schleife, kann ich insgesamt mit 5 MHz das Ergebnis erwarten, ohne durch noch unfertige Zwischenergebnisse das Endergebnis zu zerstören. Termite hat das noch besser beschrieben (und auch mehr Ahnung dabei als ich).
Vielleicht kann Termite das auch mir mal erklären... :) Noch bin ich ja kein E-Techniker.
Gruß,
Svenska
-
Nabend noch mal.
so falsch liegst du eigentlich gar nicht. das problem ist glaubich nur, das normale die grenzfrequenz für jeden baustein anders sein kann. Teilweise sogar temperatur und betriebsspannungsabhängig. deine 20Mhz werden sie sicher fast alle schaffen. nur deine 4 gatter sind etwas knapp bemessen.
gruss
-
nur deine 4 gatter sind etwas knapp bemessen.
Meinst du damit, dass 4 Gatter für einen Befehl nicht ausreicht??
Ich hab das mal gezählt und komm für die Additionsmaschine auf 88 Gatter.
Dann hätte meine CPU ja nur noch 0.23 MHz. Wie bringt es aber die MyCPU zu 8MHz???
Gruss
Nooooooooooos
EDIT: Andere Frage: Ist Pipelining etwas, das man für dieses Projekt in Betrachtung ziehen kann/muss???
-
Genau das, 4 Gatter war jetzt nur ein Beispiel von mir.
Dabei gilt die Angabe für die Gatterzahl immer hintereinander pro Signal, also wenn du 100 Gatter verbaust und dabei 5 Datenleitungen mit je 20 Gattern benutzt, sind das trotzdem nur 20 Gatter, die zählen :)
Was das myCPU-System angeht, so habe ich eben nachgeschaut. Er verwendet Gatter der Reihen 74HCxx und 75ACxx (Highspeed-CMOS).
Spontan ist mir da eine PDF hier (http://www.informatik.uni-ulm.de/ni/Lehre/SS01/TI/folien/tech.pdf) in die Hände gefallen; dort steht zumindest für die 74HCxx-Reihe eine Maximalfrequenz von etwa 75 MHz drin. Das ist knapp das vierfache - und damit wärst du schon bei beinahe einem MHz Taktfrequenz (etwa C64, der hatte 980 kHz in der PAL-Version).
Mit der 74Fxx-Baureihe hättest du 125 MHz Grenzfrequenz, aber TTL-Pegel. Ob die geeignet sind, weiß ich nicht. Ich gehe mal davon aus, dass die 74ACxx noch schneller sind, habe aber auf die Schnelle nichts gefunden.
Was das Pipelining betrifft, so halte ich es durchaus für möglich oder zweckmäßig, eine kleine Pipeline einzubinden. Zumindest schaffst du so eine relativ einfache Geschwindigkeitserhöhung. Aber du musst natürlich deinen Assembler auch entsprechend basteln - wenn du eine 3stufige Pipeline hast, müssen nach jedem Sprungbefehl 2 NOPs folgen; ebenso musst du bei aufeinanderfolgenden Registerzugriffen 2 NOPs abwarten (sonst ist der Wert u.U. noch nicht im jeweiligen Register angekommen).
In Betracht ziehen -musst- du es nicht, aber ich persönlich fände es praktisch. Zumal du dann drei voneinander unabhängige Einheiten produzierst, was sicherlich nicht die schlechteste Idee ist.
EDIT: 74Fxx-Gatter kannst du vergessen, weil der Stromverbrauch enorm ist (4 W im Vergleich mit den >25µW bei 74Hcxx)...
Gruß,
Svenska
-
Genau das, 4 Gatter war jetzt nur ein Beispiel von mir.
Dabei gilt die Angabe für die Gatterzahl immer hintereinander pro Signal, also wenn du 100 Gatter verbaust und dabei 5 Datenleitungen mit je 20 Gattern benutzt, sind das trotzdem nur 20 Gatter, die zählen :)
Ähm was meinst du mit Datenleitung??
Was das Pipelining betrifft, so halte ich es durchaus für möglich oder zweckmäßig, eine kleine Pipeline einzubinden. Zumindest schaffst du so eine relativ einfache Geschwindigkeitserhöhung. Aber du musst natürlich deinen Assembler auch entsprechend basteln - wenn du eine 3stufige Pipeline hast, müssen nach jedem Sprungbefehl 2 NOPs folgen; ebenso musst du bei aufeinanderfolgenden Registerzugriffen 2 NOPs abwarten (sonst ist der Wert u.U. noch nicht im jeweiligen Register angekommen).
OK, aber so ein NOP wäre ja dann auch ein eigenständiger Befehl?? Oder nich?
Welche 3 Stufen würdest du herausnehmen?
Gruss
Nooooooooooos
-
Genau das, 4 Gatter war jetzt nur ein Beispiel von mir.
Dabei gilt die Angabe für die Gatterzahl immer hintereinander pro Signal, also wenn du 100 Gatter verbaust und dabei 5 Datenleitungen mit je 20 Gattern benutzt, sind das trotzdem nur 20 Gatter, die zählen :)
Ähm was meinst du mit Datenleitung??
Na halt ein Draht von Anfang bis Ende... :)
Was das Pipelining betrifft, so halte ich es durchaus für möglich oder zweckmäßig, eine kleine Pipeline einzubinden. Zumindest schaffst du so eine relativ einfache Geschwindigkeitserhöhung. Aber du musst natürlich deinen Assembler auch entsprechend basteln - wenn du eine 3stufige Pipeline hast, müssen nach jedem Sprungbefehl 2 NOPs folgen; ebenso musst du bei aufeinanderfolgenden Registerzugriffen 2 NOPs abwarten (sonst ist der Wert u.U. noch nicht im jeweiligen Register angekommen).
OK, aber so ein NOP wäre ja dann auch ein eigenständiger Befehl?? Oder nich?
Klar. Aber der tut nichts böses, d.h. der pfuscht nicht in den Registern rum und auch nicht im Speicher. Wenn du einen JMP machst und du vergisst das, dann denke daran, dass du ja bereits zwei Opcodes geladen hast (3stufige Pipeline) - d.h. die beiden auf den JMP folgenden Opcodes sind (teilweise) schon ausgeführt - das darf nicht passieren, sonst zerstörst du dir den Programmablauf.
In Betracht ziehen -musst- du es nicht, aber ich persönlich fände es praktisch. Zumal du dann drei voneinander unabhängige Einheiten produzierst, was sicherlich nicht die schlechteste Idee ist.
Hmm ja wie kann denn die ALU drei Befehle gleichzeitig ausführen? Dann bräuchte es ja 6 Eingangs + 3 Ausgangsregister??
Oder ist da nur gemeint die Befehlsverarbeitung vor der ALU 3stufig zu machen???
Das würde ja eingentlich heissen, dass alles 3x vorhanden sein muss...??
Ne, du hast das Prinzip des Pipelinings nicht begriffen... oder ich hab mich vermüllt ausgedrückt.
Du hast drei Teile:
(a) Opcode laden & decodieren
(b) Opcode ausführen
(c) Ergebnisse sichern, Register schreiben
Alle drei Teile können gleichzeitig arbeiten, um keine Rechenleistung zu verschwenden. Wenn jetzt jeder Schritt 1 CPU-Takt dauert, dann braucht auch jeder Befehl 3 Takte zum Ausführen (Decodieren, Ausführen, Sichern). Aber du schaffst es, pro Takt einen Befehl auszuführen - obwohl trotzdem alles 3 Takte dauert. Das ist Pipelining.
Aber dabei musst du eben beachten, dass du in der Pipeline Brüche haben kannst, die du nicht hardwareseitig bearbeiten willst (=> Aufwand); das musst du dann im Assembler berücksichtigen. "JMP" wird dann zu "JMP NOP NOP", weil du ja nicht weißt, was die beiden folgenden Opcodes tun.
Übrigens: (b) ist die ALU, (a) und (c) sind getrennte Teile. Ich meine keinen Multicore... :)
Gruß,
Svenska
-
OK das Prinzip ist jetzt klar.
Aber der Punkt c ist ja eigenltich keiner, wenn die ALU ihre Endwerte direkt ins entsprechende Register schreibt.
Und b muss ja nicht immer die ALU sein, z.B. bei nem mov...
Wie wärs mit:
a)befehl laden + ip erhöhen
b)Überprüfung auf MOV, Bedingung(ist jetzt ein eigenständiger Befehl) oder NOP
c)Register auf ALU oder aufeinander legen bei (MOV/Bedingung)
d)Abarbeitung der Befehle
Dann wärs halt 4-stufig.
Gruss
Noooooooooos
-
Aber dabei musst du eben beachten, dass du in der Pipeline Brüche haben kannst, die du nicht hardwareseitig bearbeiten willst (=> Aufwand); das musst du dann im Assembler berücksichtigen. "JMP" wird dann zu "JMP NOP NOP", weil du ja nicht weißt, was die beiden folgenden Opcodes tun.
Hm, also den Assembler halte ich für den falschen Ort, sowas zu machen, der hat einfach meine Befehle 1:1 in Maschinencode zu übersetzen. Denn ich als proffesionel serious genuine Brotrö... Programmierer will die Delay Slots natürlich irgendwie sinnvoll nutzen, wann immer das möglich ist und mir nicht vom Assembler NOPs einbauen lassen, die eigentlich gar nicht nötig wären. Gerade bei den Sprüngen ist es für den Programmierer kein Problem, daran zu denken.
-
Moin
achtung bei piplining. wenn ihr nen jump oder call drin habt müst ihr eure pipline wieder löschen und von vorn beginnen. sonst wird das richtig kaotisch.
wobei schon piplining alleine zu richtig lustigen verhalten führen kann. :-D
ich sach da nur AT91RM55800 und remap. (arm 7 kern mit 4 stufingen piplining)
folgender asm code.
FLASH: mov 0x12345678, 0x00000080 // remap auslösen
FLASH: jump 0x00000000 // irgendwohin springen; ab hier wird ins sram addresiert.
Adressen und werte sind mal egal. beim rempa wird die speicheraddressierung extern umgeschalten. Speicherbereiche werden quasi vertauscht, die cpu krigt davon nichts mit. Beim booten ist das insofern lustig, da im flash gestartet wird, und mit dem remap in den speicherbereich das interne SRam eingeblendet wird. sprich der jump der im flash steht dürfte eigentlich nach dem remap garnicht ausgeführt werden, da der ja nur im flash aber nicht im sram steht. aber aufgrund des piplinings. ist der jump bereits aus dem flash gelesen worden. befindet sich somit bereits im prozessor und kann trotzdem ausgeführt werden. Gemein wirds erst dann wenn man genau die stelle versucht zu debuggen. ( hw debugger) da hat man dann kein piplining mehr und dann vereckt der ganze trick.
Somit überlegt euch beim piplining noch wie ihr mit z.B. nem software Monitorprogramm debuggen wollt? Gerade so sachen wie INT 3. da wird ja eigentlich nur ein befehl ausgetauscht durch nen in, damit der debugger angesprungen wird. anschliesend wird der int wieder überschrieben und durch den alten befehl ersetzt. IP wird zurückgesetzt und das programm wieder gestartet. Dadurch ist eure pipline nicht mehr korreckt und muss neu gefüllt werden.
sprich sobald von aussen sei es von debugger oder vom programmablauf selber der IP verändert wird muss die pipline neu aufgebaut werden. für mich hört sich das nach einiger zusätzlicher logik an.
gruss
-
Naja is ja eigentlich ganz logisch: Sobald ein Register von den 2/3 nachfolgenden Befehlen gebraucht wird, muss die Pipeline gelöscht werden. Und da IP von jedem Befehl benötigt wird, gibt es halt da keine Ausnahmen.
Allerdings versteh ich nicht, warum die Pipeline gelöscht werden muss.
Nach einem JUMP...usw. sind einfach noch 2/3 NOPs in der Pipeline und das macht ja nix.
Ist eine 4-stufige Pipeline auch gut machbar? (Oder je mehr Stufen vorhanden sind, desto mehr kann man die Taktrate anziehen???)
Und warum kann ich die NOPs nicht vom Assembler einfügen lassen?? Ich muss doch logischerweise nach jedem JMP diese NOPs einfügen und zwar ohne wenn und aber => Eine gute maschinen-Arbeit
(Natürlich kann man mit dem vertauschen von Befehlen auch NOPs vermeiden...)
Gruss
Nooooooooooooos
-
Und warum kann ich die NOPs nicht vom Assembler einfügen lassen?? Ich muss doch logischerweise nach jedem JMP diese NOPs einfügen und zwar ohne wenn und aber => Eine gute maschinen-Arbeit
(Natürlich kann man mit dem vertauschen von Befehlen auch NOPs vermeiden...)
Eben. Ich kann nach dem jmp noch Befehle unterbringen, die ausgeführt werden sollen, egal ob gesprungen wird oder nicht. Nenn es Vertauschen oder wie auch immer, aber da muß nicht zwingend ein nop hin.
-
Ich muss taljeth da Recht geben, der Assembler muss es nicht zwingend tun. Allerdings würde ich es einfach so implementieren, weil ich es sonst irgendwo vergesse und den Fehler garantiert nicht finden würde :)
Meinetwegen kannst du da auch ein bisschen was dazwischenpfuschen lassen oder diese Funktion abschalten. Für mich ist halt ein Assembler vor der direkten Maschinensprache noch eine Ebene, in der man nicht mit den absoluten Innereien der CPU konfrontiert werden muss (aber kann, so man denn möchte). Außerdem kannst du JMP ja als eigenes Makro definieren. Optimieren kann man später immernoch.
Wieviele Stufen du deiner Pipeline gibst, ist dabei erstmal egal - aber mit zunehmender Tiefe wird die hardwareseitige Programmierung schwieriger (erst mit einer Hochsprache, z.B. C, wirst du die Probleme der Pipeline los).
Die Taktrate sollte bei der Überlegung erstmal keine Rolle spielen, aber deine Idee stimmt. Aber mehr als 1 Befehl / Takt willst du nicht implementieren :)
@Termite: Ich würde die Pipeline nie leeren, weil das, wie du sagtest, ein Haufen Logikarbeit ist. Meine Gedanken gehen halt da hin, dass im Programmablauf selbst schon die nötigen NOPs (oder halt andere Befehle) so eingearbeitet sind, dass die Pipeline nie geflusht werden muss. Dazu ist die Architektur zu einfach.
Hardwaredebugging würde ich nicht wie beim PC implementieren. Du kannst ja im Debugger immer die Befehle einzeln abarbeiten (also Befehl NOP NOP Befehl NOP NOP ...), aber ich würde einfach die Taktfrequenz von einem Taster erzeugen lassen (vgl. auch "homebrewcpu").
Gruß,
Svenska
-
wieso muss ich wenn ein register von den nächsten 2/3 befehlen verwendet wird ein nop einfügen bzw die pipline löschen? bei einer 4 stufingen pipline hätte ich folgende 4 stats
1. opcode decodieren
2. daten laden
3. execute comand
4. save data
wenn ich in state 3 ein register verändere das ein befehl der gearde in state 2 ist benötigt, dann muss ich ihn doch erst garnicht neu laden, sondern nur das ergebnis aus stat3 entsprechend übernemen wenn der befehl in den stat3 wechselt ( sicher aufwendiger ) aber da gibts sicher noch genug stoplersteine. Die pipline muss ich doch erst dann löschen, wenn falsche befehle drin stehen, die ich da nicht drinn sein sollen. (z.B. Jump) bei einem bedingten sprung kann es vorkommen, das falsche befehle drinstehen, muss aber nicht.
nur einfach gnadenlos nops einfügen ist irgendwo nicht sinn und zweck der sache. denn man arbeitet ja mit registern damit es schneller ist als dauernd den ram zu addressieren. aber bei 20Mhz ist das sowieso fast egal. zumindest bei SRAM, da der genausoschnell wie die register der cpu sind. der einzige zusätzliche aufwand ist die addressberechnung und die busumschaltung je nach dem was für ein speicherbuss verwendet wird.
gruss
-
a) Opcode laden + decodieren => is klar
b) daten laden => welche daten? (Bei meinen Befehlen werden ausser bei mov nur Register oder Direktwerte akzeptiert)
c) execute command => OK
d) save data => welche daten? (ich hab mir das eben so gedcht, dass die ALU ohne Umweg über ein Ausgangsregister die Daten direkt in das entsprechende Register schreibt)
Somit wär das Pipelining nur noch 2stufig... Aber bringt es das??
Gruss
Noooooooooooos
-
Einfach und langsam: einstufige Pipeline (also keine).
Ich hätte eine einfache 3stufige Pipeline in Erwägung gezogen, nicht, um die Leistung/Taktfrequenz zu erhöhen, sondern primär, um den Aufbau zu vereinfachen und den einzelnen Komponenten mehr Zeit zu geben.
Um die Leistung ging es mir dabei nicht, sondern um die Trennung verschiedener Teile. Und NOPs vom Assembler primitiv einfügen ist imho die einfachste Möglichkeit, wenn auch die bei weitem langsamste.
@nooooooooos: Ob du eine 2- oder eine 4-stufige Pipeline bastelst, bleibt dir überlassen. Ob deine ALU auf die Prozessor-Register zugreifen kann oder nur auf interne Register (die dann natürlich extra geladen/gesichert werden müssen), ebenfalls. Häng dich nicht an der Pipeline auf, es geht auch ohne (das ist sogar einfacher). :)
Gruß,
Svenska
-
So
dann lass mal das noch mal anschauen.
1. ergebnis bleibt immer im Akku stehen und muss explizit in ein register verschoben werden. somit Ok. Somit kann es keine 3 addressmaschine mehr werden, da hierzu ein expliziter zwischenschrit notwendig ist. da sonst z.B. ax + bx = ax zu nem sehr lustigen verhalten fúhren kann quasi gleichzeitiges lesn und schreiben auf ein register. quasi ne loop in hw
2. die ALU arbeitet nur auf registern. und dem akku. somit 1 addressmaschine. Für eine 2 addressmaschine wird die verkabelung ohne zwischenspeicherung am alu eingang etwas komplex. Die register sind ja nichts anderes als ram zellen, die über einen kleinen z.b. 4bit addresbuss angesprochen werden. die angesprochene speicherzelle wird dann auf den ALU-Eingagn geschaltet. die addresierung und bussleitungen brauchst du bei einer 2 addressmaschine somit 2 mal. da beide registerwerte gleichzeitig zur verknüpfung anliegen müssen. bei 16 registern geht das noch. je mehr das werden umso komplexer.
(sonderregister wie IP und PSW mal ausgenommen )
und wie kommen die daten aus dem programmcode in den akku?
gruss
-
Ähm so ganz blick ich da nicht durch, aber du hast mich überzeugt, wenigstens ein Ausgangsregister an der ALU zu machen...
Damit dürfen aber in Zwei direkt aufeinander folgenden Befehlen nicht die selben Register verwendet werden.
-
Ich war jetzt in technischer Informatik nicht so der Held, aber das müßte doch passen, wenn du dann im nächsten Takt zurückschreibst und das zurückgeschriebene Register sofort wieder verwendest?
Wobei ich jetzt ehrlichgesagt eher eine Richtigstellung erwarte als Zustimmung. ;)
-
nabend
die alu hat ja bekantlicherweise 2 Eingänge A und B. und einen ausgang nenen wir ihn mal C. Bei einer 3 Addressmaschine wird für A, B und C eine Addresse oder register angegeben. Daher auch der Name. Damit die ALU sauber arbeiten kann, muss für die ganze zeit der berechnung das eingangssignal A und B anliegen. nach einer gewissen zeit ( entsprechend der gatterlaufzeiten ) wird C das entsprechende ergebnis haben, das dann von einem Register übernommen wird. durch einen kurtzen tackt ein einem register gesichert. Soweit sollte das ja mal klar sein oder?
wird nun z.B. für B und C die gleiche adresse eingetragen, wird der ausgang auf den eingang geschaltet. wird da nicht irgend was dazwischen geschaltet fängt das system an zu schwingen, da sich das eingangsignal laufend ändert. Oder was sogar noch schlimmer währe, aufgrund der nutzung des gleichen datenbusses zu den registern, die irgendwelche leitunstreiber kurtz geschlossen. CPU rip :oops:
somit muss das ergebnis erst einmal gesichert werden und nachdem die eingangssignale weggeschalten worden sind, und der datenbuss zu den registern nicht mehr belegt ist, in das register transferiert werden.
Bei einer einadress maschine ist es ja so, das nur eine addresse verwendet wird. Um nun alle ein und ausgange der alu su verarbeiten wird ein zusätzliches "register" verwendet der AKKU oder auch akkumolator. er nimmt die ergebnisse der berechnungen auf, und wird gleichzeitig auf einen der beiden eingänge geschaltet. Der 2te eingang ist somit über eine Addresse ansprechbar.
bei uns sa das so aus. der ausgang der ALU (C) ging auf die eingänge des AKKUs. die ausgänge waren auf dein eingang B beschleift. paralel dazu war ein leitungstreiberbaustein angeschlossen, der den akku ausgang auf den Datenbus zu den registern schalten konnte. Der baustein hat für den AKKU nur dann auf den Datenbuss eingekoppelt, wen der akku wert in ein register übertragen wurde, ansonsten war er vom bus abgekoppelt (tri-state). Der Datenbus selber war mit dem Eingag A der ALU verbunden, und dem Registerspeicher.
für eine berechnung lag ja quasi am ALU eingag B immer ein wert an. über die Registeradresse wurde ein register addresiert und der wert auf den Datenbuss geschaltet, und somit auf den ALU eingang A. wenn das ergebnis dann am AKKU eingang anlag, wurde ein clock signal ausgelöst, der das ergebnis in den AKKU übernommen hat. (passende flipflops verwenden)
zum sichern des akus wurde der registerspeicher auf write umgeschalten, somit war der datenbuss frei, und der AKKU wert konnte auf den bus geschalten werden.
wie genau eine 2-Addressmaschine definiert ist kann ich nicht sagen. 8086 ist glaub ich eine. opp a,b wobei addresse a meist doppelt verwendet wird sowohl als eingang als auch aus ausgang der alu
gruss
-
Damit dürfen aber in Zwei direkt aufeinander folgenden Befehlen nicht die selben Register verwendet werden.
Langsam verlier ich den Überblick :)
Wenn du Pipelining verwendest, darf ein Registerzugriff auf ein bestimmtes Register erst dann auftreten, wenn der vorhergehende Befehl vollständig abgeschlossen wurde. Das heißt, das zwischen
mov ax, 5
add ax, bx
2 NOPs gesteckt werden müssen (sofern du eine 3stufige Pipeline hast).
Wie gesagt, Termite kennt sich mit den technischen Grundlagen da am besten von uns aus (vermute ich mal :) ).
Und was ich sehr empfehlen kann, ist eine Simulation. Der Herr von myCPU hat ja auch eine timing-exakte Simulation geschrieben, in der jedes Gatter mit der dazugehörigen Gatterlaufzeit simuliert wurde. Damit lassen sich solche Schweinerei-Effekte wie halt Datenbus-Schwingungen recht schnell erkennen (und damit auch vermeiden). Glaube ich zumindest. :)
no*os: Benutzt du nun ein Programm zur Simulation, und wenn ja, welches?
Gruß,
Svenska
-
Nee...bei der Simulation bin ich noch nicht...Erstens, weil ich zuerst den Befehlssatz mittels einer Emulation testen will, und zweitens, weil ich das Projekt eigentlich erst in nem halben Jahr richtig Starten will...
Hmm naja, wenn doch bei add ax,bx der Befehl schonmal gelanden und decodiert wird, solange die Register noch nicht stimmen, macht das ja nichts aus...
Gruss
Noooooooooos
-
Nee...bei der Simulation bin ich noch nicht...Erstens, weil ich zuerst den Befehlssatz mittels einer Emulation testen will, und zweitens, weil ich das Projekt eigentlich erst in nem halben Jahr richtig Starten will...
Das ist klar, aber ich glaube, ich würde erst schauen, welche Befehle sich überhaupt in annehmbarem Aufwand "basteln" lassen; besonders, wenn du keinen Microcode verwenden willst.
Hmm naja, wenn doch bei add ax,bx der Befehl schonmal gelanden und decodiert wird, solange die Register noch nicht stimmen, macht das ja nichts aus...
Beim Laden und Decodieren des Befehls noch nicht, wohl aber beim Ausführen. Allerdings musst du vor dem Ausführen ja auch die zu addierenden Zahlen laden - und die kommen ja aus den Registern, von denen du nicht weißt, ob die Ergebnisse stimmen. Zum Decodieren eines Befehl gehören (so mein Verständnis der Materie) auch die Operanden, mit denen gearbeitet wird.
Also musst du zum Addieren auch darauf achten, dass die Pipeline keine so undefinierten/ungültigen Befehle ausführt - und dann macht es was aus.
Gruß,
Svenska
-
Zum Decodieren eines Befehl gehören (so mein Verständnis der Materie) auch die Operanden, mit denen gearbeitet wird.
Meinst du jetzt, dass ich die Register schon beim Decodieren auf die ALU legen soll?? Dann würde es ja was ausmachen...
Aber das geht ja nicht, da die ALU für den aktuellen Befehl noch die alten Register braucht.
-
Wie du das alles baust, bleibt dir überlassen.
Ich hätte eher so daran gedacht, dass ich etwa folgendes Szenario habe:
In der ersten Stufe (Einlesen):
=> Befehl einlesen
=> Befehl decodieren
=> Operanden einlesen
In der zweiten Stufe (Ausführung):
=> Operanden in ALU-Register schreiben
=> ALU rechnen lassen
=> Ergebnis in ALU-Register schreiben
In der dritten Stufe (Ausgabe):
=> ALU-Register in Zielregister schreiben
Damit verschwende ich zwar etwas Rechenleistung in der dritten Stufe, habe aber die maximal mögliche Zeit in der zweiten Stufe. Damit werden geringere zeitliche Anforderungen an die ALU gestellt, die sich nicht mit den Prozessorregistern o.ä. rumschlagen muss. Dafür hat die ALU eben eigene Register, die somit in Nullzeit erreichbar sind, ohne externe Bus-Zugriffe und somit mit einer höheren Taktfrequenz.
Inwiefern das realisierbar ist, weiß ich nicht (eine Simulation habe ich noch nicht begonnen :) ).
Gruß,
Svenska
-
Hat jetzt eigentlich schon jemand angefangen ?
-
Nee...ich weiss noch gar nicht ob das Projekt bewilligt ist...sollte aber in nächster Nähe auskommen...
Gruss
-
Ich lerne z.Zt. für die Politik-Abiprüfung. :-)
Ein paar theoretische Grundlagen habe ich ja hier schon geschrieben, viel weiter war ich da auch noch nicht.
Gruß,
Sebastian
-
Naja über sowas hat ich auch schonmal nachgedacht aber hm...*hust* egal :P
ich auch, aber ich kann ja noch nicht mal wirklich gut asm, da hab ich mir gedacht erstmal richtig asm können, und dann ein bisschen über technik lernen, ich hab nämlich schon einige projekte im kopf, die mit lowlevel zu tun haben...
-
Ich habe gerade mit dem Studium (Elektrotechnik, Fachrichtung Automatisierungstechnik) angefangen ...
Deshalb ist es zeitlich mom etwas ungünstig, zumal ich auch viel spaß mit meinem OS habe ;)
-
Naja, wann, wenn nicht im Studium? ;)
-
Nur aus Interesse: Wie sieht es mit der CPU aus? Wurde damit angefangen, ist vielleicht sogar was drauß geworden?
-
Cjreek, falls du mich meinst, nein über ein bisschen Design-Pläne ist es nicht heraus gekommen...
Ich wollte eben nicht einfach ein, zwei Chips nehmen, diese auf einer Platine anordnen und Festplatte und Display daran anschliessen. Mein Plan war es alles selbst nur aus Transistoren, Spulen etc. zusammenzustellen.
Als dann meine Arbeit kein OK bekam (weil sie niemanden der sich damit auskennt hatten) habe ich sie mal ins Unbestimmte verschoben, zumal ich wahrscheinlich mal was in der Richtung studieren will.
Gruss
Noooooooos
-
"Diese Zeiten sind vorbei" ausgerechnet von dir zu hören, entbehrt nicht einer gewissen Ironie... ;)
-
Auch OS-Dev und Hacking im Sinne der allseitsbekannten Garagen"firmen" ist längst nicht mehr aktuell und realistisch, doch wie man sieht hat es seinen Reiz deswegen noch lange nicht verloren...
-
...auch gerade weil man vollen allen Ecken hört "Wozu noch ein Betriebssystem" oder hier könnte man sagen "Warum eine eigene CPU bauen? Did you heard anything from Intel or AMD?".
Es ist halt der Reiz, so etwas selber zu machen, in stundenlanger Arbeit zu sehen: "Aha! Ich habe 4 MiB RAM gemappt! Und durch GRUB erfahren, wie viel RAM ich überhaupt hab!"
-
http://web.archive.org/web/20080120145530/www.mycpu.eu/
-
Und hier wenn du es ganz aktuell haben willst :-D:
http://www.mycpu.eu/ bzw. http://mycpu.thtec.org/www-mycpu-eu/index1.htm(Backup-Server)
-
Ach die gibts noch ... hab einfach die Adresse aus dem ersten Post bei archive.org eingegeben^^
-
Hallo,
Aber Respekt hardware Bugs zu suchen muss ja noch komplizierter sein als einen Softwarefehler in einem Betriebsystem.
Mit dem richtigen Werkzeug ist auch das keine Hexerei. Ich vermute er wird nen guten Logic-Analyzer und seinen Gate-Level-Simulator verwendet haben. Trotzdem werde ich das lieber in mehreren FPGAs umsetzen, dafür gibt es noch bequemeres Werkzeug und die Kosten sind vielleicht auch geringer.
Aber ne respektable Leistung ists auf jeden Fall.
Grüße
Erik
-
Naja, bei mir wirds wohl noch eine Weile dauern, bis ich damit groß anfangen kann. Ich werde das wohl in Form eines FPGAs/CPLDs implementieren, inzwischen sind die Teile ja einigermaßen bezahlbar (was nicht heißt, dass ich sowas besitze...).
Ein paar Gedanken hatte ich schon, nur wie weit ich den Aufwand treiben kann, weiß ich bisher noch nicht. Derzeit steht Prüfungsstress an (Respekt an Regelungstechniker, Systemtheorie ist einfach nur Bäh...) und danach mal schauen.
Gruß,
Sebastian