Forum: Mikrocontroller und Digitale Elektronik [Selbstbau CPU] Welche Befehle machen eine CPU "praktisch"?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andre G. (andgst01)


Lesenswert?

Schönen Sonntag Abend,

was sind eigentlich die wichtigsten Befehle die eine CPU beherrschen 
sollte um wirklich praktischen Wert zu haben?


Man kann ja eine CPU bauen die nur eine Anweisung kennt.
Sehr einfach in der Realisierung, aber nicht praktisch dafür 
Maschinencode zu schreiben.

Oder man kann eine CPU bauen die tausende Befehle kennt.
Aufwändig in der Realisierung, nicht praktisch dafür Maschinencode zu 
schreiben weil sich niemand den ganzen Befehlssatz merken kann.

Soviel zu den beiden Extremen.
Es geht darum den idealen Kompromiss zu finden.
Welche Befehle sind wirklich wichtig damit eine CPU "praktisch" in der 
Verwendung ist?


Die CPUs in den AVRs haben auch eine Menge an Befehlen die ich 
persönlich als unnötig empfinde.
Zum Beispiel "SBR" (Set bit in register).
Ein Bit setzen macht man doch normalerweise sowieso mit einem bitweisen 
ODER, oder?
Oder die ganzen "branch if xxxx" Befehle.
Das könnte man doch einfach mit einem "branch if status bit X is set" 
Befehl machen (man müsste eben die relevanten Informationen in einigen 
Statusbytes "zugänglich machen").

Klar, sehr viele diesr "speziellen Funktionen" dienen hauptsächlich der 
Leistungsoptimierung damit etwas dass mit einfachen Befehlen 10 Takte 
dauert nur noch 2 Takte dauert weil es in Hardware in der CPU gemacht 
wird.

Wenn ihr einen Befehlssatz für eine CPU entwerfen könntet, was würde ihr 
implementieren?





Der Grund warum ich das frage ist weil ich derzeit an einer 
halb-diskreten 8 bit CPU arbeite.
Mit "halb-diskret" meine ich "aus 74er und 4000er Logik-ICs, aber auch 
mit (E)EPROMs, SRAMS.
Das ist kein "Retro-Projekt", es werden durchaus auch moderne Chips 
verwendet.

Langsam sollte ich mich festlegen was den Befehlssatz angeht.
Die ALU basiert auf zwei 74x181s, also die wichtigsten Arithmetik- und 
Logikfunktionen sind da ja schon implementiert.
Bit-Schieben nach links und rechts mit "Nachschieben" einer 1 oder 0 ist 
in Hardware ja recht einfach.
Komparatoren die A<B, A=B, A>B ausgeben gibt es auch fertig als ICs.
Je nach Konfiguration kann man damit normale integer-Zahlen und 
Zweierkomplemente vergleichen. Das ist also auch kein Problem.
Sprungbefehle (PC auf einen bestimmten Wert setzten) sind ebenfalls 
relativ einfach in der Implementierung.

Nein, das ist kein "ich würde gerne ..." - Projekt das nach ein paar 
Wochen im Sand verläuft, ich habe die Motivation und Geduld das wirklich 
durchzuziehen.
Das Ganze hat als "ich würde irgendwann gerne ..." - Projekt angefangen 
aber seit einigen Wochen bin ich wirklich aktiv am Schaltpläne zeichnen, 
passende ICs raussuchen, Timing-Diagramme erstellen, ...
Ich habe schon einiges gelernt (Befehls-Dekoder ist komplizierter als 
man denkt, vor allem bei Befehlen die mehrere "Parameter" haben)

Weil mit Sicherheit jemand "Warum?" fragen wird werde ich diese Frage 
gleich beantworten:
Vor einigen Jahren haben wir in der Schule "Grundlagen Digitaltechnik" 
durchgenommen.
Als mir dann klar wurde dass ein Computer eigentlich nur aus logischen 
Verknüpfungen besteht dachte ich mir "Wäre es nicht cool selbst einen 
Computer zu bauen?". Mir war schon damals klar dass ein "selbstgebauter 
Computer" niemals auch nur ansatzweise mit einem "modernen" Computer 
mithalten kann.
Da ich zu jener Zeit aber nicht die finanziellen Mittel für 
kubikmeterweise Logik-ICs und Lochrasterplatinen hatte blieb das erstmal 
ein Traum.
Nun habe ich die Zeit und die Ressourcen um dieses Projekt zu 
realisieren.

Ja, ich weiß, ein paar Seiten VHDL in einem FPGA wären die bessere 
Lösung, aber das reizt mich einfach nicht so wie "echte Hardware".

Ich werde mich bemühen alle negativen Kommentare zu ignorieren.
Es geht hier NICHT um die Sinnhaftigkeit dieses Projekts sondern um die 
Befehle die eine CPU "praktisch" machen.

von (prx) A. K. (prx)


Lesenswert?

Andre G. schrieb:
> Zum Beispiel "SBR" (Set bit in register).

Den gibts ja auch nicht wirklich. Das ist ein Synonym für ORI.

von (prx) A. K. (prx)


Lesenswert?

Andre G. schrieb:
> Oder die ganzen "branch if xxxx" Befehle.
> Das könnte man doch einfach mit einem "branch if status bit X is set"

Genauer hinsehen. Exakt so funktioniert das ja auch. ;-)

Es gibt eigentlich nur BRBC und BRBS, alle anderen bedingte Sprünge sind 
darüber implementiert. Das hat allerdings Folgen für das Statusregister. 
Genau deshalb gibt es das S Flag.

: Bearbeitet durch User
von bork (Gast)


Lesenswert?

Vielleicht einfach ein paar Unterlagen zur Computerarchitektur 
durchschauen?

Der Klassiker ist Henessy&Patterns "Computer Architecture: A 
Quantitative Approach"

Wenn es ein Selbstbaucomputer werden soll, dass ist evtl. eine 
Akkubasierte Architektur für den Anfang das einfachste. Daraus leiten 
sich auch die möglichen Befehle ab. Als Referenz: PDP8, CDC1604, 
MOS6502, Motorola 6800

von (prx) A. K. (prx)


Lesenswert?

bork schrieb:
> Als Referenz: PDP8, CDC1604, MOS6502, Motorola 6800

Und RCA 1802, wenns etwas abseits des Mainstreams sein darf.

von c-hater (Gast)


Lesenswert?

Andre G. schrieb:

> Man kann ja eine CPU bauen die nur eine Anweisung kennt.

Nein. Das reicht definitiv nicht für Turing-Vollständigkeit. Da brauchst 
du mindestens zwei/drei. (je nach Betrachungweise). Ist mehr ein 
akademisches Definitionsproblem. Also etwas, was für reale 
Architektur-Designer einigermßen Huppse ist.

> Die CPUs in den AVRs haben auch eine Menge an Befehlen die ich
> persönlich als unnötig empfinde.
> Zum Beispiel "SBR" (Set bit in register).

Das ist auch nicht wirklich eine Instruktion, sondern nur eine 
Alias-Instruktion. Wird tatsächlich als ori reg,immediate umgesetzt.

Mein Gott, wer sowas wie keine Ahnung von existierenden (vergleichweise 
primitiven) Architekturen hat, wie du, sollte sich wohl eher nicht mit 
dem Design von neuen beschäftigen.

Ich würde mal auf Traffic-Troll tippen.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
>> Man kann ja eine CPU bauen die nur eine Anweisung kennt.
>
> Nein. Das reicht definitiv nicht für Turing-Vollständigkeit.

https://en.wikipedia.org/wiki/One-instruction_set_computer

von Andre G. (andgst01)


Lesenswert?

c-hater schrieb:

> Mein Gott, wer sowas wie keine Ahnung von existierenden (vergleichweise
> primitiven) Architekturen hat, wie du, sollte sich wohl eher nicht mit
> dem Design von neuen beschäftigen.

Wo bitte im Datenblatt der AVRs steht das?
In der Übersichtstabelle mit allen Befehlen steht nichts davon ...

c-hater schrieb:
> Ich würde mal auf Traffic-Troll tippen.

Ich weiß nicht mal was das sein soll ...

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:
> c-hater schrieb:
>>> Man kann ja eine CPU bauen die nur eine Anweisung kennt.
>>
>> Nein. Das reicht definitiv nicht für Turing-Vollständigkeit.
>
> https://en.wikipedia.org/wiki/One-instruction_set_computer

Wie schon gesagt: nutzlose, rein akademische Wichserei. Der Trick ist 
die Definition, was eine Instruktion ist/sein soll...

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Ein NOP Befehl scheint mir recht wichtig zu sein. Kennt wer eine CPU, 
die den nicht hat?

SCNR,
WK

von c-hater (Gast)


Lesenswert?

Andre G. schrieb:

> Wo bitte im Datenblatt der AVRs steht das?

Wenn du nicht inmal in der Lage bist, dies herauszufinden...

Tipp für dich: Schau dir einfach die Codierung der Opcodes an und 
vergleiche SBR mit ORI. Fällt dir wenigstens DANN etwas auf?

Beitrag #7001935 wurde vom Autor gelöscht.
von Thomas W. (dbstw)


Lesenswert?

Moin, -

den Patterson & Hennessey weisst Du ja jetzt schon (Appendices D 
erklaert wie Du vom Programm auf Mikroprogramming kommst), Morris Mano 
"Computer System Architecture" koenntest Du noch lesen.

Ward/Halstead (Computation Structures) erklaert sehr gut das 
Microprogramming.

Mein Favorit waere Bell/Mudge/McNamara "Computer Engineering" [Subtitle: 
A DEC View of Hardware Systems Design], aber ich habe eine Schwaeche 
fuer DEC-Produkte.

Viele Erfolg

Th.

P.S.: Du findest solche Buecher z.T. bei archive.org oder bei Library 
Genesis.

von Andre G. (andgst01)


Lesenswert?

c-hater schrieb:
> Andre G. schrieb:
>
>> Wo bitte im Datenblatt der AVRs steht das?
>
> Wenn du nicht inmal in der Lage bist, dies herauszufinden...
>
> Tipp für dich: Schau dir einfach die Codierung der Opcodes an und
> vergleiche SBR mit ORI. Fällt dir wenigstens DANN etwas auf?

Ja, aber im "normalen" Datenblatt von AVR µCs stehen die Opcodes nicht 
drin.
Da muss man schon im Datenblatt der CPU nachschauen.

von Max M. (prokrastinator)


Lesenswert?

Andre G. schrieb:
> wichtigsten Befehle die eine CPU beherrschen
> sollte um wirklich praktischen Wert zu haben?

Die kleinen PICs haben 33 Stk. RISC

Aber hast Du nicht gerade flammende Reden gegen die Komplexität einer 
MCU im Vergleich zu Eproms gehalten?
Beitrag "Re: EPROMs löschen mit UV LEDs"

Nun also eine eigene MCU

Vielleicht schnackst Du mal mit Josef darüber:
Beitrag "Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
Beitrag "8bit-Computing mit FPGA"

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> nutzlose, rein akademische Wichserei

Was ist daran nutzlos? ;-)

c-hater schrieb:
> Der Trick ist die Definition, was eine Instruktion ist/sein soll...

Manches schon, etwa beim Prinzip des einzig mir bekannten kommerziell 
realisierten OISC, dem MaxQ2000.

Aber "Subtract and branch if less than or equal to zero" ist nicht arg 
weit vom DJNZ der Z80 entfernt. Auch eine ISA mit Arithmetik und 
Sprungadresse in jedem Befehl gab es bereits früh, denn der erste in 
grösserer Stückzahl hergestellte Computer arbeitete so, die IBM 650.

: Bearbeitet durch User
von Bauform B. (bauformb)


Lesenswert?

c-hater schrieb:
> Mein Gott, wer sowas wie keine Ahnung von existierenden (vergleichweise
> primitiven) Architekturen hat...

...kann völlig frei und unvoreingenommen die optimale CPU entwerfen. 
Kein Nachteil ohne Vorteil.

(prx) A. K. schrieb:
> Und RCA 1802, wenns etwas abseits des Mainstreams sein darf.

Den kannst du wirklich mit einzelnen Gattern nachbauen. Und der 
Befehlssatz ist so einfach dass du keinen Assembler brauchst ;) Na gut, 
PDP8 ist noch einfacher.

PDP8 ist auch 12 Bit breit. Warum hat sich die perfekte Wortbreite 
eigentlich nicht durchgesetzt? Andre, das ist deine Chance, nur ein 
181er mehr eröffnet ungeahnte neue Möglichkeiten.

von (prx) A. K. (prx)


Lesenswert?

Subtract and branch if less than or equal to zeroAndre G. schrieb im 
Beitrag #7001939:
> Da muss man schon im Datenblatt der CPU nachschauen.

Genauer gesagt in der Dokumentation des Befehlssatzes. Wär vielleicht 
kein Fehler gewesen, da reinzusehen, wenn man über den Befehlssatz 
doziert. ;-)

: Bearbeitet durch User
von c-hater (Gast)


Lesenswert?

Andre G. schrieb:

> Da muss man schon im Datenblatt der CPU nachschauen.

Nö. Im "instruction set reference manual". Auf das allerdings jedes 
AVR8-DB explizit verweist...

von MaWin (Gast)


Lesenswert?

Andre G. schrieb:
> praktisch

Normalerweise ist die Fragestellung anders:

Mit welchem Befehlsatz lässt sich von einem Compiler für die üblichen 
Hochsprachen der am schnellsten ablaufende code für die üblichen 
Aufgaben erzeugen.

Da du eine 8 bit CPU designen willst, ist AVR schon recht modern und 
sinnvoll, schliesslich gibt es dafür schon Compiler.

SBR ist halt einfach kürzer und schneller als ORI.

Beim Inmos Transputer fehlten z.B. Befehle damit man schnellen Code 
schreiben konnte um Speicherbereiche umzukopieren.

von (prx) A. K. (prx)


Lesenswert?

Bauform B. schrieb:
> Warum hat sich die perfekte Wortbreite eigentlich nicht durchgesetzt?

Bis 24, 36 und 48 Bits ist man immerhin gekommen. Dann prägte jedoch IBM 
mit der 360 Architektur die Zukunft (ob sie das selbst erfunden haben 
weiss ich nicht).

Schon mal versucht, mit 12-Bit Wortbreite ein voll gepacktes Bit-Array 
zu adressieren? Durch eine Zweierpotenz dividiert es sich leichter.

von Günni (Gast)


Lesenswert?

