Nachrichten

21

Offtopic / Re: Logisim CPU

« am: 08. January 2013, 22:46 »

Hallo,


ich weiß jetzt nicht genau ob es das ist was Du meinst aber die I/O-Pins an typischen µC können bei einem Pegelwechsel einen Interrupt auslösen (bei den besseren µC ist das sehr fein konfigurierbar, z.B. nur bestimmte Flanken und/oder Pegel) aber diese Funktionalität kommt vom GPIO-Controller (ist eine Peripherie-Komponente zur Steuerung der I/O-Pins) in dem µC und hat nichts mit dem CPU-Kern ansich zu tun.

Falls Deine Frage auf was anderes abzielt dann Bitte konkreter formulieren.


Grüße
Erik

22

Offtopic / Re: Logisim CPU

« am: 07. January 2013, 22:10 »

Hallo,

Warum nicht statt "pop $pc" nicht ein "ld $sp, $r1; jmp $r1"?

Weil damit r1 kaputt gemacht wird. Diese Art von RET ist nicht zerstörungsfrei. Das ist sowohl bei Funktionen als auch bei Interrupt-Handlern ein Problem es sei denn Du definierst r1 zur alleinigen Verwendung für diesen Zweck (dann darf r1 auch nie manuell gesichert/wiederhergestellt werden).

Und bei einem Interrupt kann man den Program Counter auch in ein Kernel-Mode-Register speichern statt auf den möglicherweise kaputten Stack zu pushen.

Das ist zwar ein gutes Argument das für eine richtige CPU in jeden Fall beachtet werden muss aber für ein Test-Design zum üben ist sowas IMHO noch nicht erforderlich. Solange die CPU von Tufelix nicht zwischen User-Mode und System-Mode unterscheidet reicht es wenn Interrupt-Handler genau so behandelt werden wie Funktionen (nur mit dem Unterschied das beim Interrupt-Handler alle Register callee-save / nonvolatile sind, dafür gibt es nur ein RET und nicht RET und IRET) auch wenn das ein paar grundlegende Sicherheitsrisiken hat die man bei einer richtigen General-Purpose-CPU nicht tolerieren kann.

Wenn ein Interrupt oder eine Exception nicht auf den Speicher zugreifen soll (was grundsätzlich eine gute Idee ist) benötigt man dafür in jedem Fall für jeden System-Mode einen eigenen Programm-Counter (siehe ARM), wenn es für den System-Mode nur einen einzigen Programm-Counter gibt bedeutet dass das Syscall/Exceptions/Interrupts nicht kaskadierbar sind (auf meine CPU trifft das zu) wohingegen es ja gerade der große Vorteil von x86 ist das dort quasi beliebig kaskadiert werden kann (im RM und im PM, solange auf dem Stack noch Platz ist).


Grüße
Erik

23

Offtopic / Re: Logisim CPU

« am: 07. January 2013, 19:58 »

und ein CALL ist ein "PUSH Programcounter; JUMP Zieladresse". Den Programmcounter musst Du niemals mit einem explizitem PUSH-Befehl sichern können aber wiederherstellen ist erforderlich, also ein "POP Programmcounter" (um dann an der neuen Adresse den nächsten Befehl zu holen), das nennt sich dann RET.


Grüße
Erik

24

Offtopic / Re: binäre Division

« am: 07. January 2013, 19:53 »

Hallo,

Dann vermute ich mal das Android keine Fragezeichen darstellen kann

Eines letzten Dinge, die noch funktionieren.

Soso, da bin ich aber froh das ich keines dieser smarten Phönchen habe.

128 bit Dividend, Divisor gerne weniger.

