>möchte ich den Befehlssatz der bo8-CPU zur Diskussion stellen.
Da wirst du wohl Spinnenweben unter den Armen bekommen bevor sich
da jemand dran beteiligt;)
Das Ding hat keinen Stack, bzw. kann nur genau eine Rücksprungadresse
verwalten?
Hast Du Dir schon mal Gedanken darüber gemacht, wie man für so etwas
einen Hochsprachencompiler anpassen soll?
(Wenn ich mir selbst noch 8-Bit-Assembler antun möchte, um in der
Vergangenheit zu schwelgen, dann werd' ich das doch eher mit 6809-Code
machen als mit diesem Spartaner hier)
Deine Homepage hatte ich mir schon einmal angetan.
Deinen Gedanken zu folgen ist nicht einfach.
Auch habe ich mich oft gefragt, wie man so einen (verzeihe mir den
Ausdruck) Murks verzapfen kann.
Du hättest Dich daran https://de.wikipedia.org/wiki/MMIX orientieren
sollen.
Der MMIX macht im Gegensatz zu Deinem Entwurf Sinn.
Rufus Τ. F. schrieb:> Das Ding hat keinen Stack, bzw. kann nur> genau eine Rücksprungadresse verwalten?
Ein Unterprogramm, welches selber ein anderes Unterprogramm
aufrufen will, muss vorher die Rücksprungadresse sichern.
Vorteil der in einem CPU-Register gespeicherten Rücksprungadresse:
Wenn im Unterprogramm kein weiteres Unterprogramm aufgerufen wird,
geht der Rücksprung sehr schnell.
Weiterer Vorteil, wenn es nur einen Sprungbefehl für Sprünge,
Unterprogrammaufrufe und Rücksprünge gibt: Eine gleichzeitige
Seitenumschaltung bei Sprüngen in eine andere Seite
ist einfacher zu realisieren.
Josef G. schrieb:> Ein Unterprogramm, welches selber ein anderes Unterprogramm> aufrufen will, muss vorher die Rücksprungadresse sichern.
Dafür nutzt man in wirklich vielen anderen Prozessorarchitekturen den
Stack. Wohin sonst soll das "Unterprogramm" seine Rücksprungadresse
sichern? Schon mal über Reentranz nachgedacht?
-Reentranz hat erstmal nichts mit Interrupts zu.
-Eine CPU ohne Interrupts scheint mir unbrauchbar, zumindest stark
ausgebremst
-wie übergibst du Parameter an Funktionen?
@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
>Dafür nutzt man in wirklich vielen anderen Prozessorarchitekturen den>Stack. Wohin sonst soll das "Unterprogramm" seine Rücksprungadresse>sichern? Schon mal über Reentranz nachgedacht?
Schon mal über Josef's Disposition nachgedacht?
H.Joachim S. schrieb:> -wie übergibst du Parameter an Funktionen?
Die CPU hat 3 gleichberechtigte universell einsetzbare
Adressregister. Eines davon zeigt auf die Parameter.
Josef G. schrieb:> Rufus Τ. F. schrieb:>> Reentranz>> Meine CPU hat keine Interrupts.
Darf man fragen warum? Eine CPU ohne Interrupts macht wenig Sinn.
TriHexagon schrieb:> Eine CPU ohne Interrupts macht wenig Sinn.
Kommt drauf an, für welchen Zweck.
Sie macht sehr wohl Sinn, wenn man einen für
jedermann verstehbaren Computer bauen will.
Rufus Τ. Firefly (rufus) schrieb
>Josef G. schrieb:>> Ein Unterprogramm, welches selber ein anderes Unterprogramm>> aufrufen will, muss vorher die Rücksprungadresse sichern.>Dafür nutzt man in wirklich vielen anderen Prozessorarchitekturen den>Stack. Wohin sonst soll das "Unterprogramm" seine Rücksprungadresse>sichern? Schon mal über Reentranz nachgedacht?
Ich glaube ARM macht mit seinem LINK-Register etwas ähnliches wie
Joseph:
http://www.davespace.co.uk/arm/introduction-to-arm/branch.html
1
How do we return from the subroutine which BL invoked?
Autor: TriHexagon (Gast) schrieb
>Josef G. schrieb:>> Rufus Τ. F. schrieb:>>> Reentranz>>>> Meine CPU hat keine Interrupts.>Darf man fragen warum? Eine CPU ohne Interrupts macht wenig Sinn.
Der Parallax-Propeller ist ein ziemlich geniale CPU.
Ohne Interrupts.
https://en.wikipedia.org/wiki/Parallax_Propeller
@ chris_ (Gast)
>>Darf man fragen warum? Eine CPU ohne Interrupts macht wenig Sinn.>Der Parallax-Propeller ist ein ziemlich geniale CPU.>Ohne Interrupts.
So genial, daß sie auch so waaaahnsinning verbreitet und erfolgreich ist
. . .
https://en.wikipedia.org/wiki/Parallax_Propeller
Das war mal ne nette Idee, die Praxis mit festen Hardwareeinheiten hat
sich aber durchgesetzt, ebenso wie Soft-CPUs in FPGAs nur ein
Nischendasein fristen. Leistungsfähige Hardware(module) kann man nur
durch NOCH leistungsfähigere Hardwaremodule ersetzen. oder willst du
einen Ethernetcontroller mit einem Propeller nachbauen?
Josef G. schrieb:> TriHexagon schrieb:>> Eine CPU ohne Interrupts macht wenig Sinn.>> Kommt drauf an, für welchen Zweck.>> Sie macht sehr wohl Sinn, wenn man einen für> jedermann verstehbaren Computer bauen will.
Schon klar, im ersten Semester haben wir eine extrem minimalistische CPU
Marke Eigenbau vom Professor vorgesetzt bekommen. Einfacher gehts kaum,
war aber unglaublich lehrreich.
Aber eine general purpose CPU ohne Interrupts? Busy waiting aka polling
ist oft gar keine Option...
TriHexagon schrieb:> Busy waiting aka polling ist oft gar keine Option...
Die CPU kann mittels des Repeat-Eingangs beliebig lange angehalten
werden, insbesondere beim IO-Befehl H.. , und dann mit Genauigkeit
von 1 Taktzyklus auf ein Ereignis reagieren.
Josef G. schrieb:> auf ein Ereignis reagieren
Und das ist das Problem.
Anhalten ist doof.
Nur auf ein Ereignis reagieren ist auch doof.
Und dann ist man eben ganz schnell in einer grossen polling-Schleife
drin, die immer mehr Zeit verbraucht, je grösser sie wird und je
zeitnäher man reagieren will.
Geht ja schon mit dem einfachsten Problem los - wann rufe ich die auf?
Ne Art Timerinterrupt gibts ja nicht.
Immer, wenn ich sonst nichts zu tun habe? Nach jedem main-Befehl? Nach
jeder Funktion, die ich aufgerufen habe?
Josef G. schrieb:> TriHexagon schrieb:>> Busy waiting aka polling ist oft gar keine Option...>> Die CPU kann mittels des Repeat-Eingangs beliebig lange angehalten> werden, insbesondere beim IO-Befehl H.. , und dann mit Genauigkeit> von 1 Taktzyklus auf ein Ereignis reagieren.
Dann ich aber immer nur auf ein Ereignis reagieren oder?
H.Joachim S. schrieb:> Anhalten ist doof.
Mag sein, dass es doof ist bei einer großen und teuren
32Bit-CPU. Bei einem 8Bit-Winzling ist es nicht doof.
> Und dann ist man eben ganz schnell in einer grossen polling-Schleife> drin, die immer mehr Zeit verbraucht, je grösser sie wird und je> zeitnäher man reagieren will.
Nicht unbedingt. Man kann nach dem Warten beim IO-Befehl eine
Nummer einlesen und mit der Nummer eine Sprungtabelle auswerten.
> Ne Art Timerinterrupt gibts ja nicht.> Immer, wenn ich sonst nichts zu tun habe?
Für Anwendungen, wo man zwingend Interrupts
braucht, ist die CPU dann eben nicht geeignet.
TriHexagon schrieb:> Dann ich aber immer nur auf ein Ereignis reagieren oder?
Ist hiermit auch beantwortet:
> Nicht unbedingt. Man kann nach dem Warten beim IO-Befehl eine> Nummer einlesen und mit der Nummer eine Sprungtabelle auswerten.
Ganze Generationen von CPUs kamen ohne Hardware-Stack aus. Mir fallen da
auf die Schnelle die NOVA, PDP/8 und HP1000 (und Vorgänger) ein. Bei der
Nova wurde die Rücksprungsadresse in AC3 gespeichert (AC0..AC3 sind
deren Akkumulatoren), bei der PDP8 und HP1000 im jeweils ersten Wort der
Subroutine. Wenn da war reentrant sein sollte, musste ein Software-Stack
programmiert werden.
Rufus Τ. F. schrieb:> Das Ding hat keinen Stack, bzw. kann nur genau eine Rücksprungadresse> verwalten?
Hatte der RCA 1802 auch nicht. Nur 16 gleichberechtigte Register, von
denen jedes der Programmzähler sein konnte. Springen heisst einfach auf
einen anderen Programmzähler umschalten. In der Liste der pathologischen
Architekturen liegt das Ding ganz weit vorne.
Josef G. schrieb:> Nicht unbedingt. Man kann nach dem Warten beim IO-Befehl eine> Nummer einlesen und mit der Nummer eine Sprungtabelle auswerten.
Du pollst also einen Interruptcontroller. Großartige Idee.
Du hast meinen Respekt vor der Leistung und deiner Beharrlichkeit. Aber
ich fürchte du hast dich in eine etwas arg spezielle Nische verrant. Es
gibt für deine CPU irgendwie keinen guten Anwendungszweck. Es gehen alle
auf 32 Bit ARM, von da (oder selbst vom Atmega) wäre es ein enormer
Rückschritt auf 8 Bit ohne Stack & Interrutps in Assembler.
So ein Projekt wäre unwartbar bzw. braucht schnell verlorene
Spezialkenntnisse. Noch dazu gibt es deine CPU garnicht. Bevor jemand so
einen umständlichen Softcore einsetzt (und die Infrastruktur dafür aufs
PCB setzt) wird er das wohl lieber direkt in VHDL machen.
Das ist wiedermal typisch Forum. Ein absolut spartanischer Rechner wird
als pauschal untauglich zerrissen, weil man darauf kein Windows 10
laufen lassen kann.
Für 99% der LED-Blinkspielchen wird er schon reichen. Bestimmt kann man
damit sogar Ventile und Motoren ansteuern.
PS: Ich bin mit meinen AVRs zufrieden. Danke.
S. R. schrieb:> Du pollst also einen Interruptcontroller.
Falls damit eine in Software realisierte Warteschleife
gemeint ist: Nein. Die CPU wird durch das Repeat-Signal
angehalten, bis ein Ereignis eintritt. Die Nummer der
Ereignisquelle wird bei Ende des Repeats eingelesen.
Tr schrieb:> Es gibt für deine CPU irgendwie keinen guten Anwendungszweck.
Eine Anwendung wäre, wie weiter oben schon geschrieben,
ein für jedermann verstehbarer Computer für Hobbyisten.
> Noch dazu gibt es deine CPU garnicht.
Bisher gibt es sie als funktionsfähigen Softcore.
Als Einzelbaustein wäre sie kurzfristig
realisierbar mittels eines Antifuse-FPGA.
> wird er das wohl lieber direkt in VHDL machen.
Was ist mit das gemeint?
Anwendungszweck ist ziemlich einfach: Bau eine integrierte Lösung die
man für 10ct kaufen kann, dann werden dir die Grossabnehmer die Bude
einrennen. Es werden nämlich extrem viele unnötig grosse MCUs für
unglaublich banale Aufgaben verwendet.
Josef G. schrieb:> jedermann verstehbarer
Das denkst Du.
Irgendwie sind alle, die sich Deinen Code und Deine 'Dokumentation'
angeschaut haben, anderer Meinung...
@ Josef G. (bome) Benutzerseite
>Etwas, was es nach meiner Kenntnis bei keiner anderen CPU gibt:>Die Repeat-Befehle R.xx für schnelle Schleifen. Sie dauern nur>1 Vollzyklus. Was ist die Meinung des Publikums dazu?>http://www.mikrocontroller.net/articles/8bit-Compu...
Schon wieder danaben. Der TMS320C28x hat einen Repeat-Befehl.
Siehe Anhang.
soul e. schrieb:> Hatte der RCA 1802 auch nicht. Nur 16 gleichberechtigte Register, von> denen jedes der Programmzähler sein konnte. Springen heisst einfach auf> einen anderen Programmzähler umschalten.
Direkte Sprungbefehle gab es durchaus. Aber für Unterprogramme war eine
Umschaltung nötig, und sei es temporär für eine Hilfsroutine.
> In der Liste der pathologischen> Architekturen liegt das Ding ganz weit vorne.
Yep.
Falk B. schrieb:>>Die Repeat-Befehle R.xx für schnelle Schleifen. Sie dauern nur>>1 Vollzyklus. Was ist die Meinung des Publikums dazu?>> Schon wieder danaben. Der TMS320C28x hat einen Repeat-Befehl.
Microchips 16-Bitter PIC24/30/33 haben den auch.
Falk B. schrieb:> Der TMS320C28x hat einen Repeat-Befehl.
Hab's mir angeschaut. Wenn ich es richtig verstanden habe,
wird da nur 1 Befehl wiederholt. Bei mir können es auch
mehrere Befehle sein, im Prinzip beliebig viele.
Josef G. schrieb:> Sie macht sehr wohl Sinn, wenn man einen für> jedermann verstehbaren Computer bauen will.
Naja, "für jedermann verstehbar" sind auch andere Architekturen von
beliebigen auf dem Markt befindlichen 4 oder 8 bit CPU's.
Zu diesen gibt es darüber hinaus unendlich viel Datenblätter, Doku,
existierende Chips und Anwendungen, Hundertausende bis Millionen
Menschen, mit dennen du die Architektur etc diskutieren kannst etc.
Zu deiner Architektur gibts dich, deine dokumentation und ca. 10-100
Nerds welche sich in dein Zeugs reingedacht haben.
Insgesamt also ein ziemliches Ungleichgewicht von ca. 1:1 Million.
Um einen schrägen Vergleich zu ziehen: Es gibt auch ziemlich exotische
menschliche Sprachen, z.B.
https://de.wikipedia.org/wiki/Khoisansprachen
Man kann sich damit beschäftigen, wenn man Lust dazu hat. Man kann auch
während der Zeit z.B. Spanisch oder Chinesisch lernen, und kommt dann
mit deisen Sprachen wahrscheinlich weiter im Leben als mit
Klicklaut-Sprachen.
Josef G. schrieb:> Hab's mir angeschaut. Wenn ich es richtig verstanden habe,> wird da nur 1 Befehl wiederholt. Bei mir können es auch> mehrere Befehle sein, im Prinzip beliebig viele.
Bei der DO-Loop der dsPIC30/33 ebenfalls.
Josef G. schrieb:> Eine Anwendung wäre, wie weiter oben schon geschrieben,> ein für jedermann verstehbarer Computer für Hobbyisten.
Hmm grundsätzlich eine prima Idee. IMHO solltest du dich dann aber etwas
mehr am "Mainstream" orientieren, sonst hat man zwar deine CPU
verstanden aber muss die normalen 8 Bitter wieder neu lernen. Bzw. sieht
man dann keinen Mehrwert mit deiner CPU einzusteigen.
Wegen VHDL: Wenn ich jetzt ein Design mit FPGA hätte und bräuchte noch
ne "CPU Funktion" bzw. irgendetwas dass in einer CPU einfacher machbar
ist, würde ich trotzdem eher versuchen das mit ins VHDL zu backen als
deinen Softcore zu lernen. Oder halt einen gängigen Core mit
Hochsprachencompiler nehmen wenns sein muss.
Zitat: Mein Gott, es ist voller Sterne...
Ich habe mir deine CPU vor Jahren mal angesehen und gleich in die
virtuelle Ecke befördert. Der Befehlssatz ist nach wie vor unleserlich
und von hinten durch die Brust designt. Wenn schon 8-Bitter, dann bitte
aufgeräumter als 8051 oder AVR. Nicht ein Wust von null orthogonalen
Befehlen. So wird das nie was mit nem C-Compiler. Dann baust du lieber
nen Z8 nach, dafür gäbe es sogar ev. Nachfrage.
Josef G. schrieb:> Falls damit eine in Software realisierte Warteschleife> gemeint ist: Nein. Die CPU wird durch das Repeat-Signal> angehalten, bis ein Ereignis eintritt. Die Nummer der> Ereignisquelle wird bei Ende des Repeats eingelesen.>
Das ist ein no-go. Wenn du ohne Interrupts auskommen willst, dann nur
mit einer DMA-Engine. Aber dann mach gleich (min.) nen 16-Bitter draus.
> Eine Anwendung wäre, wie weiter oben schon geschrieben,> ein für jedermann verstehbarer Computer für Hobbyisten.
Nein. Das geht eher in Richtung obfuscated VHDL-Contest. Sorry.
Nach Jahren von vergebener Werbung für Dein HDL-Fermentat sollte sich
nun herausgestellt haben, dass dein CPU-Design nicht communitykompatibel
ist
Es gibt einen riesigen Berg von CPU-Cores, teils auch kommerziell, die
wenig Akzeptanz finden, weil ihnen folgendes Minimum (was heute unter
"anwenderfreundlich" verstanden wird) fehlt:
- Saubere Testbench und Verifikation
- Exception-Handling (auch Interrupts)
- C-Compiler (gcc), JTAG ICE debugger on board
- Standard-Bus (wishbone)
Schau dir mal den ZPUino an. DAS ist ein Referenzdesign, das sich einer
grossen Community erfreut. Den deutschsprachigen Raum hättest du noch
brachliegen, aber da müsstest du dich schon mal gegen Dennis K's mycpu
durchsetzen :-)
Reine 8-bit Cores auf dem FPGA haben spätestens seit der ZPU kein
wirkliches Pro-Argument zu bieten (Code-Dichte).
Wo Ihr grad bei den Hardware-Loops seid: Das ist alter Kaffee.
Beispiel Blackfin-Befehlssatz:
1
lsetup (l_begin, l_end) lc0 = p2;
2
l_begin:
3
r0 = w [p1++];
4
r0 >>= 2;
5
b[p0++] = r0;
6
l_end:
Das ist zudem noch lesbar wie C.
Bei einer 8bit-CPU ohne DSP-Funktionen ist dein "repeat" höchstens für
String-Copy a la 8086 zu brauchen.
Strubi schrieb:> Der Befehlssatz ist nach wie vor unleserlich
Inwiefern? Beispiel?
> So wird das nie was mit nem C-Compiler.
Dann geht's halt ohne C.
> Das ist ein no-go.
Warum?
> Das geht eher in Richtung obfuscated VHDL-Contest.
Inwiefern?
> Das ist alter Kaffee.
Ist es deshalb schlecht?
Josef G. schrieb:> wenn man einen für> jedermann verstehbaren Computer bauen will.
War das selbstironisch gemeint? Dein Projekt ist nämlich das genaue
Gegenteil: Ein Computer, den absolut niemand verstehen kann außer dir
selbst.
> Strubi schrieb:>> Der Befehlssatz ist nach wie vor unleserlich> Inwiefern? Beispiel?
Ich sage nochmal: Schau dir die ZPU mit ca. 13 Basis-Befehlen an, die
deskriptive Mnemonics haben. Dann vergleiche mit deinem Befehlssatz mit
kryptischen Mnemonics. Preisfrage: Was ist einfacher zu lernen?
>>> So wird das nie was mit nem C-Compiler.> Dann geht's halt ohne C.>
Dann musst du mindestens einen brauchbaren Assembler bereitstellen.
>> Das ist ein no-go.> Warum?>
Weil eine CPU NIE NIE aber auch gar NIE einfach anhalten und nichts mehr
tun soll. Darum. Damit schliesst du dich von der Fehlersuche in einer
Applikation schon mal aus, abgesehen von einer Menge anderer Probleme.
>> Das geht eher in Richtung obfuscated VHDL-Contest.> Inwiefern?>
Dein Code ist nicht descriptiv, sondern faktisch ein Gatter-Logikdesign
in VHDL ausgedrückt. Coverage unmöglich (dafür brauchst du einen saubere
Statemaschinenbeschreibung).
>> Das ist alter Kaffee.> Ist es deshalb schlecht?
Nein. Habe ich das gesagt? Nur ist dein Schleifenzähler keine Neuerung.
Strubi schrieb:> Ich sage nochmal:
Also keine Begründung mit Beispiel,
sondern nur eine Wiederholung der Behauptung
> Dann musst du mindestens einen brauchbaren Assembler
Den gibt es. Mag sein, dass er den Anforderungen von Profis nicht
genügt, das Projekt ist ohnehin vor allem für Hobbyisten gedacht.
> Weil eine CPU NIE NIE aber auch gar NIE einfach> anhalten und nichts mehr tun soll. Darum.
Ebenfalls keine Begründung, sondern
nur eine Wiederholung der Behauptung.
> Dein Code ist nicht descriptiv, sondern faktisch> ein Gatter-Logikdesign in VHDL ausgedrückt.
Seh ich auch so, und das war beabsichtigt. Ich möchte selber
die Kontrolle darüber haben, wie die fertige Hardware aussieht,
und nicht alles dem Synthese-Werkzeug überlassen.
Strubi schrieb:> Weil eine CPU NIE NIE aber auch gar NIE einfach anhalten und nichts mehr> tun soll.
Es gibt/gab durchaus CPUs, bei denen solche Befehle sinnvoll sind.
Gerade bei asynchronen (genauer: selbstgetakteten) CPU hat man so etwas
eingesetzt, um die Zugriffe auf Peripherieregister in anderen
Taktdomänen zu bewerkstelligen. Damit konnte man CPUs realisieren, die
während des Wartens auf externe Ereignisse nur noch ihre statische
Stromaufnahme hatten und ansonsten komplett taktlos waren. Ein Vertreter
solcher CPUs war z.B. der ARM Amulet 3H, der von der Uni Manchester und
Hagenuk entwickelt wurde. Beeindruckend bei diesem Baustein waren seine
um Größenordnungen niedrigere Stromaufnahme als vergleichbare synchrone
Designs und sein Störspektrum, welches kaum Spitzen aufwies, sondern
sehr "breit" war.
Solch eine CPU war schon hervorragend für sehr, sehr stromsparende
DECT-Mobilteile o.ä. geeignet, zumindest bezogen auf den Stand der
Technik von Mitte bis Ende der 1990er Jahre.
Josef G. schrieb:> Strubi schrieb:>> Ich sage nochmal:> Also keine Begründung mit Beispiel,> sondern nur eine Wiederholung der Behauptung>
Meine Begründung ist eine Begründung. Ich glaube, die meisten hier haben
sie auch verstanden.
Hast Du Dir die ZPU angesehen? [ ja | nein | keine Lust | nicht kapiert
] ?
Dann kommst du schon von selber drauf.
>> Dann musst du mindestens einen brauchbaren Assembler> Den gibt es. Mag sein, dass er den Anforderungen von Profis nicht> genügt, das Projekt ist ohnehin vor allem für Hobbyisten gedacht.>
Für einen Hobbyisten ist deine CPU nur Abschreckung. Wenn einfach, dann
mal beim 8051 anfangen, aufzuräumen. Nicht verkomplizieren, wie du es
tust.
>> Weil eine CPU NIE NIE aber auch gar NIE einfach>> anhalten und nichts mehr tun soll. Darum.> Ebenfalls keine Begründung, sondern> nur eine Wiederholung der Behauptung.>
Du hast offenbar das Problem nicht verstanden, und dir fehlt die Praxis,
was die Bedienung von CPUs angeht.
Abgesehen davon, dass in der Industrie obige Regel zum "Grundgesetz"
gehört, ist es für den Hobbyisten auch undurchsichtig, warum sein
Program mittendrin aufgrund eines externen Ereignisses komplett anhalten
soll.
Guck dir mal die Konzepte anderer CPUs an, da gibt es RESET und NMI.
Sonst darf die CPU nix stören. Alles andere ist schlicht Murks ohne
Sinn.
Es gibt IDLE-States mit Wakeup-Ereignissen. Aber das setzt Interrupts
voraus.
Dein Problem ist: Du hast eine CPU. Du suchst nur offenbar krampfhaft
die Anwendung.
Ich bin anwendungsorientiert, und meine erste Frage ist: Bin ich damit
schneller? Mit deiner CPU ist man das schlicht nicht, im Gegenteil. Man
schiesst sich schon absehbar ins Knie, weil grundsätzliche Dinge, die
seit den 80ern zum Standard gehören, fehlen. Somit wird man spätestens
bei einfachen Anwendungen merken, dass deine CPU lange nicht fertig ist,
sondern "broken by design". Warum sollte ich für frickeliges
Retro-Computing deine CPU evaluieren anstatt einen 8051?
>> Dein Code ist nicht descriptiv, sondern faktisch>> ein Gatter-Logikdesign in VHDL ausgedrückt.> Seh ich auch so, und das war beabsichtigt. Ich möchte selber> die Kontrolle darüber haben, wie die fertige Hardware aussieht,> und nicht alles dem Synthese-Werkzeug überlassen.
Und jeder wird Dir sagen, dass die Synthese die besseren Resultate
erzeugt, als deine von hinten durch die Brust gefrickelte Gatterlogik.
Denn die Synthese erkennt die Redundanzen im sauberen Design und hat
viel mehr Optimierungsspielraum als bei fixer codierung.
Das zeigt sich rein daran, dass div. sauber geschriebene ZPU-Kerne (32
bit) halb so wenig Logikzellen benötigen und deutlich schneller laufen
als dein Design.
Dein Code ist NULL wartbar, weder wiederverwertbar noch debugbar. Null.
Den würde dir jeder Projektleiter um die Ohren hauen.
Sorry für die nach wie vor vernichtende Kritik, aber ich beschäftige
mich jetzt schon zig Jahre mit CPU-Innereien (von VHDL bis zum
Sourcecode-Debugger) und denke mal, ich darf das :-)
Andreas S. schrieb:> Strubi schrieb:>> Weil eine CPU NIE NIE aber auch gar NIE einfach anhalten und nichts mehr>> tun soll.>> Es gibt/gab durchaus CPUs, bei denen solche Befehle sinnvoll sind.> Gerade bei asynchronen (genauer: selbstgetakteten) CPU hat man so etwas> eingesetzt, um die Zugriffe auf Peripherieregister in anderen> Taktdomänen zu bewerkstelligen. Damit konnte man CPUs realisieren, die> während des Wartens auf externe Ereignisse nur noch ihre statische> Stromaufnahme hatten und ansonsten komplett taktlos waren. Ein Vertreter> solcher CPUs war z.B. der ARM Amulet 3H, der von der Uni Manchester und> Hagenuk entwickelt wurde. Beeindruckend bei diesem Baustein waren seine> um Größenordnungen niedrigere Stromaufnahme als vergleichbare synchrone> Designs und sein Störspektrum, welches kaum Spitzen aufwies, sondern> sehr "breit" war.>
Das ist das, was ich mit obigen IDLE-States meine. Das läuft aber
umgekehrt, der Prozessor sagt: ich hab grad nix zu tun -> IDLE. Dann
kommt ein Wakeup-Event per Interrupt, dann läuft er weiter.
Die CPU level-getriggert beeinflussen darf nach Regel Nr. 1 NUR der
Reset. Ansonsten kann bei diesen asynchronen Geschichten auch ein
elektrischer Dauerhänger auftreten, wenn das externe HALT-Event noch
irgendwie vom Programmablauf bedingt ist. Das wird dann richtig spassig
zu debuggen.
Deswegen: Nicht unnötig ins Knie schiessen.
Strubi schrieb:> Dann kommst du schon von selber drauf.
Warum weigerst du dich, die Begründung auszuformulieren, und
sagst, ich soll selber drauf kommen? Bist du Psychoanalytiker?
Oder hast du in Wahrheit keine Begründung?
Strubi schrieb:> Für einen Hobbyisten ist deine CPU nur Abschreckung.
Schon wieder eine Behauptung ohne Begründung.
Strubi schrieb:> ist es für den Hobbyisten auch undurchsichtig, warum sein> Program mittendrin aufgrund eines externen Ereignisses> komplett anhalten soll.
Da gibt es offenbar ein Missverständnis. Die CPU wird zwar
durch ein externes Repeat-Signal angehalten. Die externe
Hardware, welche das Repeat-Signal betätigt, wird jedoch im
Normalfall durch die CPU dazu aufgefordert. Die CPU führt
einen IO-Befehl H.. aus, und die externe Hardware unterbricht
die H..-Operation, bis die Input-Daten bereitstehen oder ein
entsprechendes Ereignis eintritt.
Strubi schrieb:> Ich bin anwendungsorientiert,
Dann ist meine CPU offenbar nichts für dich. Vielleicht
ist sie aber etwas für Leute mit anderen Zielsetzungen.
Strubi schrieb:> Somit wird man spätestens bei einfachen Anwendungen merken,> dass deine CPU lange nicht fertig ist, sondern "broken by design".
Schon wieder eine Behauptung ohne Begründung.
Falk B. schrieb:> Und schon wieder hat der Josef willige Opfer gefunden, die gern und> ausdauernd mit einer kommunikations- und lernunfähigen Person reden . .> .
Du meinst, sie könnten genauso gut bei Kurt weiter machen um die 10000
zu vollenden? ;-)
Strubi schrieb:> Das ist das, was ich mit obigen IDLE-States meine. Das läuft aber> umgekehrt, der Prozessor sagt: ich hab grad nix zu tun -> IDLE. Dann> kommt ein Wakeup-Event per Interrupt, dann läuft er weiter.
Nein, beim Amulet-3H führte wirklich der Registerzugriff zum Anhalten
des Prozessors. Bei solchen asynchronen Designs werden Handshakesignale
mitgeführt. Wenn der Handshake ausbleibt, geht es auch nicht weiter. Bei
normalen Registerzugriffen wird das Handshake natürlich sofort nach
Übernahme bzw. Bereitstellung der Daten erzeugt, aber den den erwähnten
speziellen Registern bestand eben die Besonderheit darin, dass der
Handshake eben so lange verzögert wurde, bis es wieder etwas für den
Prozessor zu tun gab. Natürlich war das eine durchaus heikle
Angelegenheit. Im konkreten Fall ging es um Lesezugriffe auf eine Art
Interruptstatusregister. Eigentlich ist das Verhalten exakt das gleiche
wie bei einem "normalen" Prozessor, den man in einen tiefen
Power-Down-Zustand schickt, abgesehen von der überhaupt nicht
vorhandenen Taktung.
Ich erinnere mich leider nicht mehr daran, ob bzw. wie Interrupts bei
Amulet-3H realisiert waren bzw. ob diese verwendet werden konnten.
> Die CPU level-getriggert beeinflussen darf nach Regel Nr. 1 NUR der> Reset. Ansonsten kann bei diesen asynchronen Geschichten auch ein> elektrischer Dauerhänger auftreten, wenn das externe HALT-Event noch> irgendwie vom Programmablauf bedingt ist.
Ja, genau solch ein Dauerhänger kann durchaus auftreten.
> Das wird dann richtig spassig zu debuggen.
Wieso? Der Prozessor steht doch, und man kann per (extern getaktetem)
JTAG o.ä. die statischen Signale auslesen. Einfacher geht es doch nun
wirklich nicht mehr.
> Deswegen: Nicht unnötig ins Knie schiessen.
Das wesentlich größere Problem war die mangelnde Eignung der üblichen
ASIC-Toolchain, da einem natürlich solch ein Design wegen
kombinatorischer Schleifen usw. um die Ohren gehauen wird. Auch die
Simulationswerkzeuge zeigen da wohl so manche Sonderbarkeit. Viele der
beim Entwurf normaler synchroner Logik sehr wertvolle dezente Hinweise
der Toolchain sind bei solchen asynchronen Designs nicht nutzbar. Ich
hatte mich damals aber nicht damit befassen dürfen, sondern nur einige
meiner damaligen Kollegen. Ich selbst war bloß dafür zuständig, mich mit
einem USB-Funktionsblock zu beschäftigen, der über ein synchrones
AMBA-Interface mit dem eigentlichen Amulet-3H-Kern verbunden war. Der
Hersteller dieses Blocks (VLSI, später Philips, NXP) hatte damals
(1997/1998) aber noch genauso wenig Ahnung von USB wie wir. Leider kam
damals die große Hagenuk-Pleite dazwischen, so dass zwar noch die
Bausteine des ersten Tape-Outs geliefert wurden, aber außer ein paar
sehr interessantes Testprogrammen, Benchmarks und obigen Messungen zur
EMV passierte da nicht mehr viel.
Rufus Τ. F. schrieb:> Das Ding hat keinen Stack, bzw. kann nur genau eine Rücksprungadresse> verwalten?>> Hast Du Dir schon mal Gedanken darüber gemacht, wie man für so etwas> einen Hochsprachencompiler anpassen soll?
FORTRAN (in Großbuchstaben, also bis Version 77) ist bestens geeignet
für stackless Architekturen. In FORTRAN gibt es garantiert keine Stack-
Overflows. Da auch sonst der Speicher zu 100% statisch verwaltet wird,
ist der Speicherbedarf eines Programms schon vor dessen Ausführung exakt
bekannt, was gerade bei kleineren Mikrocontrollern einen großen Vorteil
darstellt.
Und wer braucht schon etwas anderes als FORTRAN? Heute meint zwar jeder,
er müsste in irgendeiner neumodischen Hipster-Sprache (wie bspw. C#)
programmieren und wundert sich dann, dass er damit ständig auf die Nase
fällt.
Sinus T. schrieb:> Ganze Generationen von CPUs kamen ohne Hardware-Stack aus. Mir fallen da> auf die Schnelle die NOVA, PDP/8 und HP1000 (und Vorgänger) ein.
Die CDC-6000-Serie war ebenfalls ein prominenter Vertreter dieser
Klasse.
> Bei der Nova wurde die Rücksprungsadresse in AC3 gespeichert (AC0..AC3> sind deren Akkumulatoren), bei der PDP8 und HP1000 im jeweils ersten> Wort der Subroutine.
So auch bei der CDC 6000. Dafür gab es den Befehl RJ (Return Jump), der
vor dem eigentlichen Sprung den Programmzähler in dem Speicherwort vor
dem eigentlichen Sprungziel sicherte.
Josef, du bist also absolut auf dem richtigen Weg!
... in die Vergangenheit ;-)
> Strubi schrieb:>> Dann kommst du schon von selber drauf.> Warum weigerst du dich, die Begründung auszuformulieren, und> sagst, ich soll selber drauf kommen? Bist du Psychoanalytiker?> Oder hast du in Wahrheit keine Begründung?>
Solange du meine Frage nicht beantwortest, ob du Dir auch andere
Architekturen angesehen hast (vergleiche Asm ZPU und bo8!), werde ich
nicht weiter mit Dir diskutieren.
Ich werde den Teufel tun, und hier gegen Windmühlen kämpfen, die
irgendwie in die andere Richtung drehen.
> Strubi schrieb:>> Für einen Hobbyisten ist deine CPU nur Abschreckung.> Schon wieder eine Behauptung ohne Begründung.>
Siehe obige Begründungen. Ich wiederhole mich:
- Unlesbare HDL und Assemblermnemonics
- Kaum dokumentierte Tools
- Fehlende Referenzapplikationen und Vorteile
Du sammelst hier nur Negativ-Echo. Jetzt gehst du mal hin, schaust Dir
die Community auf papilio.cc an (ZPUino), dann kommst du wieder, und
ziehst Bilanz. Die Renitenzenergie steckst du lieber in eine
Neuentwicklung.
Josef G. schrieb:> Da gibt es offenbar ein Missverständnis. Die CPU wird zwar> durch ein externes Repeat-Signal angehalten. Die externe> Hardware, welche das Repeat-Signal betätigt, wird jedoch im> Normalfall durch die CPU dazu aufgefordert. Die CPU führt> einen IO-Befehl H.. aus, und die externe Hardware unterbricht> die H..-Operation, bis die Input-Daten bereitstehen oder ein> entsprechendes Ereignis eintritt.
Dann ist das wohl nur ein Software-Wait-State. Das geht natürlich, wenn
die Peripherie mitmacht. Die CPU kann sich mit deinem H-Befehl dann im
Prinzip lahmlegen, wenn sie ein Event verpasst (ewiger "STALL"). Nicht
sonderlich robust...
>> Somit wird man spätestens bei einfachen Anwendungen merken,>> dass deine CPU lange nicht fertig ist, sondern "broken by design".> Schon wieder eine Behauptung ohne Begründung.
Die Begründungen wurden bereits mehrmals gegeben.
Ich würde mir als erstes mal überlegen, warum KEINER offenbar Lust hat,
sich den verschwurbelten Befehlssatz, der sich sogar ab und an noch zu
ändern scheint, im Detail anzuschauen, geschweige denn sich wegen der
redundanten ALU-Befehle mit dir streiten zu wollen.
Ganz subjektiv: Dein Befehlssatz ist einfach nicht elegant. Vergleiche
mit anderen Architekturen. Die Arbeit soll der Assembler machen, nicht
der User.
Schau, es gibt jedes Jahr an die 20-30 Studenten, die ihre eigene CPU
schreiben. Das soll auch so, denn die sollen ja was lernen.
Ab und an ist auch mal ne Neuerung dabei, aber spätestens nach Abgabe
des Papers lassen sie uns (bzw. das Forum) auch damit in Ruh und keins
dieser Designs landet in der freien Wildbahn (Das AVR-Design ist ne
Ausnahme :-) )
Wir alle haben Respekt vor dem Aufwand, der beim CPU-Design fällig wird.
Nur sollte nach Jahren von Einsammeln von Kritik vielleicht auch mal
eine Verbesserung eintreten, sonst nervt die alte Leier.
Andreas S. schrieb:> Wieso? Der Prozessor steht doch, und man kann per (extern getaktetem)> JTAG o.ä. die statischen Signale auslesen. Einfacher geht es doch nun> wirklich nicht mehr.
Ja, wenn man denn JTAG hat. Ich sehe da kein Debug-IF bei der bo8. Trägt
nicht zur "Einfachheit" bei..
Strubi schrieb:> Ja, wenn man denn JTAG hat. Ich sehe da kein Debug-IF bei der bo8. Trägt> nicht zur "Einfachheit" bei..
Meine Ausführungen bezogen sich nicht auf die bo8, sondern auf
asynchrone Stromsparprozessoren wie Amulet-3H.
Gründe, warum die CPU für jedermann verstehbar ist:
Die Adressregister X,Y,Z sind vollständig gleichberechtigt.
Es gibt nur eine Adressierungsart.
Es gibt keine Flags ausser dem Carry. Der Programmierer muss
nicht ständig nachdenken, wie welche Flags beeinflusst werden.
Bei den Verzweigungen wird zwischen Vor- und Rückwärts-Sprüngen
unterschieden. Die 8-Bit-Distanz ist nicht vorzeichenbehaftet.
Es gibt keine Compare-Befehle, welche bei anderen CPUs
häufig Anlass für Unklarheiten über die Flags geben.
Die Dauer von Befehlsfolgen ist sehr einfach zu ermitteln.
Der Programmierer muss nicht ständig mögliche Interrupts
im Auge behalten, weil es solche nicht gibt.
Josef G. schrieb:> Es gibt keine Flags ausser dem Carry. Der Programmierer muss> nicht ständig nachdenken, wie welche Flags beeinflusst werden.> Es gibt keine Compare-Befehle, welche bei anderen CPUs> häufig Anlass für Unklarheiten über die Flags geben.
Diese Ziele lassen sich auch eleganter verfolgen. Flags weglassen, beim
Vergleich ein ja/nein-Resultat in einem normalen Register hinterlegen
und abhängig von Registerinhalt springen. Oder Vergleich und Sprung in
einem Befehl kombinieren. Da gibts nullkommagarkeine Unklarheiten.
> Der Programmierer muss nicht ständig mögliche Interrupts> im Auge behalten, weil es solche nicht gibt.
Wenn ein Programmierer mit Interrupts nicht leben kann, dann soll er sie
eben nicht einsetzen.
Transputer, Propeller und XMOS haben auch keine, bieten aber ersatzweise
andere Lösungen für jene Aufgaben, derentwegen man Interrupts eingeführt
hat.
A. K. schrieb:> Diese Ziele lassen sich auch eleganter verfolgen. Flags weglassen, beim> Vergleich ein ja/nein-Resultat in einem normalen Register hinterlegen> und abhängig von Registerinhalt springen. Oder Vergleich und Sprung in> einem Befehl kombinieren. Da gibts nullkommagarkeine Unklarheiten.
Da kann man streiten, ob das elegant ist.
Jedenfalls ist es extrem CISC.
Josef G. schrieb:> Jedenfalls ist es extrem CISC.
Ich beschrieb die Methoden von Alpha und MIPS. ;-)
Die sind beide nicht wirklich als extrem CISC bekannt.
Josef G. schrieb:> dort ist aber bisher kaum> jemand sachlich auf den Befehlssatz eingegangen.> Befehlssatz der bo8-CPU - was ist gut, was ist schlecht
Ich finde es schade, dass sich niemand ernsthaft mit der Fragestellung
beschäftigt und stattdessen lieber am Konzept der CPU herumnörgelt.
Daher will ich mal den Anfang machen, unter Berücksichtigung, dass die
CPU sich ja gerade an Einsteiger richtet.
Ich finde es wichtig, dass die Befehlsnamen (Mnemonics) einprägsam sind
und eine gute Assoziation zur Funktion des Befehls ermöglichen. Unter
diesem Aspekt habe ich mir die Befehlstabelle (32 Zeilen 00- bis f8-)
auf der verlinkten Seite mal angesehen.
Zunächst fällt auf, dass es keine Sprungbefehle (JMP oder JSR - RTS)
gibt. Weiter oben im Thread gibt es ja auch schon eine Diskussion zu
Problemen mit Unterprogrammen.
Ich finde es gerade für Einsteiger gut, sie nicht mit Sprüngen zu
verwirren. Es ist kaum nachvollziehbar, warum man ein Programm woanders
fortsetzen soll, wenn es genau so gut auch an dieser Stelle weitergehen
könnte.
Ohne Sprünge ist auch ein PAP viel einfacher nachvollziehbar, einfach
eine gerade Linie von Start bis Ende, ohne Firlefanz.
Unterprogramme sind gerade für Einsteiger auch nicht erforderlich, wobei
ich den Begriff "Unterprogramm" auch schon diskriminierend finde.
Bedingte Sprungbefehle habe ich auch nicht entdeckt (BRA, BZC, BZS). Die
Abhängigkeit zu den CPU-Flags ist für Anfänger ja auch nur schwer
nachvollziehbar. Das Zero-Flag geht ja noch. BCS (Branch if Zero Set)
springt, wenn das Ergebnis der vorherigen Operation Null ist. Aber
Overflow und Carry-Flags sind eher schwer nachvollziehbar. Was ist
gesetzt, wenn bei einem vorhergehenden Vergleich der Wert größer oder
kleiner oder größer-gleich war? Ich muss da auch immer in der Doku
nachschlagen.
Hier kann ich den Verzicht gut nachvollziehen.
Als nächstes betrachte ich ein paar Befehle aus der Tabelle. Da ich
keine Beschreibung zu den Befehlen gefunden habe, schreibe ich, was mir
am wahrscheinlichsten erscheint.
1
40- O.VZ
Name: Opcode-VZ
Funktion:
Soziales Netzwerk (wie Studi-VZ) für Opcodes. Hier können sich die
Opcodes der CPU darüber austauschen, warum sie niemand mag.
1
46- BU.Z
Name: BUZ
Funktion:
Ist mir nicht klar, aber ich muss gerade an meine
Transistor-Vergleichstabelle aus den 70er Jahren denken. Kinder, wie die
Zeit vergeht...
1
56- GTA
Name: Grand Theft Auto
Funktion:
Hommage an die erfolgreichste Computerspiel-Serie.
1
57- NON
Name: No Operation Never (with this CPU)
Funktion:
Währen andere CPUs bei einem NOP-Befehl sinnlos Rechenzeit verbummeln,
dient der NON Befehl dazu, die CPU kurzfristig zur Höchstleistung zu
treiben.
Alle internen Register, mit Ausnahme des Adresszählers, werden
invertiert (Maximaer Aktionismus). Anschließend wird das Programm 42
Adressen weiter hinten fortgesetzt (Marathon-Distanz).
Es wird empfohlen, den Befehl paarweise im Abstand von 42 Adressen
anzuwenden, anschließend kann das Programm wie ursprünglich fortgesetzt
werden.
Addition / Subtraktion
Auf der Suche nach Rechenbefehlen (irgend was sinnvolles muss die CPU
doch können) wurde ich nicht fündig, zumindest bin ich mir nicht sicher.
Mir sind folgende zwei Befehle aufgefallen.
1
a6- AD.S
2
a7- SD.s
AD könnte Addition bedeuten, aber SD? - Vielleicht mit sächsischem
Dialekt (SubDragdsion).
1
c3- R.US
Name: (Toys.R.US)
Funktion:
Dieser Befehl wird für Spiele benötigt. Elementar wichtig für die
einzige Applikation, die es für die CPU bisher gibt (Game Of Life).
Viele weitere werden bald folgen (Daumendrück...)
> Befehlssatz der bo8-CPU - was ist gut, was ist schlecht
Wo viel Licht ist, ist auch Schatten.
1
02- SS.X
2
4c- O.KZ
Befehle mit SS odr KS gehen gar nicht. Sollten dringendst entfernt oder
umbenannt werden.
Vielleicht liege ich mit meinen Vermutungen falsch und die Befehle haben
eine ganz andere Funktion. Dann wäre es hilfreich, zu jedem Befehl eine
kurze Beschreibung, gerne auch mit Programmbeispiel, aufzuschreiben.
Es sollte auch erwähnt werden, welche Worte mit den Abkürzungen
Assoziiert werden sollen. Aber das wurde ja schon oft vorgeschlagen.
Die Botschaft dieser CPU für Anfänger ist klar. "Ihr versteht jetzt
Bahnhof. Und wenn Ihr dieses Hobby zu eurem Beruf macht, geht es das
ganze Leben lang so weiter."
Josef G. schrieb:> Strubi schrieb:>> wegen der redundanten ALU-Befehle>> ??
Jetzt nochmal ganz deutlich - aber ich glaube, das haben bereits einige
versucht:
1
XR. nn A wird A xor nn
2
XRM% | XR.B A wird A xor op
Warum zum Geier nimmst du dafür ein schwer zu merkendes Konstrukt wenn
es auch so geht:
1
xor a, <argument>
Schreibe <argument> entweder immediate oder Registerspec. Der Assembler
hat das aufzulösen. SO etwas macht die Bedienung einfach.
Da du dich offenbar konsequent weigerst, andere Architekturen anzusehen,
fürchte ich, wirst du dich weiter in Scheinargumente verrennen.
> Die Adressregister X,Y,Z sind vollständig gleichberechtigt.> Es gibt nur eine Adressierungsart.>
Ja, und? Der msp430 (PDP/11) bspw. unterscheided nicht mal zwischen
Daten/Adressregister.
Dafür hat er einen anständigen Stack.
> Es gibt keine Flags ausser dem Carry. Der Programmierer muss> nicht ständig nachdenken, wie welche Flags beeinflusst werden.>
Standard bei RISC, manche haben nicht mal carry. Gut dokumentierte
ALU-Flags sind jedoch hilfreich bei DSP-Ops.
> Bei den Verzweigungen wird zwischen Vor- und Rückwärts-Sprüngen> unterschieden. Die 8-Bit-Distanz ist nicht vorzeichenbehaftet.>
Kein Vorteil, sondern Nachteil. Wenn du deinen Code umstrukturierst,
musst du Befehle ändern. Doof. Sowas überlässt man dem Linker.
> Es gibt keine Compare-Befehle, welche bei anderen CPUs> häufig Anlass für Unklarheiten über die Flags geben.>
Man kann es auch elegant lösen (auch RISC):
1
beq #0, d0, label
2
call (d0)
3
label:
4
rts
> Die Dauer von Befehlsfolgen ist sehr einfach zu ermitteln.>
Standard bei fast jedem RISC, und DSP. Steht im Processor-Manual. Dein
Prozessor arbeitet aber dank des H..-Befehls offenbar nicht
deterministisch...
> Der Programmierer muss nicht ständig mögliche Interrupts> im Auge behalten, weil es solche nicht gibt.
Ich unterschreibe A.K.'s Aussage.
So am Rande: Ich habe vor ca 2 Jahren etwa an die 8 Softcores (mit
existierender toolchain) durchgetestet, davon hatten ca. 5 kein wirklich
funktionierendes bzw. robustes Exception-Handling (grundsätzlich nötig
für IRQ-Support und In-Circuit-Debugging).
Der Grund war meistens, dass die Hazard-Szenarien unvollständig
abgedeckt waren. D.h. es gibt Code, der sieht zwar korrekt aus,
produziert aber falsche Resultate, wenn eine Exception (IRQ)
dazwischenfunkt.
Das sind verständliche Gründe, Interrupts nicht zu implementieren, aber
spricht nicht für einen robusten Systemprozessor, denn aus Erfahrung
tauchen diese Hazards dann woanders (beim Assemblerprogrammierer)
plötzlich auf und machen das Leben schwer.
Deshalb mein Credo: Beim CPU-Design als erstes Exception-Handling
einbauen/verifizieren.
Apropos, es gibt auch noch einen Grund, keine Doku zu schreiben: Beim
Dokumentieren und Durchdenken fallen nämlich oft die grundsätzlichen
Fehler auf :-)
Und an WernerWeakend: Ich bin amüsiert (an Grand Theft Andreas dachte
ich auch schon...)
Und wo wir grad dabei sind: Ist dann der Befehl 02 und 4c Teil des
Überprogramms?
Strubi schrieb:> Der Grund war meistens, dass die Hazard-Szenarien unvollständig> abgedeckt waren. D.h. es gibt Code, der sieht zwar korrekt aus,> produziert aber falsche Resultate, wenn eine Exception (IRQ)> dazwischenfunkt.
Solche Probleme haben manche Designs derart geplagt, dass sie erst Jahre
später rauskamen, zeitlebens ein interessantes Büchlein über zu
vermeidende Szenarien mitführten oder der Laden unterwegs Pleite ging.
Zilogs Z8000 wurde in random logic implementiert, statt wie 8086 oder
68000 in Microcode. Bis sie das im Griff hatten ... Automatisches Design
gab es noch nicht, FPGAs auch nicht und Simulation war l-a-n-g-s-a-m.
Die 32000er Reihe von NS war bös mit Bugs gespickt.
Die zweite grössere Transputer-Generation machte dem Berliner Airport
alle Ehre, was Verzögerung angeht.
Beim Versuch, die VAX ernsthaft zu beschleunigen, ging die ehedem sehr
erfolgreiche Firma DEC fast pleite.
Werner WeakEnd schrieb:> Zunächst fällt auf, dass es keine Sprungbefehle> (JMP oder JSR - RTS) gibt.
Es gibt den Sprungbefehl J.., der für Sprünge, Unterprogramm-
Aufrufe und Rückkehr aus Unterprogrammen verwendbar ist.
> Bedingte Sprungbefehle habe ich auch nicht entdeckt (BRA, BZC, BZS).
Bedingte Sprünge sind
1
O.VZ Vorwärtssprung falls V=0
2
O.VS Vorwärtssprung falls nicht V=0
3
O.UZ Vorwärtssprung falls U=0
4
O.US Vorwärtssprung falls nicht U=0
5
O.AZ Vorwärtssprung falls A=0
6
O.AS Vorwärtssprung falls nicht A=0
7
O.KZ Vorwärtssprung falls K=0
8
O.KS Vorwärtssprung falls nicht K=0
9
10
B.VZ Rückwärtssprung falls V=0
11
B.VS Rückwärtssprung falls nicht V=0
12
B.UZ Rückwärtssprung falls U=0
13
B.US Rückwärtssprung falls nicht U=0
14
B.AZ Rückwärtssprung falls A=0
15
B.AS Rückwärtssprung falls nicht A=0
16
B.KZ Rückwärtssprung falls K=0
17
B.KS Rückwärtssprung falls nicht K=0
Hinzu kommen
1
O.WY Vorwärtssprung always
2
B.WY Rückwärtssprung always
3
B.CN Rückwärtssprung mit Zählvorgang
O steht für omit, B steht für back.
CN steht für counting> 56- GTA
GTA steht für get absolute
1
GTA nn lädt K mit 00nn
Analog dazu gibt es GTR, das steht für get relative
1
GTR nn lädt K mit P+nn+3
> 57- NON
NON No Operation, das zweite N steht für number
NON nn dauert 2+nn Zyklen
Der Befehl ist nützlich zB. bei if-else-Strukturen, um den
schnelleren Zweig auf die Dauer des langsameren Zweigs zu
verlängern, so dass die Dauer bedingungsunabhängig wird.
Der Befehl hat eine spezielle andere Funktion falls nn = 00
> a6- AD.S> a7- SD.s
1
AD.S addiere S zu K
2
SD.S subtrahiere S von K
3
LD.S reverse Subtraktion
das L steht für lessen
1
AV.S addiere S zu K mit Carry(V)
2
SV.S subtrahiere S von K mit Carry(V)
3
LV.S reverse Subtraktion mit Carry(V)
Das D bei AD,SD,LD dient der Unterscheidung von der
entsprechenden Operation mit Carry und hat keine Bedeutung,
eventuell könnte man denken an direct.
> c3- R.US
R.US Repeat falls nicht U=0
Die Schleifenstartadresse steht im Register R.
> 02- SS.X
SS.X Speichere S in X
> 4c- O.KZ
O.KZ wurde oben bereits erklärt.
> Vielleicht liege ich mit meinen Vermutungen falsch und die Befehle haben> eine ganz andere Funktion. Dann wäre es hilfreich, zu jedem Befehl eine> kurze Beschreibung, gerne auch mit Programmbeispiel, aufzuschreiben.> Es sollte auch erwähnt werden, welche Worte mit den Abkürzungen> Assoziiert werden sollen. Aber das wurde ja schon oft vorgeschlagen.
Das könnte man machen. Das ergäbe vielleicht einen Text
von 20 Seiten. Deshalb habe ich das bisher nicht gemacht.
Wenn jemand die Seite CPU-doku aufmerksam liest, findet er
dort alle Informationen. Natürlich ist es nicht damit getan,
die Seite nur zu überfliegen. Aber die eine Seite ersetzt
eben die 20 Seiten, die man sonst lesen müsste.
Josef G. schrieb:> Das könnte man machen. Das ergäbe vielleicht einen Text> von 20 Seiten. Deshalb habe ich das bisher nicht gemacht.> Wenn jemand die Seite CPU-doku aufmerksam liest, findet er> dort alle Informationen. Natürlich ist es nicht damit getan,> die Seite nur zu überfliegen. Aber die eine Seite ersetzt> eben die 20 Seiten, die man sonst lesen müsste.
YMMD!
Gerade für den Anfänger unglaublich hilfreich. Eine Doku gemacht von
Autisten für Autisten...
http://www.bomerenzprojekt.de/Website/CPU-doku.html
Das ganze ist doch für den Anfänger so hilfreich wie ein Rezept für ein
leckeres Gericht für den Verhungernden.
Mit der Doku werden 100% aller Anfänger erkennen, daß MINT nichts für
sie ist.
Josef G. schrieb:> Das könnte man machen. Das ergäbe vielleicht einen Text> von 20 Seiten. Deshalb habe ich das bisher nicht gemacht.
Und da wunderst du dich ernsthaft, dass sich niemand mit deinem Softcore
beschäftigen will? Der geneigte potentielle Anwender muss sich also erst
alles aus einer einzigen Seite zusammensuchen? Warum diese nicht auch
weglassen und gleich auf den kruden Quelltext verweisen. Da steht doch
alles ganz genau drin und man lernt auch gleich, wie VHDLnicht zu
coden ist.
> Wenn jemand die Seite CPU-doku aufmerksam liest, findet er> dort alle Informationen. Natürlich ist es nicht damit getan,> die Seite nur zu überfliegen. Aber die eine Seite ersetzt> eben die 20 Seiten, die man sonst lesen müsste.
Soll das ein neues pädagogisches Konzept sein? Funktioniert nicht!
Deine Arbeit in allen Ehren, aber damit bist du ca. 30 bis 40 Jahre zu
spät dran. In dieser Zeit hättest Du mit deinen Konzepten evtl. noch das
ein oder andere zur Entwicklung beitragen können. Aber heute gibt es en
masse ausgereifte CPUs mit Doku, Toolchain, Community etc.
Sorry, aber dein Konzept ist weder Fisch noch Fleisch. Es gibt keine
ordentliche Doku, keine wirkliche Toolchain und bisher niemanden, der
sich wirklich damit beschäftigt hat - außer du selbst. Warum wohl?
Für Profis also nicht zu gebrauchen und für Einsteiger viel zu konfus.
Wer ist also deine Zielgruppe?
Bitte tue dir selbst einen Gefallen und höre damit auf, deine Arbeit als
eine wichtige Bereicherung der Softcore-Landschaft zu sehen. Das ist sie
definitiv nicht!
Wie wäre es z.B. stattdessen einen ATMEGA-Softcore zu entwickeln oder
bestehende weiter zu treiben? Ich könnte mir vorstellen, dass daran mehr
Interesse besteht als an deiner Architektur. Dann brauchst du auch kaum
noch Doku schreiben und eine Toolchain entwickeln - gibt's schon alles!
Was genau ist deine Zielgruppe?
Bastler und Hobbyisten verstehen deine "Dokumentation" nicht. Sie
verstehen daher dein System auch nicht.
Diejenigen, die genug von der Materie verstehen, um sich in dein System
einarbeiten zu können, wenden sich angewiedert ab, weil es kryptisch und
nutzlos ist.
Du hast genug Kontra bekommen. Magst du darauf auch reagieren?
Da hält sich jemand für Napoleon und das ganze Forum versucht ihm zu
erklären, dass er nicht Napoleon ist.
Der Erfolg? Null, nada, niente, das hat auch keine Chance, Bome wird
immer glauben, er wäre Napoleon, da er bereits Jahre darauf
hingearbeitet hat, Napoleon zu sein.
Würde er nicht mehr an sich - Napoleon - glauben, würde er all die Jahre
verlieren, das kann er nicht, ergo geht das Spielchen hier immer weiter.
Das Topic wurde doch nicht eröffnet, die Frage nach Verbesserungen doch
nicht gestellt, um eine tatsächliche Verbesserung zu erzielen. Das Topic
wurde eröffnet um erneut Aufmerksamkeit zu generieren.
Auch der negativste Widerspruch bedeutet immer noch Aufmerksamkeit und
Napoleon kann seinen Schlachtplan verteidigen und die benötigte
Aufmerksamkeit erhalten. Der hat einfach 'nen Hau, wenn auch 'nen
harmlosen, da er niemanden außer sich schadet.
> Warum ... nimmst du dafür ein schwer zu merkendes Konstrukt
XRM% ist Sammelbezeichnung für XRMX, XRMY, XRMZ. Das % steht
nur in der Dokumentation und kommt im Assembler nicht vor.
1
XR. nn A wird A xor nn
2
XR.B A wird A xor B
3
XRMX A wird A xor Mem.X
Mit Mem.X ist gemeint die Speicherzelle, auf welche X zeigt.
Ich sehe nicht, was daran schwer zu merken sein soll.
> wenn es auch so geht:
1
> xor a, <argument>
Wo soll da der Vorteil sein? Das wäre unnötige mehr-Tipparbeit.
Bei xor ist der erste Operand immer A, das A braucht man deshalb
nicht hinschreiben. Und mir würde auch nicht gefallen, dass das-
selbe Mnemonic xor sowohl bei Register-Operand (1 Zyklus)
als auch bei Speicher-Operand (2 Zyklen) verwendet wird.
Beim 6502-Assembler gab es zB. diese Befehle:
1
TAX Transferiere A nach X
2
TAY Transferiere A nach Y
3
4
INX Incrementiere X
5
INY Incrementiere Y
Da hat sich auch niemand dran gestört.
>> Es gibt keine Flags ausser dem Carry. Der Programmierer muss>> nicht ständig nachdenken, wie welche Flags beeinflusst werden.>> Standard bei RISC, manche haben nicht mal carry.
Spricht das gegen meine CPU?
>> Bei den Verzweigungen wird zwischen Vor- und Rückwärts-Sprüngen>> unterschieden. Die 8-Bit-Distanz ist nicht vorzeichenbehaftet.>> Kein Vorteil, sondern Nachteil. Wenn du deinen Code> umstrukturierst, musst du Befehle ändern.
Wenn man gezwungen ist, im Assembler-Quelltext den Code umzustellen,
dann ist damit verglichen der zusätzliche Aufwand (Ersetzen
eines O durch ein B oder umgekehrt) vernachlässigbar.
Im Übrigen ist der Hauptvorteil meiner Lösung, dass man in
beiden Richtungen die volle 256-Byte-Distanz zur Verfügung hat.
Und es entfällt der sonst theoretisch mögliche
unsinnige Sprung auf das Distanz-Byte.
Beim Rückwärtssprung mit Zählvorgang B.CN wäre ausserdem
der entsprechende Vorwärtssprung nicht sinnvoll. Beim
Z80-Befehl djnz dürfte es schwer fallen, eine sinnvolle
Anwendung für positive Distanz zu finden.
>> Es gibt keine Compare-Befehle, welche bei anderen CPUs>> häufig Anlass für Unklarheiten über die Flags geben.>> Man kann es auch elegant lösen (auch RISC):
1
> beq #0, d0, label
2
> call (d0)
3
> label:
4
> rts
Den Code versteh ich nicht, und ob das elegant ist,
da kann man sicher drüber streiten.
>> Die Dauer von Befehlsfolgen ist sehr einfach zu ermitteln.>> Standard bei fast jedem RISC, und DSP.
Spricht das gegen meine CPU?
> Dein Prozessor arbeitet aber dank des H..-Befehls> offenbar nicht deterministisch...
Die CPU wird bei H.. nur angehalten, wenn zB. auf Input
von einem externen Gerät gewartet werden muss. Bei meinem
8bit-Computer wird H.. zB. verwendet für das Beschreiben
der Schatten-Pageregister, da gibt es kein Warten.
> Beim 6502-Assembler gab es zB. diese Befehle:> TAX Transferiere A nach X> TAY Transferiere A nach Y>> INX Incrementiere X> INY Incrementiere Y> Da hat sich auch niemand dran gestört.
Stimmt, den hab ich nämlich nie benutzt.
Und zwar vor 35+ Jahren.
Hallo,
Josef G. schrieb:> Wenn man gezwungen ist, im Assembler-Quelltext den Code umzustellen,> dann ist damit verglichen der zusätzliche Aufwand (Ersetzen> eines O durch ein B oder umgekehrt) vernachlässigbar.
auch zu meinen Z80 und 6510-Zeiten gabe es schon Label.
Auch beim AVR-Assembler gibt es die. Eine Umstellung ist also erstmal
Text verschieben usw.
Natürlich gibt es dann auch da meist Gemecker, weil die Sprungdistanz
relativer Sprüge nicht mehr passt.
Passiert dann ja hoffentlich bei Deinem Assembler auch, nicht daß der
dann nicht merkt, daß das Ziel jetzt rückwärts statt vorwärts liegt.
Aber Du hattest ja schon erwähnt, daß Anwenden für Deine CPU kein
Kriteriem ist, insofern muß man dann garnichts prüfen oder ändern, daß
Programm muß ja sowieso nicht laufen, soll ja nicht angewendet werden.
Carl Drexler (jcw2):
> TAX Transferiere A nach X> TAY Transferiere A nach Y>> INX Incrementiere X> INY Incrementiere Y
gerade damit und im Zusammenspiel mit der Zeropage konnte man aber sehr
nett Sachen machen, zur Laufzeit berechnete Sprungtabellen, Loops zum
Kopieren usw.
War beim Z80 mit den EX-Befehlen doch auch so, man mußt erst entdecken,
wo man die wie einsetzt, genauso die Block-Befehle.
Ich habe auf einem MC6800 angefangen, da hatte man das Theater mit
zuvielen Registern sowieso nicht, der Ansatz, 2 gleichwertige Akkus zu
haben, war aber durchaus auch praktisch.
Vergleiche mit aktuellen CPUs würde ich hier sowieso nicht machen, deren
Befehlssätze sind meist von Compiler für Hochsprachen beeinflußt.
Gruß aus Berlin
Michael
So mein Fazit als Informatiker mit noch wenig Erfahrung im Bereich
Prozessorarchitektur, wobei ich ein bisschen mit x86, AVR, ARM vertraut
bin. Bei ARM habe ich aber nur Assembler gelesen, nie wirklich was
selber geschrieben.
Die "Dokumentation" (ist das wirklich alles?) ist der Rede nicht wert,
tut mir Leid. Das sind vielleicht Notizen von jemanden der das Ding
durchschaut, aber auf keinen Fall ist das eine Dokumentation. Nicht nur
fehlen viele Informationen (Fließtext!), nein das ganze ist auch noch
formal absolut Mangelhaft. Keine Überschriften, keine erkennbare
Ordnung. Sowas kann man nicht mal in der Schule abliefern. Also ich weiß
wirklich nicht, wie du dir das vorstellst, dass jemand der keine Ahnung
hat von Prozessoren, da durchsteigen soll. Das ist ein Schwall von
Informationen die absolut nicht zuordbar sind.
Ok ich weiß zwar nicht was du im Jahre 2016 noch mit einer Akkumulator
Architektur willst, aber geschenkt. Die Mnemonics sind aber wirklich
wirr, du brichst da mit allen möglichen Konventionen. Ziemlich unsinnig,
wenn das Ding von jeden schnell verstanden werden soll.
Josef G. schrieb:>> wenn es auch so geht:> xor a, <argument>>> Wo soll da der Vorteil sein? Das wäre unnötige mehr-Tipparbeit.> Bei xor ist der erste Operand immer A, das A braucht man deshalb> nicht hinschreiben. Und mir würde auch nicht gefallen, dass das-> selbe Mnemonic xor sowohl bei Register-Operand (1 Zyklus)> als auch bei Speicher-Operand (2 Zyklen) verwendet wird.
Der Vorteil ist, dass der Ausdruck "xor" für sich steht und wirklich
jedem klar ist, dass das eine Exklusiv-Oder Operation ist. Da gibts
keine Zweifel. Gleiches gilt für and or add etc.. Die "Tipparbeit" ist
der Rede nicht wert, da sind die vielen Punkte in deinen Mnemonics viel
schlimmer. Bei Mnemonics an Zeichen zu sparen ist einfach Schwachsinn.
Gerade wenn du Anfänger ansprechen willst. Beim Assemblergeschreibsel
ist die Schreibarbeit kein Thema, Übersichtlichkeit und selbsterklärende
Mnemonics hingegen schon. Falsche Prioritäten.
So wie ich das sehe, ist dein größtes Problem, dass du zu viele
Konventionen auf einmal brichst und kein Gefühl dafür hast, wie man
anderen Menschen (gar alte Hasen) Konzepte und Sachverhalte erklärt.
Sieh dir Dokumente von großen Herstellern wie Atmel an und lerne wie man
sowas macht. Geize nicht mit Text, Diagrammen und Beispielen!
TriHexagon schrieb:> Ok ich weiß zwar nicht was du im Jahre 2016 noch mit einer Akkumulator> Architektur willst, aber geschenkt.
Ah da fällt mir noch ein, dass die Architektur meines Professors im
ersten Semester sogar keinen Akku hatte. Da waren wirklich alle Register
gleichberechtigt, da jede Operation auf alle Register anwendbar waren.
Das war eine wirklich einfache und feine Architektur, die von allen
verstanden werden konnte. Komplexeres Design kann also kein Argument für
einen Akku sein.
Sag' mal Bome, bist du etwa der kleine Bruder von Kurt Bindel, verwandt,
verschwägert oder versonstirgendwas mit ihm?
Ihr beide habt ja echt die gleichen Probleme mit eurem Ego und der
Reaktion darauf. Ihr meint, die Welt mit großen Taten und Erkenntnissen
verbessert zu haben und merkt dabei überhaupt nicht, wie lächerlich (im
wahren Sinn!) ihr euch dabei macht.
Dieses Gebaren könnte man auch als Inverses Locked-In-Syndrom
bezeichnen. Ihr seid zwar körperlich beweglich, dafür aber geistig
gefangen in eurer eignen Welt.
TriHexagon schrieb:> Ok ich weiß zwar nicht was du im Jahre 2016 noch mit einer Akkumulator> Architektur willst,
Ja, der Unterschied im Aufwand ist heute eigentlich geschenkt. Schon
1979 brachte Zilog mit der sehr eleganten und angenehm zu
programmierenden Z8 Reihe eine auf Registern basierende Architektur, die
ausschliesslich für Mikrocontroller der damaligen Zeit konzipiert war.
@ Pat A Mat (patamat)
>Dieses Gebaren könnte man auch als Inverses Locked-In-Syndrom>bezeichnen. Ihr seid zwar körperlich beweglich, dafür aber geistig>gefangen in eurer eignen Welt.
Dafür gibt es eine viel einfachere Diagnose.
Beitrag "Re: 8bit-Computing mit FPGA"
Michael U. schrieb:> Carl Drexler (jcw2):>> TAX Transferiere A nach X>> TAY Transferiere A nach Y>>>> INX Incrementiere X>> INY Incrementiere Y>> gerade damit und im Zusammenspiel mit der Zeropage konnte man aber sehr> nett Sachen machen, zur Laufzeit berechnete Sprungtabellen, Loops zum> Kopieren usw.>> War beim Z80 mit den EX-Befehlen doch auch so, man mußt erst entdecken,> wo man die wie einsetzt, genauso die Block-Befehle.>> Ich habe auf einem MC6800 angefangen, da hatte man das Theater mit> zuvielen Registern sowieso nicht, der Ansatz, 2 gleichwertige Akkus zu> haben, war aber durchaus auch praktisch.>> Vergleiche mit aktuellen CPUs würde ich hier sowieso nicht machen, deren> Befehlssätze sind meist von Compiler für Hochsprachen beeinflußt.>> Gruß aus Berlin> Michael
Es ging bei diesem aus dem Zusammenhang gerissenen Zitat eigentlich um
die Frage "sind ungewöhnliche Mnemonics gut, weil auch andere das schon
mal so gemacht haben?".
Trickreiche Assembler-Programmierung kenne ich auch, aber die hab ich in
den letzten Jahrzehnten durch trickreiche Hochsprachen-Programmierung
ersetzt.
;-)
TriHexagon schrieb:> auf keinen Fall ist das eine Dokumentation. Nicht nur> fehlen viele Informationen
Würde ich bestreiten. Welche Information zB. vermisst du?
> Josef G. schrieb:>>> wenn es auch so geht:> xor a, <argument>>>>> Wo soll da der Vorteil sein? Das wäre unnötige mehr-Tipparbeit.> Der Vorteil ist, dass der Ausdruck "xor" für sich steht und wirklich> jedem klar ist, dass das eine Exklusiv-Oder Operation ist.
Das ist ein Vorteil für jemand, der sich neu in die CPU
einarbeitet, aber nicht mehr, wenn die Einarbeitung und
die Gewöhnung an die Mnemonics abgeschlossen ist.
> Beim Assemblergeschreibsel ist die Schreibarbeit kein Thema,
Würde ich bestreiten. Für fast jedes Byte des Codes eine
eigene Assemblerzeile, da ist sehr viel zu schreiben.
Josef G. schrieb:> Das ist ein Vorteil für jemand, der sich neu in die CPU> einarbeitet, aber nicht mehr, wenn die Einarbeitung und> die Gewöhnung an die Mnemonics abgeschlossen ist.
Und genau diese Phase kann man abkürzen, indem man sich an gewisse
Gepflogenheiten hält.
Wenn du jemandem anfangs eine Pistole ins Genick hältst, dann wird er
sicherlich in der Lage sein, sich in deine Sprache einzuarbeiten. Die
Alternative ist zu unerquicklich.
Ohne Anwesenheit dieser Pistole, aber mit mehreren ebenso wenig
tödlichen Alternativen im Blickfeld, wird niemand freiwillig diese
Lernphase überwinden. Es sei denn als Wettbewerb, ob er auch das schafft
- also so wie 12 Leute, die sich in eine Telefonzelle quetschen.
Ich habe einige Übung darin, Architektur und Sprache von Maschinen
kennen zu lernen. Ich brauche daher normalerweise nicht lange um einen
groben Überblick zu gewinnen. Normalerweise. Deine jedoch schreckt ab.
Da ist erst einmal nichts verständlich, nicht in der Doku und nicht in
Beispielprogrammen.
So lange dein Angebot das einzige weit und breit ist, oder es wirklich
gewaltige Vorteile bietet, hast du Chancen. So ist es aber nicht und in
Konkurrenz hast du keine Chance.
Selbst wenn es deutliche Vorteile gäbe müsstest du die Leute erst einmal
motivieren, überhaupt einen zweiten Blick zu riskieren, weil der erste
Blick jeden abschreckt. Irgendwelche Repeat-Möglichkeiten locken heute
keinen Hund hinter dem Ofen hervor.
> Würde ich bestreiten. Für fast jedes Byte des Codes eine> eigene Assemblerzeile, da ist sehr viel zu schreiben.
Programmierung besteht zum kleinsten Teil aus Schreibarbeit und
Speicherplatz von Quellcode ist kaum ein Thema. Ich habe genug davon
betrieben, auch in Assembler auf Maschinen mit wenigen KB RAM,
Kassettenrekorder als Massenspeicher und einem Display mit einer
einzigen angezeigten Zeile.
Josef G. schrieb:> Würde ich bestreiten. Für fast jedes Byte des Codes eine> eigene Assemblerzeile, da ist sehr viel zu schreiben.
Hast du überhaupt mal richtig programmiert? Also ein großes, komplexes
Programm entwickelt? Ich denke nicht. Denn dann wüsstest du, dass das
Schreiben, das Eintippen der Zeichen, die allergeringste Arbeit beim
Programmieren ist und die wenigste Zeit bnötigt! Und das ist auch bei
Hobbyisten so.
Josef G. schrieb:> O.VZ Vorwärtssprung falls V=0
...
> B.VZ Rückwärtssprung falls V=0
Ah... was Doku manchmal ausmacht!
Nur warum nennst du das nicht
JF.VZ (Jump Forward if V=0)
JB.VZ (Jump Backward if ...)
Irgendwie werden Sprungbefehle bei den meisten Architekturen, die ich
kenne mit J (jump) oder B (branch) geschrieben. So richtig eingängig
sind deine Mnemonics halt nicht! Ich hab ja auch nur 6502, Z80, 68HC11,
680xx, i86 in Assembler programmiert. Deine Doku bei
http://www.mikrocontroller.net/articles/8bit-CPU:_bo8 reicht halt nie
und nimmer aus, schon gar nicht für Anfänger. Dafür bist du zu weit von
den gängigen Architekturen bzw. Assemblerbefehlen weg. Rodnay Zaks hat
ja nur ein Buch über 400 Seiten über den 6502 geschrieben. Ein Beispiel,
wie man den Befehlsatz eines einfachen Mikroprozessores beschreiben
könnte, ist der MOS 6502 Buch
http://archive.6502.org/books/mcs6500_family_programming_manual.pdf
IMHO solltest du folgendes wirklich ausführlicher erklären:
1) die Register und welche Funktionen sie haben
2) die möglichen Adressmodis
3) Alle Befehle, gruppiert nach Verwendungszweck (Transferbefehle,
Arithmetische Befehle, Sprungbefehle, ...) mit Beispielen!
Beispiele und nochmals Beispiele!
2⁵ schrieb:> Nur warum nennst du das nicht
Indiskutabel. Kostet 1 Byte mehr Quellcode.
Als Alleinstellungsmerkmal könnte er die deutsche Sprache als Basis
nutzen. Erspart die gelegentliche hilflose Bitte nach µC-Doku in
Deutsch.
Das wäre zwar nicht wirklich neu, aber Telefunken Rechner findet man
heute nur noch im Museum (BZ = bringe zwei Wörter, "Merklicht" statt
"Flag" uvam).
Beispiel einer sehr brauchbaren Beschreibung einer "kruden" CPU:
http://www.self8051.de/befehlsreferenz_der_8051er_familie,13295.html
Ich nehme jetzt einfach mal an deine CPU wäre viel viel besser als
dieser
olle 51-Kram, nun dann verbessere doch endlich mal deine Doku damit man
es sieht!
Josef G. schrieb:> O.WY Vorwärtssprung always> B.WY Rückwärtssprung always
Wenn es jetzt wirklich um's sparen von Tastanschlägen ginge, würde man
die zwei eher JF und JB nennen, ohne ".wy".
Josef G. schrieb:> Das könnte man machen. Das ergäbe vielleicht einen Text> von 20 Seiten. Deshalb habe ich das bisher nicht gemacht.> Wenn jemand die Seite CPU-doku aufmerksam liest, findet er> dort alle Informationen. Natürlich ist es nicht damit getan,> die Seite nur zu überfliegen. Aber die eine Seite ersetzt> eben die 20 Seiten, die man sonst lesen müsste.
Wenn du das wirklich ernst meinst: Überleg doch mal, wieviel du hier
schon von der Gebetsmühle gespult hast. Die 5fache Seitenzahl hättest du
bereits geschrieben, und die dürfte für deinen Befehlssatz auch nötig
sein.
Josef G. schrieb:> Wo soll da der Vorteil sein? Das wäre unnötige mehr-Tipparbeit.
Jetzt habe ich doch mal fast meinen Kaffee vor Lachen ausgespuckt.
Josef G. schrieb:> Wenn man gezwungen ist, im Assembler-Quelltext den Code umzustellen,> dann ist damit verglichen der zusätzliche Aufwand (Ersetzen> eines O durch ein B oder umgekehrt) vernachlässigbar.
Wenn dein Programm 20 Zeilen nicht übersteigt, mag das stimmen.
Ansonsten ist es ein weiterer Grund für ein "broken by design".
>> Im Übrigen ist der Hauptvorteil meiner Lösung, dass man in> beiden Richtungen die volle 256-Byte-Distanz zur Verfügung hat.
Wie ich schon sagte, solche Sachen überlässt man dem Assembler. Das ist
im Gnu Assembler Standard-Framework. Siehe auch Stichtwort "Linker
relaxation". Aber ich verstehe schon, dass du dir keine andern Konzepte
einverleiben möchtest.
TriHexagon schrieb:
> Ok ich weiß zwar nicht was du im Jahre 2016 noch mit einer Akkumulator> Architektur willst, aber geschenkt.
Ach, Akkus sind durchaus noch sehr modern. Siehe Blackfin und andere
DSP-Hybriden. Ich nutze intern auch einen separaten Akku, der
Programmierer sieht das nur seltenst (ausser er will an Rundungs-Bits).
A. K. schrieb:> Ja, der Unterschied im Aufwand ist heute eigentlich geschenkt. Schon> 1979 brachte Zilog mit der sehr eleganten und angenehm zu> programmierenden Z8 Reihe eine auf Registern basierende Architektur, die> ausschliesslich für Mikrocontroller der damaligen Zeit konzipiert war.
Den Z8 würde ich z.B. schon als "elegant" bezeichnen. Gerade mit seinem
schaltbaren Register-Window, das war immerhin eine Neuerung.
Beim zur Diskussion (ist es überhaupt eine Diskussion?) stehenden
Befehlssatz sehe ich immer noch unnötige Obfuscation.
Die Diskussion ist nur keine mehr, wenn man sich komplett dem Standard
verwehrt. Einhalten des "Protokolls" ist auch so eine Sache...
An Falk: Das Thema Asperger ist heikel, und bleibt vielleicht besser
unausgesprochen. Ich glaube eine IT-affine Community kann damit schon
umgehen.
So, und nach Jahren von nerviger bo8-Werbung fehlen immer noch Argumente
für die Neuerungen, sowie brauchbare Anwendungen. Ich verstehe, dass es
Spass macht, ausschliesslich mit einer CPU herumzuspielen, frei nach dem
Motto "weil ich es kann".
Was ich nicht verstehe: Wie man sich konsequent sperrt, auf gewichtige
Argumente anderer einzugehen und gebetsmühlenartig gegen den Konsens
ankämpft. Das gibt doch am Schluss nur auf die Mütze, und das Internet
vergisst nie..
Jetzt mal ganz abgesehen vom Technischen deshalb meine ernsthafte Frage
an Josef: Was bezweckst Du eigentlich genau mit diesem Thread?
P.S. "Merklicht" für Flag finde ich richtig gut :-)
Strubi schrieb:> P.S. "Merklicht" für Flag finde ich richtig gut :-)
Zumal man das bei damaligen Rechnern wörtlich nehmen darf. Die
Merklichter werden wirklich geleuchtet haben. Es wird aber wohl nie
einen Rechner gegeben haben, der auf dem Panel mit Flaggen winkt. ;-)
Josef G. schrieb:>> Der Vorteil ist, dass der Ausdruck "xor" für sich steht und wirklich>> jedem klar ist, dass das eine Exklusiv-Oder Operation ist.>> Das ist ein Vorteil für jemand, der sich neu in die CPU> einarbeitet, aber nicht mehr, wenn die Einarbeitung und> die Gewöhnung an die Mnemonics abgeschlossen ist.
Stimmt. Und da du die Einarbeitungs- und Gewöhnungsphase absichtlich
extra schwer machst, wird sich auch niemand außer dir einarbeiten oder
gewöhnen. Damit verfehlst du das Ziel deiner CPU.
Merke: Eine zu steile Lernkurve (kein sinnvolles Konzept, keine
gebrauchbare Dokumentation, kein selbsterklärendes System) ist
Abschreckung.
A. K. schrieb:> Die Merklichter werden wirklich geleuchtet haben. Es wird aber wohl nie> einen Rechner gegeben haben, der auf dem Panel mit Flaggen winkt. ;-)
Dann wird's ja Zeit! ;-)
Strubi schrieb:> schaltbaren Register-Window, das war immerhin eine Neuerung.
Das gab es schon bei TIs Minicomputern, und als Folge davon auch beim
16-Bit µP TMS9900 von 1976.
Strubi schrieb:> fehlen immer noch ..., sowie brauchbare Anwendungen.
Da bin ich auch nicht in der Lage, die zu liefern.
Deshalb versuche ich hier Mitstreiter zu finden,
die dazu in der Lage sind.
Durch das Steckkarten-Konzept des Rechners, mit definierter
Schnittstelle zur Software der Hauptplatine, hätte jedermann
die Möglichkeit, Steckkarten-Software zu entwickeln und
in Eigenregie anzubieten.
Hallo,
Josef G. schrieb:> Durch das Steckkarten-Konzept des Rechners, mit definierter> Schnittstelle zur Software der Hauptplatine, hätte jedermann> die Möglichkeit, Steckkarten-Software zu entwickeln und> in Eigenregie anzubieten.
mein letztes Steckkartenkonzept war wohl Mitte der 80er rum auf
Z80-Basis.
Da ist mir mittlerweile selbst ein Arduino ProMini für 2 Euro aus China
lieber.
Was ist bei Dir Steckkarten-Software? Eine I/O-Karte mit 4 Tastern und 4
LEDs? Sowas und die zugehörige Software würde ich von Dir als Beispile
erwarten. Aber das wäre ja schon eine Art Anwendung...
Gruß aus Berlin
Michael
Josef G. schrieb:
[Anwendungen]
> Deshalb versuche ich hier Mitstreiter zu finden,> die dazu in der Lage sind.
Ist das wirklich dein Ziel? Kein überzeugendes Konzept, keine Doku,
bevor man die CPU benutzen kann, muss man sich auch noch in FPGAs
einarbeiten usw.
Ein bisschen viel verlangt, finde ich. Außerdem gibt es noch eine große,
etablierte Konkurrenz mit Arduino, RaspberryPi & Co. Damit kann man (ja,
fast jeder) etwas anfangen und auch lernen.
A. K. schrieb:> Und was ist an Steckkarten so besonders? Ausser dass man heute dazu> übergeht, Baukastenelemente seriell oder per Funk anzubinden.
Er hat den Linker durch einen Steckverbinder ersetzt. Auch ne Idee :-)
Letztens erschütterte die Fachwelt eine gewichtige Depesche: Die
Cartridge von E.T., der Ausserirdische, wurde in einer Deponie irgendwo
im Wüstensand wieder ausgegraben. Leute, was muss Atari bei Herrn G.
damals abgekupfert haben.
Sogar Nintendo sprang auf den Zug auf.
Jetzt mal im Ernst: Das mit den Mitstreitern wird nix, bevor die
Hausaufgaben nicht gemacht sind.
Also was bezweckst du jetzt wirklich? Wirst du uns immer wieder
"Vorteile" verkaufen, bis der Forenbetreiber genug von der Unruhe hat?
Michael U. schrieb:> Eine I/O-Karte mit 4 Tastern und 4 LEDs? Sowas und die> zugehörige Software würde ich von Dir als Beispile erwarten.
Eine Test-Steckkarte gibt es ja, siehe Seite Testcard meiner Website.
Die Steckkarten müssen physikalisch nicht wirklich Steckkarten sein.
Auch in der bisher existierenden Realisierung auf FPGA-Boards
existieren sie nur aus Sicht der Software, tatsächlich sind
sie Teil der Hauptplatine.
Pat A. schrieb:> bevor man die CPU benutzen kann, muss man> sich auch noch in FPGAs einarbeiten usw.
Software testen kann man auch am PC mit dem Emulations-
Programm, sofern keine spezielle Hardware angesprochen wird.
Der Emulator muss erst noch unter Linux kompiliert werden. Wo ist da der
Unterschied zum Synthetisieren der VHDL-Files?
Niemand möchte sich immer weiter in andere Bereiche einarbeiten, nur um
sich mit deiner CPU zu beschäftigen. Und diejenigen, die sich in diesen
Bereichen schon auskennen, haben ihre Meinung hier schon oft genug
kundgetan.
Pat A. schrieb:> Der Emulator muss erst noch unter Linux kompiliert werden.
Ist nur 1 Kommando, einzutippen in einem Konsolenfenster.
Das Kommando steht auf der Seite Emul meiner Website.
Das kompilierte Programm steht dann im aktuellen Verzeichnis
und ist mit rm restlos wieder zu entfernen.
Pat A. schrieb:> Der Emulator muss erst noch unter Linux kompiliert werden. Wo ist da der> Unterschied zum Synthetisieren der VHDL-Files?
Sehr schön!! :-)))
Da tauchen überhaupt interessante Parallelen auf, zu Linux. Vielleicht
ist die Idee dahinter gut-vielleicht nicht, vielleicht funktioniert
es-vielleicht nicht...?? Kaum einer weiß es so genau, weil der Zugang zu
schwierig ist.
Und da ist auch die Lösung: Das was Android für Linux ist, das braucht
bome für seine CPU - jemanden der den Zugang einfach und überschaubar
macht. Und der muß von Außen kommen. Wer zu tief drin steckt bekommt das
im Allgemeinen kaum gebacken - Torvalds bei Linux ja auch nicht...
Deshalb muß bone hier auch bissel Werbung machen.
Nebenbei finde ich die persönlichen Angriffe auf den TO ziemlich
daneben. Wer sich mit naturwissenschaftlich technischen Dingen in seiner
Freizeit beschäftigt ist ohnehin ein kleiner Außenseiter in unserer
Gesellschaft. Habe inzwischen schon Angst Chemikalien für
Leiterplattenherstellung zu kaufen und löte lieber auf Lochraster...
Josef G. schrieb:> Ist nur 1 Kommando, einzutippen in einem Konsolenfenster.
Wetten daß das nicht funktioniert!!!
Da fehlen garantiert mindestens 1000 "Pakete" die erst mit app- üp- upt-
get. install -rf -rt -ri -sx nachinstalliert werden müssen. Natürlich
mit root rechten auf der ersten, dritten und neunten Konsole, versteht
sich...
Ja, die persönlichen Angriffe, Beispiel:
Pat A. schrieb:> Sag' mal Bome, bist du etwa der kleine Bruder von Kurt Bindel,>> Ihr beide habt ja echt die gleichen Probleme mit eurem Ego>> Dieses Gebaren könnte man auch als Inverses Locked-In-Syndrom> bezeichnen.> Ihr seid zwar körperlich beweglich, dafür aber geistig> gefangen in eurer eignen Welt.
Mal ehrlich, das ist doch unter aller Sau! Über fachliche Dinge kann man
natürlich immer streiten.
V0A schrieb:> Mal ehrlich, das ist doch unter aller Sau! Über fachliche Dinge kann man> natürlich immer streiten.
Eben genau das geht mit Bome und Kurt Bindl eben nicht!
Josef G. schrieb:> Software testen kann man auch am PC mit dem Emulations-> Programm
Ich habe (vermutlich) erfolglos versucht, damit nach dieser Anleitung
http://www.bomerenzprojekt.de/Website/Emul.html
eine Demo laufen zu lassen. Nachdem ich von hier
http://www.bomerenzprojekt.de/Website/Downloads.html
die ersten neun ZIP-Dateien¹ einzeln heruntergeladen, alle einzeln
ausgepackt, einzeln umbenannt² und die C-Dateien einzeln kompiliert³
hatte, habe ich es immerhin geschafft, das Programme emul zu starten.
Nach einer eindringlichen Gefahrenwarnung und der Quittierung derselben
öffnet sich tatsächlich ein Grafikfenster, in dessen unterem Bereich in
einer Schrift, die mich an einen kaputten Nadeldrucker aus den 80er
Jahren erinnert, seltsame Buchstaben, Ziffern und Symbole angezeigt
werden. Im Konsolenfenster, von dem aus ich das Programm gestartet habe,
erscheinen drei- bis vierstellige Hexadezimalzahlen.
Da das alles für meine Augen ähnlich verwirrend aussieht wie deine
Dokumentation, nehme ich an, dass bis hierher alles korrekt ablief.
Wenn ich nun gemäß deiner Anleitung Kommandos eingebe, kommen neue
Hexadezimalzahlen in der Konsole hinzu. Manchmal ändert sich auch eine
Kleinigkeit im Grafikfenster, weitaus öfter wird dieses aber einfach
geschlossen. In den allermeisten Fällen passiert aber gar nichts.
Leider konnte ich auch nirgends erfahren, was deine Demoprogramme tun
sollen und wie ich erkennen kann, dass sie dies tatsächlich tun.
So bin ich von einem Aha-Effekt wohl noch Lichtjahre entfernt. Woran das
liegen mag? Mir fallen dazu spontan vier ungefähr gleichwahrscheinliche
Erklärungen ein:
1. Ich bin einfach nur zu dumm, die Anleitung zu verstehen und richtig
umzusetzen⁴.
2. Ich habe nicht erkannt, dass die Anleitung zu einer ganz anderen
Software gehört.
3. Das Ganze ist ein spannendes Hackerspiel, bei dem ich nur noch nicht
den initialen Zugangscode herausgefunden habe.
4. Alles hat bestens funktioniert, nur habe ich nichts davon bemerkt.
Wenn du deinen Prozessor ernsthaft unter die Leute bringen willst,
solltest du vielleicht überlegen, Schulungen anzubieten. Leider habe ich
keine Idee, wie du es anstellen kannst, dass diese auch tatsächlich
besucht werden.
——————————————
¹) Josef, man kann in ein ZIP-Archiv auch mehrere Dateien packen, am
besten all jene, die man für ein erstes Kennenlernen des Systems
braucht.
²) Josef, bei den Dateinamen in einem ZIP-Archiv sind auch andere
Suffixe als .txt erlaubt. Du musst als bspw. die Datei emul.c nicht
in emul.c.txt umbenennen. Damit entfällt dann auch das erneute
Umbennen in den Originalnamen durch den Anwender.
³) Josef, es gibt seit kurzem ein Tool namens make, mit dessen Hilfe der
Anwender zum Kompilieren des Codes nicht n-mal eine lange
Kommandozeile, sondern nur einmal ein kurzes "make" eingeben muss.
⁴) Bei anderen Prozessoren und Mikrocontrollern, wie dem 6502, Z80,
68000, 8051, C167, TMS320Cxx und AVR (einschließlich der zugehörigen
Tools) hatte ich diese Probleme zwar nicht, aber die sind ja im
Vergleich zu deinem Prozessor auch Kinderkram.
V0A schrieb:> Josef G. schrieb:>> Ist nur 1 Kommando, einzutippen in einem Konsolenfenster.>> Wetten daß das nicht funktioniert!!!
Jetzt muss ich mal Josef in Schutz nehmen:
Obwohl der Quellcode der Programme gruselig aussieht und teilweise so
krumm formatiert ist, dass sich sogar der Compiler über die Einrückung
beschwert, hat er bei mir (natürlich mit abgeschalteten Warnings)
anstandslos kompiliert, und es werden nur Bibliotheken benutzt, die
praktisch jeder auf seinem Linux-PC hat (GCC-Libs, Glibc und X11).
Übrigens:
Dass ein Compiler wegen "misleading indentation" warnt, habe ich heute
zum ersten Mal erlebt. Bei diesem Ausschnitt (Zeilen 182 bis 186 von
mass.c) hat die Warnung IMHO aber auch eine gewisse Berechtigung:
Pat A. schrieb:> Bome ist schon ein ganz besonderes Kaliber. Nochmals zur Erinnerung:> Beitrag "wer kann sich noch an den hex-zeichensatz erinnern?"> Beitrag "Ein Vorschlag zur Intervall-Arithmetik">> Einfach mal durchlesen und sich eine eigene Meinung bilden.
Habe das jetzt nur überflogen... Es ist schon Eigenwillig. :-)))
Aber das kann man ja dann auch so mitteilen, daß man es für umständlich
oder überflüssig hält.
Oder sich halt keine Meinung bilden kann. Also ich verstehe den
Befehlssatz, oder dessen Beschreibung nicht, falls
https://www.mikrocontroller.net/articles/8bit-CPU:_bo8
alles ist was dazu existiert.
Müsste man auch mehr über die Registerstruktur, etc wissen, sehe ich
dort jetzt so auf den ersten Blick alles nicht. Habe auch keinen Bock
darauf näher einzusteigen, weil nutzloses Wissen...
Trotzdem muß ich hier keine Hypothesen über den Gesundheitszustand von
Herrn Bome anstellen.
Yalu X. schrieb:> V0A schrieb:>> Josef G. schrieb:>>> Ist nur 1 Kommando, einzutippen in einem Konsolenfenster.>>>> Wetten daß das nicht funktioniert!!!>> Jetzt muss ich mal Josef in Schutz nehmen:>> Obwohl der Quellcode der Programme gruselig aussieht und teilweise so> krumm formatiert ist, dass sich sogar der Compiler über die Einrückung> beschwert, hat er bei mir (natürlich mit abgeschalteten Warnings)> anstandslos kompiliert, und es werden nur Bibliotheken benutzt, die> praktisch jeder auf seinem Linux-PC hat
Also ich würde es testen, verwette aber mein linkes Ei daß es bei mir
gegen den Baum geht wie alles "was mit Linux ist". Hätte hier ein Ubuntu
14.04 LTS auf nem Core2Duo E6550 zur Verfügung.
Welche Datei muß ich herunterladen und wie lautet das Kommando??? :-)))
V0A schrieb:> Habe das jetzt nur überflogen... Es ist schon Eigenwillig. :-)))> ...> Trotzdem muß ich hier keine Hypothesen über den Gesundheitszustand von> Herrn Bome anstellen.
Das ist hier weder obligatorisch noch zwingt dich irgendjemand dazu ;-)
Und 'Eigenwillig' ist noch sehr höflich formuliert.
BTW: 'Bome' ist nur der Nickname von Herrn Josef Gnadl.
> Welche Datei muß ich herunterladen und wie lautet das Kommando??? :-)))
Perfekt auf den Punkt gebracht: Das ist die Gretchenfrage aller Fragen!
;-)
V0A schrieb:> Also ich würde es testen
Nur zu! Ich glaube nicht, dass du mit dem Bauen der Programme unter
Ubuntu Schwierigkeiten haben wirst. Die Schwierigkeiten kommen
vermutlich erst, wenn du versuchst, die Programme auch zu nutzen ;-)
Auf dieser Seite kannst du die Quellen herunterladen:
http://www.bomerenzprojekt.de/Website/Downloads.html
emul.c.txt.zip: Emulator
coka.txt.zip: Assemblierte ROM-Software
mass.c.txt.zip: Assembler (optional)
dass.c.txt.zip: Disassembler (optional)
Nach dem Auspacken und Umbenennen (<dateiname>.txt -> <dateiname>) der
vier Dateien:
gcc -o emul emul.c -lX11
gcc -o mass mass.c
gcc -o dass dass.c
Zum Ausführen aller drei Programme muss sich die Datei coka im aktuellen
Verzeichnis befinden. Die Dateien
emtext_[bcd].txt.zip
enthalten wohl irgendwelche Demoprogramme, mit denen ich aber bisher
noch nichts anfangen konnte. Natürlich kannst du auch eigene Programme
schreiben und mit mass assemblieren (wenn du es kannst, ich kann's
nicht). Wichtig ist, dass die assemblierten Dateien den Namen
emtext_[a-z]
haben.
Nach spätestens 26 Programmen musst du also in ein neues Verzeichnis
wechseln (das erinnert mich irgendwie an die Laufwerksbuchstaben von
Microsoft :))
So, dann wünsche ich dir mal viel Erfolg!
... auch wenn dich das möglicherweise dein
> linkes Ei
kostet :)
Wenn man nur am Emulations-Programm interessiert ist,
braucht man nur emul.c und coka, optional auch teca.
Nach dem Starten des Emulations-Programms tippe man
für ein erstes Erfolgserlebnis ein 61.demo - Enter
Danach drückt man am besten die Taste #, das
vereinfacht die Eingabe von Zahlen.
Bitte beachten:
der erste Operand OPA ist stets mit Vorzeichen.
Josef G. schrieb:> Nach dem Starten des Emulations-Programms tippe man> für ein erstes Erfolgserlebnis ein 61.demo - Enter
Hey, da tut sich ja tatsächlich etwas :)
Ich habe jetzt erfolgreich den Modus 3 (Addition) eingegeben, worauf der
Cursor zum ersten Operanden springt. Auch hier habe ich eine Zahl
eingegeben und mit Enter bestätigt und würde nun erwarten, dass der
Cursor zum zweiten Operanden springt. Das tut er aber nicht.
Was mache ich falsch?
O-M-F-G. Also wenn der Rest des Projektes genauso Obfuscation ist wie
dieser grausam hingerotzte Code, dann kann man das einfach nur gepflegt
wegwerfen.
> Nach dem Starten des Emulations-Programms tippe man> für ein erstes Erfolgserlebnis ein 61.demo - Enter
Wie zur Hölle gibt man das ein?
Bei mir klappt das nicht...
Yalu X. schrieb:> V0A schrieb:>> Also ich würde es testen>> Nur zu! Ich glaube nicht, dass du mit dem Bauen der Programme unter> Ubuntu Schwierigkeiten haben wirst.
Ihr seit schon alle viel weiter, herzlichen Glückwunsch!
Leider weiß ich nicht wie ich hier unter Linux nen Screenshot anfertige,
aber auf meiner Konsole steht:
meinname@meinname-OptiPlex-755:~$ cd Downloads
meinname@meinname-OptiPlex-755:~/Downloads$ cd emul
meinname@meinname-OptiPlex-755:~/Downloads/emul$ gcc -o emul emul.c
-lX11
emul.c:2:24: fatal error: X11/keysym.h: Datei oder Verzeichnis nicht
gefunden
#include <X11/keysym.h>
^
compilation terminated.
meinname@meinname-OptiPlex-755:~/Downloads/emul$
Keine Peilung, alles wie immer, Linux tut nicht...:-)
Guido B. schrieb:> VOA schrieb:>> Keine Peilung, alles wie immer, Linux tut nicht...:-)>> sudo apt-get install linux-headers
Soll ich die Terminal-Ausgabe wirklich hier einfügen, das wird laaang...
Verkürzte Version:
meinname@meinname-OptiPlex-755:~$ sudo apt-get install linux-headers
[sudo] password for meinname:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paket linux-headers ist ein virtuelles Paket, das bereitgestellt wird
von:
linux-headers-3.16.0-30-generic 3.16.0-30.40~14.04.1
linux-headers-4.4.0-38-lowlatency 4.4.0-38.57~14.04.1
linux-headers-4.4.0-38-generic 4.4.0-38.57~14.04.1
linux-headers-4.4.0-36-lowlatency 4.4.0-36.55~14.04.1
linux-headers-4.4.0-36-generic 4.4.0-36.55~14.04.1
...
...
...
linux-headers-3.13.0-30-generic 3.13.0-30.55
linux-headers-3.13.0-29-lowlatency 3.13.0-29.53
linux-headers-3.13.0-29-generic 3.13.0-29.53
linux-headers-3.13.0-27-lowlatency 3.13.0-27.50
linux-headers-3.13.0-27-generic 3.13.0-27.50
linux-headers-3.13.0-24-lowlatency 3.13.0-24.47
linux-headers-3.13.0-24-generic 3.13.0-24.47
Sie sollten eines explizit zum Installieren auswählen.
E: Für Paket »linux-headers« existiert kein Installationskandidat.
Linux wie ich es kenne... Lasst es gut sein, damit kann man ganze Abende
zubringen und es wird nicht besser...;-)
VOA schrieb:> emul.c:2:24: fatal error: X11/keysym.h: Datei oder Verzeichnis nicht> gefunden> #include <X11/keysym.h>
Ich kenne mich Ubuntu nicht so gut aus, aber vermutlich brauchst du das
Paket libx11-dev. Dieses wird eine Handvoll (oder vielleicht auch zwei
davon) weitere Pakete nach sich ziehen, darunter auch x11proto-core-dev,
das den fehlenden Header enthält.
Guido B. schrieb:> sudo apt-get install linux-headers
Um Himmels Willen, nein. Das sind die Kernel-Headers. Die werden von
Kernel-Hackern und Treiberprogrammierern gebraucht, aber ganz sicher
nicht für Josefs Emulator. Bei mir hier sind die auch nicht installiert.
———————————
¹) Bei Debian und Ubuntu sind die wichtigsten Dinge immer in den
dev-Paketen enthalten, die zwar nicht sehr groß sind, aber trotzdem
nur auf persönliche Anfrage hin installiert werden ;-)
Jiri schrieb:> Wie zur Hölle gibt man das ein?> Bei mir klappt das nicht...
Aber Josef hat doch <ironie>klipp und klar</ironie> geschrieben:
> 61.demo - Enter
^^^^^^^^^
Du musst alle markierten Zeichen einschließlich dem Minus tippen und
anschließend die Enter-Taste drücken. Ich dachte auch erst, das Minus
sollte lediglich anzeigen, dass das darauffolgende "Enter" nicht als die
Zeichen "E", "n", "t", "e" und "r", sondern als einzelne Taste
einzugeben ist.
Da aber alle verwendeten Befehle so seltsame Namen haben und zusätzlich
noch von Sonderzeichen durchsetzt sind, ist es für uns Normalsterbliche
beim Lesen der Doku schwer zu entscheiden,
- welche Zeichen so getippt werden müssen, wie sie dastehen,
- welche zu Befehlsnamen gehören, von denen erst der Hexcode in einer
Tabelle nachgeschlagen werden müssen (die man auch erst einmal finden
muss) und
- welche davon zum erläuternden Text gehören und deswegen nicht
eingetippt werden dürfen.
Der Befehl zum Starten der Demo steht übrigens auch in der
Dokumentation, allerdings in anderer Form:
1
Beispieltext a wird durch das Kommando 1.DEMO geladen.
Naiv wie ich bin, habe ich natürlich einfach die Zeichen von "1.DEMO"
der Reihe nach eingetippt und mit <Enter> abgeschlossen (wobei ich nicht
sicher war, ob die Enter-Taste wirklich nötig oder womöglich sogar
falsch ist).
Jetzt erfahren wir aber, dass die "1" als "61" und "DEMO" in
Kleinbuchstaben einzugeben sind, und dass danach noch " -" folgen muss.
Wahrscheinlich kann man das alles irgendwie aus Josefs vielen Tabellen
ableiten. Dazu müsste man aber erst einmal die Zusammenhänger besser
verstehen, und schon beißt sich die Katze in den eigenen Schwanz.
Immerhin habe ich mittlerweile den Ursprung der "61" gefunden: Das ist
in Josefs eigener Zeichenkodierung der Hexcode der Ziffer "1". Mit "#"
schaltet man in einen Modus um, in dem die Taste "1" tatsächlich die
Ziffer "1" liefert (so wie man das seit der Erfindung der
Schreibmaschine gewohnt ist). In diesem Modus können aber keine
Buchstaben eingegeben werden (nur die Hex-Ziffern "a" bis "f"). Um
Buchstaben einzugeben, muss man mit der Leertaste zurück in den
Normalmodus schalten, in dem Ziffern wiederum nur als Hex-Zeichencode
eingegeben werden können.
Ähnlich kompliziert kenne ich das nur bei einigen Taschenrechnern, die
zwar alphanumerische Zeichen unterstützen, aber wegen zu geringer
Tastenzahl mit drei und mehr Umschalttasten plus mehreren Eingabemodi
arbeiten. Ich frage mich nur, warum das auf einer PC-Tastatur mit über
100 Tasten genauso kompliziert sein muss.
Von dem ganzen Rest habe ich bisher nichts, aber auch gar nichts
kapiert. Ich glaube, das Ganze ist tatsächlich ein Hackerspiel, bei dem
Josef so nach und nach die Hints preisgibt. Wenn wir dann irgendwann
von dem Spiel so richtig angefixt sind, kommt die Meldung
"PLEASE INSERT COIN TO CONTINUE"
und darunter ein Link zu Paypal ;-)
Auf dem realen System lädt das Kommando 1.DEMO
einen Beispieltext in die Seite E des Text-RAM.
Wenn man stattdessen eingibt 1.DEMO - (oder 1.DEMO #), wird
der Text automatisch kompiliert und das Programm gestartet.
Das steht auf der Seite Testcard meiner Website.
Im Emulations-Programm am PC werden Zeichen eingegeben durch
ihren Hexcode (00 .. 7f), weil mein Computer einen anderen
Zeichensatz besitzt als der PC und nicht alle Zeichen am PC
zur Verfügung stehen. Nur manche Zeichen sind auch durch
einen einzigen Tastendruck erreichbar, insbesondere die
Großbuchstaben. Die Ziffern kann man so aber nicht eingeben,
denn die sind ja für die Eingabe von Hexcodes reserviert.
Deshalb muss man die Ziffer 1 durch ihren Hexcode 61
eingeben. Oder man schaltet vorher in den Ziffernmodus,
dann kann man sie direkt eingeben.
Das ganze ist aber auf der Seite Emul beschrieben.
Oder welche Information fehlt in dieser Beschreibung?
Richtig ist, dass die Zeicheneingabe am PC nicht
zufriedenstellend gelöst ist. Ich habe zB. keine
Möglichkeit gefunden, die Cursortasten abzufragen.
Falls jemand weiter unten auf der Seite Emul die
Informationen zu mass und dass liest:
Da steht zwar, dass die Programme auf dem Emulations-Programm
beruhen. Jedoch tritt das Problem der Zeichen-Eingabe hier nicht
auf, man möge sich also nicht abschrecken lassen.
Yalu X. schrieb:> Da aber alle verwendeten Befehle ...> und zusätzlich noch von Sonderzeichen durchsetzt sind,
Das ist aber jetzt übertrieben.
Die Befehle der Hauptplatine beginnen mit =
Die Befehle der Test-Steckkarte beginnen mit 1
Einziges Sonderzeichen innerhalb mancher Befehle ist
der auf der Grundlinie Bindestrich, welcher am PC
durch einen Punkt ersetzt ist.
Josef G. schrieb:> Beim> Z80-Befehl djnz dürfte es schwer fallen, eine sinnvolle> Anwendung für positive Distanz zu finden.
Hö?
1
eins: DJNZ r1, zwei
2
Krempel, der bei r1 = 1 passieren soll
3
zwei: DJNZ r1, drei
4
Krempel, der bei r1 = 2 passieren soll
5
drei: DJNZ r1, vier
6
Krempel, der bei r1 = 3 passieren soll
7
vier: DJNZ r1, fuenf
8
Krempel, der bei r1 = 4 passieren soll
9
fuenf: DJNZ r1, ende
10
Krempel, der bei r1 = 5 passieren soll
11
ende:
DAS war schwer ...
Aber mit Flags und Verzweigungen hast Du ja auch so Deine Probleme.
Dein Prozessorprojekt taugt bei mir allerdings nur zur Belustigung.
Du darfst diesen Kram natürlich toll finden und auch so benutzen. (Über
die Sinnhaftigkeit rede ich jetzt besser nicht)
Wenn Du jedoch eine breite Masse erreichen möchtest, solltest Du das
System auch so designen, dass die breite Masse damit umgehen kann.
Ohne Stack kann man eine CPU sicherlich aufbauen, man muss dann die
Rücksprünge von Hand irgendwo sichern (SW-Stack?)
Widerspricht allerdings der von Dir gepredigten Codesparsamkeit.
Wenn das Ding auch nur ein wenig Erfolg haben soll, dann werden IRQs
benötigt - wenigstens einer.
Dir wurden viele wertvolle Tips gegeben, die Du allesamt ignoriert hast.
Sicher hast Du bei dem Aufbau eine Menge gelernt.
Meiner Meinung nach ist es aber nun Zeit für eine komplette
Neuentwicklung - NACHDEM Du alle Tips berücksichtigt hast und Dich auch
mal bei anderen Stukturen umgesehen hast.
Ich habe allerdings wenig Hoffnung, dass Du das einsiehst.
Du hältst Dein System für etwas ganz tolles. Ist es nicht!
Gruß
Jobst
Jobst M. schrieb:> Meiner Meinung nach ist es aber nun Zeit für eine komplette> Neuentwicklung - NACHDEM Du alle Tips berücksichtigt hast und Dich auch> mal bei anderen Stukturen umgesehen hast.
Diesen Tipp hatte ich Josef auch schon vor langer Zeit gegeben, ebenso
dann auf Josefs ausstehende Antworten zu den von mir formulierten
Kritikpunkten und Ratschlägen hingewiesen. Statt diese dann inhaltlich
zu beantworten, konnte Josef angeblich keine entsprechenden Inhalte
finden. Das ist schon reichlich absurd.
@ Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill)
>Kritikpunkten und Ratschlägen hingewiesen. Statt diese dann inhaltlich>zu beantworten, konnte Josef angeblich keine entsprechenden Inhalte>finden. Das ist schon reichlich absurd.
Keine Sekude, es ist tyisch für Josef's Disposition. Einem
(Farben)blinden wirst du auch keinen Regenbogen erklären können.
Josef G. schrieb:> Tja, was gelernt zum djnz ...
8-|
Das obige Beispiel habe ich mir vorhin gerade ausgedacht.
Die Funktionalität des Befehls ist klar festgelegt.
Es geht darum die Befehle kreativ zu kombinieren, um das zu erreichen,
was erreicht werden soll. Nur schon mal gesehene Kombinationen
hinzuschreiben ist wie malen nach Zahlen und sich darüber wundern, dass
kein neues Bild entstanden ist.
Deshalb bist Du auch nicht dazu in der Lage, einen sinnvollen
Befehlssatz zu entwerfen.
Gruß
Jobst
Jobst M. schrieb:> Josef G. schrieb:>> Tja, was gelernt zum djnz ...>> 8-|>> Das obige Beispiel habe ich mir vorhin gerade ausgedacht.
Bin jetzt nicht sicher, ob ich nicht missvertanden wurde.
Ich wollte sagen: da hab ich jetzt was gelernt zum djnz.
Josef G. schrieb:> Bin jetzt nicht sicher, ob ich nicht missvertanden wurde.> Ich wollte sagen: da hab ich jetzt was gelernt zum djnz.
Ja, dass habe ich genau so verstanden.
Deshalb.
Gruß
Jobst
Josef G. schrieb:> TriHexagon schrieb:>> auf keinen Fall ist das eine Dokumentation. Nicht nur>> fehlen viele Informationen> Würde ich bestreiten. Welche Information zB. vermisst du?
Zum Beispiel ein einleitender Text, der einfach mal beschreibt welche
Features deine CPU bietet, was sie anders als Etablierte macht und vor
allem warum. Ein Bild die den Aufbau deiner Architektur zeigt, um
überhaupt mal sowas wie einen Überblick zu bieten. Etc. etc. Daran hakt
es schon.
Ach so und irgendwelche Interna deiner CPU kommen ans Ende der
Dokumentation. Erst mal muss man wissen, was das Ding kann und wie man
damit etwas macht. Zu allerletzt interessiert man sich mal, wie die
Architektur was umsetzt. Wenn überhaupt...
Josef G. schrieb:>> Josef G. schrieb:>>>> wenn es auch so geht:> xor a, <argument>>>>>>> Wo soll da der Vorteil sein? Das wäre unnötige mehr-Tipparbeit.>> Der Vorteil ist, dass der Ausdruck "xor" für sich steht und wirklich>> jedem klar ist, dass das eine Exklusiv-Oder Operation ist.>> Das ist ein Vorteil für jemand, der sich neu in die CPU> einarbeitet, aber nicht mehr, wenn die Einarbeitung und> die Gewöhnung an die Mnemonics abgeschlossen ist.>>> Beim Assemblergeschreibsel ist die Schreibarbeit kein Thema,> Würde ich bestreiten. Für fast jedes Byte des Codes eine> eigene Assemblerzeile, da ist sehr viel zu schreiben.
Das ist doch nicht dein Ernst. Für die Übersichtlichkeit ist diese
zwanghafte Abkürzerei absolut kontraproduktiv und absolut unnötig. Wenn
ich da an die K&R C Beispiele denke, kommt mir das grausen. Damals gabs
aber wenigstens noch das Argument, dass Speicher verdammt teuer ist.
Hallo
TriHexagon schrieb:>> Würde ich bestreiten. Für fast jedes Byte des Codes eine>> eigene Assemblerzeile, da ist sehr viel zu schreiben.>> Das ist doch nicht dein Ernst. Für die Übersichtlichkeit ist diese> zwanghafte Abkürzerei absolut kontraproduktiv und absolut unnötig. Wenn> ich da an die K&R C Beispiele denke, kommt mir das grausen. Damals gabs> aber wenigstens noch das Argument, dass Speicher verdammt teuer ist.
da kann ich nur voll zustimmen.
Ich habe vor Jahrzehnten so angefangen: kein Speicherplatz und kein
Assemblerprogramm. "Programm" auf einen Zettel, HEX-Codes rausgesucht
und dazu geschrieben und dann eingetippt.
Wenn ich heute noch was in ASM auf dem AVR mache, wird jedes Bit
benannt, jedes genutzte Register eine passenden Namen, jedes Label wird
verständlich benannt. Die Zeiten, wo nur die ersten 8 Zeichen im
Assembler zur Unterscheidung genutzt wurden sind auch lange vorbei.
An manchen Stellen ist jeder Befehl ausführlich kommentiert, damit ich
meine "Tricks" später selber nachvollziehen kann.
Und da bastelt jemand ein CPU-Konzept und hat Probleme, daß man zuviel
zu schreiben hätte???
Gruß aus Berlin
Michael
>Die Zeiten, wo nur die ersten 8 Zeichen im>Assembler zur Unterscheidung genutzt wurden sind auch lange vorbei.>An manchen Stellen ist jeder Befehl ausführlich kommentiert, damit ich>meine "Tricks" später selber nachvollziehen kann.
Da hast Du völlig recht. Bei modernen Programmierstilen ist der Code die
Dokumentation. Der Code sollte wie ein normaler Text lesbar sein.
Steht auch ausführlich in diesem Buch ( das ich mit meinen 30 Jahren
Programmiererfahrung jedem empfehlen kann ):
https://www.oreilly.de/buecher/120174/9783897215672-weniger-schlecht-programmieren.html
Michael U. schrieb:> Die Zeiten, wo nur die ersten 8 Zeichen im Assembler> zur Unterscheidung genutzt wurden sind auch lange vorbei.
Damit es hier keine Missverständnisse gibt: Solche Schweinereien
wie Namen, wo nur ein Teil der Gesamtlänge Unterscheidungskraft
besitzt, gibt es in meinem ganzen Projekt nicht.
TriHexagon schrieb:> Ein Bild die den Aufbau deiner Architektur zeigt,> um überhaupt mal sowas wie einen Überblick zu bieten.
Reicht das nicht?
1
P Q R S X Y Z K V Bezeichnung: A7 = U
2
| | | | | | | |A AB = K
3
| | | | | | | |B
4
5
P Programmzähler Q Rückkehradresse
6
X Adressregister R Schleifenstartadresse
7
Y Adressregister S Schleifenzähler
8
Z Adressregister A Akku B Erweiterung V Carry
> Ach so und irgendwelche Interna deiner CPU kommen ans Ende der> Dokumentation. Erst mal muss man wissen, was das Ding kann und> wie man damit etwas macht. Zu allerletzt interessiert man sich> mal, wie die Architektur was umsetzt. Wenn überhaupt...
Interna stehen gar keine in meiner CPU-Dokumentation.
Josef G. schrieb:> TriHexagon schrieb:>> Ein Bild die den Aufbau deiner Architektur zeigt,>> um überhaupt mal sowas wie einen Überblick zu bieten.>> Reicht das nicht?>
1
> P Q R S X Y Z K V Bezeichnung: A7 = U
2
> | | | | | | | |A AB = K
3
> | | | | | | | |B
4
>
5
> P Programmzähler Q Rückkehradresse
6
> X Adressregister R Schleifenstartadresse
7
> Y Adressregister S Schleifenzähler
8
> Z Adressregister A Akku B Erweiterung V Carry
9
>
Nein:
Was bedeuten die komische striche unter den Registernamen?
Wie groß (in bits) sind die Register?
Ist V ein komplettes X-bit register?
Warum wird A7 mit U bezeichnet? Was ist A7 überhaupt?
Warum wird K mit AB bezeichnet? Was ist K überhaupt?
Eric B. schrieb:> Ist V ein komplettes X-bit register?
V ist selbstverständlich das Carry-Flag. Wahrscheinlich, weil das Y in
Carry entfernt an ein V erinnert.
Und weil ein Q so klingt wie ein K, ist ein Q für Rückkehradresse
geradezu selbstverständlich.
> Warum wird A7 mit U bezeichnet? Was ist A7 überhaupt?
Ich tippe auf U für Vorzeichen von A. Weil das V ungefähr so wie in U
aussieht.
> Warum wird K mit AB bezeichnet? Was ist K überhaupt?
Vermutlich ein 16-Bit Akku aus A und B. Könnte man natürlich auch AB
nennen, aber dann tippt Josef sich die Finger wund. Kenner aus Motorolas
besseren Zeiten hätten D genommen.
Es würde auch schon ein bisschen helfen, wenn man die Benennung aus
anderen Architekturen übernehmen würde:
Carry: C statt V (das bei anderen Architekturen eine andere Bedeutung
hat)
Programmcounter (PC statt P)
Linkregister: (LR statt Q (siehe ARM))
Ansonsten kann man sich eric anschließen. Es ist nicht ersichtlich was |
bedeutet. Wahrscheinlich 8bit, aber das MUSS dabei stehen. Und warum
braucht man für AB eine extra Bezeichnung K, statt einfach nur AB? Nur
um sich von den bestehenden Architekturen abzuheben und es extra zu
verkomplizieren?
Eric B. schrieb:> Was bedeuten die komische striche unter den Registernamen?
Jeder Strich symbolisiert 1 Byte.
Sollte klar sein, da es sich um eine 8bit-CPU handelt.
> Wie groß (in bits) sind die Register?
Ist damit beantwortet.
> Ist V ein komplettes X-bit register?
Steht doch da: V ist das Carry-Flag
> Warum wird A7 mit U bezeichnet? Was ist A7 überhaupt?
Warum: Damit die Mnemonics einfacher werden.
A7 ist Bit7 von A, also das Vorzeichenbit.
> Warum wird K mit AB bezeichnet? Was ist K überhaupt?
K ist die Kurzbezeichnung für AB, steht doch da.
Warum? Damit die Mnemonics einfacher werden.
Josef G. schrieb:> Steht doch da
Du hast noch nicht begriffen, dass das was Du schreibst, niemand außer
Dir versteht.
Die Kryptik dahinter verstehst nur Du.
Josef G. schrieb:> Reicht das nicht?
Nein. Das reicht nicht. Gar nicht. Überhaupt nicht. In welcher Sprache
soll man dir das erzählen damit du es endlich mal verstehst?
Josef G. schrieb:> Warum? Damit die Mnemonics einfacher werden.
Einfacher für dich. Für alle anderen werden sie dadurch nur
unverständlicher.
Gib es doch bitte endlich auf aller Welt deine CPU als die größte Sache
seit der Erfindung des Sex verkaufen zu wollen. Sei einfach Glücklich
mit dem, was du geleistet hast. Für dich persönlich. Aber lass alle
anderen damit in Ruhe.
@ MaLin (Gast)
>> Reicht das nicht?>Nein. Das reicht nicht. Gar nicht. Überhaupt nicht. In welcher Sprache>soll man dir das erzählen damit du es endlich mal verstehst?
In welcher Sprache muss man es DIR und allen, die hier ernsthaft noch
mitreden, erzählen, damit IHR es versteht?
Beitrag "Re: 8bit-Computing mit FPGA"https://de.wikipedia.org/wiki/Autismus
MaLin schrieb:> In welcher Sprache> soll man dir das erzählen damit du es endlich mal verstehst?
Such dir irgendwas aus, was du kennst, aber nicht er. Das ist für ihn
sicherlich kein Problem "... wenn die Einarbeitung und die Gewöhnung
[...] abgeschlossen ist." (O-Ton Josef).
Hallo,
hmmmm, ich glaube, ich habe eine Anwendung für sein Konzept gefunden:
ein Bekannter macht Geo-Caching. Der soll die nächsten Koordinaten
hinter der Beantwortung dieser Fragen verstecken:
Bei welcher CPU heißt das Carry-Flag V?
Bei welcher CPU ist U das Vorzeichenbit?
Wo wird AB durch K abgekürzt?
Ich fürchte nur, den Cache wird dann nie jemand finden...
Gruß aus Berlin
Michael
Josef G. schrieb:> Eric B. schrieb:>> Was bedeuten die komische striche unter den Registernamen?> Jeder Strich symbolisiert 1 Byte.
Ach so, das wird aber nirgendwo erklärt.
>> Wie groß (in bits) sind die Register?> Ist damit beantwortet.
8 bit, da es sich um einen 8-bit CPU handelt!
>> Ist V ein komplettes X-bit register?> Steht doch da: V ist das Carry-Flag
Nöh, da steht "Carry", nicht "Carry-Flag". Hätte auch ein 8 oder 16-bit
Register sein können mit Carry-flags für jeden Bit-Position. Und warum
heisst es dann nicht C, wie Carry?
>> Warum wird A7 mit U bezeichnet? Was ist A7 überhaupt?> Warum: Damit die Mnemonics einfacher werden.ROFL> A7 ist Bit7 von A, also das Vorzeichenbit.
Ach so. Und warum heisst es dann nicht V? Weil das Carry schon V heisst?
>> Warum wird K mit AB bezeichnet? Was ist K überhaupt?> K ist die Kurzbezeichnung für AB, steht doch da.> Warum? Damit die Mnemonics einfacher werden.
Aah! K für "Kurz für AB", alles klar! o_O
Mir ist durchaus bewusst, dass meine CPU-Dokumentation,
wie auch die Dokumentation zum Gesamtsystem, sehr knapp
und stichwortartig ist. Ich hatte mir das so vorgestellt,
dass Unklarheiten im Forum geklärt werden. Nur leider
hat, auch im Thread 8bit-Computing mitFPGA, kaum jemand
eine konkrete Frage dazu gestellt, auch nachdem ich mehrfach
darum gebeten hatte. Stattdessen wurde der Thread mit
unsachlichen Beiträgen zugemüllt, so dass die wenigen
informativen Beiträge in diesem Wust kaum noch zu finden
sind. Darum habe ich nochmal einen neuen Thread aufgemacht.
Ich glaube auch nicht, dass meine CPU das Maß aller Dinge
ist, so wie mir das hier mehrfach unterstellt wurde. Aber
ich glaube nach wie vor, dass sie eine Chance hätte, ihre
Anwendungs-Nische zu finden, weil es ihre Eigenschaften
jedenfalls in dieser Kombination bei anderen CPU's nicht
gibt, und weil sie besonders einfach zu verstehen und zu
programmieren ist. Mit besonders einfach zu verstehen
meine ich hier die CPU, nicht die Dokumentation. Eine
ausführliche Dokumentation wäre noch zu erstellen,
aber die Arbeit würde ich mir erst dann antun (oder
jemand anderer), wenn sich Mitstreiter finden.
Josef G. schrieb:> aber die Arbeit würde ich mir erst dann antun ... wenn sich Mitstreiter finden.
Sei unbesorgt, du hast die nächsten Jahrzehnte frei.
Josef G. schrieb:>> Warum wird A7 mit U bezeichnet? Was ist A7 überhaupt?> Warum: Damit die Mnemonics einfacher werden.
Mnemonics sollten zwar nicht zu lang sein, aber man sollte sie sich auch
merken können, denn (aus Wikipedia):
1
Mnemonic (englisch für „Gedächtnisstütze“ vom griechischen mnēmoniká
2
„Gedächtnis“, teilweise auch deutsch Mnemonik) steht allgemein für eine
3
Merkhilfe, im Speziellen jedoch für:
4
5
- ein für den Menschen lesbares Kürzel für einen Befehl einer
6
Assemblersprache
7
- […]
Folgende Mnemonics können für mich definitiv nicht als Gedächtnisstütze
dienen, da ich mir unter den Buschtabenkombinationen überhaupt nichts
vorstellen kann:
1
GT. nn A wird nn
Das ist ein Ladebefehl, der sonst MOV, LDA, LDI o.ä heißt. Wraum GT?
1
LV. nn A wird nn-A-V V erhält Übertrag
Das ist eine Subtraktion mit vertauschten Operanden. Das V ist klar,
aber was heißt das L? Warum nimmst du nicht das L (oder besser LD) für
Ladebefehle (statt GT) und nennst diese umgedrehte Subtraktion – wenn
der Name schon unbedingt so kurz sein muss – bspw. SN (subtract and
negate)?
1
R.CN wenn S >0 dann ( P wird R , S wird S-1 )
Das scheint der Schleifenrücksprungbefehl zu sein. Aber was soll das
CN bedeuten?
1
SL.$ $ LowByte erhält A , $ HighByte wird 0
Das kopiert ein 8-Bit- in ein 16-Bit-Register. Aber wieso SL?
1
CP.V V wird V xor U
Hier wird aus dem V-Flag (was normalerweise C heißt) mit Hilfe des
U-Flags (was normalerweise N heißt) ein Overflow-Flag gemacht (was
normalerweise V. Damit trägt das V-Flag nach Ausführung dieses Befehls
erstmals sein Kürzel zurecht. Aber warum CP? Heißt das vielleicht
"ComPatible to existing naming convention"? ;-)
1
EX.$ | ES.% Austausch von K<>$ | S<>%
ES heißt wohl "Exchange with S". Wäre es da nicht logisch EX ind EK
umzubenennen? Oder noch besser: EXK statt EX und EXS statt ES.
1
I%s mit s= 0..7 % wird %+s+1
Wieso nicht
I%s mit s= 1..8 % wird %+s
Dann würde im Quellecode die Zahl dastehen, die auch tatsächlich
addiert wird, und man müsste beim Schreiben des Codes nicht selber die
1 vom Operanden subtrahieren.
1
GT.Q K erhält Q
2
NON 00 K erhält R 2 Zyklen
Wenn man erst einmal weiß, was GT bedeutet, ist der erste Befehl klar.
Wieso heißt dann der zweite nicht GT.R? NON ist doch sonst ein NOP mit
n Taktzyklen, aber dieser Befehl hier tut ja mehr als nur Zyklen
verzehren.
Noch ein kleine Frage zum Verständnis:
In deiener Doku steht AB = K. Heißt das, dass A das High- und B das
Low-Byte ist? Da A der Akkumulator ist, hätte ich eher die umgekehrte
Reihenfolge vermutet.
Josef G. schrieb:> Mir ist durchaus bewusst, dass meine CPU-Dokumentation,> wie auch die Dokumentation zum Gesamtsystem, sehr knapp> und stichwortartig ist. Ich hatte mir das so vorgestellt,> dass Unklarheiten im Forum geklärt werden. Nur leider> hat, auch im Thread 8bit-Computing mit FPGA, kaum jemand> eine konkrete Frage dazu gestellt, auch nachdem ich mehrfach> darum gebeten hatte.
Eine Frage stellt man für gewöhnlich dann, wenn man von einem Thema
mindestens 90% verstanden hat und nur noch wenige Punkte unklar sind.
Hat man nur 10% verstanden, kann man nicht einmal sicher sein, ob einen
das Thema überhaupt interessiert. Warum sollte man sich dann die Mühe
machen, einen monströsen Fragekatalog zu den restlichen 90% zu
schreiben?
Die Einarbeitung in ein komplexes Thema wird normalerweise durch so
genannte Tutorials erleichtert. So etwas gibt es für deinen Prozessor
leider (noch) nicht. Ein Tutorial unterscheidet sich von einer Referenz
dadurch, dass die einzelnen Teilthemen nicht perfekt logisch gruppiert
sind, sondern in der Reihenfolge aufgeführt werden, wie sie den
schnellsten Lernfortschritt ermöglichen. Ist etwas in dieser Richtung
geplant?
Aus deine Doku zu Lernen ist dann ungefähr so, wie wenn du in die
C-Programmierung einsteigen möchtest und ich dir dafür die ISO-Norm
empfehle mit dem Hinweis, dass da garantiert alles zu dem Thema darin
steht. Selbst jemand, der bereits lange Erfahrung mit anderen
Programmiersprachen hat, wird sich extrem schwertun, allein damit
zurechtzukommen. Wenn du's nicht glaubst, probier es einfach aus :)
Und im Gegensatz zur C-ISO-Norm scheint deine Doku nicht einmal
vollständig zuu sein. Die Fragen mit den Bitbreiten der einzelnen
Register kam ja schon. Ich habe auch keine Informationen darüber
gefunden, ob und wie das V-Flag bei Additionen und Subtraktionen gesetzt
wird. Man kann es sich zwar aus den Erfahrungen mit anderen Prozessoren
zusammenreimen, aber deine CPU unterscheidet sich in so vielen Punkten
vom Mainstream, dass man sich da überhaupt nicht sicher sein kann.
Für C gibt es von der ISO zusätzlich zur eigentlichen Norm noch ein
"Rationale"-Dokument, in dem sämtliche seltsam bis unlogisch
erscheinenden Passagen der Norm erläutert werden. In deiner CPU gibt es
einige Befehle, die man von herkömmlichen CPUs nicht kennt. Ein Beispiel
wäre dieser hier:
CR.V U wird V xor U , dann wird ein RU.A ausgeführt
(und das ist bei Weitem nicht der einzige)
Hier wäre ein Hinweis angebracht, wozu es diesen Befehl gibt, zusammen
mit einem Beispiel, wie er sinnvoll eingesetzt wird.
Dasselbe gilt für altbekannte Befehle, die in deiner CPU zu fehlen
scheinen. Warum gibt es bspw. einen NOR- aber keinen OR-Befehl?
1
NR. nn A wird A nor nn
OR habe ich schon geschätzte 1000-mal verwendet, vor allem zum Setzen
einzelner Bits in einem Register. NOR habe ich vielleicht 2-mal
gebraucht und dann eben aus zwei Einzelbefehlen zudsammengesetzt.
Josef G. schrieb:> Aber> ich glaube nach wie vor, dass sie eine Chance hätte, ihre> Anwendungs-Nische zu finden,
Da bist Du der Einzige.
Ich kann mir nicht vorstellen, dass sich jemand mit so einer wirren CPU
beschäftigt. Vorher wird Parallax Marktführer bei MCUs.
(Und da ist das Konzept zumindest interessant!)
> weil es ihre Eigenschaften> jedenfalls in dieser Kombination bei anderen CPU's nicht> gibt,
Du meinst kryptische Befehle und Registernamen? Aus gutem Grund ist das
bei anderen CPUs nicht so!
> und weil sie besonders einfach zu verstehen und zu> programmieren ist.
Nein, ist sie nicht. Sie ist chaotisch. Eine Zumutung!
Kein Mensch kann sich Befehle und Registernamen merken!
> Mit besonders einfach zu verstehen> meine ich hier die CPU, nicht die Dokumentation.
Die Dokumentation ist nich um ihrer selbst Willen vorhanden.
Und ebenfalls chaotisch.
Josef G. schrieb:> Niemand wird gezwungen, den Thread anzuklicken ...
Doch. Du versuchst Deine CPU jedem aufzuschwatzen. Deshalb startest Du
auch immer wieder einen neuen Thread.
„Wenn jemand inkompetent ist, dann kann er nicht wissen, dass er
inkompetent ist. […] Die Fähigkeiten, die man braucht, um eine richtige
Lösung zu finden, [sind] genau jene Fähigkeiten, die man braucht, um
eine Lösung als richtig zu erkennen.“
– David Dunning
Viel Spaß noch!
Gruß
Jobst
Hallo,
Yalu X. (yalu) (Moderator):
ich muß jetzt hier mal Danke sagen, daß Du das soweit auseinadergenommen
hast. Ich gebe zu, daß ich dazu die Zeit und wohl auch die Lust nicht
hatte, mir die Zeit zu nehmen.
Deine Beispiele haben meinen ersten Eindruck bestätigt.
Mal schauen, was der TO dazu sagt.
Gruß aus Berlin
Michael
Jürgen schrieb im Beitrag #4734526:
> MWS schrieb:>> Das Topic>> wurde eröffnet um erneut Aufmerksamkeit zu generieren.>> Hilft nix.
Kommt auf den Standpunkt an, für den TO hat's geklappt.
> Wieder fallen alle darauf rein.
Einerseits glauben die immer noch, es beim User Bome mit einer rational
denkenden Person zu tun zu haben, andererseits würde gerne jeder den
kleinen Sieg nach Hause tragen, Bome von der Sinnlosigkeit seines Tuns
zu überzeugen, bzw. wenigstens einen Prozess ernsthaften Nachdenkens
bei ihm angeregt zu haben.
Selbst wenn Bome unwiderlegbar bewiesen würde, dass er auf dem Holzweg
ist, so würde er dies dennoch ignorieren und Argumente dafür finden,
warum seine Sicht der Dinge richtig ist. Das war bei jedem seiner
Threads so und das wird auch so bleiben.
Zur Not füllt Bome einen Thread auch allein, aber was er noch viel mehr
mag ist Aufmerksamkeit, Aufmerksamkeit und nochmals Aufmerksamkeit.
Diese Aufmerksamkeit bekommt er hier, selbst dann wenn alle gegen ihn
sind, da fühlt er sich dann als Partisan, einer gegen alle.
Deswegen auch der debile Bezug auf einen Thread, der wenigstens noch
Gehalt hatte:
> Beitrag "AVR: Werden gleiche Opcodes unterschieden?"
Denn das:
> Angeregt durch diesen aktuellen Thread> ...> möchte ich den Befehlssatz der bo8-CPU zur Diskussion stellen.
ist genauso sinnlos wie das örtliche Telefonbuch diskutieren zu wollen.
>> Das ist ein Ladebefehl, der sonst MOV, LDA, LDI o.ä heißt. Wraum GT?
GT: GET (erhalte), passt optisch gut zu ST
>
1
> LV. nn A wird nn-A-V V erhält Übertrag
2
>
>> Das ist eine Subtraktion mit vertauschten Operanden. Das V ist klar,> aber was heißt das L? Warum nimmst du nicht das L (oder besser LD) für> Ladebefehle (statt GT) und nennst diese umgedrehte Subtraktion – wenn> der Name schon unbedingt so kurz sein muss – bspw. SN (subtract and> negate)?
L: LESSEN vermindere zweiten Operanden um A (Ergebnis in A)
>
1
> R.CN wenn S >0 dann ( P wird R , S wird S-1 )
2
>
>> Das scheint der Schleifenrücksprungbefehl zu sein. Aber was soll das> CN bedeuten?
R: REPEAT CN: COUNTING>
1
> SL.$ $ LowByte erhält A , $ HighByte wird 0
2
>
>> Das kopiert ein 8-Bit- in ein 16-Bit-Register. Aber wieso SL?STORE A in LOW-Byte von $
>
1
> CP.V V wird V xor U
2
>
>> Hier wird aus dem V-Flag (was normalerweise C heißt) mit Hilfe des> U-Flags (was normalerweise N heißt) ein Overflow-Flag gemacht (was> normalerweise V. Damit trägt das V-Flag nach Ausführung dieses Befehls> erstmals sein Kürzel zurecht. Aber warum CP? Heißt das vielleicht> "ComPatible to existing naming convention"? ;-)
CP: COMPARE>
1
> EX.$ | ES.% Austausch von K<>$ | S<>%
2
>
>> ES heißt wohl "Exchange with S". Wäre es da nicht logisch EX ind EK> umzubenennen? Oder noch besser: EXK statt EX und EXS statt ES.
Bei Akku-zentriertem Befehlssatz ist es nicht ungewöhnlich,
den Akku als ersten Operanden nicht anzugeben. K ist der
auf 2 Byte erweiterte Akku.
>
1
> I%s mit s= 0..7 % wird %+s+1
2
>
>> Wieso nicht>> I%s mit s= 1..8 % wird %+s>> Dann würde im Quellecode die Zahl dastehen, die auch tatsächlich> addiert wird, und man müsste beim Schreiben des Codes nicht selber die> 1 vom Operanden subtrahieren.
Ausser IXs gibt es auch IXL nn : Inkrementiere X, lange Distanz.
Würde man hier nicht um nn+1 inkrementieren, müsste man gesondert
festlegen: 00 entspricht 100. Damit es einheitlich ist, habe ich
auch bei s festgelegt s+1. Leicht zu merken: Wenn X auf eine
Adresse zeigt, ist s bzw. nn die Anzahl der übersprungenen Byte.
>
1
> GT.Q K erhält Q
2
> NON 00 K erhält R 2 Zyklen
3
>
> Wenn man erst einmal weiß, was GT bedeutet, ist der erste Befehl klar.> Wieso heißt dann der zweite nicht GT.R? NON ist doch sonst ein NOP mit> n Taktzyklen, aber dieser Befehl hier tut ja mehr als nur Zyklen> verzehren.
Würde den Assembler verkomplizieren, aber Einwand ist berechtigt.
> Noch ein kleine Frage zum Verständnis:>> In deiener Doku steht AB = K. Heißt das, dass A das High- und B das> Low-Byte ist? Da A der Akkumulator ist, hätte ich eher die umgekehrte> Reihenfolge vermutet.
Wenn K das Ergebnis von zwei 1-Byte-Additionen enthält, steht im
Akku das High-Byte. Auch wenn ich beim Laden einer Adresse nach K
zuerst das Low-Byte lade, steht in A das High-Byte.
Laden einer relativen Adresse:
1
GTMX
2
IXE
3
GTMX
4
AD.X
5
ST.Y
> ... Tutorial ... Ist etwas in dieser Richtung geplant?
Wie schon geschrieben: Erst müsste sich etwas tun in Richtung
Mitstreiter, damit ich glauben kann, dass sich das lohnt.
> Ich habe auch keine Informationen darüber gefunden, ob und wie> das V-Flag bei Additionen und Subtraktionen gesetzt wird.
Steht immer dabei: V erhält Übertag. Die Polarität ergibt sich
aus der Forderung nach Kaskadierbarkeit ohne Negierung von V.
> CR.V U wird V xor U , dann wird ein RU.A ausgeführt> Hier wäre ein Hinweis angebracht, wozu es diesen Befehl gibt,> zusammen mit einem Beispiel, wie er sinnvoll eingesetzt wird.
Achtfache Ausführung berechnet die Parität. Wenn man dann noch
ein RU.A anhängt, wird Graycode in Normalcode konvertiert.
> Warum gibt es bspw. einen NOR- aber keinen OR-Befehl?
Das ergibt sich aus der Forderung, dass alle logischen Operationen
unabhängig davon sein sollen, welcher Operand zuerst in A steht.
Statt [A and not XX] führt man aus [not (not A or XX)].
>
1
> NR. nn A wird A nor nn
2
>
>> OR habe ich schon geschätzte 1000-mal verwendet, vor allem zum Setzen> einzelner Bits in einem Register. NOR habe ich vielleicht 2-mal> gebraucht und dann eben aus zwei Einzelbefehlen zudsammengesetzt.
OR lässt sich häufig ersetzen durch XOR, nur selten
musste ich bisher Negation nach NOR verwenden.
Siehe auch
Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
>>>> Das ist ein Ladebefehl, der sonst MOV, LDA, LDI o.ä heißt. Wraum GT?>> GT: GET (erhalte), passt optisch gut zu ST
Englisch.
>>>
1
>> LV. nn A wird nn-A-V V erhält Übertrag
2
>>
>>>> Das ist eine Subtraktion mit vertauschten Operanden. Das V ist klar,>> aber was heißt das L? Warum nimmst du nicht das L (oder besser LD) für>> Ladebefehle (statt GT) und nennst diese umgedrehte Subtraktion – wenn>> der Name schon unbedingt so kurz sein muss – bspw. SN (subtract and>> negate)?>> L: LESSEN vermindere zweiten Operanden um A (Ergebnis in A)
Deutsch.
>>>
1
>> R.CN wenn S >0 dann ( P wird R , S wird S-1 )
2
>>
>>>> Das scheint der Schleifenrücksprungbefehl zu sein. Aber was soll das>> CN bedeuten?>> R: REPEAT CN: /COUNTING/
Repeating oder Count? Warum Repeat und Counting?
>>>
1
>> SL.$ $ LowByte erhält A , $ HighByte wird 0
2
>>
>>>> Das kopiert ein 8-Bit- in ein 16-Bit-Register. Aber wieso SL?>> STORE A in LOW-Byte von $>>>
1
>> CP.V V wird V xor U
2
>>
>>>> Hier wird aus dem V-Flag (was normalerweise C heißt) mit Hilfe des>> U-Flags (was normalerweise N heißt) ein Overflow-Flag gemacht (was>> normalerweise V. Damit trägt das V-Flag nach Ausführung dieses Befehls>> erstmals sein Kürzel zurecht. Aber warum CP? Heißt das vielleicht>> "ComPatible to existing naming convention"? ;-)>> CP: /COMPARE/
Warum Compare? Inconsistent. Müsste XR heißen. Etwas anderes darf dann
eben nicht XR sondern muss wieder anders heißen.
>>>
1
>> GT.Q K erhält Q
2
>> NON 00 K erhält R 2 Zyklen
3
>>
"erhält" ist im Deutschen mehrdeutig.
Was ist der Unterschied zwischen "erhält" und "wird"?
"NON" sind 3 Buchstaben. Warum nicht 2? Inkonsistent. Dies sollte zB. NO
heißen.
Josef G. schrieb:> Lars R. schrieb:>> Was ist der Unterschied zwischen "erhält" und "wird"?>> In meiner CPU-doku: kein Unterschied.
Inkonsistent. Inkonsistent ist gegensätzlich zu selbsterklärend oder
logisch oder zu leicht verständlich.
Warum verwendet Du verschiedene Worte (die bereits allein für sich
mehrdeutig sind) zum Ausdrücken von ein und der selben Sache?
Was ist mit meinen anderen Punkten?
Grüße
Lars
Josef G. schrieb:> Mir ist durchaus bewusst, dass meine CPU-Dokumentation,> wie auch die Dokumentation zum Gesamtsystem, sehr knapp> und stichwortartig ist. Ich hatte mir das so vorgestellt,> dass Unklarheiten im Forum geklärt werden.
Und der von deiner spartanischen Doku noch nicht abgeschreckte
potentielle Anwender soll dann auch noch hunderte von Posts durchackern,
um irgendeine brauchbare Information zu erhalten? Das schreckt doch
selbst den hartgesottensten Anwender ab!
Der richtige Weg wäre, die Unklarheiten, auf die im Forum hingewiesen
wurden, in der Doku zu verbessern!
Kaum ein Entwickler schreibt gerne Doku - aber es muss sein, damit
andere auf diese Arbeit aufbauen können. Ohne ordentliche Doku ist die
Arbeit im Grunde nur One-Time-Usable - und zwar nur vom Entwickler
selbt.
Josef G. schrieb:> Lars R. schrieb:>> Was ist mit meinen anderen Punkten?>> Ist die Frage wirklich ernst gemeint?
Ja. Ich habe Kritik angebracht. Dabei habe ich den Maßstab, Du den als
Anspruch für Dein Projekt hier dargestellt hast, zu Grunde gelegt.
Dieser Kritik könntest Du zustimmen, sie ablehnen oder sagen, dass sie
unverständlich ist.
Hallo,
ich habe jetzt zumindest noch in die am Anfang verlinkten Wiki-Beiträge
geschaut. Wenn die Verwirrung um die Menmotics und die Striktur der CPU
nicht groß genug ist, kann man sich also auch noch bola anschauen?
Keine Formatbeschreibung, keine Syntaxbeschreibung, keine Beipiele
dafür, auch alles zum selber zusammensuchen?
Ich frage mich immernoch, wofür das alles sein soll?
Wenn ich das jetzt also ernst mehmen wollte, müßte ich mir ein offenbar
zeimlich teures FPGA-Board beschaffen, zusehen, wie ich die CPU da drauf
bekomme und dann könnte ich mehr oder weniger erfolgreich mein "Hello
World" oder die blinkende LED zustande bekommen?
Wo ist hier eigentlich für wen die Stelle mit dem
"...wenn man einen für
jedermann verstehbaren Computer bauen will."
Das hat Herr Sinclair schon mit seinem ZX80 besser hinbekommen...
Gruß aus Berlin
Michael
Grosses Kino.
Mir mag irgendwie nicht mehr viel einfallen, ausser folgender Liedtext,
man möge mir überdies eine allfällige Off-Topic-Verfehlung nachsehen.
Logikaufstand in der ALU
Spät des Abends, crasht die Kiste
Der Fehler liegt an der Netzliste,
Schuld hat a-synchrone Logik,
wie auch Schleifen-Komb'natorik,
Umba Umbaa-assa...
Viele Mühe gibt sich Yalu
mit Kritik an bomes ALU,
doch der Aufwand will nicht glücken,
und der Befehlssatz nicht entzücken.
Umba Umbaa-assa...
Und sie streiten immer weiter,
doch kein Horizont wird breiter,
Es wird weiterhin geworben,
für ne CPU, die schon gestorben.
Umba Umbaa-assa...
Manchen scheint es Hokuspokus,
andern fehlen nur die Dokus,
meinerseits will Ruhe haben,
und sähe gern den Thread begraben.
Umba umbaa-assa...
Josef G. schrieb:>> ... Tutorial ... Ist etwas in dieser Richtung geplant?> Wie schon geschrieben: Erst müsste sich etwas tun in Richtung> Mitstreiter, damit ich glauben kann, dass sich das lohnt.
Ohne verständliche Dokumentation (und damit eventuell Tutorial) wirst du
keine Mitstreiter finden. Da du diese aber von Mitstreitern abhängig
machst, wirst du weder Mitstreiter noch verständliche Dokumentation
bekommen.
Sowas nennt man im Englischen einen Catch-22 und der ist hier
offensichtlich beabsichtigt.
Josef G. schrieb:> GT: GET (erhalte), passt optisch gut zu ST
Das sollte aber in der Doku dabeistehen, Gleiches gilt für alle anderen
Befehle. Sonst kann sich das niemand merken.
> CP: COMPARE
Und was genau wird da mit was verglichen?
>>>> EX.$ | ES.% Austausch von K<>$ | S<>%>> >>> ES heißt wohl "Exchange with S". Wäre es da nicht logisch EX ind EK>> umzubenennen? Oder noch besser: EXK statt EX und EXS statt ES.>> Bei Akku-zentriertem Befehlssatz ist es nicht ungewöhnlich,> den Akku als ersten Operanden nicht anzugeben. K ist der> auf 2 Byte erweiterte Akku.
Und was ist mit SL.K, NE.K, ZO.K, IC.K, DC.K, O.KZ, O.KS, B.KZ und B.KS,
R.KZ, R.KS, IKL und DKL? Warum lässt du dort das K nicht ebenfalls weg?
> Ausser IXs gibt es auch IXL nn : Inkrementiere X, lange Distanz.> Würde man hier nicht um nn+1 inkrementieren, müsste man gesondert> festlegen: 00 entspricht 100.
Nein. Der Wertebereich geht von 1 bis 256 (hex 01 bis 100). Dann möchte
ich den Wert auch genauso hinschreiben. Darum, wie diese Werte dann im
erzeugten Binärcode dargestellt werden, sollte sich der Programmierer
nicht kümmern müssen. Der wahre Grund für diese seltsame Verhalten liegt
doch eher darin, dass dein Assembler keine dreistelligen Hexzahlen
(geschweige denn Dezimalzahlen) lesen kann, oder?
> Leicht zu merken: Wenn X auf eine Adresse zeigt, ist s bzw. nn die> Anzahl der übersprungenen Byte.
Das ist vielleicht eine Kleinigkeit, aber von diesen Kleinigkeiten muss
man sich in deiner Assemblersprache eine ganze Menge merken.
>> NON 00 K erhält R 2 Zyklen>> ...> Würde den Assembler verkomplizieren, aber Einwand ist berechtigt.
Ich dachte, ein Assembler sei dazu da, dem Programmierer Arbeit
abzunehmen und nicht umgekehrt.
>> ... Tutorial ... Ist etwas in dieser Richtung geplant?>> Wie schon geschrieben: Erst müsste sich etwas tun in Richtung> Mitstreiter, damit ich glauben kann, dass sich das lohnt.
Also noch eine Katze, die sich in den Schwanz beißt.
>> Ich habe auch keine Informationen darüber gefunden, ob und wie>> das V-Flag bei Additionen und Subtraktionen gesetzt wird.>> Steht immer dabei: V erhält Übertag.
Ok, das habe ich falsch verstanden, ist aber klar, wenn man noch einmal
darüberliest. Das heißt dann aber, dass es keinen Additionsbefehl gibt,
der A = A + <irgendwas> (unabhängig von V) rechnet, trotzdem aber das
V-Flag in Abhängigkeit des Ergebnisses setzt. Für die Addition zweier
32-Bit-Zahlen, die man bspw. auf einem AVR mit 4 Befehlen (1×ADD und
3×ADC) erschlägt, muss man bei dir noch ein ZO.V voranstellen, um V zu
löschen. Richtig?
>> CR.V U wird V xor U , dann wird ein RU.A ausgeführt> ...> Achtfache Ausführung berechnet die Parität. Wenn man dann noch> ein RU.A anhängt, wird Graycode in Normalcode konvertiert.
Dann schreib das doch in die Doku mit hinein.
Wobei ich mich frage, warum du für eine so selten benötigte Operation
extra einen Befehl spendiert hast. Und wenn die Paritätsgenerierung und
Gray-Code-Dekodierung für dich so wichtig sind, warum hast du nicht
einen Befehl implementiert, der alle 8 Schritte auf einmal durchführt?
Der wäre wahrscheinlich sogar weniger komplex geworden, weil er nur auf
den Bits von A operiert und nicht noch das V-Flag behandeln muss.
>> Warum gibt es bspw. einen NOR- aber keinen OR-Befehl?>> Das ergibt sich aus der Forderung, dass alle logischen Operationen> unabhängig davon sein sollen, welcher Operand zuerst in A steht.
OR ist doch – genauso wie AND – kommutativ und assoziativ. Wo liegt da
das Problem?
> Statt [A and not XX] führt man aus [not (not A or XX)].
Und [A or not XX]? Dafür bräuchte man doch ein NAND, was es aber auch
nicht gibt.
> OR lässt sich häufig ersetzen durch XOR, nur selten> musste ich bisher Negation nach NOR verwenden.
OR wird zum Setzen, AND zum Löschen und XOR zum Toggeln von Bits
verwendet, wobei IMHO das Toggeln deutlich seltener benötigt wird als
das Setzen und Löschen.
Andere Frage: Manche Befehle enthalten einen (J.. sogar zwei) Punkte im
Namen. Gibt es für die Anzahl und die Position der Punkte eine Regel?
Yalu X. schrieb:>> CP: COMPARE>> Und was genau wird da mit was verglichen?
V mit U. 1-Bit-Vergleich ist dasselbe wie xor.
> Und was ist mit SL.K, NE.K, ZO.K, IC.K, DC.K, O.KZ, O.KS, B.KZ und B.KS,> R.KZ, R.KS, IKL und DKL? Warum lässt du dort das K nicht ebenfalls weg?
Bei SL.K ist K der zweite Operand (wie bei SL.X), nicht der erste.
Bei NE.K .. R.KS gibt es dasselbe auch mit A statt K.
Bei IKL und DKL gibt es das auch für X,Y,Z, aber ok., das
sind keine Akkus, insofern ist es inkonsequent. Mir ist halt
nichts besseres eingefallen.
>> Ausser IXs gibt es auch IXL nn : Inkrementiere X, lange Distanz.>> Würde man hier nicht um nn+1 inkrementieren, müsste man gesondert>> festlegen: 00 entspricht 100.>> Nein. Der Wertebereich geht von 1 bis 256 (hex 01 bis 100). Dann möchte> ich den Wert auch genauso hinschreiben. Darum, wie diese Werte dann im> erzeugten Binärcode dargestellt werden, sollte sich der Programmierer> nicht kümmern müssen. Der wahre Grund für diese seltsame Verhalten liegt> doch eher darin, dass dein Assembler keine dreistelligen Hexzahlen> (geschweige denn Dezimalzahlen) lesen kann, oder?
Ja. Und mir leuchtet auch nicht ein, warum man wegen eines
Sonderfalls eine zusätzliche Stelle reservieren soll. Aber vielleicht
schreibt ja mal jemand einen Assembler, der es anders macht.
>>> NON 00>> Würde den Assembler verkomplizieren, aber Einwand ist berechtigt.>> Ich dachte, ein Assembler sei dazu da, dem Programmierer Arbeit> abzunehmen und nicht umgekehrt.
Ein einziger OpCode, den man sich als Ausnahme merken muss ...
> Das heißt dann aber, dass es keinen Additionsbefehl gibt,> der A = A + <irgendwas> (unabhängig von V) rechnet, trotzdem> aber das V-Flag in Abhängigkeit des Ergebnisses setzt.> ...> muss man bei dir noch ein ZO.V voranstellen, um V zu löschen.
Wegen der von mir gewählten Polarität von V bei der Subtraktion
gibt es eine klare Vorzugslage für V, nämlich V=0. Deshalb wird
V beim Abfragen automatisch gelöscht. Es kommt selten vor,
dass man V gesondert löschen muss.
>>> CR.V U wird V xor U , dann wird ein RU.A ausgeführt> ...> Wobei ich mich frage, warum du für eine so selten benötigte Operation> extra einen Befehl spendiert hast.
Da es V xor U mit Resultat in V gibt und eine gewisse Symmetrie
zwischen U und V besteht, sollte es auch V xor U mit Resultat in U
geben. Das erreicht man mit CR.V und RD.A
> einen Befehl implementiert, der alle 8 Schritte auf einmal durchführt?
Weil man vielleicht auch mal weniger als 8 Bit braucht.
>> Statt [A and not XX] führt man aus [not (not A or XX)].>> Und [A or not XX]? Dafür bräuchte man doch ein NAND,
[A or not XX] wird realisiert durch [not (not A and XX)].
[not A or XX] wird realisiert durch [not (not A nor xx)],
und die Situation ist hinsichtlich Platzbedarf und Dauer
wieder symmetrisch.
>> OR lässt sich häufig ersetzen durch XOR, nur selten>> musste ich bisher Negation nach NOR verwenden.>> OR wird zum Setzen, AND zum Löschen und XOR zum Toggeln von Bits> verwendet, wobei IMHO das Toggeln deutlich seltener benötigt wird als> das Setzen und Löschen.
OR lässt sich durch XOR ersetzen, wenn man den
alten Zustand kennt, was häufig der Fall ist.
> Andere Frage: Manche Befehle enthalten einen (J.. sogar zwei) Punkte im> Namen. Gibt es für die Anzahl und die Position der Punkte eine Regel?
Der Punkt ist der auf der Grundlinie liegende Bindestrich.
In meiner Systematik sind Namen mindestens 3 Zeichen lang,
deshalb werden zwei .. ergänzt, ebenso wie bei H.. Beide
Operationen enthalten nur ein hohes Zeichen, damit sie
im übrigen Code auffallen.
In anderen Befehlen dient der . als Trennzeichen anstelle eines
Leerzeichens, weil in meiner Systematik die Operanden im
Mnemonik enthalten sind.
Yalu X. schrieb:> OR ist doch – genauso wie AND – kommutativ und assoziativ.> Wo liegt da das Problem?
Nur bei Operationen, wo A vorher negiert wird,
weil das beim zweiten Operanden nicht möglich ist.
>>> Statt [A and not XX] führt man aus [not (not A or XX)].
Die dazu symmetrische Operation wäre [not A and XX],
das als Ergänzung zu meinem vor-vorherigen Beitrag.
Josef G. schrieb:> weil das beim zweiten Operanden nicht möglich ist.
Gemeint war hier, wenn ein nicht-immediate-Operand im
Speicher steht. Bei B ist es natürlich möglich, aber dann
hat man halt B geändert, was man vielleicht nicht möchte.
Yalu X. schrieb:> Darum, wie diese Werte dann im erzeugten Binärcode dargestellt> werden, sollte sich der Programmierer nicht kümmern müssen.
Tja, da gibt es einen grundsätzlichen Unterschied in den
Zielsetzungen. Der anwendungsorientierte Programmierer möchte
sich nicht darum kümmern müssen. Der verwendet aber ohnehin
lieber C als Assembler. Der Hobbyist mit Freude an Bits und
Bytes möchte gern alles selber kontrollieren. Und solche
Leute habe ich im Auge als Anwender meines Systems. Hierzu
passt auch die von mir favorisierte Programmiertechnik
mit taktgenau berechenbaren Programmlaufzeiten.
Und natürlich der Zeichensatz ...
Josef G. schrieb:> Ja. Und mir leuchtet auch nicht ein, warum man wegen eines> Sonderfalls eine zusätzliche Stelle reservieren soll. Aber vielleicht> schreibt ja mal jemand einen Assembler, der es anders macht.
Unwahrscheinlich, mangels hinreichender Dokumentation und Interesse.
>> Ich dachte, ein Assembler sei dazu da, dem Programmierer Arbeit>> abzunehmen und nicht umgekehrt.> Ein einziger OpCode, den man sich als Ausnahme merken muss ...
Siehst du die Maschine als Sklaven des Menschen oder den Mensch als
Sklaven der Maschine an?
Mir ist klar, dass die Welt stramm in Richtung "maschinenfreundlicher
Mensch" marschiert, dennoch sollten Tools für den Menschen entworfen
sein.
> OR lässt sich durch XOR ersetzen, wenn man den> alten Zustand kennt, was häufig der Fall ist.
Ich korrigiere:
OR lässt sich durch XOR ersetzen, wenn man den alten Zustand vorher
erfragt, was nicht immer möglich ist und zusätzliche Befehle benötigt.
Solche unbegründeten Entscheidungen machen deinen Befehlssatz im
Vergleich zu anderen CPUs sowohl in Geschwindigkeit als auch in
Programmgröße ineffizient. Ein Blick in den Hennessy/Patterson hätte
geholfen, die wichtigen von den unwichtigen Instruktionen zu trennen.
Durch das Fehlen allgemein üblicher Instruktionen ist die Programmierung
des Systems in Assembler mit Vorkenntnissen schwerfällig (und dank der
vorhandenen Dokumentation ohne Vorkenntnisse nahezu unmöglich).
Da es keinen Compiler für übliche Hochsprachen gibt (und durch den
Befehlssatz auch weder sinnvoll noch gewünscht sind), gibt es auch keine
Alternativen dazu. Wahre Programmierer schreckt das zwar nicht ab (vgl.
8031), aber diese sind wieder nicht deine Zielgruppe.
Du hast zwei Fragen bisher noch nicht beantwortet:
Was ist deine Zielgruppe und warum glaubst du, sie mit deinem System
erreichen zu können?
Was ist die Besonderheit deines Systems (was kann es besonders gut),
also für welche Nische ist es besser geeignet als die Alternativen und
warum?
S. R. schrieb:> OR lässt sich durch XOR ersetzen, wenn man den alten Zustand vorher> erfragt, was nicht immer möglich ist und zusätzliche Befehle benötigt.
Auch dann, wenn man den alten Zustand kennt,
weil man ihn vorher selber erzeugt hat.
Im übrigen: Es geht hier nur um ein einziges NE.A, welches
man ggf. zusätzlich braucht, um eine OR-Operation zu erzeugen.
>> OR ist doch – genauso wie AND – kommutativ und assoziativ.>> Wo liegt da das Problem?>> Nur bei Operationen, wo A vorher negiert wird,
Sollte heissen: Das Problem besteht nur bei Operationen, ...
> Und wenn die Paritätsgenerierung und Gray-Code-Dekodierung> für dich so wichtig sind, warum hast du nicht einen Befehl> implementiert, der alle 8 Schritte auf einmal durchführt?
Das ist in der Tat eine Frage, die mich lange beschäftigt hat,
was da besser ist. Für den Einzelschritt-Befehl habe ich bisher,
wenn ich mich recht erinnere, nur an zwei Stellen eine Anwendung
in meiner Software gefunden. Letztlich gab den Ausschlag die
Überlegung, dass der Hardware-Aufwand für die Berechnung der 8
Teilparitäten deutlich größer wäre als für den Einzelschritt.
Die zweite Stelle, wo ich lange unschlüssig war, sind die
Befehle IKL und DKL. Hier ist im Gegensatz zu IXL und DXL
das Inkrementieren/Dekrementieren um 100 überflüssig, da
es mit AD. 01 bzw. AD. ff einen gleichwertigen Ersatz
gibt. Würde man nur um nn inkrementieren/dekrementieren,
hätte man als nutzlosen Grenzfall den Wert nn=00, also NOP,
wofür es bei maschineller Code-Generierung eher eine
Anwendung gäbe. Letztlich gab hier den Ausschlag die
Gleichbehandlung mit IXL/DXL, was die interne Hardware
ein wenig vereinfacht. Und auch der Programmierer muss
nur eine Variante im Kopf behalten.
Josef G. schrieb:> Ja. Und mir leuchtet auch nicht ein, warum man wegen eines> Sonderfalls eine zusätzliche Stelle reservieren soll. Aber vielleicht> schreibt ja mal jemand einen Assembler, der es anders macht.
"Stelle reservieren"? Mit anderen Worten, einen vernünftigen Parser
bekommst Du auch nicht hin? Naja kein Wunder bei den unterirdisch wirren
Code-Auszügen, die man hier zu sehen bekam. Das kann man auch nicht mehr
warten.
Josef G. schrieb:> Yalu X. schrieb:>> Darum, wie diese Werte dann im erzeugten Binärcode dargestellt>> werden, sollte sich der Programmierer nicht kümmern müssen.>> Tja, da gibt es einen grundsätzlichen Unterschied in den> Zielsetzungen. Der anwendungsorientierte Programmierer möchte> sich nicht darum kümmern müssen. Der verwendet aber ohnehin> lieber C als Assembler. Der Hobbyist mit Freude an Bits und> Bytes möchte gern alles selber kontrollieren.
Mit dieser Begründung hättest du auch die Sprungmarken in deinem
Assembler weglassen (und damit einiges an Entwicklungsaufwand einsparen)
können, denn der Hobbyist mit Freude an Bits und Bytes möchte die
relativen Sprungadressen ja schließlich selber ausrechnen ;-)
Zur Rechtfertigung der Implementierung von NOR statt OR
Weiter oben schon angesprochen, hier eine Zusammenstellung:
Bei den asymmetrischen logischen Funktionen sind Platzbedarf und
Dauer bei Operanden-Vertauschung gleich. Der Programmierer muss
also nicht darauf achten, welcher Operand als erster in A steht.
1
not A and Mem.X | A and not Mem.X =
2
| not A nor Mem.X
3
|
4
NE.A | NE.A
5
ANMX | NRMX
6
7
8
not A or Mem.X = | A or not Mem.X =
9
not (not A nor Mem.X) | not (not A and Mem.X)
10
|
11
NE.A | NE.A
12
NRMX | ANMX
13
NE.A | NE.A
Wenn man reverse Subtraktion implementiert und somit bei den
arithmetischen Operationen Symmetrie bezüglich Vertauschung
der Operanden erreicht, dann ist es konsequent, diese Sym-
metrie auch bei den logischen Operationen zu fordern.
Zu meiner Aussage, dass OR sich häufig durch XOR ersetzen lässt:
Sehr häufig geht einem OR nn ein AND nn voraus. Man muss
dann bei AND nur nn so wählen, dass die Bits, die man mit OR
setzen will, Null werden, und kann dann OR durch XOR ersetzen.
NOR nn ist nützlich zum Testen, ob mehrere Bits gesetzt sind.
Zu den Repeat-Befehlen mit Adresse-Inkrementieren/Dekrementieren
Beispiel Blockverschiebung:
1
S.RP
2
GTMX
3
STMY
4
IX0
5
R.IY
S.RP setzt die Schleifenstartadresse auf den GTMX-Befehl.
R.IY dekrementiert den Schleifenzähler, inkrementiert Y
und springt zu GTMX, falls Schleifenzähler nicht Null ist.
R.IY dauert nicht länger als einfaches Inkrementieren IY0.
Damit entfällt der Anreiz, zur Beschleunigung den Schleifen-
inhalt mehrmals hinzuschreiben, wie es ohne Existenz eines
R.IY -Befehls der Fall wäre:
Was ich nicht verstehe ist: warum dieser Assembler der kryptischte ist,
den ich je gesehen habe. Das macht doch keinen Spass.
Wenn ich diesen Code sehe
GTMX
STMY
IX0
IY0
GTMX
STMY
IX0
IY0
Habe ich keinen Eindruck, was da abgeht. Alternativ
print_b move.b #OUTCH,d7 prepare to display characters
cmp.b #0,d1
beq print_b_none print 'no more' if zero
clr.l d2
move.b d1,d2 copy beer count
divu #10,d2 and split into two digits
beq print_b_unit branch if no tens digit
move.b d2,d0
add.b #$30,d0 convert number to ASCII
trap #14 display tens digit
Kann man diesen Assmblercode lesen. Man erkennt, das was passiert.
Register, Konstanten und Befehle sind eindeutig.
Und das ist ein Beispiel aus den 80er Jahren.
Warum macht man im Jahre 2016 so ein unverständliches Zeug?
Ich habe vor 30 Jahren mit Assembler mein Geld verdient, kenne also
diverse CPUs und Vor/Nachteile der Befehlssätze.
Und ich würde jedem Anfänger lieber einen 68000 Assmbler vorsetzt. Da
kann er etwas lernen. Aber nicht diese wirre Bome-CPU.
Warum ist eigentlich der TO so resistent gegenüber fremden Argumenten.
Das hat ja fast missionarische Züge. Warum guckt er nicht über den
Tellerrand und erkennt, dass auch andere Ansätze durchaus Vorteile
haben.
Er sollte erst einmal aus der Geschichte (alte Assembler) lernen, bevor
er etwas neues versucht.
PittyJ schrieb:> Warum macht man im Jahre 2016 so ein unverständliches Zeug?
Beispiel: GTMX GET Memory X - Lade (X) nach A
Das hieße in deiner Notation vielleicht: move a,(X)
Was möchtest du lieber hundertmal schreiben müssen,
GTMX oder move a,(X) ?
Josef G. schrieb:> Beim 6502-Assembler gab es zB. diese Befehle:
Josef G. schrieb:> Was möchtest du lieber hundertmal schreiben müssen,> GTMX oder move a,(X) ?
lieber hundert mal
move a,(x)
oder
move a,$42
move (x),a
...
BTW, bei modernen Entwicklungstools schreibt man "m" und der Editor
ahnt, das man mit 70% Wahrscheinlichkeit "move\t" schreiben will und
schlägt das vor. Mit TAB quittiert man dann diesen Vorschlag und schon
hat man 5zu2 Tasten kompimiert.
Warum darf ein 6502 sich lustige Befehle erlauben?
Weil er schon Millionenfach verkauft wurde!
Josef G. schrieb:> Da hat sich auch niemand dran gestört.
In den 50ern und 60er war Kraut- und Rüben-Technik üblich. Die
Einstellung zur Lesbarkeit war wie deine: Experten verstehen es, der
Rest sollte nicht erst auf die Idee kommen, es lesen zu können. Ein
CDC6600 Beispiel hatte ich schon gebracht.
Auch IBM 360 ist noch recht kryptisch, mit A für ADD, und Axx für
Varianten davon. Weil man schon gewohnt war, jeden Mist ins Mnemonik
hinein zu packen, gibt es auch in der 64-Bit Variante Schönheiten wie
AGHIK für ein ganz gewöhnliches Add-Immediate (A=add, G=64bit, H=16bit,
I=immediate, K=?).
Aber Syntax und Mnemotechnik von Assembler haben sich im Laufe der
Jahrzehnte weiterentwickelt. Autos und Flugzeuge sehen heute auch anders
aus als vor 100 Jahren. Für Piloten war es damals selbstverständlich, im
Freien zu sitzen. Will man heute seltsamerweise nicht mehr.
Carl D. schrieb:> Warum darf ein 6502 sich lustige Befehle erlauben?> Weil er schon Millionenfach verkauft wurde!
Die lustigen Befehle waren zuerst da.
Der millionenfache Verkauf kam erst danach,
trotz oder wegen der lustigen Befehle.
Josef G. schrieb:> Beispiel: GTMX GET Memory X - Lade (X) nach A>> Das hieße in deiner Notation vielleicht: move a,(X)
Das ist eine Frage der Orthogonalität.
Die Operation ist immer die gleiche:
move
Und was wohin bewegt wird, wird durch die Operanden ausgedrückt.
Quelle und Ziel*. Und bei beidem kann durch die Schreibweise auch die
Adressierungsart unterschieden werden.
Dafür braucht man aber keine unterschiedlichen Operationen, denn es ist
immer move.
move a,(x)
Lade den Inhalt der Speicherstelle, auf die x zeigt, nach a
move a,(x+)
Lade den Inhalt der Speicherstelle, auf die x zeigt, nach a, und erhöhe
danach x
move a,b
Lade den Inhalt von b nach a
move a,#12
Lade den Wert 12 nach a
Das ist einfach, strukturiert und geradlinig. Man muss sich nicht zig
verschiedene Operationen für unterschiedliche Register merken, sondern
man muss nur wissen, was man tun will: Daten bewegen.
Und da bei einer vernünftigen Architektur jedes Register gleichwertig
ist, kann jedes Register als Operand verwendet werden, sowohl als Quelle
als auch als Ziel.
Bei einer 8-Bit-Architektur ist das natürlich nicht durchgängig möglich,
da braucht es 8- und 16-Bit-Register, und entsprechende
Transfermöglichkeiten.
Bei 16- und 32-Bit-Architekturen möchte man auch kleinere Zugriffe als
die volle Registerbreite durchführen, dafür gibt es dann
move.b und move.w
*) es gibt Systeme, bei denen beides in vertauschter Reihenfolge
angegeben wird (bewege QUELLE nach ZIEL), aber das Grundkonzept bleibt
erhalten
Rufus Τ. F. schrieb:> Die Operation ist immer die gleiche:>> move
Das ist Geschmackssache, ob man einen Registerzugriff
und einen Speicherzugriff, mit unterschiedlicher Dauer,
als gleiche Operation empfindet oder nicht.
A. K. schrieb:> In den 50ern und 60er war Kraut- und Rüben-Technik üblich. Die> Einstellung zur Lesbarkeit war wie deine: Experten verstehen es, der> Rest sollte nicht erst auf die Idee kommen, es lesen zu können. Ein> CDP6000 Beispiel hatte ich schon gebracht.
Im Gegensatz zur Bome-(Un)Logik finde ich den 6502 z.B. aber gar nicht
so "Kraut und Rüben", sondern relativ gut strukturiert und leicht
erlernbar.
TAX u.ä. ist doch sehr gut zu merken. Move-Befehle heißen eindeutig LDx
für Daten Speicher->Register und STx für Register -> Speicher, JMP ist
ein Sprung und JSR ein Spung in eine Subroutine (oder "Jump, save Return
Address") usw...
Am Fehlen eines Operanden kann man auch leicht die Befehlslänge im
Speicher ablesen, nämlich dann nur 1 Byte. Die Mnemonics haben durchweg
drei Buchstaben und sind insgesamt recht eingängig. Ich sehe da gar
keine Ähnlichkeit mit der Bome-Philosophie.
Wenn in den 60ern (oder eher 70ern, da ist er designed worden)
tatsächlich Kraut und Rüben üblich war, dann war der 6502 seiner Zeit
wohl ein Stück voraus.
Thomas E. schrieb:> Im Gegensatz zur Bome-(Un)Logik finde ich den 6502 z.B. aber gar nicht> so "Kraut und Rüben", sondern relativ gut strukturiert und leicht> erlernbar.
Ist ja auch schon aus den 70ern und ich schrieb von den 50/60ern. ;-)
> TAX u.ä. ist doch sehr gut zu merken.
Klar, war auch bei 6800 so. Da kommt das ja her. Der hatte wenig
Register und nicht alle Transfers, die man gerne gehabt hätte. Beim 6809
waren es dann ein paar mehr Register und es mutierte zu TFR x,y. Hätte
man auch gleich machen können.
Ein Echo der frühen Jahre findet man freilich in den 8-Bit PICs. Deren
Mnemotechnik und Assembler-Syntax entstand im gleichen Zeitraum wie
6800, atmet aber streckenweise noch den Geist der Vorzeit.
Thomas E. schrieb:> Im Gegensatz zur Bome-(Un)Logik finde ich den 6502 z.B.> aber gar nicht so "Kraut und Rüben", sondern relativ gut> strukturiert und leicht erlernbar.> Move-Befehle heißen eindeutig LDx für> Daten Speicher->Register und STx für Register -> Speicher,
Gilt entsprechend auch bei mir.
> Am Fehlen eines Operanden kann man auch leicht die> Befehlslänge im Speicher ablesen, nämlich dann nur 1 Byte.
Gilt auch bei mir.
> Die Mnemonics haben durchweg drei Buchstaben
Finde ich jetzt nicht so gut, weil man bei unterschiedlicher Länge
beim schnellen Drüberschauen leichter bestimmte Befehle findet.
> und sind insgesamt recht eingängig.
Wenn man sich an sie gewöhnt hat. Und das gilt auch bei mir.
> Ich sehe da gar keine Ähnlichkeit mit der Bome-Philosophie.
Ich sehe da eine große Ähnlichkeit.
Thread beobachten
Seitenaufteilung abschalten