Ich finde den Befehlssatz des 8051 für sehr gelungen. Nicht umsonst 
hatte diese Familie eine sehr große Verbreitung. Überflüssig war dabei 
nur der MUL-Befehl. Der braucht relativ viel Chipfläche und wird bei den 
meisten Anwendungen eher selten gebraucht. Noch weniger aufwändig ist 
der Befehlssatz des 8048. Auch damit konnte man gut arbeiten. Wenn 
weniger auf Steuerungsanwendungen abgezielt wird, war der 6502 ein 
idealer Baustein. Der wurde deshab ja auch in vielen Personal Computern 
genutzt. Ich habe damals sowohl (Assembler-)Programme für den 6502 als 
auch für den 6800 / 6809 geschrieben, wobei mir der 6502-Befehlssatz 
besser gefiel.

von (prx) A. K. (prx)


Lesenswert?

MaWin schrieb:
> Beim Inmos Transputer fehlten z.B. Befehle damit man schnellen Code
> schreiben konnte um Speicherbereiche umzukopieren.

Hmm. "move"?

von Thomas W. (dbstw)


Angehängte Dateien:

Lesenswert?

Bauform B. schrieb:
> c-hater schrieb:

> Den kannst du wirklich mit einzelnen Gattern nachbauen. Und der
> Befehlssatz ist so einfach dass du keinen Assembler brauchst ;) Na gut,
> PDP8 ist noch einfacher.
>
> PDP8 ist auch 12 Bit breit. Warum hat sich die perfekte Wortbreite
> eigentlich nicht durchgesetzt? Andre, das ist deine Chance, nur ein
> 181er mehr eröffnet ungeahnte neue Möglichkeiten.

Nun ja, ich weiss nicht: Hinten dran haengt der Decoding Tree fuer die 
PDP8-CPU (aus dem Bell/Nudge/McNamara, Part II, Chap.8 "Structural 
Levels of the PDP-8", p.216, 1978)

Herrlich, was es alles an Dokumentation gab.

Gruesse

Th.

von (prx) A. K. (prx)


Lesenswert?

MaWin schrieb:
> SBR ist halt einfach kürzer und schneller als ORI.

Ähhhm - die sind identisch. Nicht mal der Name ist kürzer.

von Max M. (prokrastinator)


Lesenswert?

Die PIOs im RP2040 kommen mit 9 Befehlen aus und haben einen praktischen 
Wert.
Aber für einen praktischen wert braucht man nicht alle 9 davon.
Also wie war die Frage gleich?

von (prx) A. K. (prx)


Lesenswert?

Bauform B. schrieb:
> Den kannst du wirklich mit einzelnen Gattern nachbauen.

Schlechtes Argument. Man kann sogar 60-Bit Maschinen aus 
Einzeltransistoren aufbauen, die als Vorläufer der Supercomputer gelten 
(CDC6600+7600). Bisschen mehr Arbeit halt.

von c-hater (Gast)


Lesenswert?

Bauform B. schrieb:

> c-hater schrieb:
>> Mein Gott, wer sowas wie keine Ahnung von existierenden (vergleichweise
>> primitiven) Architekturen hat...
>
> ...kann völlig frei und unvoreingenommen die optimale CPU entwerfen.

Das bezweifele ich ernsthaft.

Wenn wir irgendwo im Jahr 1950 wären, ja dann ok. Sind wir aber nicht. 
Mit 70 Jahren Abstand und unzähligen (zumindest zweitweise) 
existierenden Architekturen gibt es aber genug Stoff, um aus all den 
Fehlern zu lernen, die andere bereits zuvor gemacht haben. Es wäre sehr 
dumm, diesen Wissenschatz zu ignorieren.

von Andre G. (andgst01)


Lesenswert?

c-hater schrieb:
> Bauform B. schrieb:
>
>> c-hater schrieb:
>>> Mein Gott, wer sowas wie keine Ahnung von existierenden (vergleichweise
>>> primitiven) Architekturen hat...
>>
>> ...kann völlig frei und unvoreingenommen die optimale CPU entwerfen.
>
> Das bezweifele ich ernsthaft.
>
> Wenn wir irgendwo im Jahr 1950 wären, ja dann ok. Sind wir aber nicht.
> Mit 70 Jahren Abstand und unzähligen (zumindest zweitweise)
> existierenden Architekturen gibt es aber genug Stoff, um aus all den
> Fehlern zu lernen, die andere bereits zuvor gemacht haben. Es wäre sehr
> dumm, diesen Wissenschatz zu ignorieren.

Gut, dann werde ich mal mit dem Lesen anfangen ...


Ich möchte übrigens nicht stumpfsinning etwas "nachbauen" ...

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> MaWin schrieb:
>> SBR ist halt einfach kürzer und schneller als ORI.
>
> Ähhhm - die sind identisch. Nicht mal der Name ist kürzer.

Das war mal wieder der Fake-MaWin (oder einer der Fake-Mawins). 
Jedenfalls ein Idiot, den man problemlos daran erkennen kann, dass er 
sich idiotisch äußert. Der echte MaWin hätte das niemals geschrieben.

von Thomas W. (dbstw)


Lesenswert?

Moin, -

ich hatte Dir vor vielen Monaten den https://www.homebrewcpuring.org/ 
ans Herz gelegt. Hast Du mal geguckt wie andere sich ihre CPUs selbst 
gebaut haben?

Gruesse

Th.

von (prx) A. K. (prx)


Lesenswert?

Dergute W. schrieb:
> Ein NOP Befehl scheint mir recht wichtig zu sein. Kennt wer eine CPU,
> die den nicht hat?

Kennt jeder, nutzt jeder, aber nicht jeder weiss es: 8086.
Da ist NOP ein Alias für XCHG AX,AX.

: Bearbeitet durch User
von Hirnfurz (Gast)


Lesenswert?

Der minimalistische Befehlssatz eines PICs wird von den
ST6 noch deutlich unterboten.

Allerdings fehlen dem TO wie schon gesehen, der Fleiss sich
überhaupt eine Orientierung zu verschaffen, als auch die
Kompetenz eine Architektur zu bewerten.

Ausserdem fehlen ihm die zur Realisierung unbedingt nötigen 74182.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

bork schrieb:
> Vielleicht einfach ein paar Unterlagen zur Computerarchitektur
> durchschauen?
>
> Der Klassiker ist Henessy&Patterns "Computer Architecture: A
> Quantitative Approach"
>
> Wenn es ein Selbstbaucomputer werden soll, dass ist evtl. eine
> Akkubasierte Architektur für den Anfang das einfachste. Daraus leiten
> sich auch die möglichen Befehle ab. Als Referenz: PDP8, CDC1604,
> MOS6502, Motorola 6800

Für so eine einfache CPU reicht auch Patterson&Hennessy "Computer 
Organization and Design: The Hardware/Software Interface".

Das sollte in jedem Fall lesen. Frühere Ausgaben von Hennessy&Patterson 
waren noch eigenständig lesbar, aber seit es Patterson&Hennessy gibt, 
wurde im Grunde der Umfang erweitert und auf die beiden Bücher verteilt 
(die früheren Einführungskapitel aus P&H sind also in deutlich 
erweiterter Form in H&P ausgelagert), wobei nun Patterson&Hennessy die 
Grundlagen für Hennessy&Patterson legt.

von Max M. (prokrastinator)


Lesenswert?

c-hater schrieb:
> Der echte MaWin hätte das niemals geschrieben.

Das ist wie in der Religion.
Passiert etwas Gutes, war das Gott.
Passiert etwas schlechtes war das der Teufel.
Je nach Auslegung ist die Frage warum Gott das schlechte geschehen lässt 
dann ketzerei + Scheiterhaufen oder die Wege des MaWin äh Herrn sind 
halt unergründlich

Also KANN der echte MaWin ganichts dummes sagen, weil das dann per 
Definition der falsche MaWin gesagt hat.

Respekt! Das muss man erstmal hinbekommen.
Da zünde ich mal gleich eine Kerze an.
MaWin der Du bist bei Mc.net, geheiligt werde Dein Name ...

von (prx) A. K. (prx)


Lesenswert?

Hirnfurz schrieb:
> Ausserdem fehlen ihm die zur Realisierung unbedingt nötigen 74182.

Wieso sollen die unbedingt nötig sein? Für ein Spassprojekt braucht man 
kein Tempo, sogar bitseriell wär kein Drama (vgl NS SC/MP, irgendein 
Motorola 68xx). Oder man rechnet in 4 Bit Häppchen, wie bei Z80.

: Bearbeitet durch User
von Andre G. (andgst01)


Lesenswert?

Philipp Klaus K. schrieb:
> Für so eine einfache CPU reicht auch Patterson&Hennessy "Computer
> Organization and Design: The Hardware/Software Interface".

Werde ich lesen.

von Andre G. (andgst01)


Lesenswert?

Hirnfurz schrieb:
> Der minimalistische Befehlssatz eines PICs wird von den
> ST6 noch deutlich unterboten.
>
> Allerdings fehlen dem TO wie schon gesehen, der Fleiss sich
> überhaupt eine Orientierung zu verschaffen, als auch die
> Kompetenz eine Architektur zu bewerten.

Nein.
Ich dachte mir ich fange einfach mal an.

Klar, man kann Jahrzehnte lang studieren wie und wieso andere das anders 
gemacht haben.
Ein gewisses "Grundwissen" schadet aber sicher nicht, deshalb werde ich 
die erwähnten Bücher lesen.

"Probieren geht über studieren", oder?



Hirnfurz schrieb:
> Ausserdem fehlen ihm die zur Realisierung unbedingt nötigen 74182.

Der "Carry look-ahead" Chip?
Mir persönlich ist egal ob ich ein zwei Taktzyklen warten muss bis der 
eine 181 das Carry Signal des anderen 181 mitverarbeitet hat.
Das wird (natürlich) kein Hochleistungsrechner.

von H.Joachim S. (crazyhorse)


Lesenswert?

Viele Sachen sind mit studieren (das ist mehr als auswendig lernen) 
sinnvoller erledigt als mit probieren (eigentlich ist das sogar ein 
ziemlich dämliches Sprichwort, kann eigentlich nur von Deppen erfunden 
sein und passt eher zu dem berühmten blinden Huhn).

von (prx) A. K. (prx)


Lesenswert?

H.Joachim S. schrieb:
> eigentlich ist das sogar ein
> ziemlich dämliches Sprichwort, kann eigentlich nur von Deppen erfunden
> sein und passt eher zu dem berühmten blinden Huhn

Der Sinn ergibt sich, wenn man es historisch betrachtet. Aus der Praxis 
kommende unstudierte Knochenklempner, die Soldaten wieder 
zusammenflickten, hatten darob weit mehr Ahnung von der Realität, als 
jene, die nur die Schriften Galens auswendig lernten.

: Bearbeitet durch User
von Ein Kommentar (Gast)


Lesenswert?

> Nun habe ich die Zeit und die Ressourcen um dieses Projekt zu realisieren.

Inzwischen haben wir ganz andere Probleme.

So ein paar Gatter für überflüssige Bitbefehle interessieren niemanden 
mehr. Heutzutage haben wir das umgekehrte Problem. Die Milliarden von 
Transistoren auf einem Chip lassen sich mit der klassischen Denkweise 
nicht mehr sinnvoll einsetzen. Wenn wir Rechenleistung brauchen, lassen 
wir die Algorithmen auf den 1000 Kernen einer GPU laufen.

Heutzutage geht es um ganz andere Fragen. Z.B. Können wir Ransomware 
verhindern, wenn jede einzelne Funktion in ihrer eigenen Sandbox läuft? 
Können wir zuverlässigere Software schreiben, wenn sich die Hardware um 
Eigentümer und Garbage Collection der Objekte kümmert? Soll die Hardware 
Datentypen kennen, Rechenoperationen auf Zeiger ergeben grundsätzlich 
wieder gültige Zeiger? ...

Eine CPU mit einem Befehlssatz, in dem sich die Rechteverwaltung nicht 
umgehen lässt - das wäre doch mal ein interessantes Projekt.

von Dieter R. (drei)


Lesenswert?

Andre G. schrieb:

> Ich dachte mir ich fange einfach mal an.

Nachdem dir mehrfach (und meiner bescheidenen Meinung nach 
richtigerweise) eine PDP-8 als Basis ans Herz gelegt wurde: hast du mal 
eine gesehen, in der originalen TTL-Version? Da bist du als 
Einzelkämpfer ein paar Jahre am Löten. Billig wird es auch nicht gerade, 
und die Stromversorgung solltest du ebenfalls nicht unterschätzen.

von udok (Gast)


Lesenswert?

Andre G. schrieb:
>> Für so eine einfache CPU reicht auch Patterson&Hennessy "Computer
>> Organization and Design: The Hardware/Software Interface".
>
> Werde ich lesen.

Wenn du damit anfängst wirst du nie was bauen.

Must dich halt entscheiden, ob du ein Theoretiker oder ein Praktiker 
sein willst...

von (prx) A. K. (prx)


Lesenswert?

Ein Kommentar schrieb:
> Eine CPU mit einem Befehlssatz, in dem sich die Rechteverwaltung nicht
> umgehen lässt - das wäre doch mal ein interessantes Projekt.

Jene Probleme, mit dem sich Intel, AMD und ARM derzeit mal wieder 
rumplagen, nämlich die neueste Geburt in der Spectre-Familie, hat 
weniger mit dem Befehlssatz zu tun, als mit Nebeneffekten trickreich 
beschleunigter Implementierung.

Soll keiner sagen, Intel hätte es nicht mit einer ISA versucht, die an 
jeder Stelle ein Bündel Rechte rumschleppt. Das Desaster iAPX432 ging ja 
in diese Richtung. Kids, don't try this at home.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

udok schrieb:
> Must dich halt entscheiden, ob du ein Theoretiker oder ein Praktiker
> sein willst...

Warum muss man sich dazwischen entscheiden, entweder oder? Die Synthese 
machts.

von (prx) A. K. (prx)


Lesenswert?

Ein Kommentar schrieb:
> Rechenoperationen auf Zeiger ergeben grundsätzlich
> wieder gültige Zeiger?

Auch hier hilft ein Blick in die Geschichte, diesmal die deutsche. Die 
TR440 hatte zu ihren 48 Datenbits noch 2 Bits Typenkennung für die Art 
des Inhalts. Zu den weniger beliebten Ergebnissen eines Programmlaufs 
zählte daher der Typenkennungsalarm, wenn Operation und Daten nicht 
harmonierten. Das war noch nicht perfekt, aber ausbaufähig.

https://de.wikipedia.org/wiki/TR_440#Informationsdarstellung

: Bearbeitet durch User
von michael_ (Gast)


Lesenswert?

Andre G. schrieb:
> Schönen Sonntag Abend,

Hä, hab ich was verschlafen?

Sind denn die EPROM schon alle verbaut?

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Kennt jeder, nutzt jeder, aber nicht jeder weiss es: 8086.
> Da ist NOP ein Alias für XCHG AX,AX.

Auch bei vielen anderen Archtikturen ist ein (definiertes) NOP effektiv 
nur ein Alias für irgendeine tatsächlich nützliche Instruktion mit 
bestimten Operanden. Eigentlich sogar bei den meisten.

von udok (Gast)


Lesenswert?

(prx) A. K. schrieb:
>> Must dich halt entscheiden, ob du ein Theoretiker oder ein Praktiker
>> sein willst...
>
> Warum muss man sich dazwischen entscheiden, entweder oder? Die Synthese
> machts.

Na ja, wenn der TE mit dem Wissenstand heute anfängt den H&P zu lesen,
dann braucht er mal 1-2 Jahr bis er das alles verdaut hat.
Wenn er dann soweit ist, sind aber seine Ansprüche so hoch, das er damit 
nie fertig wird.  Eventuell packt er das ganze dann in der Pension an, 
aber auch
nur wenn er keine Enkeln oder Alzheimer hat...

Aber der TE geht eh schon in die falsche Richtung.
Wenn er schon in einem Forum wie diesem anfängt solche Fragen zu 
stellen, anstatt sich einfach ein Duzend Befehle aufzuschreiben, und 
damit anzufangen.

Jeder der sowas mal gemacht hat, fängt sehr klein an, oder er macht es 
nie fertig.  Am besten mit einer Befehlsbreite von 4 Bit und 16 
elementaren Befehlen, einem Akkumulator, PC und SP.
Dann ist der Spass in einem Monat fertig.  8 Bit erhöht Aufwand dann 
schon
um 2^4 auf 16 Monate.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Eigentlich sogar bei den meisten.

6502 hat NOP als selbstständigem Befehl, wie auch die 6800er und 
68000er. Ebenso Z80, Z8, 8051, 1802, AVR, PIC, SC/MP, 4004, ...

Also so arg selten ist das wahrlich nicht.

: Bearbeitet durch User
von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Andre G. schrieb:
> Man kann ja eine CPU bauen die nur eine Anweisung kennt.
> Sehr einfach in der Realisierung, aber nicht praktisch dafür
> Maschinencode zu schreiben.
>
Etwas mehr als ein Befehl diese möglichst schnell und man kommt in dem 
Bereich was man als RISC bezeichnet. In seinen extremeren Ausprägungen 
zum direkten Programmieren eher ein Krampf durch die vielen 
Einschränkungen. Compiler haben da anfänglich auch mal soviel Code 
erzeugt das die Kisten am Ende wieder langsamer waren als ihre 
CISC-Gegner die zig cycle pro per Instruction benötigen, dafür aber 
recht wenige von diesen.

> Oder man kann eine CPU bauen die tausenden Befehle kennt.
> Aufwändig in der Realisierung, nicht praktisch dafür Maschinencode zu
> schreiben weil sich niemand den ganzen Befehlssatz merken kann.
>
Du vergisst das es nicht nur den Befehlssatz gibst, sondern auch noch 
die ganzen Adressierungsarten je Befehl.

Insgesamt nennt man das dann CISC. Die Hochzeit dieser Technik war wohl 
der 68040 (da wurde aber schon angefangen RISC & CISC zu mischen). Mit 
dem 68060 hat man dieses Konzept dann quasi mit einigen 
Befehlserweiterungen zum Platzen gebracht:-)
- https://de.wikipedia.org/wiki/Motorola_68060