Aber die Größe des Divisors gibt vor wie viel Logik die Divisions-HW kostet, der Divisor bestimmt die Breite der Subtraktionen/Vergleiche und der Dividend gibt nur vor wie breit das Shift-Register ist von dem immer ein kleiner Teil (der so groß ist wie der Divisor) bearbeitet wird. Für meine CPU hab ich mir überlegt das ich zwei leicht unterschiedliche Divisionseinheiten haben will (wenn im FPGA noch Platz ist): eine mit voller Breite 128:64 = 64,64 (Dividend:Divisior = Quotient,Rest) die immer nur ein Bit pro Takt errechnet und eine mit reduziertem Divisor 128:24 = 64,24 die immer 4 Bit pro Takt errechnet. Da ich in der Slow-ALU eh mindestens einen Takt zum Vorbereiten der Parameter und selektieren der zuständigen Logik benötige kann ich dabei auch prüfen wie viele Bits im Divisor tatsächlich benutzt werden und damit sicher einen Großteil der Divisionen erheblich beschleunigen.

Ein Branch des Ausführungs-Graphen. Also alles zwischen Bedingungen und Schleifen.

Aha, Dir geht es also um Loop-Unrolling in Hardware. Das schätze ich mal als relativ Aufwendig ein da dabei die HW selbstständig ermitteln muss welche Variablen (Register) bei jeder Iteration neu benutzt werden (also parallelisiert werden können) und welche Variablen den Schleifenzähler darstellen (das muss nicht nur eine Variable sein und die muss auch nicht simpel Inkrementiert/Dekrementiert werden) und welche Variablen für alle Iterationen immer Konstant sind. Dazu kommt das die Hardware zuverlässig erkennen können muss welche Schleifen nicht parallelisierbar sind (selbst wenn die Abhängigkeit zwischen den Iterationen nicht linear ist und nur über den Speicher geht), schau Dir dazu mal den RC4-Verschlüsselungsalgorithmus an (das ist ein tolles Beispiel für sehr simplen Code bei dem man trotzdem nicht erkennen kann welche Iteration von welcher abhängt). Ich vermute mal das es einfacher ist sowas dem Compiler zu überlassen und dafür ein bisschen mehr Code-Cache zu haben (damit die Schleifen auch größer sein dürfen). Beim Pentium 4 war Loop-Unrolling extrem effektiv weil diese CPU relativ viele Befehle aktiv haben kann und der L1-Code-Cache hinter dem Decoder sitzt (die damaligen Intel-Compiler haben das Loop-Unrolling auch bis ins extrem getrieben und damit auch einen echten Vorteil gegenüber dem gcc raus geholt).

Jeder Kern ist für allgemeine Zwecke vorgesehen. Es sollen nur wenige Instruktionen angeboten werden, darunter Integer-Arithmetik, Bit-Manipulation und Vergleiche (alles gepackt in 8, 16, 32, 64 oder 128 bit), dazu Bedingungen und Schleifen

Also RISC mit SIMD.

anstelle von Sprungbefehlen.

Um allgemeine Sprungbefehle wirst Du nicht umhin kommen, überlege mal wie Du ein switch-Konstrukt umsetzen möchtest.

Vergleiche werden im Register gespeichert. Es gibt überhaupt keine Flags.

Also sowas wie Alpha, der hat auch keine Flags und prüft bei bedingten Befehlen direkt den Inhalt eines beliebigen Registers ob dies bestimmten Kriterien entspricht. Hast Du Dir schon mal überlegt was für Nachteile dieses Konzept haben kann? Meiner persönlichen Meinung nach ist es effektiver den Vergleich und den bedingten Sprung in einen Befehl zu vereinen also einen bedingten Sprung bauen der das Verhältnis zwischen 2 beliebigen Registern prüft (das geht sogar für Floating-Point ganz einfach), solange Du genug Bits in den Befehlen hast sollte das kein Problem sein (das Sprungziel muss auch nicht allzu viele Bits haben da bedingte Sprünge üblicherweise nur kurze Strecken springen).

Bedingungen und Schleifen stellen nicht parallelisierbare Befehle dar.

Das ist aber doof, Sprünge stellen ein interessantes Betätigungsfeld für spekulative Ausführung dar.

Hast Du schon mal an VLIW oder EPIC gedacht?
Kannst Du Bitte noch ein paar Sätze mit einer allgemeineren Zielbeschreibung dazu packen?  Damit man auch mal das große Ganze etwas besser erkennen kann.


