mikrocontroller.net

Forum: Offtopic Befehlssatz der bo8-CPU - was ist gut, was ist schlecht


Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-7 lesenswert
nicht lesenswert
Angeregt durch diesen aktuellen Thread
Beitrag "AVR: Werden gleiche Opcodes unterschieden?"
möchte ich den Befehlssatz der bo8-CPU zur Diskussion stellen.

Zu finden ist er hier:
http://www.mikrocontroller.net/articles/8bit-CPU:_bo8

Zwar gibt es bereits einen langen Thread zu dem Projekt
im Forum Projekte und Code, dort ist aber bisher kaum
jemand sachlich auf den Befehlssatz eingegangen.

: Verschoben durch Moderator
Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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;)

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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)

Autor: Codix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Reentranz

Meine CPU hat keine Interrupts.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
-Reentranz hat erstmal nichts mit Interrupts zu.
-Eine CPU ohne Interrupts scheint mir unbrauchbar, zumindest stark 
ausgebremst
-wie übergibst du Parameter an Funktionen?

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@ 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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> -wie übergibst du Parameter an Funktionen?

Die CPU hat 3 gleichberechtigte universell einsetzbare
Adressregister. Eines davon zeigt auf die Parameter.

Autor: TriHexagon (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Josef G. schrieb:
> Rufus Τ. F. schrieb:
>> Reentranz
>
> Meine CPU hat keine Interrupts.

Darf man fragen warum? Eine CPU ohne Interrupts macht wenig Sinn.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: chris_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

How do we return from the subroutine which BL invoked?

MOV pc, r14

or

BX r14 (on ARMv4T or later)


Autor: chris_ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@ 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?

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Sinus Tangentus (micha_micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul eye (souleye)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Tr (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: ASM Superprofi (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ASM Superprofi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Friedrich (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Josef G. schrieb:
> jedermann verstehbarer
Das denkst Du.
Irgendwie sind alle, die sich Deinen Code und Deine 'Dokumentation' 
angeschaut haben, anderer Meinung...

Autor: Falk Brunner (falk)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
@  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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Bei der DO-Loop der dsPIC30/33 ebenfalls.

Kann man damit auch while-Schleifen realisieren?
Bei mir geht das.

Autor: Tr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Josef G. schrieb:
> Bei mir geht das.

Kaffee kochen geht auch?

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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:
        lsetup (l_begin, l_end) lc0 = p2;
l_begin:
        r0 = w [p1++];
        r0 >>= 2;
        b[p0++] = r0;
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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?

Autor: MaLin (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: PittyJ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu der Stack Diskussion:

Ein Turingmaschine hat auch keinen Stack.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Allerdings ist diese asynchrone Technik eine der vielen interessanten 
und hoffnungsvollen Entwicklungen, die wieder im Sande verliefen.

Autor: Strubi (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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 :-)

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und schon wieder hat der Josef willige Opfer gefunden, die gern und 
ausdauernd mit einer kommunikations- und lernunfähigen Person reden . . 
.

Beitrag "Re: wer kann sich noch an den hex-zeichensatz erinnern?"

Beitrag "Re: Ein Vorschlag zur Intervall-Arithmetik"

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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? ;-)

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 ;-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Josef, du bist also absolut auf dem richtigen Weg!

Der CDC Assembler liest sich aus heutiger Sicht ähnlich intuitiv wie 
Josefs Code: https://en.wikipedia.org/wiki/COMPASS/Sample_Code

: Bearbeitet durch User
Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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..

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> wegen der redundanten ALU-Befehle

??

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Werner WeakEnd (Gast)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
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.
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.
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...
56- GTA
Name: Grand Theft Auto
Funktion:
Hommage an die erfolgreichste Computerspiel-Serie.
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.
a6- AD.S
a7- SD.s
AD könnte Addition bedeuten, aber SD? - Vielleicht mit sächsischem 
Dialekt (SubDragdsion).
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.
02- SS.X
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."

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Strubi schrieb:
>> wegen der redundanten ALU-Befehle
>
> ??

Jetzt nochmal ganz deutlich - aber ich glaube, das haben bereits einige 
versucht:
XR. nn         A wird   A xor nn
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:
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):
    beq #0, d0, label
    call (d0)
label:
    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?

Autor: Falk Brunner (falk)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
ASM, BO8, LMAA

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
O.VZ  Vorwärtssprung  falls       V=0
O.VS  Vorwärtssprung  falls nicht V=0
O.UZ  Vorwärtssprung  falls       U=0
O.US  Vorwärtssprung  falls nicht U=0
O.AZ  Vorwärtssprung  falls       A=0
O.AS  Vorwärtssprung  falls nicht A=0
O.KZ  Vorwärtssprung  falls       K=0
O.KS  Vorwärtssprung  falls nicht K=0

B.VZ  Rückwärtssprung falls       V=0
B.VS  Rückwärtssprung falls nicht V=0
B.UZ  Rückwärtssprung falls       U=0
B.US  Rückwärtssprung falls nicht U=0
B.AZ  Rückwärtssprung falls       A=0
B.AS  Rückwärtssprung falls nicht A=0
B.KZ  Rückwärtssprung falls       K=0
B.KS  Rückwärtssprung falls nicht K=0
Hinzu kommen
O.WY  Vorwärtssprung  always
B.WY  Rückwärtssprung always
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
GTA nn   lädt K mit 00nn
Analog dazu gibt es GTR, das steht für get relative
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
AD.S   addiere S zu K
SD.S   subtrahiere S von K
LD.S   reverse Subtraktion
das L steht für lessen
AV.S   addiere S zu K       mit Carry(V)
SV.S   subtrahiere S von K  mit Carry(V)
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.

Autor: Автомат Калашникова (dermeckrige)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pat A Mat (patamat)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 VHDL nicht 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!

Autor: S. R. (svenska)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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?

Autor: MWS (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Strubi schrieb:
> XR. nn         A wird   A xor nn
> XRM% | XR.B    A wird   A xor op
> 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.
XR. nn           A wird   A xor nn
XR.B             A wird   A xor B
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:
> 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:
TAX   Transferiere  A nach X
TAY   Transferiere  A nach Y

INX   Incrementiere X
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):
>     beq #0, d0, label
>     call (d0)
> label:
>     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.

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TriHexagon (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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 zuor­dbar 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!

Autor: TriHexagon (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Pat A Mat (patamat)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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"

: Bearbeitet durch User
Autor: Carl Drexler (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
;-)

Autor: Pat A Mat (patamat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk B. schrieb:

> Dafür gibt es eine viel einfachere Diagnose.
>
> Beitrag "Re: 8bit-Computing mit FPGA"

Stimmt natürlich!

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Pat A Mat (patamat)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: 2⁵ (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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_progr...

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!

Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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).

: Bearbeitet durch User
Autor: bko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beispiel einer sehr brauchbaren Beschreibung einer "kruden" CPU:
http://www.self8051.de/befehlsreferenz_der_8051er_...

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!

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 :-)

Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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. ;-)

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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! ;-)

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was ist an Steckkarten so besonders? Ausser dass man heute dazu 
übergeht, Baukastenelemente seriell oder per Funk anzubinden.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Pat A Mat (patamat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nase (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 :-)

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pat A Mat (patamat)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: V0A (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: V0A (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hast Du nicht eben noch geschrieben, daß Du die Angriffe auf Josef 
daneben fändest?

Autor: V0A (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pat A Mat (patamat)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Josef G. schrieb:
> Ist nur 1 Kommando, einzutippen in einem Konsolenfenster.

Mag sein, aber was machen Windows-User? Extra nur deswegen Linux oder 
Cygwin installieren? Wohl eher nicht!


V0A schrieb:
> Nebenbei finde ich die persönlichen Angriffe auf den TO ziemlich
> daneben.

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.

Autor: Pat A Mat (patamat)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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:

    ...
    }} 
        if(OP>0x59) { P++; n= (OP>>1) & 3; if(OP & 1) S[n]=S[n]-b-1;
        else S[n]=S[n]+b+1; continue; }
   
    if(OP) { P++; switch(OP) {
    ...

:D

Autor: V0A (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: V0A (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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??? :-)))

Autor: Pat A Mat (patamat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! 
;-)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Yalu X. (yalu) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Nop (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yalu X. zitierte im Beitrag #4731950:
     }}
         if(OP>0x59) { P++; n= (OP>>1) & 3; if(OP & 1) S[n]=S[n]-b-1;
         else S[n]=S[n]+b+1; continue; }
 
     if(OP) { P++; switch(OP) {

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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Was mache ich falsch?

Vielleicht liegt's daran:

Josef G. schrieb:
> Bitte beachten:
> der erste Operand OPA ist stets mit Vorzeichen.

Autor: Jiri (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jiri schrieb:
> Bei mir klappt das nicht...

Doch, die Folge 61 dient zur Eingabe der Ziffer 1.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, das noch:

Bei MUL und DIV ist Multiplikator bzw. Divisor = OPB+1.

Autor: VOA (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...:-)

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
VOA schrieb:
> Keine Peilung, alles wie immer, Linux tut nicht...:-)

sudo apt-get install linux-headers

Autor: VOA (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...;-)

Autor: Guido B. (guido-b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, das System ist gut zugemüllt. ;-)

Mach erst mal eine sudo apt-get autoremove.

Dauert aber sicher eine Weile.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 ;-)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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:

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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Josef G. schrieb:
> Beim
> Z80-Befehl djnz dürfte es schwer fallen, eine sinnvolle
> Anwendung für positive Distanz zu finden.

Hö?


eins:  DJNZ r1, zwei
       Krempel, der bei r1 = 1 passieren soll
zwei:  DJNZ r1, drei
       Krempel, der bei r1 = 2 passieren soll
drei:  DJNZ r1, vier
       Krempel, der bei r1 = 3 passieren soll
vier:  DJNZ r1, fuenf
       Krempel, der bei r1 = 4 passieren soll
fuenf: DJNZ r1, ende
       Krempel, der bei r1 = 5 passieren soll
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, was gelernt zum djnz ...

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
@ 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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: TriHexagon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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/978389721567...

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TriHexagon schrieb:
> Ein Bild die den Aufbau deiner Architektur zeigt,
> um überhaupt mal sowas wie einen Überblick zu bieten.

Reicht das nicht?
P  Q R S  X Y Z    K     V            Bezeichnung:  A7 = U
|  | | |  | | |    |A                               AB = K
|  | | |  | | |    |B

P Programmzähler      Q Rückkehradresse
X Adressregister      R Schleifenstartadresse
Y Adressregister      S Schleifenzähler
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.

Autor: Le X. (lex_91)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Immer wenn er so ne Antwort bringt drängt sich mir ganz stark der 
Gedanke auf, dass es sich dabei wirklich nur um Satire handeln kann.

Autor: Eric B. (beric)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?
>
> P  Q R S  X Y Z    K     V            Bezeichnung:  A7 = U
> |  | | |  | | |    |A                               AB = K
> |  | | |  | | |    |B
> 
> P Programmzähler      Q Rückkehradresse
> X Adressregister      R Schleifenstartadresse
> Y Adressregister      S Schleifenzähler
> Z Adressregister      A Akku   B Erweiterung   V Carry
> 

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?

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: MaLin (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
MaLin schrieb:
> Aber lass alle anderen damit in Ruhe.

Niemand wird gezwungen, den Thread anzuklicken ...

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Eric B. (beric)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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. 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.

Autor: Route 66 (route_66)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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):

Mnemonic (englisch für „Gedächtnisstütze“ vom griechischen mnēmoniká
„Gedächtnis“, teilweise auch deutsch Mnemonik) steht allgemein für eine
Merkhilfe, im Speziellen jedoch für:

  - ein für den Menschen lesbares Kürzel für einen Befehl einer
    Assemblersprache
  - […]

Folgende Mnemonics können für mich definitiv nicht als Gedächtnisstütze
dienen, da ich mir unter den Buschtabenkombinationen überhaupt nichts
vorstellen kann:

GT. nn         A wird   nn

  Das ist ein Ladebefehl, der sonst MOV, LDA, LDI o.ä heißt. Wraum GT?

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

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?

SL.$          $ LowByte erhält A ,  $ HighByte wird 0

  Das kopiert ein 8-Bit- in ein 16-Bit-Register. Aber wieso SL?

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

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.

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.

GT.Q        K erhält Q
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?

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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du nicht überzeugen kannst, dann verwirre wenigstens mit 
Schwachsinn.

Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: MWS (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
>
> GT. nn         A wird   nn
> 
>
>   Das ist ein Ladebefehl, der sonst MOV, LDA, LDI o.ä heißt. Wraum GT?

GT: GET (erhalte), passt optisch gut zu ST

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

L: LESSEN  vermindere zweiten Operanden um A  (Ergebnis in A)

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

R: REPEAT  CN: COUNTING

>
> SL.$          $ LowByte erhält A ,  $ HighByte wird 0
> 
>
>   Das kopiert ein 8-Bit- in ein 16-Bit-Register. Aber wieso SL?

STORE A in LOW-Byte von $

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

CP: COMPARE

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

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

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.

>
> GT.Q        K erhält Q
> 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.

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:
GTMX
IXE
GTMX
AD.X
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)].

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

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"

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Yalu X. schrieb:
>>
>> GT. nn         A wird   nn
>> 
>>
>>   Das ist ein Ladebefehl, der sonst MOV, LDA, LDI o.ä heißt. Wraum GT?
>
> GT: GET (erhalte), passt optisch gut zu ST

Englisch.

>
>>
>> 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)?
>
> L: LESSEN  vermindere zweiten Operanden um A  (Ergebnis in A)

Deutsch.

>
>>
>> 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?
>
> R: REPEAT  CN: /COUNTING/

Repeating oder Count? Warum Repeat und Counting?

>
>>
>> SL.$          $ LowByte erhält A ,  $ HighByte wird 0
>> 
>>
>>   Das kopiert ein 8-Bit- in ein 16-Bit-Register. Aber wieso SL?
>
> STORE A in LOW-Byte von $
>
>>
>> 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"? ;-)
>
> CP: /COMPARE/

Warum Compare? Inconsistent. Müsste XR heißen. Etwas anderes darf dann 
eben nicht XR sondern muss wieder anders heißen.

>
>>
>> GT.Q        K erhält Q
>> NON 00      K erhält R      2    Zyklen
>> 

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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Was ist der Unterschied zwischen "erhält" und "wird"?

In meiner CPU-doku: kein Unterschied.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Was ist mit meinen anderen Punkten?

Ist die Frage wirklich ernst gemeint?

Autor: Pat A Mat (patamat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Ja.

Das Mnemonic NON sollte man vielleicht ändern.
Zu deinen anderen Kritikpunkten möchte nichts sagen.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Josef G. schrieb:
> Das Mnemonic NON sollte man vielleicht ändern.

Nicht doch, das ist das einzig verständliche. Auf französisch.

Autor: Strubi (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Josef G. schrieb:
> Zu deinen anderen Kritikpunkten möchte nichts sagen.

Gut. Es kann an dieser Stelle endlich abgebrochen werden.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;-)

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.
not A  and  Mem.X            |      A  and  not Mem.X  =
                             |      not A  nor  Mem.X
                             |
    NE.A                     |          NE.A
    ANMX                     |          NRMX


not A  or  Mem.X   =         |      A  or  not Mem.X   =
not (not A  nor  Mem.X)      |      not (not A  and  Mem.X)
                             |
    NE.A                     |          NE.A
    NRMX                     |          ANMX
    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.

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu den Repeat-Befehlen mit Adresse-Inkrementieren/Dekrementieren

Beispiel Blockverschiebung:
S.RP
GTMX
STMY
IX0
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:
GTMX
STMY
IX0
IY0
GTMX
STMY
IX0
IY0
Dekrementiere Zähler und springe zum ersten GTMX

Autor: PittyJ (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  PittyJ (Gast)

>Warum ist eigentlich der TO so resistent gegenüber fremden Argumenten.

Darum.

Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
> TAX   Transferiere  A nach X
> TAY   Transferiere  A nach Y
> 
> INX   Incrementiere X
> INY   Incrementiere Y
> Da hat sich auch niemand dran gestört.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er ist nicht der erste mit "GET". RCAs 1802 hat ebenfalls Get und Put im 
Angebot (Register-Transfer). Allerdings auch Load und Store (Speicher).

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Erich (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Man könnte sich --um bei 30 Jahre altem Stand zu bleiben--
mal ein Beispiel an der Zilog-Mnemonik des Z80 nehmen.

http://www.z80.info/z80syntx.htm

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Thomas Elger (picalic)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Michael U. (amiga)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

Josef G. schrieb:
> Das ist Geschmackssache, ob man einen Registerzugriff
> und einen Speicherzugriff, mit unterschiedlicher Dauer,
> als gleiche Operation empfindet oder nicht.

mich interessiert, daß Wert x aus Quelle y in Register z landet.
Mich interessiert nicht, wielange das jeweils dauert.

Ich habe auf dem C64 (6510) Takte gezählt, um die VIC-Register passend 
umzuschalten, damit die Ränder aus sind.
Ich habe manchmal in einer ISR Takte gezählt, um sicher zu sein, daß mir 
auch im ungünstigsten Fall noch genug Rechenzeit für den Rest bleibt.

Wann sonst sollte ich wissen wollen oder müssen, wielange eine 
Befehlsausführung braucht?

PS: ich habe mich mal durch den Thread
Beitrag "8bit-Computing mit FPGA"
gewühlt.
Ich habe auch hier fast alles mitgelesen.

Du bist vermutlich wirklich eine etwas mißglückte Inkarnation von ELIZA.
Weizenbaum hätte an den Threads vermutlich seine Freude oder wäre noch 
entsetzter als damals.

Gruß aus Berlin
Michael

: Bearbeitet durch User
Autor: Gu. F. (mitleser)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wo nimmst du nur die Engelsgedult her?

Autor: Gerald (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Josef G. schrieb:
> Befehlssatz der bo8-CPU - was ist gut, was ist schlecht

Fazit:
Also die Doku ist schlecht, die Mnemonics zumindest extrem ungewohnt.
Schlecht im Sinne von: für 99,995% der Nutzer nicht ausreichend.

Da nun verschiedene Leute die eine oder andere Diagnose zur Ignoranz der 
Argumente geliefert haben, meine Frage an die Psychologen:

Wie geht man mit Josef um?

1. Mehr Aufmerksamkeit verschaffen, indem man tatsächlich Programme für 
das Ding schreibt? Oder

2. wie mit einen Troll: ignorieren? oder

3. ...

Gerald

Autor: Falk Brunner (falk)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
@  Gerald (Gast)

>Wie geht man mit Josef um?

DAS ist mal eine sinnvolle Frage.

>1. Mehr Aufmerksamkeit verschaffen, indem man tatsächlich Programme für
>das Ding schreibt? Oder

Bis du Masochist? Oder leidest du am Samariter-Komplex?

>2. wie mit einen Troll: ignorieren? oder

Sinnvoll und pragmatisch.

>3. ...

Man kann es auch als Belustigung betrachten. Aber auf KEINEN Fall ernst 
nehmen und mit der Illusion diskutieren, daß Josef auch nur ANSATZWEISE 
was versteht oder gar einsieht, daß er in seinem Projekt mehrere Fehler 
bzw. totalen Mist drin hat.

Autor: Axel Schwenke (a-za-z0-9)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> 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.

Aus Sicht auf das logische Modell einer CPU schon. Es geht darum, Daten 
von A nach B zu bekommen. Ob A und B nun Register sind oder Speicher 
oder IO-Ports, das ist aus logischer Sicht unerheblich.

Wenn ich etwas auszusetzen hätte, dann am Wort "move". Denn umgangs- 
sprachlich hat es die Bedeutung, etwas zu verschieben. Nach dem 
Verschieben befindet es sich im Ziel und nicht mehr in der Quelle. Aus 
sprachlicher Sicht ist die Operation eher "copy" - es wird eine Kopie 
der Daten am Ziel angelegt. Auch "transport" würde passen. Oder eben 
"load" - was für mich außerdem den Charme hat, daß ich damit 
aufgewachsen bin (Z80).

Details über die Art der Operanden (Register, Immediate oder Speicher 
auf die eine oder andere Art adressiert) schreibt man sinnvollerweise an 
den Operanden, so wie Rufus das oben gezeigt hat. Und wenn man das jetzt 
auch für die Operanden anderer Befehlsgruppen so macht (z.B. ALU- 
Operationen) dann kriegt man am Ende einen hübsch orthogonalen und 
leicht lernbaren Befehlssatz.

Autor: Martin S. (strubi)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Moin,

jetz hab ich den Thread doch wieder angeklickt, da Geralds Frage doch 
eine recht gute ist.

Die Frage muss sich der Forenbetreiber schlussendlich stellen.
Mein Fazit ist, dass die Qualität der hiesigen Beiträge in den letzten 
Jahren massiv in den Keller gegangen ist. Das hat u.a. mit vielen Usern 
zu tun, die man als "Störer" betrachten könnte. Diese halten zwar die 
Netiquette oberflächlich ein, aber stören mit Beiträgen, die dem 
allgemeinen Konsens entgegenlaufen oder völlig bezugsfrei dazu sind. 
Leider kann man da kaum noch Argumente hinzufügen, sondern: es nervt. 
Wie irgendwann eben ELIZA:

User: "Schwarz ist nicht weiss"
Eliza: Warum ist schwarz nicht weiss?

Wir hatten es mal in einer Physik-Diskussionsgruppe mit einem zu tun, 
der die Drehimpulserhaltung widerlegt haben wollte, und davon mehr 
überzeugt zu sein schien, als Einstein mit seiner Speziellen RT.
Das Ende vom Lied war, dass die NNTP-Admins (ach, ist das lange her) den 
Nutzer schliesslich sperrten, um weitere üble Flamewars zu verhindern.
Das erschien aus mehreren Gründen legitim:
- Manchmal muss man Nutzer vor sich selbst (und Mobbing durch andere) 
schützen
- Forenbetreiber sollten auch einer beitragenden Community (die einen 
gewissen "Standard" erwartet) gegenüber eine gewisse Sorgfaltspflicht 
walten lassen

Die einfachste Variante für mich persönlich ist natürlich, mich einfach 
auszuklinken und von weiterem Knowhow-Austausch komplett abzusehen. 
Damit überlässt man schlussendlich das Feld den Thread-Messies. Ob das 
so soll....darüber kann man sich streiten :-)

Grüsse,

- Strubi

Autor: Автомат Калашникова (dermeckrige)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerald schrieb:
> 3. ...
>
> Gerald

Man könnte im ersten Schritt den ganzen Thread ins Offtopic verfrachten. 
Das eigentliche Thema ist hinreichend durchgekaut und das PingPong-Spiel 
zwischen bome und dem Rest hat mit dem Thema nicht mehr viel gemein.

: Wiederhergestellt durch Moderator
Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Was möchtest du lieber hundertmal schreiben müssen,
> GTMX  oder  move a,(X) ?

Zweiteres. Das ist lesbar. Ersteres hat etwa so viel Aussage wie 7§k@%.
Mit copy-paste auch genau so viel Aufwand.

Und wenn ich wirklich unbedingt solchen Spaghetticode produzieren 
müsste, dann würde ich vermutlich ein Makro machen. Und das würde dann 
ehr 'max' heißen.


Gruß

Jobst

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Josef G. schrieb:
> Ich sehe da eine große Ähnlichkeit.

Man muss eb begriffen haben, um unterscheiden zu können.


Gruß

Jobst

Autor: Gerald (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Falk B. schrieb:
> Oder leidest du am Samariter-Komplex?
Machen das nicht alle, die hier (sinnvoll) auf eine Frage antworten?

> Man kann es auch als Belustigung betrachten.
Das hilft im Leben auch an anderen Stellen öfter mal weiter. BTDT. :-)


Martin S. schrieb:
> Mein Fazit ist, dass die Qualität der hiesigen Beiträge in den letzten
> Jahren massiv in den Keller gegangen ist. Das hat u.a. mit vielen Usern
> zu tun, die man als "Störer" betrachten könnte. Diese halten zwar die
> Netiquette oberflächlich ein, aber stören mit Beiträgen, die dem
> allgemeinen Konsens entgegenlaufen oder völlig bezugsfrei dazu sind.
Nunja, das 'Problem' gab es ja schonmal:
https://de.wikipedia.org/wiki/Eternal_September

Je einfacher der Zugang ist, und je mehr Leute dabei sind, um so mehr 
hat das (gefühlt) negative Auswirkungen auf's Niveau.
Ich denke aber, daß nur ein sehr geringer Teil bewusst provozieren will.
Der große Anteil fragt und antwortet 'so gut' wie er eben kann.
Insofern ist Deine Beobachtung zur Qualität in meinen Augen ein ganz 
normaler Vorgang. Außerdem kommt ja noch hinzu, das das eigene Wissen 
stetig wächst (wenn man was dafür tut). Als Studi habe ich mich immer 
über die geforderten xx Jahre Berufserfahrung in Stellenanzeigen lustig 
gemacht. So langsam bekomme ich inzwischen eine Ahnung von der Bedeutung 
der Erfahrung...

Автомат К. schrieb:
> Man könnte im ersten Schritt den ganzen Thread ins Offtopic verfrachten.
Das wäre tatsächlich eine Maßnahme.
Gibt es hier nicht auch ein Bewertungssystem, für die angemeldeten 
Teilnehmer?
Wo steht denn der Thread momentan?
Gab es da nicht auch mal ein Usenet-Law, von wegen je länger der 
Beitrag, desto mehr Off-Topic?

Andererseits gibt es ja auch immer noch Beiträge mit 
Verbesserungsvorschlägen zu den Mnemnonics.
Für diese Beiträge gilt (leider) Falks Aussage:
> Aber auf KEINEN Fall ernst
> nehmen und mit der Illusion diskutieren, daß Josef auch nur ANSATZWEISE
> was versteht oder gar einsieht, daß er in seinem Projekt mehrere Fehler
> bzw. totalen Mist drin hat.

Gerald

Autor: MWS (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Josef G. schrieb:
> Gilt entsprechend auch bei mir.

> Gilt auch bei mir.

> Wenn man sich an sie gewöhnt hat. Und das gilt auch bei mir.

> Ich sehe da eine große Ähnlichkeit.

Dass Du diesen Thread eröffnet hast und speziell die Wahl der Topic "was 
ist gut, was ist schlecht" zeugt von Heuchelei. Wenn man den Thread 
beobachtet, gibt's viele User die kritisieren und vorschlagen und einen 
User "Bome", der sein schwachsinniges Softwarekonstrukt verteidigt.

Da ist nichts zu erkennen von einem Verstehen, von Einsicht und vom 
Willen die Argumente und Kritik aufzugreifen und zu verarbeiten. Es 
findet nur eine laufende Abwehr jeglicher Ratschläge statt.

Und genau da ist die Ursache für den von Dir produzierten Murks: Du bist 
geistig versteinert und gefangen in Deinem kleinen Gefängnis aus 
Einbildung, Sturheit und verirrten Annahmen.

Sicher darf man an ein Ziel glauben und dies nachdrücklich verfolgen, 
dies auch gegen Widerstände. Aber man sollte dabei lernen und 
verbessern, immer wieder, eben das was Evolution ausmacht. Unsinniger 
Stolz und Borniertheit hat in der Evolution auch nichts zu suchen.

Das ist das, was Du nicht kannst, Du bist nicht bereit zu lernen und 
Ratschläge anzunehen. Und deswegen ist das Ding hier so eine Krücke 
trotz der enormen Arbeitsleistung, die Du reingesteckt hast, das wird 
auch nichts mehr. Vom eigenen Anspruch, Kleincomputer für jedermann, 
bist Du doch soweit entfernt, wie es nur irgend möglich ist.

Und so ist alles, was Du erreichst oder aus diesem Thread erhältst, ein 
wenig Aufmerksamkeit. Dann solltest Du im nächsten Thread auch den Titel 
so wählen, schreib' dann einfach: "Bome braucht Aufmerksamkeit, bitte 
keine Ratschläge".

So ein Titel wäre dann wenigstens ehrlich und nicht so geheuchelt, wie 
dieser hier.

Autor: 2⁵ (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Da die Standpunkte ausgetauscht, die Meinungen bekannt und alles 
westliche gesagt wurde (nur noch nicht von jedem), wäre es IMHO 
angebracht, diesen Thread zu schließen.
@Mods: Wäre dies möglich?

Autor: Lars R. (lrs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:

> Nutzer schliesslich sperrten, um weitere üble Flamewars zu verhindern.
> Das erschien aus mehreren Gründen legitim:
> - Manchmal muss man Nutzer vor sich selbst (und Mobbing durch andere)
> schützen
> - Forenbetreiber sollten auch einer beitragenden Community (die einen
> gewissen "Standard" erwartet) gegenüber eine gewisse Sorgfaltspflicht
> walten lassen

In wie vielen Threads schreibt Josef G.?
Wie viele neue Threads macht er pro Woche auf?
In wie vielen Threads schiebt er bis zum Umfallen Off-topic und 
persönliche Diffamierung dazu und stört Threads immer wieder?
Die waren Neurotiker sind ja wohl mehr als offensichtlich andere!


> Die einfachste Variante für mich persönlich ist natürlich, mich einfach
> auszuklinken und von weiterem Knowhow-Austausch komplett abzusehen.
> Damit überlässt man schlussendlich das Feld den Thread-Messies. Ob das
> so soll....darüber kann man sich streiten :-)

Deine Ansichten sind wertgeschätzt. Aber es ist nun wirklich kein großer 
Verlust, wenn Du in diesen 2 Threads nichts mehr schreibst.

> jetz hab ich den Thread doch wieder angeklickt, da Geralds Frage doch
> eine recht gute ist.

Eben. Scheinbar gar nicht so einfach, diesen einen Thread von Hunderten 
einfach NICHT anzuklicken und durchzulesen, nur um sich dann (wieder) 
darüber aufzuregen.

Also: Weils die Neurotiker nicht schaffen, den Thread NICHT anzuklicken, 
soll er geschlossen werden? Und wenn nicht, dann wird der Thread einfach 
so lang weiter zugemüllt: Auf jeden Beitrag von Josef G. 5x 
BS-Antworten, die dem Informationsaustausch (noch) weniger dienlich sind 
als Josefs Uneinsichtigkeit. Solang, bis die Mods den Threads endlich 
dicht machen! Tolle Demokratie.

Grüße
Lars

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Auf jeden Beitrag von Josef G. 5x
> BS-Antworten, die dem Informationsaustausch (noch) weniger dienlich sind
> als Josefs Uneinsichtigkeit. Solang, bis die Mods den Threads endlich
> dicht machen! Tolle Demokratie.

Du hast ja (zum Großteil) Recht, aber was bringt der Thread noch Neues, 
außer off-topic Gelaber? Mein Wunsch nach Schließung war eher ein 
pragmatischer Ansatz. Klar, ich könnte auch einfach den Thread (oder 
gleich das ganze Forum) ignorieren...

Autor: MWS (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lars R. schrieb:
> Auf jeden Beitrag von Josef G. 5x BS-Antworten,

Meinst Du solch' eine Antwort eines Englisch-Legasthenikers?

Lars R. schrieb:
>> GT: GET (erhalte), passt optisch gut zu ST
>
> Englisch.
>
...
>> L: LESSEN  vermindere zweiten Operanden um A  (Ergebnis in A)
>
> Deutsch

Da hätte ich an Stelle des TE auch nicht mehr gewusst, was darauf zu 
antworten wäre.

> Also: Weils die Neurotiker nicht schaffen

Du solltest versuchen, die Bedeutung von Dir verwendeter Worte wie 
"Neurotiker" zu verstehen, dann würdest Du evtl. weniger abwertend über 
andere Threadteilnehmer schreiben. Andererseits, es könnte auch 
Selbstreflektion sein. ;D

> Tolle Demokratie.

Ein Forum ist keine Demokratie.

Autor: Lars R. (lrs)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
MWS schrieb:
> Lars R. schrieb:
>> Auf jeden Beitrag von Josef G. 5x BS-Antworten,
>
> Meinst Du solch' eine Antwort eines Englisch-Legasthenikers?

Für Korrektur bin ich dankbar. Hier ist mir unklar, was gemeint ist. 
"Englisch" wird im Deutschen mit "sch" geschrieben.

> Lars R. schrieb:
>>> GT: GET (erhalte), passt optisch gut zu ST
>>
>> Englisch.
>>
> ...
>>> L: LESSEN  vermindere zweiten Operanden um A  (Ergebnis in A)
>>
>> Deutsch
>
> Da hätte ich an Stelle des TE auch nicht mehr gewusst, was darauf zu
> antworten wäre.

Mein Hinweis war für Josefs Antwort auf eine bestimmte Frage. Vielleicht 
hat er es verstanden. Erklärung hatte ich explizit angeboten. Danach 
hast du dann nicht gefragt und jetzt auch nicht. Interessiert Dich gar 
nicht.


Edit: Jetzt habe ich es verstanden. Mein ursprünglicher Einwand an 
dieser Stelle war unberechtigt. Habe den Text bestimmt 5x angeschaut und 
vielleicht auch aufgrund der anderen Beschreibungen immer wieder so 
interpretiert:
L: LESEN; (und ebenso)  vermindere zweiten Operanden um A


>> Also: Weils die Neurotiker nicht schaffen
>
> Du solltest versuchen, die Bedeutung von Dir verwendeter Worte wie
> "Neurotiker" zu verstehen, dann würdest Du evtl. weniger abwertend über
> andere Threadteilnehmer schreiben. Andererseits, es könnte auch
> Selbstreflektion sein. ;D

In Josefs Threads habe ich nicht alles gelesen. An den von mir gelesenen 
Stellen ist mir kein logischer Fehler in Josefs Argumentation 
aufgefallen. Fast immer ist das Ende eines Diskussionsstranges eine 
nicht konsensfähige Ansicht, gegen die nicht weiter argumentiert wurde, 
bzw. gegen die man nicht mehr weiter logisch argumentieren konnte.

In diesem Thread wollte Josef auf meine Äußerungen nicht erwidern. Das 
hätte auch anders herum sein können. Oft genug habe ich schon in anderen 
Threads nicht weitergeschrieben. Um so bemerkenswerter, dass dies 
einigen anderen, die ebenso auch schon in anderen Threads einfach nicht 
weiter geschrieben haben, hier nur schwerlich oder mit unpassenden 
Vorschlägen (User löschen, Thread löschen) gelingt. Ganz im Sinne von 
"Josef gefährdet die öffentliche Denkordnung" ...mit einem einzigen 
aktiven Thread!
Oder sinngemäß: "Wegen einem aktiven Thread von Josef könne man das 
ganze Forum nur schwerlich ertragen, könnte ggf. das ganze Forum 
ignorieren" (mehrfach geäußert).

Ich bin bzgl. der Klassifizierung von Verhalten kein Experte. Mir fällt 
neben der Zwangsneurose spontan nur eine andere Möglichkeit ein: Es 
handelt sich (teilweise) um "Gutmenschen", die anders Denkenden 
"helfen", die Dinge richtig zu verstehen. Wenn diese Hilfe beim anders 
Denkenden jedoch nicht erfolgreich ist, so wird er bekämpft, weil die 
andere Ansicht nicht tollieriert werden kann. Schließlich hat man sich 
so sehr Mühe gegeben...
Ich habe eine Bezeichnung dafür, aber ich schreib sie hier nicht hin. 
Glaube auch nicht, dass das (auf alle) hier zutrifft.

Dennoch: Die Hemmschwelle sinkt, wenn man als Gruppe auf Einzelne 
losgeht. Das trifft auch ohne Internet zu.

Hier im Forum wird häufig der Anspruch erhoben, als Entwickler und 
Ingenieure besonders vertraut mit dem rationalen Denken und Handeln zu 
sein. Vor diesem Hintergrund finde ich die Abläufe schade. Dann braucht 
man sich über andere Vorgänge im Land nicht wundern und eigentlich auch 
nicht ständig beschweren, wenn es hier keinen Deut besser abläuft.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Lars R. schrieb:
> In Josefs Threads habe ich nicht alles gelesen. An den von mir gelesenen
> Stellen ist mir kein logischer Fehler in Josefs Argumentation
> aufgefallen.

Aussagen wie "dies ist meine Meinung, und die solltet ihr teilen" sind 
weder logisch noch unlogisch, egal auf welcher Seite davon man steht. Es 
ist keine Frage der Logik, Meinungen zu kritisieren.

> handelt sich (teilweise) um "Gutmenschen", die anders Denkenden
> "helfen", die Dinge richtig zu verstehen. Wenn diese Hilfe beim anders
> Denkenden jedoch nicht erfolgreich ist, so wird er bekämpft

Ich bin halt lieber Gut- als Bösmensch. Ich versuche, ihm zu helfen, 
bevor ich ihm eine reinhaue. Andere sparen sich die Mühe des ersten 
Schritts. Apropos: Wie nennt man eigentlich die dritte Kategorie, also 
die Schweizer bei Asterix, die erst eine überziehen und danach 
verarzten? ;-)

Einrechnen sollte man freilich, dass er sich vorsätzlich dieser 
Diskussion stellte. Er wollte die Reaktionen darauf wissen. Nur waren es 
nicht jene, die er sich erhoffte.

> Hier im Forum wird häufig der Anspruch erhoben, als Entwickler und
> Ingenieure besonders vertraut mit dem rationalen Denken und Handeln zu
> sein.

Können und tun sind zwei paar Stiefel. Die Vorstellung, dass man über 
seinen Emotionen steht, ist üblicherweise eine Illusion.

: Bearbeitet durch User
Autor: Josef G. (bome) Benutzerseite
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Die Operation ist immer die gleiche:
>
> move

Habe den Beitrag von Rufus nochmal in Ruhe gelesen.
Ich muss zugeben, dass das Konzept der Trennung von
Schlüsselwort und Operanden eine klare Struktur hat.

Es ist aber doch wohl so, dass dieses Konzept eingeführt
wurde für Prozessoren mit einer großen Zahl von Operanden.
Meine CPU hat aber keine große Zahl von Operanden. Es ist
problemlos möglich, die paar Operanden ins Schlüsselwort
zu integrieren. Warum also soll ich das nicht tun?

========

Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
Weil darauf inhaltlich keine Antwort kam noch ein Versuch

Zu den Repeat-Befehlen mit Adresse-Inkrementieren/Dekrementieren

Beispiel Blockverschiebung:
S.RP     setze Schleifenstartadresse auf den GTMX-Befehl
GTMX     lade Memory(X) nach A
STMY     speichere A in Memory(Y)
IX0      inkrementiere X
R.IY     dekrementiere Schleifenzähler, inkrementiere Y
         und springe zu GTMX, falls Zähler nicht Null.
R.IY dauert nicht länger als einfaches Inkrementieren IY0.
Bei Realisierung der Schleife mit separatem Rückwärtssprung
bestünde ein Anreiz, zur Beschleunigung den Schleifeninhalt
GTMX
STMY
IX0
IY0
zweimal hinzuschreiben. Das entfällt durch den R.IY -Befehl.

Das ist jetzt aber doch eine positive Eigenschaft
meiner CPU, oder etwa nicht?

========

Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"

In dem Beitrag wurde der auf PC laufende Cross-Assembler
erwähnt. Vielleicht hat ihn jemand ausprobiert und war
enttäuscht. Ich habe ihn überarbeitet, vielleicht mag
ihn nochmal jemand testen ...

Autor: Horst G. (horst_g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Josef G. schrieb:
> Meine CPU hat aber keine große Zahl von Operanden. Es ist
> problemlos möglich, die paar Operanden ins Schlüsselwort
> zu integrieren. Warum also soll ich das nicht tun?

Natürlich gibt es kein Gesetz, das das verbietet. Allerdings würde ich, 
wenn ich einen neuen Befehlssatz (quasi eine neue "Sprache") entwerfen 
würde, als Autor auf eine Zukunftssicherheit Wert legen.
Heißt konkret: Wenn Du nun irgendwann eine bo16-/bo32-CPU entwerfen 
möchtest, die naturgemäß eine komplexere Registerstruktur umfasst (oder 
auch "nur" eine Version 2 der bo8, die diverse 
Verbesserungen/Erweiterungen mit sich bringt), ist es extrem 
vorteilhaft, wenn die Befehlssätze konsistent sind - die Nutzer müssen 
nicht noch eine weitere Sprache für eine architekturell ähnliche CPU 
lernen, und die Tools sind u. U. wiederverwendbar bzw. können kompatibel 
gestaltet werden und müssen nicht von Grund auf neu entwickelt werden.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst G. schrieb:
> die naturgemäß eine komplexere Registerstruktur umfasst

Wieso eigentlich? Was bei 8 Bits richtig ist kann bei 32 Bits nicht 
falsch sein, oder? Eine 32-Bit Akkumulator-Architektur wäre derzeit wohl 
ein Alleinstellungsmerkmal. Die letzte dieser Art könnte die Z380 
gewesen sein, eine 32-Bit Z80, die hat aber nie gross abgehoben.

: Bearbeitet durch User
Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> 32-Bit Akkumulator-Architektur

Die leider nie offiziell dokumentierten Erweiterungen der CMOS-Version 
des 6809 von Hitachi (HD6309) waren auch eine, wenngleich dank des 
8-Bit-Daten- und 16-Bit-Adressbus leider von vornherein zum Scheitern 
verurteilte.

https://en.wikipedia.org/wiki/Hitachi_6309#/media/...

Zu den Akkus A und B gesellten sich zwei weitere namens E und F, die zu 
einem 16-Bit-Akku W zusammengefasst werdem konnten. Der aus A und B 
gebildete 16-Bit-Akku D wiederum konnte mit diesem zu einem 32-Bit-Akku 
Q zusammengefasst werden.

Dieser bestand dann aus den vier 8-Bit-Akkus A, B, E und F.