> Soviel zu den beiden Extremen.
> Es geht darum den idealen Kompromiss zu finden.
> Welche Befehle sind wirklich wichtig damit eine CPU "praktisch" in der
> Verwendung ist?
Daran werkeln heutzutage praktisch alle CPU-Designer. Lösung, von jeder 
theoretischen Technik etwas und das im richtigen Mischungsverhältnis, am 
besten noch auf die Bedürfnisse der einsatzüblichen Hochsprache und der 
damit geschriebenen Anwendungen abgestimmt.

Die Programmierbarkeit in Assembler interessiert dabei aber Heutzutage 
nicht mehr die Bohne, es geht vor allem darum das die typischen 
Konstrukte von Hochsprache möglichst effizient übersetzt/abgearbeitet 
werden können.

Altertümlich dazwischen:
AVR, das uralten Museumszeugs war meiner Meinung nach bei schon 
verkrüppelt auf die Welt gekommen. Die taugen höchstens als 
abschreckendes Beispiel wie man es nicht machen sollte (nur noch 
übertroffen von den PIC:-)

Ganz lustig und noch recht überschaubar und vom Befehlssatz her so 
minimalistich, dass man die ganze Zeit über nur kotzen konnte bei den 
ganzen Verrenkungen die man auf Grund der wenigen Befehle und Register 
machen musste.
Das schöne daran ist aber das dieser quasi vollständig intern 
dokumentiert ist und auch schon in diskreter lokik nachgebaut wurde.
- https://c74project.com/
- https://davidmjc.github.io/6502/
- http://www.6502.org/tools/emu/

Von der Handhabbarkeit her, was Assembler anging, waren meiner Meinung 
nach die Z80 eigentlich ganz passabel. Nicht so eingeschränkt wie die 
650x, aber auch nicht so umfangreich wie die 680xx. Von daher einfach 
mal deren Befehlssatz genauer anschauen als Inspiration für was eigenes.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

(prx) A. K. schrieb:
> https://en.wikipedia.org/wiki/One-instruction_set_computer

Das ist aber schon eine gutes Beispiel für:

Andre G. schrieb:
> aber nicht praktisch dafür
> Maschinencode zu schreiben.

Wobei man hier fast schon Philosophieren könnte ab eine Instruktion die 
sich je nach Parametern etwas unterschiedlich verhält überhaupt noch nur 
eine ist:-)

von bork (Gast)


Lesenswert?

Irgend W. schrieb:
> AVR, das uralten Museumszeugs war meiner Meinung nach bei schon
> verkrüppelt auf die Welt gekommen.

Abgesehen von STM8 ist AVR wahrscheinlich die neuste 8 bit Architektur. 
Mit "Museumzeugs" hat das nichts zu tun.

von (prx) A. K. (prx)


Lesenswert?

Irgend W. schrieb:
> AVR, das uralten Museumszeugs

... gehört zu den jüngsten Architekturen für jenen Markt, für den sie 
entwickelt wurde, den 8/16-Bit Mikrocontrollern. Sogar MSP430 ist älter. 
Neuer wäre z.B. MaxQ2000.

: Bearbeitet durch User
von EAF (Gast)


Lesenswert?

Andre G. schrieb:
> Gut, dann werde ich mal mit dem Lesen anfangen ...

Vielleicht ist ja auch der "Befehlssatz" des F18 bzw. GA144 von 
GreenArrays für dich interessant

von Andi (Gast)


Lesenswert?

Andre G. schrieb:
> Es geht hier NICHT um die Sinnhaftigkeit dieses Projekts sondern um die
> Befehle die eine CPU "praktisch" machen.

Welche Instruktionen praktisch sind für eine CPU hängt eigentlich nur 
von der Anwendung ab. Da du anscheinend keine Anwendung im Sinn hast, 
ist der einzig praktische Befehl der NOP.
Solch eine NOP-CPU vereinfacht vieles, man braucht keinen 
Befehlsdekoder, da nur ein Befehl existiert. Dieser Befehl ist fest 
verdrahtet, also kein Instruktionsspeicher. Du hast keine Daten, also 
auch kein Datenspeicher. Für ein NOP brauchst du auch keine ALU.
Was bleibt ist ein Programmzähler und ein Register für den Akku. Am 
Besten hängst du an jeden Ausgang des Befehlszählers und des Akkus eine 
LED. Damit kannst du dann wunderbar sehen wie die Adresse hochzählt und 
der Inhalt des Akku immer gleich bleibt, der NOP funktioniert also.
Ist das sinnlos? Nun:

Andre G. schrieb:
> Es geht hier NICHT um die Sinnhaftigkeit dieses Projekts sondern um die
> Befehle die eine CPU "praktisch" machen.

Andi

Beitrag #7002126 wurde vom Autor gelöscht.
von A. F. (qq_q)


Lesenswert?

MaWin schrieb:
> schliesslich gibt es dafür schon Compiler.

Das wäre für mich ein wichtiges Argument, einen Befehlssatz zu 
implementieren, für den bereits Compiler existieren. Ansonsten musst du 
nämlich dein eigenes Backend schreiben. Der Aufwand ist nicht zu 
unterschätzen.

von Max M. (prokrastinator)


Lesenswert?

Tilo R. schrieb im Beitrag #7002126:
> Es kommt darauf an, was die CPU tun soll!

Naja, praktischen Wert soll sie haben.
Aber wenn wir ehrlich sind kann sie das na nur für den TO, denn niemand 
sonst wird sie je benutzen.
Der TO hat da Begeisterung für und das finde ich gut.
Alles was Menschen tun und dabei ihr Gehirn benutzen statt im 
Fernsehkoma dahinzudämmern, finde ich gut.
Aber niemand sonst wird das je benutzen.
Wenn ich eine geile MCU haben will, die viel Spaß macht und die kaum 
einer kennt, nehme ich einen STM8 und hab Spaß.

Selbst für Josefs BO8 kann ich ein fertiges FPGA Board nehmen.
Andre kann seine CPU ja gerne bauen, aber niemand sonst wird das je 
wieder tun.

Der Nutzen für den TO ist klar.
Er lernt eine CPU zu bauen.
Wenn ich das auch will, muss ich eine eigene bauen.
Wenn ich das nicht will, sondern es mir reicht eine neue, besonders 
spannende MCU zu lernen, dann will ich Doku, Toolchain etc. pp. und da 
ist jede kommerzielle CPU besser, weil ein Einzelkämpfer das einfach 
nicht leisten kann.

Also an den TO:
Mach einfach. Stell Dir nicht so viele Fragen, es geht doch nur um 
Deinen Spaß. Es muss nicht perfekt sein, es muss nicht für 
irgendjemanden taugen ausser für Dich.
Denn das hier ist nur Dein Baby, das mit Dir entsteht und mit Dir 
vergeht.
Josef hat das vergessen, gerade deswegen ist sein Thread so wertvoll.
Man darf sich in dieser Sache nicht verlieren.
Es wird kein Game Changer, niemand wird es lizensieren, niemand ausser 
Dir wird es je bauen. Der Gewinn liegt in dem was Du lernst.
Mach es, schliess es ab, geht weiter und mach was anderes.
Unperfekt und fertig ist so viel mehr wert als so ein dauer BO8 Projekt 
das ein ganzes Leben dauert ohne jemals irgendwohin zu führen.

Worum geht es im Endeffekt?
Um eine CPU die was tun kann um sich zu beweisen das man das bauen kann.
Das reicht dann aber auch.
Niemand von uns ist besser als STM, TI, MC, WCH und niemand von uns ist 
billiger für eine einsetzbare MCU also wars das einfach mit dem Design.
Fertig, nächstes Projekt!

von Andre G. (andgst01)


Lesenswert?

Danke für die vielen mehr oder wenig hilfreichen Antworten!

Ja, ich habe mir selbst widersprochen:
"So eine CPU kann nie mit modernen CPUs mithalten"
"... sollte praktisch sein ..."

Das ist ein Widerspruch.

Ich bin schon sehr froh wenn das Ding am Schluss überhaupt funktioniert.
Wenn es dann etwas umständlich ist dafür Code zu schreiben dann ist das 
eben so.

von Fpgakuechle K. (Gast)


Lesenswert?

Andre G. schrieb:
> Schönen Sonntag Abend,
>
> was sind eigentlich die wichtigsten Befehle die eine CPU beherrschen
> sollte um wirklich praktischen Wert zu haben?

Lies die Klassiker zu dem Thema, ISBN: 978-3528051730

Stichworte "Orthogonal instruction set" und "DLX architecture". Lezteres 
ist  im akademischen Bereich recht beliebt, da findet sich also einiges 
für lau aus Unis:
https://www.techinf.informatik.uni-kiel.de/de/lehre/vorlesungen/digital-systems/Lecture9%20from%202014.pdf


> Soviel zu den beiden Extremen.
> Es geht darum den idealen Kompromiss zu finden.
> Welche Befehle sind wirklich wichtig damit eine CPU "praktisch" in der
> Verwendung ist?

Das ist die uralte Doskusion zwischen CISC und RISC, die würde schon 
längst in der Realität mit der Feststellung: "Die Leistung liegt im 
Befehlssatz nicht allein" entschieden.

https://www.heise.de/ct/artikel/RISC-CISC-MISC-1425837.html

Man nimmt das Beste aus beiden Welten, bspw. die hohe Anzahl von aus 
Speicherblöcken implementierten Registern von CISC und kombiniert das 
mit komplexeren Befehlsatz. Natürlich muss das Speicherinterface schnell 
sein (caches) und die Peripherie darf die CPU nicht stören (DMA, 
Busstandrad AMBA)

von MaWin (Gast)


Lesenswert?

Andi schrieb:
> Ist das sinnlos?

Es ist nicht Turing-vollständig und damit kein Prozessor mehr, also 
keine Lösung zum Problem.

"machen eine CPU 'praktisch'? "

Dein NOP ist bloss noch ein Taktgeber, keine CPU mehr.

von (prx) A. K. (prx)


Lesenswert?

Fpgakuechle K. schrieb:
> Das ist die uralte Doskusion zwischen CISC und RISC, die würde schon
> längst in der Realität mit der Feststellung: "Die Leistung liegt im
> Befehlssatz nicht allein" entschieden.

Wobei sich diese Aussage auf superskalare Out-Of-Order Implementierungen 
bezieht, und diese Arbeit macht niemand in Gatterbauweise, der noch bei 
Verstand ist. Zumal es erklärtermassen nicht um Performance geht.

Im Kontext dieses Threads ist der Unterschied zwischen RISC- und CISC- 
Ansätzen durchaus relevant. Denn da spielt die Grundsatzentscheidung mit 
hinein, ob die Ablaufsteuerung per Microcode erfolgt. Komplex ablaufende 
Befehle sind nur mit Microcode sinnvoll implementierbar, wenn man FPGAs 
ausschliesst. Mit sehr einfach gehaltenen Befehlen tut man sich 
leichter.

: Bearbeitet durch User
von Andre G. (andgst01)


Lesenswert?

(prx) A. K. schrieb:
> Im Kontext dieses Threads ist der Unterschied zwischen RISC- und CISC-
> Ansätzen durchaus relevant. Denn da spielt die Grundsatzentscheidung mit
> hinein, ob die Ablaufsteuerung per Microcode erfolgt. Komplex ablaufende
> Befehle sind nur mit Microcode sinnvoll implementierbar, wenn man FPGAs
> ausschliesst.

Ja, ich habe schon vor Mikrocode zu implementieren.
Das macht die Ausgabe der ganzen Steuersignale viel einfacher.

von (prx) A. K. (prx)