Grüße
Erik

25

Offtopic / Re: binäre Division

« am: 07. January 2013, 13:52 »

Hallo,

Und ja, ich lese alle Beiträge sehr sorgfältig, im Rahmen der Möglickeiten auf dem kleinen Android-Display.

Sicher? Dann vermute ich mal das Android keine Fragezeichen darstellen kann, Du hast genau 12 Stück davon in meinen Beiträgen komplett übersehen und nur dieses eine beachtet.


Grüße
Erik

26

Offtopic / Re: Logisim CPU

« am: 07. January 2013, 13:44 »

Hallo,


Der Frame-Pointer ist eher eine reine Software-Angelegenheit für Hochsprachen-Compiler aber er sollte trotzdem vorhanden sein und flexibles Adressieren mit positiven und negativen Displacements ermöglichen.

... im Interrupthandler alle Register sichern können musst ...

Dazu gehören auch die Flags (deswegen hab ich die einfach in ein normales Register gelegt) und alles andere was zum Zustand eines Threads/Task gehört. Dieses Sichern und Wiederherstellen muss übrigens Zerstörungsfrei sein (darf den zu sichernden/wiederherzustellenden Zustand nicht beeinflussen).

Floating-Point soll bei mir integraler (aber optionaler) Bestandteil der CPU sein

Damit ist gemeint das bei meiner CPU die Floating-Point-Befehle u.a. die selben Flags benutzen so das man z.B. nach einem FSUB die selben bedingten Sprünge nutzen kann um das Ergebnis auszuwerten wie nach einem SUB (reine CMP/FCMP wird es auf meiner CPU nicht geben so das man für Vergleiche immer SUB/FSUB nutzen und ein Register verschwenden muss). Auch bedeutet dass das z.B. IDIV das selbe "Divide-by-Zero"-Flag setzt (und damit auch die selbe Exception auslösen kann) wie FDIV um diese Art von Fehler zu signalisieren. Dazu kommt der Vorteil das der Scheduler im OS-Kernel nur einen Register-Satz sichern/wiederherstellen muss um den Zustand eines Threads immer komplett verwalten zu können.


Grüße
Erik

27

Offtopic / Re: binäre Division

« am: 06. January 2013, 00:28 »

Hallo,


hast Du meine Beiträge eigentlich vollständig gelesen?

Wieviel Transistoren wird ein SRT-Dividierer mit 128 bit in etwa verbrauchen?

Ich vermute mal das es kaum mehr als 100 Menschen auf diesem Planeten gibt die dazu wirklich echte Zahlen nennen können. Auf was beziehen sich die 128 Bit, auf den Dividend oder den Divisor?

Ich will mit einem Kern insgesamt unter 1m Transistoren kommen, zzgl. Cache.

Dann dürfte nicht sehr viel mehr als ein besserer 486 bei raus kommen (wobei ich jetzt nicht weiß wie viele von dessen gut 1M-Transistoren auf den Cache entfallen), falls Du ein schlankes RISC-Design nimmst sollte aber zumindest eine gewisse Menge an Instruction-Level-Parallelism und eventuell sogar Superscalar-Execution möglich sein. Der 486 hatte übrigens keinen SRT-Dividierer.


Grüße
Erik

28

Offtopic / Re: Logisim CPU

« am: 05. January 2013, 19:21 »

Hallo,

Ich weiß aber garnicht ob RISC CPUs überhaupt ein explizite Stackpointerregister haben....

