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.
Andre G. schrieb: > Zum Beispiel "SBR" (Set bit in register). Den gibts ja auch nicht wirklich. Das ist ein Synonym für ORI.
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
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
bork schrieb: > Als Referenz: PDP8, CDC1604, MOS6502, Motorola 6800 Und RCA 1802, wenns etwas abseits des Mainstreams sein darf.
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.
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
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 ...
(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...
Moin, Ein NOP Befehl scheint mir recht wichtig zu sein. Kennt wer eine CPU, die den nicht hat? SCNR, WK
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.
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.
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.
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"
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
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.
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
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...
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.
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.
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.
MaWin schrieb: > Beim Inmos Transputer fehlten z.B. Befehle damit man schnellen Code > schreiben konnte um Speicherbereiche umzukopieren. Hmm. "move"?
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.
MaWin schrieb: > SBR ist halt einfach kürzer und schneller als ORI. Ähhhm - die sind identisch. Nicht mal der Name ist kürzer.
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?
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.
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.
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" ...
(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.
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.
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
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.
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.
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 ...
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
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.
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.
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).
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
> 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.
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.
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...
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
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.
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
Andre G. schrieb: > Schönen Sonntag Abend, Hä, hab ich was verschlafen? Sind denn die EPROM schon alle verbaut?
(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.
(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.
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
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.
(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:-)
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.
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
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
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.
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.
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!
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.
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)
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.
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
(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.
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.
(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.
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.
bork schrieb: > Referenz: PDP8, CDC1604, MOS6502, Motorola 6800 Die PDP-14 nicht vergessen, und den darauf aufbauenden MC14500B. Wo wir schon bei Minimalistik sind. ;-)
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?
Tilo R. schrieb: > Logik: NOT, AND, OR, SHL (mit Carry) Linksshift ist über ADD ersetzbar - aber Rechtsshift?
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.
(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.
Der hässliche und extrem archaische Nebeneffekt dieser Architektur ist der Zwang zu selbstmodifizierendem Code.
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
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
(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.
(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 ;-)
Oft ist es wichtig zu wissen, wie man es sicher NICHT machen sollte! 8bit-CPU: bo8 Lesen auf eigene Gefahr!
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.
(prx) A. K. schrieb: > und den darauf aufbauenden MC14500B. Mit seinen 16 Befehlen ein überschaubares, schönes 1-Bit Teil ;-)
Und unter den 16 Befehlen sind immerhin 2 NOPs. Das illustriert deren Unersetzlichkeit? ;-)
:
Bearbeitet durch User
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.
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.
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.
@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.
Uups gerade gesehen der Anhang ist riesig - sorry! Viellleicht kann ein Mod den noch schrumpfen.
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? ;-)
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
Dergute W. schrieb: > das Ende von Linu^h^h Bo8!!!einsElf11!! Was soll das heißen?
:
Bearbeitet durch User
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
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" ...
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
> Welche Befehle machen eine CPU "praktisch"?
HCF
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.
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 ... ;-)
Angehängte Dateien:
-
M68000Hochsprache.jpg
330 KB
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.
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.
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
An Interrupts habe ich noch gar nicht gedacht ...
(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.
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
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?
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.
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.
Arbeiten eigentlich alle (nicht historischen) CPUs intern mit Mikrocode?
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.
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.
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.
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.
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.
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.
(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.
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
(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.
(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. ä.
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
Andre G. schrieb: > aber auch mit (E)EPROMs Der hat es glaub ich auch so gemacht: http://www.mycpu.eu/
(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.
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).
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
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.
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
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.
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.
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!
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
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.
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
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
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.
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)
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 :-)
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".
Andre G. schrieb: > Nur "für mich selbst verständlicher und nachvollziehbarer". Dann fang doch erst mal mit dem Rad an :-;
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.
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.
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. ;-)
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.
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/
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.
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
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.
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 ...
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.
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.
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 ...
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.
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?
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 ...
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 ...
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.
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.
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.
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?
...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.
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
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 ;-)
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.
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...
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
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.
c-hater schrieb: > Tipp: wir reden hier von Torussen Russen kommen grad nicht gut an. Rede lieber über Tori. ;-)
:
Bearbeitet durch User
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. ;)
https://www.youtube.com/channel/UCS0N5baNlQWJCUrhCEo8WlA Sehr interessant und unterhaltsam, animiert auch sehr zum Nachmachen!
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...
(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)
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
(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"
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.