Lesenswert?

Allerdings landete mancher bei einem solchen Projekt recht bald bei 
einem ROM-Grab, weil man versucht ist, nicht nur Microcode über solche 
Bausteine zu implementieren, sondern auch Logikfunktionen, wie ALUs oder 
Dekoder.

von Andre G. (andgst01)


Lesenswert?

(prx) A. K. schrieb:
> Allerdings landete mancher bei einem solchen Projekt recht bald bei
> einem ROM-Grab, weil man versucht ist, nicht nur Microcode über solche
> Bausteine zu implementieren, sondern auch Logikfunktionen, wie ALUs oder
> Dekoder.

Erwischt!

Ja, der Decoder für die Instruktionen mach ich mit einem ROM.
In diesem ist gespeichert bei welcher Microcode-Programm-Adresse der 
Microcode für den jeweiligen Befehl beginnt.
Der Microcode ist ebenfalls in einem ROM und wird mit einem weiteren ROM 
dekodiert (z.B. Micro-Opcode 0x01 heißt S0 auf 1, S2 auf 0 ...)

Bei der ALU wird nichts mit ROMs gemacht, dafür nehme ich ja zwei 
74x181s, die "fehlenden" Funktionen (Komparatoren, bitshift, ...) bastle 
ich selbst dazu.

von (prx) A. K. (prx)


Lesenswert?

Hirnfurz schrieb:
> Der minimalistische Befehlssatz eines PICs wird von den
> ST6 noch deutlich unterboten.

Da wirds knapp, wenn man die 12-Bit PICs betrachtet, die auf den 1650 
von 1977 zurück gehen, der auch nicht gerade überbordend komplex 
ausgestaltet war.

von (prx) A. K. (prx)


Lesenswert?

bork schrieb:
> Referenz: PDP8, CDC1604, MOS6502, Motorola 6800

Die PDP-14 nicht vergessen, und den darauf aufbauenden MC14500B.
Wo wir schon bei Minimalistik sind. ;-)

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

Als Architektonisches Minimum sehe ich eine CPU mit den Registern A,B 
und X für Operanden und Ergebnis der Alu. Weiterhin einen PC.

Für Befehle sehe ich als notwendiges Minimum:

Speicherzugriff:
Für X und Y Befehle zum Laden von Konstanten.
Absolut adressierte Speicher-Lese-Befehle für A und B.
Ein absolut adressierter Speicher-Schreib-Befehl für X.

ALU-Flags: Zero, Carry.
ALU-Befehle:
* Logik: NOT, AND, OR, SHL (mit Carry)
* Rechnen: ADD (mit Carry) (Damit kann man im 2er Komplement alles 
rechnen)
* Vergleichsbefehle kann man sich sparen, wenn man einen 
Subraktionsbefehl baut und danach Zero oder Carry auswertet.

2 Bedingte Sprungbefehle, abhängig von Carry und Zero, mit absolutem 
Sprungziel.

Ok, das macht jetzt vielleicht nicht super viel Spaß damit zu 
programmieren, aber imho sollte man damit alle General-Purpose-Aufgaben 
hinbekommen.
Habe ich was vergessen? Welche Opcodes braucht man zwingend zusätzlich?

von (prx) A. K. (prx)


Lesenswert?

Tilo R. schrieb:
> Logik: NOT, AND, OR, SHL (mit Carry)

Linksshift ist über ADD ersetzbar - aber Rechtsshift?

von Andre G. (andgst01)


Lesenswert?

Tilo R. schrieb:

> Ok, das macht jetzt vielleicht nicht super viel Spaß damit zu
> programmieren, aber imho sollte man damit alle General-Purpose-Aufgaben
> hinbekommen.
> Habe ich was vergessen? Welche Opcodes braucht man zwingend zusätzlich?

Dann habe ich eh mehr als das absolute Minimum.
Danke.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

(prx) A. K. schrieb:
> Tilo R. schrieb:
>> Logik: NOT, AND, OR, SHL (mit Carry)
>
> Linksshift ist über ADD ersetzbar - aber Rechtsshift?
stimmt.
Rechtsshift lässt sich durch links-Shifts und Auswertung des Carry-Flags 
ersetzen.
OK, beide Shifts sind unnötig.

Und zu meiner Compare-Überlegung: man braucht keinen Subtraktionsbefehl 
(Dafür hat man ja das 2er Komplement). Besser wäre es, das MSB auch noch 
als Flag für einen bedingten Sprungbefehl nutzen zu können.

von (prx) A. K. (prx)


Lesenswert?

Der hässliche und extrem archaische Nebeneffekt dieser Architektur ist 
der Zwang zu selbstmodifizierendem Code.

von (prx) A. K. (prx)


Lesenswert?

Tilo R. schrieb:
> Rechtsshift lässt sich durch links-Shifts und Auswertung des Carry-Flags
> ersetzen.

Aber äusserst umständlich. Linksshift/Rotate durch ADD zu ersetzen ist 
hingehen trivial.

Da kannst du dann auch gleich ADD durch Bitlogik ersetzen. ;-)

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Tilo R. schrieb:
> Und zu meiner Compare-Überlegung: man braucht keinen Subtraktionsbefehl

Oder umgekehrt. Subtraktion statt Addition, und Compare direkt damit 
abdecken, mit der Addition übers Komplement.

: Bearbeitet durch User
von Fpgakuechle K. (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Wobei sich diese Aussage auf superskalare Out-Of-Order Implementierungen
> bezieht, und diese Arbeit macht niemand in Gatterbauweise, der noch bei
> Verstand ist.

Bravo, wieder mal eine wichtige Beobachtung (Aufwand der klassischen 
Gatterimplementierung) zu einem Totschlagargument verk[r|n]üppelt.

Die Startpunkt der Diskussion (Befehlssatz) ist falsch gewählt. Ein 
(guter) CPU-Entwurf beginnt beim Datenpfad gelegentlich auch 
CPU-Architektur genannt. Also ein Blockbild von Registerblock, ALU(s), 
Speicher-interface(s) (Harvard|Neumann),  evtl. weitere Alu-Blöcke 
(DSP-Mult, weitere Adressrechnung) und die Mulitplexer/Gates dazwischen.

Erst dann bündelt man die einzigen Steuerleitungen (bspw. Sel der 
Datenpfad-muxer, Alu-modes) zu µ-Opcodes. Ob man diese dann in PROM,LUT 
oder Gatter weider implementiert ist grad egal weil man das inzwischen 
der Hardwarebeschreibungssprachen und CAE dem Computer überlassen kann. 
was diverse FPGA-Implementierungen 25 Jahre nach dem ikonischen µ-Code 
Entwurfes Motorola MC68000 beweisen. Das Prinzip Mikrocode-PROM entstand 
wegen beschränkungen die es heute so nicht mehr gibt.

von Falk B. (falk)


Lesenswert?

(prx) A. K. schrieb:
>> Als Referenz: PDP8, CDC1604, MOS6502, Motorola 6800
>
> Und RCA 1802, wenns etwas abseits des Mainstreams sein darf.

68000 rulez! (Meine erste Assemblerliebe, die vergißt man nie ;-)

von Falk B. (falk)


Lesenswert?

Oft ist es wichtig zu wissen, wie man es sicher NICHT machen sollte!

8bit-CPU: bo8

Lesen auf eigene Gefahr!

von (prx) A. K. (prx)


Lesenswert?

Fpgakuechle K. schrieb:
> was diverse FPGA-Implementierungen 25 Jahre nach dem ikonischen µ-Code
> Entwurfes Motorola MC68000 beweisen.

Nur war seine Prämisse, kein FPGA zu verwenden. Darauf beruht dann auch 
meine Kommentierung. Mit FPGA ändert sich alles.

von m.n. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> und den darauf aufbauenden MC14500B.

Mit seinen 16 Befehlen ein überschaubares, schönes 1-Bit Teil ;-)

von (prx) A. K. (prx)


Lesenswert?

Und unter den 16 Befehlen sind immerhin 2 NOPs. Das illustriert deren 
Unersetzlichkeit? ;-)

: Bearbeitet durch User
von W.S. (Gast)


Lesenswert?

Andre G. schrieb:
> was sind eigentlich die wichtigsten Befehle die eine CPU beherrschen
> sollte um wirklich praktischen Wert zu haben?

Du fängst mit der falschen Frage an.

Am Anfang steht, wie die Maschinenbefehle codiert werden sollen. Da hat 
man zuerst die Wahl, ob das byteweise oder mit breiterem Befehlswort 
stattfinden soll. Die Rasterung auf 8, 16 oder 32 Bit Befehlsbreite ist 
einfach dem erhältlichen Spektrum an Speicherbausteinen geschuldet. Nun 
kann man sich ein Szenario ausdenken, wo es Befehle unterschiedlicher 
Breite gibt. Eigentlich alle älteren CPU's machen das so. Es ist aber 
mit einem höheren Organisationsaufwand verbunden.

Hat man sich auf eine Befehlsbreite festgelegt, dann kommt die Arbeit, 
die Bits nach Funktionsgruppen sinnvoll aufzuteilen. Da wird man schnell 
feststellen, daß man in jeder Funktionsgruppe nur begrenzten Platz hat 
für unterschiedliche Befehle. Man muß also eine Auswahl treffen und den 
verfügbaren Platz im Befehlswort dazu passend aufteilen.

Dann kommt erst die Frage, welche Maschinenbefehle man nötiger braucht 
als andere. So herum.

W.S.

von Thomas W. (dbstw)


Lesenswert?

Moin, -

ein bischen Hilfe, wie man das realisieren kann findest Du in 
Ward/Halstead, Computing Structures, 1990, MIT-Press. Ist latuernich 
akademisch (es ist ein Lehrbuch), aber ab p.660 sind Schaltplaene und 
Mikroprogramming fuer den MAYBE-Computer (das Stueck mit dynamischen 
Speicher kannst Du heute durch ein IC austauschen, Fortschritt). Der 
MAYBE-Computer ist eine einfache Register-Maschine (ein 6116 als 
Register-File!)

Das Buechlein findest Du entweder in einer Bibliothek, Archive.org oder 
bei Genesis. Wenn Du es gar nicht findest, kann ich Dir die Seiten mit 
den Schaltplaenen mailen.

Gruesse

Th.

von Andre G. (andgst01)


Lesenswert?

Ja, die grundsätzliche "Architektur" steht bereits fest:
Harvard Architektur, 16 bit Adressbus, 8 bit Datenbus, 16 bit 
Program-Counter, 16 "Arbietsregister" die als A und/oder B Eingänge für 
die ALU verwendet werden können.

Die ALU besteht wie schon gesagt aus zwei 74x181s, einem 8 bit 
Komparator (A<B, A=B, A>B) und einer Schaltung die linksschieben und 
rechtsschieben kann, mit "Nachschieben" einer 0 oder 1.

Das Statusregister der ALU enthält folgende Informationen:
Bit 0: A==B
Bit 1: A<B
Bit 2: Z == 0  (Z ist das Ausgangs-Register der ALU)
Bit3: Overflow
Bit4: Underflow

Sprungbefehle würde ich folgende implementieren:
JUMP IF A==B
JUMP IF A<B
JUMP IF A>B
JUMP IF 0
JUMP

Register-Zugriffsbefehle habe ich vorerst folgende:
MOVE
Verschiebt Inhalt von einem Register in ein anderes, löscht das 
Ursprungsregister.
COPY
Kopiert Inhalt von einem Register in ein anderes.
LOAD
Lädt einen Wert in ein Register.
USEA
Verwendet ein Arbeitsregister als "A" Eingang für die ALU
USEB
Verwendet ein Arbeitsregister als "B" Eingang für die ALU
UWEZ
Verwendet ein Arbeitsregister als "Ausgangsregister" für die ALU


Die Breite der Befehle steht ebenfalls fest (8 bit, also 256 Befehle 
maximal, das müsste mehr als ausreichen).
Manche Befehle bestehen aus mehreren Bytes, das wird der Befehlsdekoder 
dann entsprechend handhaben.
Zum Beispiel ein MOVE Befehl hat 4 Bytes "Parameter", zwei Bytes die das 
Ursprungsregister festlegen, zwei Bytes die das Zielregister festlegen.

von Zeno (Gast)


Angehängte Dateien:

Lesenswert?

@TO
Da gibt es einige interessante Relaisrechnerprojekte. Schau Dir dort mal 
an was die an Befefehlen so implementiert haben. Bei so einem 
Relaisrechner sind ja praktisch keine fertigen Bausteine vorhanden die 
bestimmte Operationen ausführen können, mit anderen Worten da geht alles 
zu Fuß. Da wird man den Befehlssatz erst mal auf das notwendigste 
beschränken.
Hier mal ein paar Links wo Du Dich informieren kannst:
- http://www.foerderverein-tsd.de/index.php?id=23
- http://www.relaiscomputer.de
- 
http://rechenwerk.halle.it/usr/digital-ag/projekte/technisch/Relaisrechner/
Schau Dir das einfach mal an, was man dort an Befehlen implementiert 
hat. Ich denke mal das ist das Minimum was man so braucht.
Hab Dir mal noch ne Beschreibung der OPREMA (Optikrechenmaschine, 
entwickelt 1955) angehangen. Das Ding wurde wirklich produktiv zur 
Berechnung von Optikbauteilen eingesetzt. Mit anderen Worten der dort 
implementierte Befehlssatz ist durchaus für anspruchsvolle Dinge 
geeignet.

von Zeno (Gast)


Lesenswert?

Uups gerade gesehen der Anhang ist riesig - sorry! Viellleicht kann ein 
Mod den noch schrumpfen.

von Falk B. (falk)


Lesenswert?

Andre G. schrieb:
> Ja, die grundsätzliche "Architektur" steht bereits fest:
> Harvard Architektur, 16 bit Adressbus, 8 bit Datenbus, 16 bit
> Program-Counter, 16 "Arbietsregister" die als A und/oder B Eingänge für
> die ALU verwendet werden können.

Ist es wirklich sinnvoll, einen AVR nachzubauen? ;-)

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Andre G. schrieb:
> Ja, die grundsätzliche "Architektur" steht bereits fest:

Juhuu, das ist das Ende von Linu^h^h Bo8!!!einsElf11!!

SCNR,
WK

von Andre G. (andgst01)


Lesenswert?

Dergute W. schrieb:

> das Ende von Linu^h^h Bo8!!!einsElf11!!


Was soll das heißen?

: Bearbeitet durch User
von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

Obwohl du kein FPGA verwenden willst:

Ich habe schon verschiedene CPU mit "MAX PLUS + 2" Designet.
Das tue ich dann wenn es für eine ganz spezielle Anwendung ist.
Als Beispiel als Controller für Späne-Förderer bei CNC.
mit Synchromotor Kontroller mit Pulscoder.
Da habe ich dann jeweils der Befehlssatz den Umständen angepasst.
Meist waren diese an den 6502 und Z80 als Gemisch von Instruktionen 
der beiden & was halt grad Praktisch war.

