Thema: Verrückter als wir...?

[RedEagle]

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.

[Termite]

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

[RedEagle]

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

[Svenska]

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

[nooooooooos]

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

[kevin]

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.

[nooooooooos]

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

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

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

[nooooooooos]

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

[ST-225]

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 

[RedEagle]

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.

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

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

[nooooooooos]

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

[kevin]

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.

Code: [Auswählen]

function fakultaet(x) is begin
  y := 1;
  while (x > 0) do
    y := y * x;
    x := x - 1
  od;
  return y
end fakultaet;


[Termite]

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

[Svenska]

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

[Termite]

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

[nooooooooos]

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

[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

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

[nooooooooos]

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