Thema: Logisim CPU

[Svenska]

Hallo,

Nun wie schwer wird es nen Einplatinen-Computer aufzubauen ?

Welche Randbedingungen? "moderner Mikrocontroller + Spannungsregler + Peripherie" reicht aus. Wenn du einen richtigen Mikroprozessor benutzen möchtest, kommen da noch mindestens Chips für Taktversorgung, I/O, Timer, RAM und ROM dazu, ehe das System funktioniert. Das ist dann schon ziemlich viel Aufwand.

Und wieso ist das eigentlich komplexer wie ein C64 ?

Ist es nicht, wenn du heutige Technologien verwendest. Ein STM32 braucht fast keine externe Beschaltung und bildet den Kern - Displayansteuerung und Tastatur sind dann nur noch Software.

Gruß,
Svenska

[Tufelix]

Nun ich kann ja mal versuchen sowas zu bauen...
Für den Controller nehme ich einen Propeller-Chip von Parallax. An seinen Ports schließe ich einfach den VGA und den PS/2 anschluss an und regle den rest mit der software.
Mein einzigste Problem ist neben der Fehlenden Ausrüstung das ich noch nicht ganz die Vertikale und Horizontale Synchronisation-Pins im VGA Anschluss verstehe, werden da die bits über mehrende Takt-Zyklen transportiert ?

[erik.vikinger]

Hallo Tufelix,

Für den Controller nehme ich einen Propeller-Chip von Parallax.

dann schau Dir mal das an: http://www.linusakesson.net/scene/turbulence/, damit Du weist wo die Messlatte hängt.
Der Typ hat auch was ähnliches mit nem AVR gemacht (findest Du bestimmt auf seiner Seite).

das ich noch nicht ganz die Vertikale und Horizontale Synchronisation-Pins im VGA Anschluss verstehe, werden da die bits über mehrende Takt-Zyklen transportiert?

VGA arbeitet analog, das bedeutet das die (Farb-)Information im Spannungspegel (üblicherweise zwischen 0,0V und 0,7V) enthalten ist.


Zu Deiner CPU kann ich nur empfehlen das Du erst mal versuchen solltest ein System mit maximal 8 Tastern und maximal 8 LEDs und ein ganz klein wenig Software (kein RAM oder sonstige Peripherie) zum Laufen zu bekommen, damit Du eine bessere/konkretere Vorstellung davon bekommst was Du eigentlich tun willst.

Erst wenn du das Ziel kennst, solltest du loslaufen - den Weg findest du notfalls unterwegs.

Full ACK, vor allem zum zweiten Teil.


Grüße
Erik

[kevin]

Erst wenn du das Ziel kennst, solltest du loslaufen

Dann hätte ich bis heute noch keinen Kernel gebastelt...

[erik.vikinger]

Erst wenn du das Ziel kennst, solltest du loslaufen

Dann hätte ich bis heute noch keinen Kernel gebastelt...

Es fällt mir tatsächlich etwas schwer das komplett zu glauben.
Oder wolltest Du anfangs einfach nur ein besseres Terminal-Programm entwickeln?

[kevin]

Ich? Ich wollte einfach einen Kernel schreiben. Mit nicht näher definiertem Umfang und zu keinem Zweck. Because I can. (Oder eigentlich konnte ich es nicht... )

[Svenska]

Ich? Ich wollte einfach einen Kernel schreiben.

Ist das kein Ziel?

[Tufelix]

Nun...

VGA arbeitet analog, das bedeutet das die (Farb-)Information im Spannungspegel (üblicherweise zwischen 0,0V und 0,7V) enthalten ist.

Aja, ich glaub ich habs kappiert: Die einzellen Bildzeilen werden von links nach rechts erstellt, die zeilen werden von oben nach unten erstellt. Nun die Horizontale Synchronisation markiert das ende einer alten bzw den anfang einer neuen Zeile, die Vertikale Synchronisation markiert das Ende der letzten Zeile und somit auch den Anfang eines neuen Bildes. Ist das jetzt so richtig ?

dann schau Dir mal das an: http://www.linusakesson.net/scene/turbulence/, damit Du weist wo die Messlatte hängt.
Der Typ hat auch was ähnliches mit nem AVR gemacht (findest Du bestimmt auf seiner Seite).

Sowas ähnliches hab ich auch geplant, auch mit 2-Bit DAC's für den VGA anschluss eben ohne audioausgang(obwohl, nen audioausgang währe eigentlich ziemlich cool) dafür mit nem Ps/2 anschluss für ein Keyboard .

[kevin]

Ich? Ich wollte einfach einen Kernel schreiben.