So ergab sich ein IdealµC, der mit wenig Instruktionen dass tat was er 
soll.

: Bearbeitet durch User
von Alois (Gast)


Lesenswert?

Irgend W. schrieb:
> Die Programmierbarkeit in Assembler interessiert dabei aber Heutzutage
> nicht mehr die Bohne, es geht vor allem darum das die typischen
> Konstrukte von Hochsprache möglichst effizient übersetzt/abgearbeitet
> werden können.

Das habe ich grob noch so in Erinnerung:

Bei der Vorstellung der AVR Architektur (um 1997, INELTEC hatte dazu 
eingeladen) wurde vermittelt, dass für'n AVR zuerst der C-Compiler 
fertig war, und dann erst die Hardware gegossen wurde.

So viel zu "Heutzutage" ...

von (prx) A. K. (prx)


Lesenswert?

Alois schrieb:
> Bei der Vorstellung der AVR Architektur (um 1997, INELTEC hatte dazu
> eingeladen) wurde vermittelt, dass für'n AVR zuerst der C-Compiler
> fertig war, und dann erst die Hardware gegossen wurde.

The AVR Microcontroller and C Compiler Co-Design
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.1447&rep=rep1&type=pdf

"To improve this feature even more, the development of the C compiler 
was started before the architecture and the instruction set were 
completed. By allowing professional compiler developers at IAR Systems 
in Sweden to comment on the architecture and instruction set, we were 
able to make a microcontroller very well suited for C compiler generated 
code."

IAR hat dabei wohl auch sorgfältig darauf geachtet, dass die Konkurrenz 
es nicht leicht haben wird. IAR verwendet zwei Stacks, aber nimmt man 
nur einen, wie GCC, braucht man eine atomare Manipulation des 
Stackpointers. Die fehlt bis heute.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

> Welche Befehle machen eine CPU "praktisch"?
HCF

von Fpgakuechle K. (Gast)


Lesenswert?

Alois schrieb:
> Irgend W. schrieb:
>> Die Programmierbarkeit in Assembler interessiert dabei aber Heutzutage
>> nicht mehr die Bohne,
> Bei der Vorstellung der AVR Architektur (um 1997, INELTEC hatte dazu
> eingeladen) wurde vermittelt, dass für'n AVR zuerst der C-Compiler
> fertig war, und dann erst die Hardware gegossen wurde.
>
> So viel zu "Heutzutage" ...

Abgesehenm das 'entweder C oder Assembler' ohnehin Quatsch ist, die 
Hochsprachenauslegung von CPU-Architekturen reicht locker zwei weitere 
Jahrzehnte zurück, das war schon beim MC68000 Thema. Wer den 
Henessey/Patterson kennt, kann auch die Hardwareteile benennen, die zur 
Hochsprachenunterstützung vorteilhaft sind (POP,PUSHD, 
pointerarithmetik, Stack-verwaltung, Registerwindowing (bspw. Sparc)). C 
hat ja auch ein halbes Jahrhundert auf dem Buckel.

Später wurden hinsichtlich Unterstützung von Multitask-OS Mechanismen 
für den Speicherschutz und Memory managment eingebaut (priorities) Aber 
damit kommen die wenigsten Programmierheinis in Berührung.

von Andre G. (andgst01)


Lesenswert?

Ben B. schrieb:
>> Welche Befehle machen eine CPU "praktisch"?
> HCF

Ja, das könnte ich spaßhalber einbauen ...
Ein Tantal-Elko der mit Überpsnnung betrieben wird wenn dieser Befehl 
dekodiert wird ...
Vielleicht auf einem externen Board ...

;-)

von Fpgakuechle K. (Gast)


Angehängte Dateien:

Lesenswert?

Da ein Auszug aus ISBN: 3-89362-080-X  bezüglich MC68000 
(Entwicklungsstart 1977) und Hochsprache. Interessanterweise wird hier 
der Schwerpunkt auf modulare und positionsunabhängige Programmierung 
gelegt.

von (prx) A. K. (prx)


Lesenswert?

Fpgakuechle K. schrieb:
> Abgesehenm das 'entweder C oder Assembler' ohnehin Quatsch ist, die
> Hochsprachenauslegung von CPU-Architekturen reicht locker zwei weitere
> Jahrzehnte zurück, das war schon beim MC68000 Thema.

Wobei das unterschiedliche Ergebnisse zur Folge hat, je nachdem, auf 
welche Sprache(n) man den Fokus legt.

Sprachen wie C etc arbeiten wenns irgend geht mit einem Activation 
Record auf dem Stack, und auch sonst gerne mit Daten, die relativ zu 
einem Pointer adressiert werden. Was bei 16-Bittern mit Adressierung 
über mehr als 16 Bits  auf eine Adressierung mit einem breiten 
Adressregister und einer schmaleren konstanten Distanz rausläuft. 
Motorola trug dem Rechnung und implementierte genau das.

Zilog hingegen wird bei der Z8000 eher FORTRAN im Auge gehabt haben, wo 
Daten vorherrschend an einer festen Adresse liegen, ggf. plus variabler 
Distanz bei Arrays, oder die als Parameter indirekt adressiert werden. 
Folglich gibts in jedem speicherbezogenen Befehl neben der indirekten 
Adressierung für Parameter eine Addressierungsart mit breiter 
Adresskonstante im Befehl und schmaler Distanz im Register. 
Pointer-relativ wie oben gibts hingegen nur beim Move-Befehl (LD). In 
C/PASCAL ist das etwas unglücklich.

von (prx) A. K. (prx)


Lesenswert?

Fpgakuechle K. schrieb:
> Interessanterweise wird hier
> der Schwerpunkt auf modulare und positionsunabhängige Programmierung
> gelegt.

Die hinter dem Befehlssatz stehende Philosophie wurde von Motorola 
ziemlich konsequent durchgezogen. An sich wäre es beim Befehlssatz der 
68000 problemlos möglich gewesen, nicht nur PC-relativ zu laden, sondern 
auch so zu speichern. Aber Daten sollten im Codebereich nichts verloren 
haben und tatsächlich kann man so nur laden, die speichernde Variante 
wurde vorsätzlich unterbunden. Bei jedem Befehl bzw Operand wurde darauf 
geachtet, welche Adressierungsart politisch korrekt ist und die falschen 
Varianten wurden unterbunden.

Später freilich wendete sich das Blatt, und man erkannte, dass 
PC-relative Adressierung von Daten klar besser ist als global statische. 
Wenn man das Gesamtpaket aus Code und Daten relativ zum PC adressieren 
kann, ist man heutzutage besser dran, weil die Ladeadresse von Modulen 
variabel geworden ist. Für Motorola kam diese Erkenntnis zu spät, aber 
AMD trug dem Rechnung, indem sie bei der 64-Bit Erweiterung von x86 aus 
der statischen Adressierungsart in speicherbezogenen Befehlen eine 
PC-relative machten. Über die man auch speichern kann und soll. O 
tempora o mores.

: Bearbeitet durch User
von Andre G. (andgst01)


Lesenswert?

An Interrupts habe ich noch gar nicht gedacht ...

von Alois (Gast)


Lesenswert?

(prx) A. K. schrieb:
>
> The AVR Microcontroller and C Compiler Co-Design
> 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.63.1447&rep=rep1&type=pdf

Danke für den Link - zu 100% hatte ich das nach 25 Jahren nicht mehr in 
Erinnerung. Im zitierten Paper stehen eine Menge Tipps für den TO, 
worauf man u.A. "so achten könnte" ...

Der AVR mag heute 'outdated' sein, ich halte ihn (zumindest die Teile 
aus der Vor-Microchip-Ära) aber immer noch für einen schnuckeligen, 
geradlinig konstruiertern Controller.

von (prx) A. K. (prx)


Lesenswert?

Andre G. schrieb:
> An Interrupts habe ich noch gar nicht gedacht ...

Da bist du nicht allein. National Semiconductor muss das noch später 
eingefallen sein, denn beim SC/MP I/II haben Interrupts eine äusserst 
hässliche Nebenwirkung für die Programmierung: Das Ding adressiert alle 
Daten über 4 Adressregister, eines davon ist der PC, und wenn man 
Interrupts zulässt, ist ein weiteres davon für die normale 
Programmierung unbenutzbar, weil darin die Returnadresse vom Interrupt 
landet.

Allerdings war das nur konsequent, denn Unterprogrammaufrufe hatte man 
auch nicht so wirklich auf dem Radar gehabt (Hint ;-), die waren bizarr 
umständlich. Auf die Idee eines Stacks kam man erst im SC/MP III.

Auch ARM hatte an diesem Punkt ins Klo gegriffen. An Interrupts hatte 
man zwar früh gedacht, nicht aber an verschachtelte. Im klassischen 
32-Bit ARM Modus ist dafür ein ziemlich übler Hack erforderlich.

: Bearbeitet durch User
von udok (Gast)


Lesenswert?

Andre G. schrieb:
> Der Grund warum ich das frage ist weil ich derzeit an einer
> halb-diskreten 8 bit CPU arbeite.
> Mit "halb-diskret" meine ich "aus 74er und 4000er Logik-ICs, aber auch
> mit (E)EPROMs, SRAMS.

Der TE will was mit 74'er Logik-ICs bauen...  der muss sich seine Hörner 
erst abstossen.
Da ist es nicht zielführend, eine einzige Überlegung auf Hochsprachen
zu verschwenden.
Wobei 999/1000 solcher überambitionierter und sinnloser Projekte nie 
über das Quatschstadium hinausgehen, und Quatschen ja auch schön ist.

Bei einem 16 Bit breiten Bus in diskreter Logik führt das Übersprechen 
auf Leitungen schnell zu massiven Problemen, die man praktisch nicht 
debuggen kann.  Dazu kommen Latch-Up Probleme, wenn die Module nicht 
alle
gleichzeitig Strom haben.
Mein Tipp: Nimm nicht 74xxx, oder das elendslangsame 4000 (gibts die 
überhaupt noch?), sondern eine moderne und gutmütige ALVC Logikfamilie.

Hier mit theoretischen Überlegungen zum Befehlssatz zu starten ist na ja 
Zeitverschwendung. Das was dabei rauskommt will keiner zusammenlöten.
Der Befehlssatz muss so einfach wie nur möglich sein, dann kommt lange 
nichts mehr.

Selbst ein 4 Bit Intel 4004 liegt laut Wikipedia bei 2200 Transistoren 
(ca. 550 Gatter).
Ein 8086 liegt bei 29k Transistoren (ca. 4000 Gatter). Ein AVR liegt bei 
48k Transistoren (ca 12000 Gatter).  Wie viele Gatter willst du 
zusammenlöten?

von Andre G. (andgst01)


Lesenswert?

udok schrieb:
> Da ist es nicht zielführend, eine einzige Überlegung auf Hochsprachen
> zu verschwenden.

Genau.

udok schrieb:
> Mein Tipp: Nimm nicht 74xxx, oder das elendslangsame 4000 (gibts die
> überhaupt noch?), sondern eine moderne und gutmütige ALVC Logikfamilie.

Ich bleibe lieber bei meinen 5V und bei meinen halbwegs verfügbaren und 
bedrahteten 74er und 4000er ICs.

Da ich EPROMs als Look-Up-Table RAMs verwende wird das eh nicht 
besonders schnell.

udok schrieb:
> Wie viele Gatter willst du
> zusammenlöten?

Gatter-Anzahl != Anzahl der Logik ICs.
Ich verwende ja zum Beispiel 74x181s als Hauptteil der ALU oder CD4063s 
als Komparatoren, das sind zwar nur ein einzelne ICs aber die "Anzahl 
der Gatter" wird dadurch um einiges erhöht.
Wie gesagt, ich mache das "halb diskret".
Wenn ich das aus einzelnen UND, ODER und Inverter-Gattern oder gar aus 
einzelnen Transistoren aufbauen würde dann wäre dass ein Endlosprojekt, 
ja.

von Thomas W. (dbstw)


Lesenswert?

Moin, -

ich sehe nicht das so kritisch: Seine A-CPU (Andres CPU) wird sicherlich 
keine optimierte CPU im Sinne von Geschwindigkeit oder Speichergroesse 
sein, aber acht Bitter lassen sich mit Hobbymitteln schon gut 
realisieren. Und wenn er die Micro-Programme mit Eproms loesen kann: 
Alles machbar (fuer den Hobbyisten realisieren).

Die technischen Probleme lassen sich bei einem Takt von 100kHz bestimmt 
in Griff bekommen.

Ich hoffe er findet irgendwo ein paar Gleichsinnte, denn hier bei 
ucontroller wird es nicht so viele Enthusiasten geben. Eventuell bei 
https://www.homebrewcpuring.org/ findet er andere Mitstreiter.

Gruesse

Th.

von Stefan F. (stefanus)


Lesenswert?

Arbeiten eigentlich alle (nicht historischen) CPUs intern mit Mikrocode?

von Thomas W. (dbstw)


Lesenswert?

Andre G. schrieb:
> An Interrupts habe ich noch gar nicht gedacht ...

Tja, nochmal Ward/Halstead, Computing Structures, 1990, MIT-Press: 
Interrupts  werden nicht behandelt, die Autoren schlagen als Loesung ein 
zusaetzlicher Flag im Status mitzunehmen und dann bei jedem M1-Zyklus 
abzufragen (da kann man latuernich auch ein FlipFlop abfragen ob 
interrupt enabled/disabled sind).

Gruesse

Th.

von Thomas W. (dbstw)


Lesenswert?

Stefan ⛄ F. schrieb:
> Arbeiten eigentlich alle (nicht historischen) CPUs intern mit Mikrocode?

Seit 1955 ja. Allerdings ist der Microcode meistens nicht modifizierbar 
(wie es z.B. bei Intel/AMD oder bei einer VAX ist).

Gruesse

Th.

von udok (Gast)


Lesenswert?

Andre G. schrieb:
>> Wie viele Gatter willst du
>> zusammenlöten?
>
> Gatter-Anzahl != Anzahl der Logik ICs.

Trotzdem braucht jedes Gatter ca. 3 Pins, und die wollen auch gelötet 
werden.
Aber ich will nicht zu negativ rüberkommen, und wünsch dir gutes 
Gelingen.

von (prx) A. K. (prx)


Lesenswert?

Stefan ⛄ F. schrieb:
> Arbeiten eigentlich alle (nicht historischen) CPUs intern mit Mikrocode?

Nein. RISC Architekturen waren angetreten, Microcode unnötig zu machen. 
ARM tut das nicht, MIPS nicht, IBMs Power nur anfangs.

