Thema: Verrückter als wir...?

[Termite]

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

[RedEagle]

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

[nooooooooos]

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??

[RedEagle]

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...

[nooooooooos]

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??

[RedEagle]

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)??

[Termite]

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]

@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

[nooooooooos]

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.

[Svenska]

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

[nooooooooos]

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

[Svenska]

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

[nooooooooos]

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

[Svenska]

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

[Termite]

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

[nooooooooos]

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?

[RedEagle]

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.

[Svenska]

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

[ScAr_TeX]

Find das ganz schön krass, seine eigene CPU zu bauen. 

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 

[blitzmaster]

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.