Ist das kein Ziel?

Ja, aber ein reichlich unkonkretes. Wenn du das gelten lässt, dann kennt Tufelix sein Ziel auch...

[Svenska]

Ich? Ich wollte einfach einen Kernel schreiben.

Ist das kein Ziel?

Ja, aber ein reichlich unkonkretes. Wenn du das gelten lässt, dann kennt Tufelix sein Ziel auch...

Ich meinte nicht, dass du das Ziel in allen Details schon vorher kennen sollst. Eine grobe Idee, in welche Richtung du entwickeln willst, solltest du aber schon vorher haben (dein Kernel wird auch so Dinge wie "Protected Mode" und "Multitasking" vorgesehen haben, ehe du angefangen hast - oder?).

[erik.vikinger]

Hallo Tufelix,

Sowas ähnliches hab ich auch geplant ...

Aha, sorry wenn ich da jetzt ein ganz klein wenig arrogant klinge, aber hast Du wirklich eine konkrete Vorstellung davon wie der Weg zu diesem Ziel aussieht? Damit meine ich noch nicht mal die Probleme bei seiner konkreten Umsetzung seines Demos (z.B. Frame-Buffer mit nur ner Hand voll Bytes an RAM, also gar keinen Frame-Buffer sondern alles in Real-Time-Calculation u.a.m.) sondern die Techniken die man zur Lösung solcher Probleme beherrschen muss. Als Kevin mit dem Tyndur-Kernel angefangen hat wusste er mit Sicherheit noch nicht wie man jedes einzelne Teilproblem lösen kann (viele dieser kleinen Stolpersteine hat er wohl nicht mal gesehen als er angefangen hat, einiges davon sieht man eben erst wenn man es tatsächlich versucht umzusetzen) aber ich unterstelle mal das Kevin ungefähr wusste wie eine Flat-Memory-Speicherverwaltung aussieht und was diese zu leisten hat und er auch ausreichend Erfahrung mit den ganzen Techniken wie der Programmiersprache oder der Tool-Chain hatte.

Dieser Linus Akesson hat das Demo auf dem Propeller (turbulence) 2009 gemacht und das Demo auf dem ATmega88 (craft) 2008, seiner Homepage ist zu entnehmen das er auch vorher schon einige andere sehr Hardware-nahe Projekte (C64-Programmierung fällt IMHO immer in diese Kategorie ) erfolgreich abgeschlossen hat, an dieser Historie kann man die erforderliche Lernkurve für so ein Demo ablesen und das waren sicher 10 oder mehr Jahre (von der ersten Programmiererfahrung angefangen). Ich selber habe auch schon etliche Projekte mit Micro-Controllern u.ä. erfolgreich abgeschlossen (beruflich aber auch privat, dazu kommen jetzt 20 Jahre Programmiererfahrung allgemein) aber so ein Demo würde ich mir trotzdem nicht einfach so zutrauen, ich schätze mal das ich etwa 3 bis 5 Jahre bräuchte (bei der Menge Freizeit die ein berufstätiger und alleinerziehender Vater so hat) um mir die dafür nötigen Fähigkeiten (also alles das was mir zu so einem Demo heute fehlt) anzueignen und das obwohl ich 1997-1998 selber an Demos, allerdings auf dem PC, mitgearbeitet hab.

Mir ist klar das Du nicht vor hast so ein anspruchsvolles Demo zu entwickeln aber eine richtige General-Purpose-CPU ist auch keine Kleinigkeit, an meinem Projekt hänge ich jetzt bald 5 Jahre dran und hab erst einige kleine Teile meiner CPU fertig und für vieles andere nur recht detaillierte Konzepte (wenn mein Privatleben die letzten Jahre etwas leichter gewesen wäre wäre ich aber schon etwas weiter). Gut mein Ziel ist auch etwas ambitionierter: ich möchte bei gleichen Takt etwa die Performance eines Pentium Pro (686) erreichen (zumindest wenn ich richtige Out-of-Order-Execution hinbekomme, ansonsten wird es wohl höchstens für nen normalen Pentium (586) reichen). Auch einem Cortex M mit gleichem Takt möchte ich überholen können, was sich von alleine ergibt wenn ich den Pentium Pro erreiche. Bei Performance pro Watt dürfte ich dank heutiger FPGAs wohl mit dem Pentium Pro gerade so mithalten können aber für den normalen Pentium sind FPGAs einfach zu durstig und einem Micro-Kontroller der dank heutiger Fertigungstechnologie mit ein paar mW auskommt komm ich mit nem FPGA natürlich erst recht nicht bei.