In Highend-Implementierungen davon findet man heute auch eine Zerlegung 
mancher Befehle in mehrere Microops, aber nicht per ROM und Sequencer, 
sondern direkt aus den Decodern. Das als mikroprogrammierte 
Implementierung zu bezeichnen wäre etwas grenzwertig.

Thomas W. schrieb:
> Seit 1955 ja.

Das mag das Datum gewesen sein, ab dem man mit Microcode anfing. Das 
bedeutet aber nicht, dass man es seit damals immer so tat. Gerade bei 
den 8-Bittern war das nicht üblich. Auch Zilogs Z8000 nicht, was zwar 
Transistoren sparte, aber ein Grund für die erhebliche Verzögerung war.

: Bearbeitet durch User
Beitrag #7002531 wurde vom Autor gelöscht.
von Andre G. (andgst01)


Lesenswert?

udok schrieb:
> Trotzdem braucht jedes Gatter ca. 3 Pins

Was?

Ich habe gesagt ich baue das Ding aus 74er und 400er ICS, nicht aus 
einzelnen Gattern.
Also wenn ich einen Komparator brauche nehme ich einen CD4063.
Ich baue keinen Komparator aus einzelnen UND und ODER Gattern.

von (prx) A. K. (prx)


Lesenswert?

udok schrieb:
> Trotzdem braucht jedes Gatter ca. 3 Pins, und die wollen auch gelötet
> werden.

Nicht jedes verbaute Gatter hat ca 3 Pins, weil in MSI/LSI-Logik viele 
Gatter schon vom IC-Hersteller intern "verlötet" werden.

Am 32x8 Registersatz der AVR-Cores dürften einige Tausend Transistoren 
beteiligt sein. Wenn man den nicht als Schrank von Flipflops und 
Einzelgattern implementiert, sondern naheliegenderweise als RAM, haut 
das mit der Zählung von Transistoren und Gattern auch nicht hin.

von Dieter R. (drei)


Lesenswert?

(prx) A. K. schrieb:
> Stefan ⛄ F. schrieb:
>> Arbeiten eigentlich alle (nicht historischen) CPUs intern mit Mikrocode?
>
> Nein. RISC Architekturen waren angetreten, Microcode unnötig zu machen.
> ARM tut das nicht, MIPS nicht, IBMs Power nur anfangs.
>
Hatte die PDP-8 Mikrocode? Ich finde in Foren die Behauptung, dass das 
so war. Meiner Erinnerung nach hatte die aber einen festen 
4-State-Zyklus (Fetch-Decode-Execute-Store), wovon eben einer der States 
die Instruktionsdecodierung war, fest verdrahtet in Logik. Ich sehe da 
keinen Platz für Mikrocode.

von (prx) A. K. (prx)


Lesenswert?

Dieter R. schrieb:
> Hatte die PDP-8 Mikrocode?

Laut Wikipedia schon, aber abhängig vom Befehl. Siehe
https://en.wikipedia.org/wiki/PDP-8#Basic_instructions
OPR – microcoded OPeRations (see below).

Aber "This did not mean what the word means today (that a lower-level 
program fetched and interpreted the OPR instruction),", daher evtl die 
Verwirrung. Das kann man in diesem Sinn also vielleicht auch als "Nein, 
aber DEC nannte das so" bezeichnen.

Wobei es die eine PDP-8 Implementierung nicht gab, sondern über die 
Jahre diverse Implementierungen, die auch nicht durchweg von DEC waren.

: Bearbeitet durch User
von Fpgakuechle K. (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Am 32x8 Registersatz der AVR-Cores dürften einige Tausend Transistoren
> beteiligt sein.

Für ein Register braucht es 6 Transistoren, also insgesamt 6*8*32 = 
1536.

Einen Schaltplan auf Transistorebene für den intel 4004 (16x8bit 
register) findet man dort: 
http://alumni.media.mit.edu/~mcnerney/2009-4004/i4004-schematic.gif 
Insgesamt werkelten in diesem ca. 2300 Transen.

von Dieter R. (drei)


Lesenswert?

(prx) A. K. schrieb:
> Dieter R. schrieb:
>> Hatte die PDP-8 Mikrocode?
>
> Laut Wikipedia schon, aber abhängig vom Befehl. Siehe
> https://en.wikipedia.org/wiki/PDP-8#Basic_instructions
> OPR – microcoded OPeRations (see below).
>
Aha, danke. So weit ging meine Erinnerung nicht mehr. Nach dem Beispiel 
aus Wikipedia:

For example, combining CLA (CLear Accumulator), CLL (CLear Link), and 
IAC (Increment ACcumulator) first clears the AC and Link, then 
increments the accumulator, leaving it set to 1. Adding RAL to the mix 
(so CLA CLL IAC RAL) causes the accumulator to be cleared, incremented, 
then rotated left, leaving it set to 2. In this way, small integer 
constants were placed in the accumulator with a single instruction.

Ist wohl nicht wirklich Mikrocode, aber die Ausführung von mehreren 
Operationen nacheinander, codiert in einer Instruktion. Also 
Fetch-Decode-Execute-Execute ... o. ä.

von (prx) A. K. (prx)


Lesenswert?

Fpgakuechle K. schrieb:
> Für ein Register braucht es 6 Transistoren, also insgesamt 6*8*32 =
> 1536.

8 Transistoren weil mindestens dual-ported, plus Dekoder.

: Bearbeitet durch User
von Josef G. (Gast)


Lesenswert?

Andre G. schrieb:
> aber auch mit (E)EPROMs

Der hat es glaub ich auch so gemacht:
http://www.mycpu.eu/

von W.S. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Allerdings war das nur konsequent, denn Unterprogrammaufrufe hatte man
> auch nicht so wirklich auf dem Radar gehabt (Hint ;-), die waren bizarr
> umständlich.

Und?
Als ich mit dem Programmieren anfing, wurde die Returnadresse in die 
Startadresse der aufgerufenen Routine gepackt. Die mußte also 
freigehalten werden und der Maschinencode kam erst danach.

OK, das war ein alter diskret aufgebauter Rechner mit Kernspeicher. 
Damals gab es eine ganze Reihe von Plattform-Versuchen. Das war wohl so 
ähnlich wie in der Prähistorie die Saurier-Zeit. Sind inzwischen alle 
ausgestorben.

Allerdings gab es da einen Nachzügler von Maxim. WIMRE hieß der MAXQ2000 
oder so ähnlich. War auch ne abenteuerliche Konstruktion.

W.S.

von FS (Gast)


Lesenswert?

Ein Kommentar schrieb:
> Eine CPU mit einem Befehlssatz, in dem sich die Rechteverwaltung nicht
> umgehen lässt - das wäre doch mal ein interessantes Projekt.

Interessant ja, aber ein sehr zweischneidiges Schwert. In einer freien 
und ethisch vernünftigen Welt wäre die Lösung dieser Frage sicherlich 
kein Problem. In so einer leben wir aber nicht. Wir leben in einer Welt, 
die und deren technologischer Fortschritt zunehmend von 
Konzerninteressen diktiert wird. Es wird gebaut, entsprechend genutzt 
und eingehegt, was Profit erzeugt und eine Herrscharr von ethisch 
unbedarften Ingenieuren ermöglicht dies. Das sieht man auch an dem ein 
oder anderen historischen Beispiel belegt, das empirisch zur Schau 
stellt, dass sich nicht zwangsläufig die beste Lösung durchsetzt.

Darum sehe ich beispielsweise eine CPU, deren Rechteverwaltung sich 
nicht umgehen lässt, als hochproblematisch an. Denn wenn man das 
weiterdenkt, könnte man ja auf die Idee kommen, eine CPU insoweit zu 
beschränken, dass nur noch Programme oder Algorithmen darauf ausgeführt 
werden können, die als "sicher" gelten oder entsprechend signiert 
wurden. Und wer definiert dann "sicher" oder stellt die Lizenzen dafür 
aus? Ein am gemeinwohl orientierter Staat (den wir heute schon nicht 
haben) oder eine Konzernwirtschaft, die sich komplett aus jeglicher 
sozialen Verantwortung verabschiedet hat? Ein Beispiel in der Art aus 
der Realität, dass in diese Richtung geht, fällt mir dazu ein: 
UEFI/SecureBoot.

Das Problem mit den Menschen ist: sie haben geniale Ideen. Aber ebenso 
primitiv ist leider ihr Drang, diese schlicht zu ihrem Eigennutz 
(Profit) für ihre Partikularinteressen (["Markt"]Macht/Kontrolle) 
umzusetzen.

Das geht jetzt leider etwas am Thema vorbei, aber das größte Manko in 
der Informationstechnologie (und damit verbunden die gesamte 
Elektrotechnik) ist dementsprechend das Fehlen und daraus folgend die 
Durchsetzung eines Ethikkodexes (der u.a. oben gesagtes oder 
beispielsweise die Entwicklung, Mitwirkung und Umsetzung von Technologie 
zum Zwecke einer Waffe untersagen und unter Strafe stellen könnte).

von (prx) A. K. (prx)


Lesenswert?

W.S. schrieb:
> Als ich mit dem Programmieren anfing, wurde die Returnadresse in die
> Startadresse der aufgerufenen Routine gepackt.

Vorzugsweise als direktem Sprungbefehl. Ja, kenne ich.

Aber auch das wäre nicht einfach gewesen. Schau dir den Befehlssatz vom 
SC/MP INS8060 an und suche nach einem geeigneten Sprungbefehl. Auch 
indirekt über zu ladende Adresse war das umständlich. An dem Teil war 
fast alles umständlich, was man von 6502 oder 8080 kennt.

Das Ding besass keine direkten Sprungbefehle, sondern wie bei den Daten 
konnte nur relativ zu einem Register adressiert werden, mit 8-Bit 
Displacement. Ich hatte einstmals ein 2kB BASIC disassembliert. Sprünge 
hoppelten darin über etliche Zwischenstationen in Abständen von maximal 
127 Bytes ins Ziel.

Alternative:
  A = low(destination)
  A <=> Px.low
  A = high(destination)
  A <=> Px.high
  PC <=> Px

: Bearbeitet durch User
von H.Joachim S. (crazyhorse)


Lesenswert?

Der gute Andre hat ja ein Talent hier riesige Diskussionen zu entfachen, 
Respekt!
Auch wenn mich CPUs immer interessiert haben, ich hatte niemals den 
Drang es selbst anders/besser machen zu wollen. Ein Volladierer (8bit) 
aus Standardgattern war das höchste meiner Gefühle.

von Falk B. (falk)


Lesenswert?

Ich hab vor über 20 Jahren (ufff) mal mit dem Picoblaze ein paar Sachen 
gemacht und dabei auch die Struktur studiert. War nett. Aber mehr nicht. 
Den Drang, sowas mit old school Logikbauteilen nachzubauen, erst recht 
mit so vielen Registern etc. hatte ich nie.

PiBla

von Andre G. (andgst01)


Lesenswert?

H.Joachim S. schrieb:
> Der gute Andre hat ja ein Talent hier riesige Diskussionen zu entfachen,
> Respekt!

Naja, meine Interessen sind eben etwas "unkonventionell" ...
Ich bemühe mich eh möglichst wenig solcher Fragen zu stellen weil ich 
den Großteil der (negaticen) Antworten schon kenne ...
Aber diesmal waren zu meiner Überraschung ein paar sehr interessante 
Literaturempfehlungen dabei!

H.Joachim S. schrieb:
> es selbst anders/besser machen zu wollen

Ich will es nicht "anders machen" nur um es anders zu machen.
Und von "besser" kann auch nicht die Rede sein.
Einfacher ist es sicher auch nicht.
"Für mich verständlich und nachvollziehbar" wäre vielleicht passend.

von S. R. (svenska)


Lesenswert?

Andre G. schrieb:
> An Interrupts habe ich noch gar nicht gedacht ...

Die meisten CP/M-Computer kommen ohne Interrupts aus,
obwohl der i8080 damit umgehen kann. Aber nicht gut.
Mein CPU-Emulator lässt die deswegen einfach weg.

FS schrieb:
> Denn wenn man das weiterdenkt, könnte man ja auf die Idee
> kommen, eine CPU insoweit zu beschränken, dass nur noch
> Programme oder Algorithmen darauf ausgeführt werden können,
> die als "sicher" gelten oder entsprechend signiert wurden.

Wo ist die Neuheit? Das ist bereits schon länger so,
z.B. Intel ME, ARM TrustZone oder sowas. Nur eben nicht
überall eingeschaltet und erzwungen. Außer manchmal.

von michael_ (Gast)


Lesenswert?

S. R. schrieb:
> Die meisten CP/M-Computer kommen ohne Interrupts aus,
> obwohl der i8080 damit umgehen kann.

Hä, Daisi-Chain sagt dir nix?

Aber bei den Fragen von "andgst01" rollen sich mir die Zehennägel hoch!

von (prx) A. K. (prx)


Lesenswert?

michael_ schrieb:
> Daisi-Chain sagt dir nix?

Verwechselst du gerade 8080 mit Z80? Die Interrupts von Intels 8080 
funktionierten ganz grob so wie die des IBM-PC, denn dessen 
Interrupt-Controller entstammt der 8080/8085 Schiene. Daisy-Chaining 
brachte erst Zilog ein.

Wenn S.R. darauf hinweist, dass CP/M oft ohne Interrupts auskam, dann 
heisst das nicht, dass die Hardware keine kannte, sondern dass die 
Geräte diese Möglichkeit oft nicht nutzten. CP/M selbst brauchte keine.

: Bearbeitet durch User
von michael_ (Gast)


Lesenswert?

Klar doch, CP/M ist was für Weicheier und braucht auch keine Interrupt.
Für bissl Text, Rechnung oder Datenbank braucht es auch heute die nicht.

von (prx) A. K. (prx)


Lesenswert?

FS schrieb:
> könnte man ja auf die Idee kommen, eine CPU insoweit zu
> beschränken, dass nur noch Programme oder Algorithmen darauf ausgeführt
> werden können, die als "sicher" gelten oder entsprechend signiert
> wurden.

Im Mobilbereich ist das völlig normal. Wobei das freilich eher eine 
Funktion des Betriebssystems und Boot-Verfahrens als des Prozessors ist. 
Der Prozessorkomplex bietet ggf Hilfestellung.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

michael_ schrieb:
> Klar doch, CP/M ist was für Weicheier und braucht auch keine Interrupt.
> Für bissl Text, Rechnung oder Datenbank braucht es auch heute die nicht.

Heutige Betriebssysteme wie Windows, Linux oder Apples Oevres setzen 
aufgrund ihres Arbeitsprinzips zwingend Interrupts voraus. Selbst wenn 
überhaupt keine Anwendungen drauf laufen.

Das hat auch nichts mit weichen oder harten Eiern zu tun, sondern mit 
dem inneren Aufbau der Betriebssysteme.

: Bearbeitet durch User
von Stefan F. (stefanus)


Lesenswert?

FS schrieb:
> Wir leben in einer Welt, die und deren technologischer
> Fortschritt zunehmend von Konzerninteressen diktiert wird.

Auch die Regierungen wollen da einem Wörtchen mitreden. Während die 
einen starke Verschlüsselung fordern, fordern die anderen Hintertüren um 
sie zu unterwandern.

> Das geht jetzt leider etwas am Thema vorbei

Sollten wir aber auch mal drüber diskutieren, finde ich.

: Bearbeitet durch User
von rbx (Gast)


Lesenswert?

Mir fällt so ein:

Add Carry

Multiply Add:

https://de.wikipedia.org/wiki/Multiply-Accumulate

oder Barrel-Shifter:

https://de.wikipedia.org/wiki/Barrel-Shifter

Außerdem könnte man den Umgang mit DSPs überlegen, vor allem bei so 
Dingern wie AVR.

Und: wie siehts aus mit Komprimiergeschichten beschleunigen?

Je nach Speicher und Tabellen(rechen) - Konstruktion sind auch 
Speichernavigations-Strategien zu überlegen.

Was gibt es noch? Parallel-Rechnereien - wie gut kann man die 
Hardwareseitig unterstützen? Sowas wie einen Kopierbefehl über mehrere 
Register-Bahnen bzw.
Der Hintergrund dieser Überlegung ist, dass sich gezeigt hatte, dass es 
z.B. sehr förderlich für den Leistungs-Out (im Sinne von Schnell) eines 
Cell-Prozessors ist, diesen in Assembler zu programmieren.

https://de.wikipedia.org/wiki/Cell_(Prozessor)

von Hugo H. (hugo_hu)


Lesenswert?

Andre G. schrieb:
> Der Grund warum ich das frage ist weil ich derzeit an einer
> halb-diskreten 8 bit CPU arbeite.
> Mit "halb-diskret" meine ich "aus 74er und 4000er Logik-ICs, aber auch
> mit (E)EPROMs, SRAMS.

rbx schrieb:
> Multiply Add:
>
> https://de.wikipedia.org/wiki/Multiply-Accumulate
>
> oder Barrel-Shifter:
>
> https://de.wikipedia.org/wiki/Barrel-Shifter
>
> Außerdem könnte man den Umgang mit DSPs überlegen, vor allem bei so
> Dingern wie AVR.
>
> Und: wie siehts aus mit Komprimiergeschichten beschleunigen?
>
> Je nach Speicher und Tabellen(rechen) - Konstruktion sind auch
> Speichernavigations-Strategien zu überlegen.
>
> Was gibt es noch? Parallel-Rechnereien - wie gut kann man die
> Hardwareseitig unterstützen? Sowas wie einen Kopierbefehl über mehrere
> Register-Bahnen bzw.

Das passt prima zusammen :-)