Eigentlich nicht, echte RISC-CPUs geben nicht mal vor ob der Stack nach unten oder nach oben wächst (das ist dann eine Vorgabe des OS oder Compilers). Bei ARM sind im Assembler z.B. PUSH und POP nur Aliase für Speicherzugriffe mit R13 (ist bei ARM der "offizielle" Stackpointer) und Pre-Decrement bzw. Post-Inkrement aber das könnte man auch ganz anders lösen da diese Befehle mit jedem Register als Adressregister umgehen können.
Das Problem ist eher der erforderliche Schaltungsaufwand in der CPU (jedes beliebige Register als Adressregister benutzen zu können erfordert mehr Logik als immer nur bestimmte Register zu benutzen) und der verfügbare Platz in den OpCodes (PUSH und POP für die normalen Register sind bei 8086 nur 1 Byte groß aber bei ARM immer 32Bit, früher war das durchaus relevant aber bei heutigen Speicherpreisen ist das nicht mehr so schlimm). Ein anderes Problem sind die verfügbaren Adressierungsmodi, bei x86 gibt es kein Pre/Post-Inkrement/Dekrement so das sich PUSH und POP gar nicht ohne zusätzliche Rechenbefehle (die dann auch noch die Flags modifizieren) mit normalen Speicherzugriffen ersetzen ließen.
Ein anderes Problem ist die Performance. So ist z.B.

Code: [Auswählen]

pop  ecx
pop  ebx
pop  eaxlangsamer als

Code: [Auswählen]

mov  ecx,[esp]
mov  ebx,[esp+4]
mov  eax,[esp+8]
add  esp,12da im ersten Code jeder der POP-Befehle warten muss bis der vorangegangene POP-Befehl ESP fertig modifiziert hat bevor er weiß von wo er Daten lesen soll wohingegen im zweiten Code alle 4 Befehle parallel ausgeführt werden können (zumindest theoretisch) solange sichergestellt ist das die Modifikation an ESP durch den ADD-Befehl erst dann sichtbar wird wenn alle vorangegangenen Befehle ESP gelesen haben (der eigentliche Speicherzugriff muss deswegen noch nicht fertig sein).


@Tufelix:
mach Deine CPU erst mal so einfach wie irgend möglich, die komplexeren Dinge kommen später (und Performance noch viel später).


Grüße
Erik

29

Offtopic / Re: Logisim CPU

« am: 05. January 2013, 18:41 »

Hallo,

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

Hm, vielleicht bin ich aber auch der einzige der ein Projekt hat bei dem man auf keinen Fall am Ende feststellen möchte das man am Anfang etwas falsch gemacht hat (egal wie klein dieses etwas auch sein mag).
Deswegen beschäftige ich mich zur Zeit mit der Funktionsweise von Floating-Point-Befehlen obwohl ich erstmal gar keine implementieren möchte, nur um Heute schon Flag-Register/Exception-Handling/.... anständig designen zu können (Floating-Point soll bei mir integraler (aber optionaler) Bestandteil der CPU sein und nicht als zusätzliches Rechenwerk oder gar zusätzlicher Coprozessor realisiert werden) und hoffentlich später nicht feststellen muss das ich etwas übersehen habe und dann entscheiden darf ob ich eine Krücke dranbastle oder noch mal von vorne anfange.

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

Soll das heißen das es im User-Mode nichts gibt was Dich mal interessieren würde?

jeder der 2 Kerne bekommt dann seinen eigenen Ram und Programmspeicher und über das Round-Robin-Verfahren könnten dann jeder der 2 Kerne auf das externe Bussystem zugreifen.

Wenn Du da "Ram" und "Programmspeicher" gegen L1-Data/Code-Cache austauscht und dann noch anständige Cache-Kohärenz schaffst hast Du echtes SMP (was Du beschreibst ist AMP).
Ich will jetzt wirklich nicht überheblich klingen aber ich schätze mal dass das Heute die Grenzen Deiner Möglichkeiten ein ganz klein wenig überschreitet.
Du solltest wirklich erst mal mit was ganz einfachem Anfangen: erst mal eine kleine CPU nach Harvard und als einzigste Peripherie ein paar Taster und LEDs (noch nicht mal Data-RAM, für die ersten kleinen Programmchen reichen die Register). Erst nachdem Du das erfolgreich geschafft hast würde ich mal einen UART als Schnittstelle zur Außenwelt und RAM dazu packen und erst dann wenn Deine Programme deutlich komplexer werden und wirklich mehr Möglichkeiten brauchen solltest Du weiter denken. Vor allem sammelst Du so Erfahrungen noch bevor die Größe Deines Projekts in Mann-Jahre gemessen werden muss und ein Fehlschuss in zu vielen Tränen endet.