Daher kann ich nur wiederholen:

Zu Deiner CPU kann ich nur empfehlen das Du erst mal versuchen solltest ein System mit maximal 8 Tastern und maximal 8 LEDs und ein ganz klein wenig Software (kein RAM oder sonstige Peripherie) zum Laufen zu bekommen, damit Du eine bessere/konkretere Vorstellung davon bekommst was Du eigentlich tun willst.

Ich denke das Du noch auf dem richtigen Weg bist aber Du solltest Dir erst mal ein Etappenziel in realistischer Entfernung vornehmen und dann weitersehen. Ich würde an Deiner Stelle erst mal versuchen eine reine 8Bit-CPU (wie nen kleinen AVR) aber einem nur 8-bittigem Speicher-Adressraum (der Code-Adressraum darf aber größer sein, schau Dir mal die kleinen PICs 14F...18F von Microchip an) umzusetzen. An Tastatur oder gar Monitor solltest Du auch noch nicht denken, fürs erste reichen ein paar Taster und ein paar LEDs völlig aus.

Hast Du schon daran gedacht das Du für Deine eigene CPU auch eigene Linker/Assembler/Compiler benötigst?
Auch da gilt es einige Herausforderungen zu meisten.


Grüße
Erik


PS.: Bitte glaube mir das es wirklich nicht meine Absicht ist zu Desillusionieren.

[XanClic]

Als ich mit Kernelentwicklung angefangen hab, wollte ich nur Assembler lernen. Dass es sowas wie Protected Mode oder Speicherverwaltung überhaupt gibt, wusste ich gar nicht.

Gut, Assembler kann ich heute akzeptabel, insofern kann man behaupten, dass ich mein Ziel erreicht habe, aber na ja…

[kevin]

Ich meinte nicht, dass du das Ziel in allen Details schon vorher kennen sollst. Eine grobe Idee, in welche Richtung du entwickeln willst, solltest du aber schon vorher haben (dein Kernel wird auch so Dinge wie "Protected Mode" und "Multitasking" vorgesehen haben, ehe du angefangen hast - oder?).

Okay, klar, Multitasking schon. Die noch lange nicht verwirklichte Vision eines Desktop-OS gibt das ja quasi vor. Ich bin mir nicht sicher, ob die allerdings in den Anfängen als konkretes Ziel taugt, und mit der Zeit gibt man sie ja sowieso auf. Protected Mode war eigentlich kein Ziel, sondern eher so eine Sache, wo überall stand "das macht man so" und dann hab ich es halt so gemacht. Damit es ein Ziel hätte sein können, hätte ich ja genau wissen müssen, was das überhaupt ist.

Ansonsten war das einfach ein Vorwärtstasten. Was hätte ich noch gern, ist mit überschaubarem Aufwand machbar und habe ich grad Lust, zu basteln? Dann schaue ich da mal rein. So funktioniert das bei mir mit der tyndur-Entwicklung nach wie vor. Wobei sich in letzter Zeit bedauerlicherweise eine gewisse Diskrepanz zwischen was nötig ist und worauf ich Lust habe eingestellt hat - dann funktioniert dieses Modell nicht mehr so richtig gut...

Als Kevin mit dem Tyndur-Kernel angefangen hat wusste er mit Sicherheit noch nicht wie man jedes einzelne Teilproblem lösen kann (viele dieser kleinen Stolpersteine hat er wohl nicht mal gesehen als er angefangen hat, einiges davon sieht man eben erst wenn man es tatsächlich versucht umzusetzen) aber ich unterstelle mal das Kevin ungefähr wusste wie eine Flat-Memory-Speicherverwaltung aussieht und was diese zu leisten hat und er auch ausreichend Erfahrung mit den ganzen Techniken wie der Programmiersprache oder der Tool-Chain hatte.

*hust* Willst du raten, was mein erstes richtiges Projekt in C war, mit dem ich die Sprache eigentlich gelernt habe?

Und natürlich wusste ich nicht, wie man jedes einzelnes Teilproblem lösen kann, ich wusste ja nicht mal welche Teilprobleme es gibt. Und wie man sie richtig löst, weiß ich bis heute nicht, ich kenne nur teilweise mehr unbefriedigende Möglichkeiten... Und wie ein malloc funktioniert, hatte ich in der Tat schonmal an der Uni gehört; dass es sowas wie Paging gibt und wie man das unfallfrei verwendet, war trotzdem Neuland für mich.

tl;dr: Ich hatte keine Ahnung, was ich tat, und ich habe das Gefühl, dass sich seither nur das Niveau der Ahnungslosigkeit verschoben hat.

[Svenska]