Andre G. wird die MC-Hersteller "das Fürchten lehren" :-). Ein neuer 
Stern an was für einem Himmel auch immer :-)

von Andre G. (andgst01)


Lesenswert?

Hugo H. schrieb:
> Andre G. wird die MC-Hersteller "das Fürchten lehren" :-). Ein neuer
> Stern an was für einem Himmel auch immer :-)

Ich sage es nochmal:
Ich habe nicht vor etwas "besser" zu machen!

Nur "für mich selbst verständlicher und nachvollziehbarer".

von udok (Gast)


Lesenswert?

Andre G. schrieb:
> Nur "für mich selbst verständlicher und nachvollziehbarer".

Dann fang doch erst mal mit dem Rad an :-;

von S. R. (svenska)


Lesenswert?

michael_ schrieb:
> Hä, Daisi-Chain sagt dir nix?

Doch, aber der 8080 kannte die nicht.
Die coolen Dinge (z.B. Interruptvektoren) kamen erst mit dem Z80.

A.K. hat das schon wunderbar zusammengefasst.

von Axel S. (a-za-z0-9)


Lesenswert?

Andre G. schrieb:

> Ich habe nicht vor etwas "besser" zu machen!
>
> Nur "für mich selbst verständlicher und nachvollziehbarer".

Wenn die Architektur der AVR für dich nicht verständlich und 
nachvollziehbar ist, dann muß es an dir liegen. Ich persönlich habe mit 
dem Z80 (U880) angefangen und fand das gut verständlich. OK, ich hatte 
ein paar Tage Zugriff auf einen Poly880 - ein Z80 Minimalsystem mit 
vielen LEDs an allen Bussignalen und Einzelschrittbetrieb. Aber nach ein 
paar Wochen war das langweilig. Man hatte schlicht alles gesehen.

Später habe ich den 6502 gesehen und fand ihn geradezu trivial (und in 
Trivialitäten eingeschränkt).

Man muß nicht alles zu Fuß nachbauen. Schon gar nicht mit den 
Möglichkeiten von heute. Kennst du http://visual6502.org/? Die diversen 
Emulatoren wie http://www.jens-mueller.org/jkcemu/poly880.html?

Ich will dir nicht die gute Laune verderben. Aber wenn ich sehe, wieviel 
Weg zwischen dem unbeholfenem Versuch, eine CPU zu bauen und - sagen wir 
mal - einem Webframework mit asynchronem Javascript liegt, würde ich 
sagen, daß du zu wenig Lebenszeit hast, um sie auf so einen Urschleim zu 
verschwenden. YMMV.

von michael_ (Gast)


Lesenswert?

S. R. schrieb:
> A.K. hat das schon wunderbar zusammengefasst.

Nö, am Anfang hat er es geleugnet.

von (prx) A. K. (prx)


Lesenswert?

michael_ schrieb:
> Nö, am Anfang hat er es geleugnet.

???

von Andre G. (andgst01)


Lesenswert?

Axel S. schrieb:
> Ich will dir nicht die gute Laune verderben. Aber wenn ich sehe, wieviel
> Weg zwischen dem unbeholfenem Versuch, eine CPU zu bauen und - sagen wir
> mal - einem Webframework mit asynchronem Javascript liegt

Wer hat den gesagt dass ich auf dem Ding ein Webframework mit JS laufen 
lassen will?

Ich bin schon froh wenn ich einfache assembler-ähnliche Programme darauf 
zum laufen bringe.

Nicht alles muss "state of the art" sein.

Und ein ganzes Betriebssystem oder ein Webframework zu verstehen, das 
sind ganz andere Dimensionen als "eine einfache 8 bit CPU".
DAS grenzt eher an "Unmöglichkeit" ...

Axel S. schrieb:
> ürde ich
> sagen, daß du zu wenig Lebenszeit hast, um sie auf so einen Urschleim zu
> verschwenden.

Danke für die Sorge, aber ich bin "erst" 22.
;-)

von udok (Gast)


Lesenswert?

ndre G. schrieb:
> Danke für die Sorge, aber ich bin "erst" 22.
> ;-)

Hehe, in dem Alter habe ich das auch gemacht.  Inklusive 20 Seiten auf 
Papier gezeichneter händischer Schaltpläne.  Ich bin damals zur 
Texas-Instruments Niederlassung gepilgert, und habe mir die gelben TTL 
Datenbücher geholt. War eine schöne Zeit, aber heute würde ich es nicht 
mehr machen.

Noch ein Tipp: Bau es in SMD, das ist einfacher zu löten, und du kannst 
auch einen Bestückungsservice in China in Anspruch nehmen.
Da geht gleich 10x so viel, wie wenn du das händisch löten musst.

Interessant wäre auch ein richtiger Retro-Computer.
Ich meine einen Analogen Computer aus den 50-ern.  Im Gegensatz zu den
8 Bit Krücken konnten die schon damals Differenzialgleichungen lösen.

von Asdf Q. (Gast)


Lesenswert?

Andre G. schrieb:

> Ich sage es nochmal:
> Ich habe nicht vor etwas "besser" zu machen!
>
> Nur "für mich selbst verständlicher und nachvollziehbarer".

Du kennst den Gigatron? Das ist ein ziemlich minimalistischer Computer 
aus TTL-Bausteinen, mit dem sich bei geeigneter Programmierung sogar 
VGA-Graphik und Ton erzeugen lässt.

https://gigatron.io/

von Axel S. (a-za-z0-9)


Lesenswert?

Andre G. schrieb:
> Axel S. schrieb:
>> Ich will dir nicht die gute Laune verderben. Aber wenn ich sehe, wieviel
>> Weg zwischen dem unbeholfenem Versuch, eine CPU zu bauen und - sagen wir
>> mal - einem Webframework mit asynchronem Javascript liegt
>
> Wer hat den gesagt dass ich auf dem Ding ein Webframework mit JS laufen
> lassen will?

Ich bestimmt nicht. Aber ich nehme an, daß du das erworbene Wissen 
irgendwann, irgendwie auch nutzen willst.

> Ich bin schon froh wenn ich einfache assembler-ähnliche Programme darauf
> zum laufen bringe.

Klar. Nur gewinnst du damit keinen Blumentopf.

> Und ein ganzes Betriebssystem oder ein Webframework zu verstehen, das
> sind ganz andere Dimensionen als "eine einfache 8 bit CPU".
> DAS grenzt eher an "Unmöglichkeit" ...

Eigentlich nicht. Es hängt natürlich davon ab, wie man sich das neue 
Wissen aneignet. Im Laufschritt geht schneller als Krabbeln. Und genau 
darum ging es mir. Im Moment bist du am Krabbeln. Und du scheinst zu 
denken, daß du immer weiter krabbeln kannst. Für die weitaus meisten 
Menschen ist das aber eine Phase, die sie schnell hinter sich lassen.

>> würde ich sagen, daß du zu wenig Lebenszeit hast, um sie auf so
>> einen Urschleim zu verschwenden.
>
> Danke für die Sorge, aber ich bin "erst" 22.

Schlimm genug. Mit 19 hatte ich meinen ersten Computer gebaut (was CP/M- 
artiges, auf U880 Basis). Mit 22 habe ich glaube ich an einem A5120 
gesessen und einen EPROMMER auf einer selbstgestrickten Karte in 
Turbo-Pascal zum Leben erweckt. Auf dem Esstisch im Wohnheim.

Und danach bin ich ins Computerkabinett gegangen und habe die 
reservierte Zeit vor einem niegelnagelneuen IBM Model 220 mit den Lernen 
von C verbracht. Und über dieses neuartige Ding, das World Wide Web 
gestaunt, das man mit dem "mosaic" Browser ansehen konnte.

von (prx) A. K. (prx)


Lesenswert?

udok schrieb:
> aber heute würde ich es nicht mehr machen.

Ich auch nicht. Aber das ist da nur natürlich. Der Reiz liegt vorwiegend 
bei jenen, die die Zeit des Eigenbaus nicht selbst erlebt haben. 19" 
Frame, Karten in Doppeleuro-Format, Wrap-Technik etc.

: Bearbeitet durch User
von Stefan F. (stefanus)


Lesenswert?

Andre G. schrieb:
> Wer hat den gesagt dass ich auf dem Ding ein Webframework mit JS laufen
> lassen will?

Er meinte, dass man in der Zeit wesentlich sinnvollere Sachen 
lernen/machen kann. Etwas, womit man heute etwas praktischen tun kann 
oder einfach nur Geld verdienen.

von Andre G. (andgst01)


Lesenswert?

Stefan ⛄ F. schrieb:
> Andre G. schrieb:
>> Wer hat den gesagt dass ich auf dem Ding ein Webframework mit JS laufen
>> lassen will?
>
> Er meinte, dass man in der Zeit wesentlich sinnvollere Sachen
> lernen/machen kann. Etwas, womit man heute etwas praktischen tun kann
> oder einfach nur Geld verdienen.

Ja, aber "Geld verdienen" ist nicht Sinn und Zweck eines Hobbyprojekts, 
oder?

Und was "sinnvoll" ist ist auch immer sehr subjektiv ...

von Thomas W. (dbstw)


Lesenswert?

Moin, -

ich verstehe nicht, warum ihr das Projekt so schlecht macht (ich 
erinnere mich an das 4GB RAM-Modul :-) mit Frontplatte). Aber eine 
Acht-Bit-CPU konzipieren und bauen halte ich in 2-3 Jahren (ist ja 
Hobby) realistisch. Und wenn er die ISA komplett selbst baut, kann er 
erstmal in Assembler (und auf dem Papier!) programmieren.

Und Bauteile sind heute billig (wirklich) und auch gut verfuegbar (man 
muss ein wenig bestellen und planen, aber: Das ist Hobby. Und wenn die 
Bauteile noch irgendwo in Post haengen, kann er was anderes machen).

Ich wuerde allerdings als Fingeruebung ein kleines Z80-System bauen ob 
das mit dem Loeten und bauen so einfach ist (er wird dann auch merken, 
welche Messgeraete ihm noch fehlen und welche Software er noch braucht). 
So ein kleines Z80-System kann er in 1-2 Monate bauen.

Gruesse

Th.

von Stefan F. (stefanus)


Lesenswert?

Andre G. schrieb:
> Ja, aber "Geld verdienen" ist nicht Sinn und Zweck eines Hobbyprojekts,
> oder? Und was "sinnvoll" ist ist auch immer sehr subjektiv ...

Das stimmt wohl.

von Andre G. (andgst01)


Lesenswert?

Thomas W. schrieb:
> er wird dann auch merken,
> welche Messgeraete ihm noch fehlen

Ich denke das meiste habe ich schon: DMM(s), digitales Oszi (mit 16 
Kanal Logikanalysator), Frequenzzähler.

Was braucht man sonst noch für solche digitalen Projekte?

Mir fällt da weiter nichts ein ...

von Thomas W. (dbstw)


Angehängte Dateien:

Lesenswert?

Dann bist Du ja schon gut ausgestattet. Stromversorgung brauchst Du 
noch, aber da man heute 32Kb Ram im mA-Bereich(!) speisen kann, reicht 
fast eine Powerbank.

Ich haenge mal einen Ausschnitt von Ward/Halstaed an, das Design des 
MAYBE-Computer aus dem Buch (die zwei Seiten mit dem dyn.Speicher sind 
fast nur noch historisch interessant).

Gruesse

Th.

: Bearbeitet durch User
von Stefan F. (stefanus)


Lesenswert?

Andre G. schrieb:
> Was braucht man sonst noch für solche digitalen Projekte?

Ein Signal-Generator ist ab und zu hilfreich. Den kann man sich ggf. 
selbst basteln, aber bei dem Preis...
https://de.aliexpress.com/item/4000029595016.html

USB-UART Adapter hast du schon?

: Bearbeitet durch User
von Andre G. (andgst01)


Lesenswert?