Dein CPU-Diagramm sieht nach einem realistischem Plan aus, beim BUS fehlen noch 2 Byte-Enable-Leitungen falls Du nicht nur 16Bit-Weise zugreifen willst und die Adressleitung A0 kann eventuell eingespart werden (wird durch die 2 Byte-Enables erledigt) falls Du Byteweise adressieren möchtest (falls Dein BUS als kleines Datum 16Bit-Werte verarbeitet/adressiert ist er so aber Okay).


Grüße
Erik

30

Softwareentwicklung / Re: Batch - Dateiverwaltung

« am: 04. January 2013, 17:24 »

Hallo,

Dass heist alles spricht dafür als nächstes C zu lernen, da ein OS pur aus ASM nicht viel Sinn macht.

Ja.

Könnt ihr da evt. ein gutes buch empfehlen?

Auch wenn das hier wohl einige Leute anders sehen so empfehle ich da eher das man wenigstens mal ein paar normale Programme entwickelt (mit ansteigendem Schwierigkeitsgrad) um mit den erforderlichen Werkzeugen auch den sicheren Umgang zu üben bevor man sich an ein eigenes OS macht. Bücher über C gibt es ne Menge, wimre gab es da mal ne Liste im Wiki.


Grüße
Erik

31

Offtopic / Re: Logisim CPU

« am: 04. January 2013, 17:16 »

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

32

Offtopic / Re: binäre Division

« am: 04. January 2013, 16:56 »

Hallo,

Was genau hast du denn nicht verstanden?

Alles.

Ich will viele Kerne auf wenig Chipfläche bringen.

Okay, so weit so gut.

Diese sollen selbst parallel auf einem Branch rechnen können.

Branch von was? Und was meinst Du mit rechnen? Also was genau ist der gewünschte Funktionsumfang eines Kerns? Sollen das normale General-Purpose-CPU-Kerne werden?

Jeder Kern soll mit 50-80% der Chipfläche aus cache bestehen

Das ergibt sich von allein wenn die Caches groß genug sind. Man sagt nicht umsonst das Intel der größte SRAM-Hersteller auf diesem Planeten ist.

und diesen unabhängig von anderen Kernen mit dem DRAM synchronisieren können.

Das erfordert ein wirklich sehr gutes Kohärenz-Protokoll und sowas ist wahrlich keine einfache Aufgabe. Du kannst ja mal probieren die große Version der HyperTransport-Spezifikation (also die Version die Kohärenz beinhaltet und leider nicht frei verfügbar ist) zu bekommen, falls Du das schaffst hast Du auf jeden Fall guten Lesestoff (HyperTransport soll in diesem Bereich recht gut sein, vor allem die High-Node-Count-Version), für eine Kopie wäre ich sehr dankbar. Ich selber möchte auch SMP (ccNUMA) erreichen und das dürfte eine der härtesten Nüssen sein die ich für mein Projekt knacken muss.

Es geht mir erstmal nur um die reine Machbarkeit

Machbar ist das bestimmt, die Frage ist ob Du es schaffst alle Detail-Probleme auf dem Weg dahin zu lösen.

Kann man SRAM-Cache mit der doppelten Schaltgeschindigkeit eines Transistors takten?