Der PM gibt einen Rahmen vor, was theoretisch möglich ist - auch dann, wenn man ihn nicht nutzt oder kennt. Darum heißt es hier im Forum ja auch immer "GRUB", "PM" und "VESA", wenn jemand nicht weiß, womit er anfangen soll. Bei Hardware ist die Entscheidung nicht so einfach, finde ich. Da sollte man diesen Rahmen stecken, bevor man anfängt; eine 8-Bit-CPU ohne Adress-/Datenbusse geht halt nicht.

So, mit diesem Link (http://www.youtube.com/watch?v=DIwC9vdqfqw) zu einem Vortrag vom 29C3 kehre ich wieder zum Thema zurück.

[Tufelix]

Mhh, ich glaub es ist zunächst besser wieder zu logisim zurück zu kehren und wenn ich dann ein besseres Verständniss für Hardware hab zu versuchen so ein Demo-board zu bauen.

[Svenska]

Die grundsätzlichen Ideen bleiben aber die gleichen (also Daten-/Adressbus usw.).

[Tufelix]

Jop bleiben gleich...
Nun ich hab mir jetzt überlegt das ich nen Cisc-CPU mit 5 Pipline stufen baue. Zunächst, wie kann ich löst man am besten solche Pipeline-Hazard ohne das Lücken entstehen?

[erik.vikinger]

Hallo,

Protected Mode war eigentlich kein Ziel [....]. Damit es ein Ziel hätte sein können, hätte ich ja genau wissen müssen, was das überhaupt ist.

Vor allem hättest Du auch die Alternativen kennen müssen um Dich überhaupt bewusst für oder gegen Konzepte wie PM oder Flat-Memory entscheiden zu können.

*hust* Willst du raten, was mein erstes richtiges Projekt in C war, mit dem ich die Sprache eigentlich gelernt habe?

Bin ich hier eigentlich der einzigste der auch nur halbwegs strukturiert vorgeht?

und ich habe das Gefühl, dass sich seither nur das Niveau der Ahnungslosigkeit verschoben hat.

Mir fehlen die Worte!

Mhh, ich glaub es ist zunächst besser wieder zu logisim zurück zu kehren und wenn ich dann ein besseres Verständniss für Hardware hab zu versuchen

Ja, das klingt nach einem guten Plan.

so ein Demo-board zu bauen.

Und was soll dann da drauf?
Wenn Du wirklich eine CPU entwickeln möchtest dann empfehle ich Dir so ein FPGA-Board mit gut DRAM und einigen Schnittstellen. Ich weiß das man da durchaus mit 250 Euronen (eventuell auch etwas mehr) dabei ist aber dafür bekommt man auch ein echt tolles Spielzeug auf dem das Basteln an einer eigenen CPU richtig viel Spaß machen kann.

Nun ich hab mir jetzt überlegt das ich nen Cisc-CPU mit 5 Pipline stufen baue.

Also von CISC würde ich eher abraten da es heute günstiger ist wenige schnelle Befehle zu haben als viele langsame und komplexe Befehle. Vor allem würde ich davon abraten das prinzipiell jeder Befehl in der Lage ist auf den Speicher zuzugreifen. Ist aber nur meine persönliche subjektive Meinung.

wie kann ich löst man am besten solche Pipeline-Hazard ohne das Lücken entstehen?

Gar nicht. Wenn Du diese Lücken nicht willst dann musst du echte Out-of-Order-Execution schaffen damit Du die Pipeline mit voneinander unabhängigen Befehlen befüllen kannst.


Grüße
Erik

[kevin]

*hust* Willst du raten, was mein erstes richtiges Projekt in C war, mit dem ich die Sprache eigentlich gelernt habe?

Bin ich hier eigentlich der einzigste der auch nur halbwegs strukturiert vorgeht?

Vermutlich. Und der einzige, der noch keine Ergebnisse hat. *duck*

Aber mal ganz ehrlich: Womit hätte ich denn sonst C lernen sollen, wenn nicht mit einem Projekt, das mich interessiert?

[Svenska]

Cisc-CPU

Rate ich von ab, baue lieber wenige Befehle - spart Komplexität.

5 Pipline stufen

Rate ich von ab, baue lieber eine Maschine mit entweder 1 Takt/Befehl (komplizierter) oder x Takte/Befehl (einfacher) ohne Pipeline.

Bei deinem Wissen, zumindest so wie ich das einschätze, würde ich erstmal ganz klein anfangen. Du wirst schon dabei genug Wissen anhäufen, um eine Menge Fehler im zweiten Anlauf zu vermeiden.

Gruß,
Svenska