Thomas W. schrieb:
> Stromversorgung

Ja, habe ich mehr als genug ...

Thomas W. schrieb:
> Ich haenge mal einen Ausschnitt von Ward/Halstaed an, das Design des
> MAYBE-Computer aus dem Buch (die zwei Seiten mit dem dyn.Speicher sind
> fast nur noch historisch interessant).

Ja das sieht sehr vertraut aus ...

von Andre G. (andgst01)


Lesenswert?

Stefan ⛄ F. schrieb:
> Andre G. schrieb:
>> Was braucht man sonst noch für solche digitalen Projekte?
>
> Ein Signal-Generator ist ab und zu hilfreich. Den kann man sich ggf.
> selbst basteln, aber bei dem Preis...
> https://de.aliexpress.com/item/4000029595016.html

Jemand hier im Forum verkauft einen guten Funktionsgenerator, aber der 
antwortet irgendwie weder auf PM noch auf Antworten in dem Thread ...


> USB-UART Adapter hast du schon?
Ist bestellt, kann man ja für alles mögliche brauchen ...

von Spielratz (Gast)


Lesenswert?

Nicht unbedingt nützlich, sondern eher interessant wäre es, die Regeln 
von Conways Game of Life in eine CPU zu packen.

Das sollte sogar mit Recht wenigen Befehlen zu machen sein.

von c-hater (Gast)


Lesenswert?

Spielratz schrieb:

> Nicht unbedingt nützlich, sondern eher interessant wäre es, die Regeln
> von Conways Game of Life in eine CPU zu packen.
>
> Das sollte sogar mit Recht wenigen Befehlen zu machen sein.

Ja klar. Aber nur, wenn man sich auf ein Regelwerk und eine bestimmte 
Biotop-Größe beschränkt.

Sonst wird es schnell deutlich komplizierter.

von Spielratz (Gast)


Lesenswert?

Wieso denn?
Ein Befehl lässt eine Zelle nachsehen, was in der aktuellen Iteration 
passiert, also ob eine Zelle entsteht, stirbt oder nichts passiert, ein 
weiterer Befehl legt in zwei Speicherzellen die Regeln ab (entstehen bei 
x Nachbarn, sterben bei mehr als/ weniger als y/z Nachbarn) dazu reichen 
2 Byte, denn mehr als 8 Nachbarn hat eine Zelle im 2dimensionalen Raum 
nicht.
Ein Dritter Befehl legt die Größe des Feldes fest und mit einem vierten 
wird die nächste Iteration gestartet

In einem 3dimensionalen Raum sieht das natürlich schon ganz anders aus, 
wobei die Befehle die gleichen sind, nur daß mehr Speicher gebraucht 
wird.

von c-hater (Gast)


Lesenswert?

Spielratz schrieb:

> Wieso denn?
> Ein Befehl lässt eine Zelle nachsehen, was in der aktuellen Iteration
> passiert, also ob eine Zelle entsteht, stirbt oder nichts passiert

Nun dann designe mal so einen Befehl (nennen wir ihn BDL (birth, death 
or live)) in Hardware...

Tipp: wir reden hier von Torussen, die aber notgedrungen in linearem 
endlichen Speicher liegen müssen, denn Speicher, der als Torus 
organisiert ist, gibt's wohl nicht.

Soweit wäre das noch beherrschbar, wenn die Abmaße des Torus und das 
Regelwerk fix sind. Aber es wird eben gleich sehr viel komplexer, wenn 
das nicht der Fall ist.

> ein
> weiterer Befehl legt in zwei Speicherzellen die Regeln ab (entstehen bei
> x Nachbarn, sterben bei mehr als/ weniger als y/z Nachbarn) dazu reichen
> 2 Byte, denn mehr als 8 Nachbarn hat eine Zelle im 2dimensionalen Raum
> nicht.
> Ein Dritter Befehl legt die Größe des Feldes fest

Tja, schönes Ding das. Und der BDL-Befehl mutiert dann jeweils durch 
göttliche Eingebung einfach und macht plötzliche was ganz anderes oder 
wie hast du dir das vorgestellt?

von Paul G (Gast)


Lesenswert?

...schon lustig, vor einigen Jahren hate ich ungefähr die selbe Idee, 
eigenes soc aber in einem fpga. Die Motivation war eine "bessere" 
softcore CPU zu basteln als den nios2-e von Altera/Intel um sich die 
Lizenzkosten für die performantere nios2-f Variante zu sparen.
Mein instruction set hatte am Ende knapp 40 Befehle, die meiner Ansicht 
nach wichtigsten Rechen und Bit-shift Operationen und bedingte Sprünge.
Das Projekt ist nach Jahren (habe nur Hobby-mäßig daran "gearbeitet") 
dann im Sande verlaufen weil als ich beim Interrupt Controller 
angekommen bin reichten die einfachen mit meinem diy-assembler 
compilierten Test Programme nicht mehr aus und da schrillten dann 
endlich die Alarmglocken: es gab natürlich keinen c-compiler der mein 
instruction set unterstützt!!! Nachdem ich mich dann Wochen mit compiler 
design, ASTs, GCC portierungen usw. auseinandergesetzt hatte habe ich 
den diy-c-compiler dann gar nicht mehr angefangen, die Zeit wollte ich 
nicht mehr verschwenden. Bei näherer Betrachtung stellte ich dann auch 
endlich fest: meine CPU ist eigentlich nichts anderes als eine risc-v 
CPU nur die haben es um einige Klassen besser hinbekommen!
Also das nur zum Thema man kann seine Zeit auch sinnvoller vergeuden.
Hab ich dabei viel gelernt? Definitiv!
Würde ich sowas nochmal versuchen? Nein!

Will niemanden entmutigen, vielleicht bekommst du ja am Ende was 
funktierendes und brauchbares hin.

von Frank B. (frank501)


Lesenswert?

Wirklich Sinnvoll ist eine GOL-CPU sicher nicht. Bestenfalls 
interessant.
Wenn man so eine CPU mit Logikchips aufbaut, könnte man doch einfach 
einen kleinen Controller nehmen und mit diesem die GOL-Befehle 
implementieren. Ist natürlich getrickst, aber wen stört das bei einer 
CPU, die keinen wirklichen praktischen Wert hat, schon?
Man könnte ja sogar Doom auf einem eigenen Chip als Befehl 
implementieren.

SCNR

von Falk B. (falk)


Lesenswert?

Frank B. schrieb:
> Man könnte ja sogar Doom auf einem eigenen Chip als Befehl
> implementieren.

ooooch, das ist leicht. Einfach ein Halbleiterrelais von 230VAC nach +5V 
deiner CPU klemmen und mit einem IO einschalten ;-)

von Dieter R. (drei)


Lesenswert?

c-hater schrieb:

> Tipp: wir reden hier von Torussen, die aber notgedrungen in linearem
> endlichen Speicher liegen müssen, denn Speicher, der als Torus
> organisiert ist, gibt's wohl nicht.

Wie kommst du denn darauf? Ich zitiere mal Wikipedia:

"The universe of the Game of Life is an infinite, two-dimensional 
orthogonal grid of square cells,..."

Ein Torus als Spielfeld-Topologie ist eine (finite) Sonderform, die sich 
andere später ausgedacht haben, erschien wohl als zusätzliche 
Herausforderung. Man kann sich noch mehr Varianten ausdenken, siehe:

https://www.cs.ou.edu/~rlpage/secollab/20projects/ConwayPlusTopology.htm

"Damals" haben wir in der Vorlesung "Zellularautomaten" noch Simulation 
auf Karopapier gemacht, Rechenzeit war kostbar und stand dafür nicht zur 
Verfügung. Kann man sicher auch auf eine CPU portieren.

von c-hater (Gast)


Lesenswert?

Dieter R. schrieb:

> Wie kommst du denn darauf? Ich zitiere mal Wikipedia:
>
> "The universe of the Game of Life is an infinite, two-dimensional
> orthogonal grid of square cells,..."
>
> Ein Torus als Spielfeld-Topologie ist eine (finite) Sonderform, die sich
> andere später ausgedacht haben, erschien wohl als zusätzliche
> Herausforderung.

Kaum. Es ging wohl eher darum, die Sache real umsetzen zu können. 
Schließlich sind Unendlichkeiten nicht so ganz einfach auf realer Hard- 
und Software abzubilden...

Aber das ist natürlich nur die Meinung eines Hassers jedweder sinnloser 
Abstraktion...

von Alois (Gast)


Lesenswert?

Paul G schrieb:
> ...schon lustig, vor einigen Jahren hate ich ungefähr die selbe
> Idee ...

Vor gefühlten Äonen, zu Vor-AVR-Zeiten, hatte ich mich mal mit 8051 und 
Small-C vergnügt, sogar einen Codegenerator geschrieben. Dabei hatte ich 
viel gelernt (auch durch Review von Keil-generiertem Code), v/a aber, 
wie C-taugliche Prozessoren nicht aussehen sollten.

Dann kam AVR - und die 48/51er-Schiene war für mich passe.

Was ich damit sagen will: Ohne Tools macht kein Prozessor Spaß. Und für 
einen A-Prozessor müsste man diese erst noch schreiben. Wenn man‘s 
richtig machen wollte, müsste Andre den Weg von Atmel/IAR beschreiben. 
Aber ich wiederhole mich ...

Andres Projekt hat was - ohne Zweifel. Wo ich Zweifel habe ist, dass 
sich so was als Einzelkämpfer und ohne viel Wissen um 
Prozessorarchitekturen, in nicht unendlicher Zeit durchziehen lässt. Und 
das vor allem ohne Frust.

Für mich könnte es nie Ziel sein, einfach aus dem hohlen Bauch einen 
Prozessor zu basteln - und am Ende mit einem Haufen gefädelten 
Pertinax-Patten dazustehen und nicht zu wissen, wohin damit. Irgendwas 
sollte dieser A-Prozessor ja schließlich tun, außer nur rumzugammeln ...

An Andres Stelle würde ich mir ein erreichbares Ziel setzen, z.B. eine 
Spezial-CPU, die eine Mini-Language wie Karel (Stanford) oder Kara 
(SwissEduc) direkt ausführen kann. Damit wäre dann auch gleich die 
Eingangsfrage geklärt ...

Für's Testbed, um das Ganze nett zu visualisieren, kann man sich sicher 
bei den o.g. Quellen bedienen ...

just my 2ct

von Dieter R. (drei)


Lesenswert?

c-hater schrieb:

> Kaum. Es ging wohl eher darum, die Sache real umsetzen zu können.
> Schließlich sind Unendlichkeiten nicht so ganz einfach auf realer Hard-
> und Software abzubilden...

Du hast es nicht begriffen oder willst es nicht begreifen. Der Computer 
muss nicht das Universum abbilden. Es reicht durchaus ein endlicher 
Automat. Damals reichte Karopapier, das war auch endlich.

von (prx) A. K. (prx)


Lesenswert?

c-hater schrieb:
> Tipp: wir reden hier von Torussen

Russen kommen grad nicht gut an. Rede lieber über Tori. ;-)

: Bearbeitet durch User
von rbx (Gast)


Lesenswert?

Man kann sich zumindest fragen, was den Reiz der Motivation früher 
ausmachte.

https://binarium.de/meilensteine_personal_computer_geschichte_heimcomputer_homecomputer

Was ich meine ist, wo war der Mehrwert zu beispielsweise zu einem 
Elektor Formant?

Einer der Vorteile für uns war der, dass wir viele Entwicklungen 
schrittweise über Jahre hinweg mitmachen konnten. Es gab einfache 
Lehrbücher zu Datenverarbeitung, Basic-Kurse in den Volkshochschulen, 
verschiedene Zeitschriften mit Programmierbeispielen oder auch 
(z.B.)(akustik-) Filterschaltplänen und auch regelmäßig passende 
Fernsehsendungen, nicht zuletzt die mit Jean Pütz. Der hatte selber 
sogar noch ein gar nicht so schlechtes Buch zum Thema Elektronik 
herausgegeben.

Der Intel 4004 ( https://de.wikipedia.org/wiki/Intel_4004 ) war auch 
schon sehr beeindruckend. Die (Logik-)Schaltpläne von dem waren 
gigantisch, und man brauchte schon die komplexesten eigenen bzw. 
verstandenen Wertetabellen/Schaltpläne als Referenz, um nicht zu 
verzweifeln. ;)

von Falk B. (falk)


Lesenswert?

https://www.youtube.com/channel/UCS0N5baNlQWJCUrhCEo8WlA

Sehr interessant und unterhaltsam, animiert auch sehr zum Nachmachen!

von MCUA (Gast)


Lesenswert?

Von wegen 100 kHz.

Es gibt nach wie vor auch schnelle 74F.. Bausteine (bipolar).

Ein 8-16-32-Bit Parallel-Bus hat nicht unbedingt Hazards, man muss 
entspr. Steuerleitungen (Clk usw) mit GND (richtig) trennen (bzw. 
anpassen)

Eine Minimal-Version (typ. 1 Akku-CPU) wäre z.B. mit ALU  '181 und 
(L-R)-Shift-Register.

Nach oben sind keine Grenzen gesetzt.
Es gibt auch 9-HE-Eurokarten...

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Russen kommen grad nicht gut an. Rede lieber über Tori. ;-)

Das wollte ich nicht, wenn ich das höre, denke ich immer zuerst an den 
Teil des britischen Parlaments, der mir nicht so zusagt. :o)

von Dirk S. (dirkst)


Lesenswert?

Gruss zum Wochenende
 und ein schönes.

... schrieb:
> Ausserdem fehlen ihm die zur Realisierung unbedingt nötigen 74182.

PS. Kessler-elektronic
 hat den (74) HC182 im online
 shop da.

Dirk St

von Jens B. (dasjens)


Lesenswert?

(prx) A. K. schrieb:
> RCA 1802

c-hater schrieb:
> Bauform B. schrieb:
>
>> c-hater schrieb:
>>> Mein Gott, wer sowas wie keine Ahnung von existierenden (vergleichweise
>>> primitiven) Architekturen hat...
>>
>> ...kann völlig frei und unvoreingenommen die optimale CPU entwerfen.
>
> Das bezweifele ich ernsthaft.
>
> Wenn wir irgendwo im Jahr 1950 wären, ja dann ok. Sind wir aber nicht.
> Mit 70 Jahren Abstand und unzähligen (zumindest zweitweise)
> existierenden Architekturen gibt es aber genug Stoff, um aus all den
> Fehlern zu lernen, die andere bereits zuvor gemacht haben. Es wäre sehr
> dumm, diesen Wissenschatz zu ignorieren.

Hallo?
Hat die Menschheit je aus ihren Fehlern gelernt?
Wir leben nach: "Aus Fehlern wird man klug, drum ist einer nicht genug"

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.