Eher nicht. Eine Taktperiode sollte mindestens 5 bis 10 Transistor-Schaltzeiten + die zugehörigen Signallaufzeiten zwischen den Transistoren umfassen damit die Logik auch wenigstens ein klein wenig sinnvolle Arbeit pro Takt verrichten kann. Der L1-Cache in aktuellen Intel-CPUs hat etwa 3 bis 4 Takte Latenz (was etwa 1.5 bis 2.0 ns entspricht) und die ergibt sich wimre im wesentlichen aus den Signallaufzeiten (da selbst der kleine L1-Cache in Relation zur Ausbreitungsgeschwindigkeit bereits eine recht große Fläche belegt) und weniger aus der Schaltgeschwindigkeit der Transistoren. Aktuelle L2-Caches (bei AMD und Intel) liegen so im Bereich von 20 bis 30 Takten. Dazu kommt das man bei jedem Zugriff auf eine Cache-Line auch den zugehörigen Tag aktualisieren muss (falls man eine bessere Ersetzungsstrategie als Round-Robin verwenden will).

mit der doppelten Schaltgeschindigkeit eines Transistors takten?

Was glaubst Du mit was für Elementen das Taktsignal auf einem CMOS-IC verteilt/verstärkt wird? Selbst eine halbe Taktperiode muss mindestens ein vielfaches der normalen Transistor-Schaltzeit betragen, pro Takt muss ein Transistor zum Takt-Transport ja immer genau zwei mal schalten.


Grüße
Erik

33

Offtopic / Re: binäre Division

« am: 04. January 2013, 09:54 »

sorry, aber ich habe kein einziges Wort verstanden,
Bitte erkläre doch erst mal in ein paar Sätzen was Du eigentlich willst (im Groben und dann auch im Feinen für Dein aktuelles Problem)

34

Softwareentwicklung / Re: Batch - Dateiverwaltung

« am: 02. January 2013, 21:14 »

Hallo Manello,

Wenn ich ein OS schreibe, wäre es schneller, ressurcen sparender mit C oder Assembler?

Mit sehr hoher Wahrscheinlichkeit die C-Variante, unter der Voraussetzung das Du in beiden Wegen die selben Algorithmen umsetzt (da die Wahl des richtigen Algorithmus oft deutlich mehr ausmacht als die Wahl der richtigen Programmiersprache, gute Compiler können nicht nur die Leute hinter einer Sprache schreiben und mache Compiler haben für mehrere Sprachen ein gutes Front-End so das oft ein sehr ähnliches Ergebnis bei raus kommt). Die Frage ist eher ob ein durchschnittlicher Assembler-Programmierer ein besseres Ergebnis hinbekommt als ein moderner Compiler (der von echten Profis auf diesem Gebiet entwickelt wird, diese Leute arbeiten manchmal sogar mit dem CPU-Hersteller zusammen oder bekommen zumindest besseren Support als irgendwer anders) und das dürfte eindeutig zu Gunsten des modernen Compilers ausgehen.

Und was wäre mit der GUI, in Assembler habe ich noch nie eine "richtige" GUI geschrieben.

Selbe Antwort wie zuvor.

Dies ist ein Zitat aus der wiki, und weis jetzt nicht was ich davon halten soll.

Klar gibt es einzelne Situationen in denen ein Compiler mal nicht unbedingt den optimalen Code abliefert aber ich denke die sind bei modernen Compilern schon ziemlich selten (solange man die gut ausgetrampelten Standard-Pfade der jeweiligen Programmiersprache nicht zu sehr verlässt) und deswegen würde ich mich lieber mit dem Ergebnis eines 99%-tigem Compilers zufrieden geben (und gegebenenfalls an der einen oder anderen Stelle meinen Hochsprachen-Quell-Code ein bisschen anders formulieren damit der Compiler das besser rafft) als selber anzufangen den x-fachen (x dürfte wohl größer als 10 sein, je nach CPU) Quell-Code-Umfang in Assembler zu bauen. Eine Frage die Du Dir selber stellen solltest ist die ob Du noch vor Deinem Tod fertig werden willst.

Hatten wir diese Diskussion hier nicht schon mal vor etwas über einem Jahr?


Grüße
Erik

Und es wäre theoretisch möglich, das OS aus der Wiki zu nehmen, und es so zu schreiben dass es .ASM ausführen kann, und dann den Kernel eine .ASM ausführen lassen dass dann das OS ist...

Also für ASM würde ich eindeutig einen JIT-Compiler einem Interpreter vorziehen. Du solltest noch mal ganz gründlich über die Funktionsweise von Assembler und Compiler nachdenken.
SCNR

35

Offtopic / Re: binäre Division

« am: 02. January 2013, 19:44 »

Hallo Dimension,

Die Funktionen werden iterativ auf das Register angewendet. log2(128)=7, also muss 7-Fach verschaltet werden.

Hä? Was tust Du da meinen?

Im Schaltbild setze ich nur die (platz&zeit-)kritischen Instruktionen um.

Gerade das dürfte ein automatisches Synthesetool deutlich besser als Du schaffen, hier passt der Vergleich zwischen Assembler und einer Hochsprache mit gutem Compiler durchaus. Wenn es auf möglichst kurze Durchlaufzeit ankommt werden binäre Addition/Subtraktion (und auch Multiplikation) schon lange nicht mehr aus einfachen 1Bit-Addierern zusammengesetzt, da gibt es deutlich effizientere Methoden.


Bitte beschriebe doch erst mal was Du eigentlich konkret erreichen willst.
Hast Du wirklich vor einen echten eigenen CMOS-IC zu entwickeln?


Grüße
Erik

36

Offtopic / Re: Logisim CPU

« am: 02. January 2013, 19:29 »

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.

37

Lowlevel-Coding / Re: Qemu stürtzt ab bei Multitasking

« am: 31. December 2012, 15:38 »

Hallo,

Normale Programme beenden sich auch über einen Systemaufruf und nicht über ein return. (Auch wenn die Library/Programmiersprache deiner Wahl das eventuell so aussehen lässt.)

Die Programme im COM-Format von DOS konnten durchaus mit einem einfachen RET beendet werden aber in allen echten OSen ist dazu ein richtiger Systemaufruf erforderlich (schon um einen Return-Code/Error-Level/... mitzugeben, siehe exit() ).


Grüße vom Oberlehrer
Erik

38

Offtopic / Re: Logisim CPU

« am: 31. December 2012, 15:30 »

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?

39

Offtopic / Re: binäre Division

« am: 31. December 2012, 15:25 »

Hallo Dimension,

Mit welchem Programm kann man Logik-Gatter mit Timing simulieren?

Das geht ganz sicher auch mit ModelSim, man kann in VHDL schließlich auch Gatter beschreiben und auch die Durchlaufzeiten durch ein Gatter mit angeben und auch die Durchlaufzeiten von Leitungen kann man in VHDL abbilden. Alles was Du dazu bräuchtest wäre ein Synthese-Tool das Deinen normalen VHDL-Code nimmt und daraus eben Schaltungen nur mit AND/OR/NAND/NOR/NOT/XOR-Gattern baut und alle Laufzeiten passend einbaut, ob es sowas gibt weiß ich aber nicht. Der Macher von MyCPU.eu hat wimre geschrieben das er seine CPU auf Gatter-Ebene mit Laufzeiten simuliert hat, vielleicht kann er ja sagen womit (ist immerhin ein Deutscher).

Ich will das design parallel zu VHDL per Schaltbild machen

Das klingt für mich so als würdest Du ein Programm zusätzlich zu C++ auch noch mal parallel in Assembler umsetzen wollen (inklusive Optimierungen), diesen erheblichen zusätzlichen Aufwand würde ich nur Treiben wenn es dafür auch wirklich einen triftigen Grund gibt.

da die Verdrahtung einen bedeutenden Anteil an der Gesamtfläche hat

Auf einem echten CMOS-IC belegt die Verdrahtung keine zusätzliche Fläche da diese über dem Silizium in mehreren Kupfer-Ebenen gemacht wird.
das Bild ist aus http://de.wikipedia.org/wiki/Integrierter_Schaltkreis#Front-End
Das eigentliche Silizium ist nur die untere Hälfte von FEOL und die Verdrahtung ist in BEOL.


Was genau ist Dein eigentliches Ziel?


Grüße
Erik

40

Offtopic / Re: Logisim CPU

« am: 30. December 2012, 21:49 »

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