Befehlssatz der bo8-CPU - was ist gut, was ist schlecht

[Michael U. (amiga)]

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

[Gu. F. (mitleser)]

Wo nimmst du nur die Engelsgedult her?

[Gerald (Gast)]

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

[Falk B. (falk)]

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

[Axel S. (a-za-z0-9)]

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.

[Martin S. (strubi)]

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

[Автомат К. (dermeckrige)]

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.

[Jobst M. (jobstens-de)]

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

[Jobst M. (jobstens-de)]

Josef G. schrieb:
> Ich sehe da eine große Ähnlichkeit.

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


Gruß

Jobst

[Gerald (Gast)]

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

[MWS (Gast)]

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.

[2⁵ (Gast)]

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?

[Lars R. (lrs)]

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

[2⁵ (Gast)]

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

[MWS (Gast)]

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.

[Lars R. (lrs)]

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.

[(prx) A. K. (prx)]

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.

[Josef G. (bome)]

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

[Horst G. (horst_g)]

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.

[(prx) A. K. (prx)]

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.

[Rufus Τ. F. (rufus)]

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/File:6309programmingmodel.png

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.

[Yalu X. (yalu) (Moderator)]

IMHO sind die Architekturen mit Akkumulator und nur wenigen zusätzlichen
Registern ab dem Zeitpunkt immer mehr aus der Mode gekommen, als die
CPU-Geschwindigkeit begann, schneller als die Speichergeschwindigkeit zu
wachsen. Ein großer Satz an Datenregistern erlaubt es halt, längere
Codeabschnitte ohne (Daten-)Speicherzugriffe auszuführen. Es könnte
allenfalls sein, dass mit immer effektiver arbeitenden Datencaches
Akkumulatorarchitekturen wieder interessanter werden. Die Frage ist
aber, was der Vorteil einer solchen Architektur wäre. Kleinere
Chipfläche? Die dürfte eine eher untergeordnete Rolle spielen, da bei
schnellen CPUs heute der größte Teil der Chipfläche ohnehin mit Cache
belegt ist.

[Josef G. (bome)]

Ich hab zwar nicht viel Ahnung von 16- und 32-Bit-CPUs,
aber ich habe den Verdacht, dass der Grund für die große
Zahl von Registern darin besteht, die durch die größere
Wortbreite bedingte große Zahl möglicher OpCodes
irgendwie sinnvoll nutzen zu wollen.

[Rufus Τ. F. (rufus)]

Josef G. schrieb:
> aber ich habe den Verdacht

Aha. Wenn Du das ernst meinst, erklärt das natürlich vieles.

[Josef G. (bome)]

Rufus Τ. F. schrieb:
> Josef G. schrieb:
>> aber ich habe den Verdacht
>
> Aha. Wenn Du das ernst meinst, erklärt das natürlich vieles.

Versteh ich nicht. War mein Beitrag Unsinn?

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Josef G. schrieb:
> Versteh ich nicht. War mein Beitrag Unsinn?

Ich vermute ja.

Ich kann mir nicht vorstellen, dass ein CPU-Entwickler erst eine Liste 
mit Op-Codes entwickelt und dann den passenden Prozessor darum baut...

[Rufus Τ. F. (rufus)]

Josef G. schrieb:
> Versteh ich nicht.

Wenn Du den Nutzen von mehr Prozessorregistern nicht erkennen kannst ... 
scheinst Du eine sehr, sagen wir mal im positiven Sinne 
"ressourcensparende" Art der Programmierung zu verfolgen, die aber auch 
die Komplexität des damit erzielbaren in sehr überschaubaren Bahnen 
hält.

[Yalu X. (yalu) (Moderator)]

Außerdem orientiert sich die Länge der Befehle nicht immer an der
Wortbreite der CPU. Das ist bei 8- und 16-Bit-Prozessoren zwar oft der
Fall, bei 32- und 64-Bit-Prozessoren gibt es aber viele Gegenbeispiele.
Der Intel Core i7, vor dem ich gerade sitze, kennt bspw. Befehle mit den
Längen 1, 2, 3, 4, 5, 6 und 7 Byte. Kein Befehl nutzt die vollen 64 Bit
und nur ein relativ kleiner Anteil davon genau ein halbes CPU-Wort, also
32 Bit.

Wenn die CPU-Entwickler viele Register in ihre CPUs packen, könnte das
also noch andere Gründe haben. Einen habe ich oben schon genannt.

[(prx) A. K. (prx)]

Yalu X. schrieb:
> IMHO sind die Architekturen mit Akkumulator und nur wenigen zusätzlichen
> Registern ab dem Zeitpunkt immer mehr aus der Mode gekommen, als die
> CPU-Geschwindigkeit begann, schneller als die Speichergeschwindigkeit zu
> wachsen.

Einerseits dies. Andererseits kann auf Register recht einfach über 
mehrere Ports gleichzeitig zugegriffen werden. Bei Speicher ist der 
Aufwand dafür erheblich höher.

Dazu kommen Pipeline-Effekte. Egal wie man eine Pipeline baut, man 
kriegt immer irgendwelche Stalls, wenn der Folgebefehl unweigerlich die 
gleichen Ressourcen verwenden muss (Akku/Index). Erst durch Verzahnung 
unabhängiger Operationen lassen sich die vermeiden. Siehe Delay-Slot 
beim LOAD der ersten RISC CPUs.

> Die Frage ist aber, was der Vorteil einer solchen Architektur wäre.

Keiner. Der von mir verwendete Begriff "Alleinstellungsmerkmal" lässt 
sich nicht nur positiv verstehen. ;-)

[(prx) A. K. (prx)]

Josef G. schrieb:
> Ich hab zwar nicht viel Ahnung von 16- und 32-Bit-CPUs,
> aber ich habe den Verdacht, dass der Grund für die große
> Zahl von Registern darin besteht, die durch die größere
> Wortbreite bedingte große Zahl möglicher OpCodes
> irgendwie sinnvoll nutzen zu wollen.

Nein. Wenn man Operationen der Art
  a := b + c
so ausführen will, dass man pro Takt ein Ergebnis erhält, dann setzt das 
Register voraus, oder einen arg hohen Aufwand im Speicherzugriff.

Wenn man dann auch noch mehrere davon pro Takt ausführen will, dann wird 
das noch viel krasser (Cortex M7).

Es gibt keinen Zusammenhang zwischen Wortbreite der Maschine und Breite 
der Opcodes, ausser dass es irgendwie zusammenpassen muss (oder auch 
nicht - iAPX432, mit krass ineffizienter Bitstream-Codierung).

Der Opcode-Stream der VAX war byteweise aufgebaut. Einfache Befehle ohne 
Registerangabe waren 1 Byte lang.

Die 60-Bit CDC6600 (Mitte 1960er) hatte 3 Sätze zu je 8 Registern. Die 
Opcodes waren 15 und 30 Bits breit.

[(prx) A. K. (prx)]

Yalu X. schrieb:
> Der Intel Core i7, vor dem ich gerade sitze, kennt bspw. Befehle mit den
> Längen 1, 2, 3, 4, 5, 6 und 7 Byte.

Es sind 1-15 Bytes. Theoretisch ginge auch mehr, aber so ist es 
definiert, damit der Fetch/Decode Mechanismus nicht noch komplizierter 
wird, als er sowieso schon ist. Der Aufwand, bei 4 pro Takt gleichzeitig 
dekodierten Befehlen rauszukriegen, wo welcher davon anfängt und wo der 
letzte aufhört, ist nicht eben klein. Weshalb es eine Obergrenze für die 
kumulierte Länge aller in einem Takt decodierbarer Befehle gibt.

[(prx) A. K. (prx)]

A. K. schrieb:
> Dazu kommen Pipeline-Effekte. Egal wie man eine Pipeline baut, man
> kriegt immer irgendwelche Stalls, wenn der Folgebefehl unweigerlich die
> gleichen Ressourcen verwenden muss (Akku/Index). Erst durch Verzahnung
> unabhängiger Operationen lassen sich die vermeiden. Siehe Delay-Slot
> beim LOAD der ersten RISC CPUs.

Bevor irgendwer solche Kleinigkeiten für neumodische Probleme hält: Die 
erwähnte CDC6600 hatte etliche parallel arbeitende Ausführungseinheiten 
(und Multithreading ;-), im Nachfolger CDC7600 waren diese Einheiten 
gepipelined, und eine IBM 360 verwendete bereits Out-of-Order Execution 
mit Renaming um den Konsequenzen zu entkommen. Alles 60er Jahre.

[Yalu X. (yalu) (Moderator)]

A. K. schrieb:
> Es sind 1-15 Bytes.

Stimmt, die 7 sind noch lange nicht das Maximum. Das zeigt aber noch
deutlicher, dass die Befehlsworte in keinem Zusammenhang mit den
Datenworten oder der Busbreite stehen, eine Sache die man von 8-Bit-CPUs
so nicht kennt. Oder gibt es vielleicht irgendeine exotische 8-Bit-CPU,
bei der bspw. zwei 12-Bit-Befehlsworte in drei Bytes untergerbracht
sind? Mich würde das nicht einmal allzu sehr wundern ;-)

[Carl D. (jcw2)]

A. K. schrieb:
> Bevor irgendwer solche Kleinigkeiten für neumodische Probleme hält: Die
> erwähnte CDC6600 hatte etliche parallel arbeitende Ausführungseinheiten
> (und Multithreading ;-), im Nachfolger CDC7600 waren diese Einheiten
> gepipelined, und eine IBM 360 verwendete bereits Out-of-Order Execution
> mit Renaming um den Konsequenzen zu entkommen. Alles 60er Jahre.

Das klingt aber für Leute, die zum Jahrtausendwechsel noch im 
Kindergarten waren, wie "Opa erzählt vom Krieg". Das auf einer solchen 
360er Virtuelle Maschinen liefen, die teils Hunderte User "betreuten", 
ist ja eigentlich gar nicht möglich, denn das wurde alles doch "erst 
gestern" erfunden.

[Yalu X. (yalu) (Moderator)]

Carl D. schrieb:
> Das auf einer solchen 360er Virtuelle Maschinen liefen, die teils
> Hunderte User "betreuten", ist ja eigentlich gar nicht möglich, denn
> das wurde alles doch "erst gestern" erfunden.

Ja, auch die Abkürzung "VM" gab es damals schon als Name für ein
Betriebssystem von IBM. Diese VMs konnten damals mehr als heute. Oder
finde mal eine "moderne" VM, die sogar den Lochkartenstanzer und -leser
virtualisiert ;-)

[(prx) A. K. (prx)]

Yalu X. schrieb:
> Oder gibt es vielleicht irgendeine exotische 8-Bit-CPU,
> bei der bspw. zwei 12-Bit-Befehlsworte in drei Bytes untergerbracht
> sind? Mich würde das nicht einmal allzu sehr wundern ;-)

Gibt es. Die PIC10/12. ;-)

[Jobst M. (jobstens-de)]

Horst G. schrieb:
> Wenn Du nun irgendwann eine bo16-/bo32-CPU entwerfen
> möchtest

Oh Herr, bitte verschone uns!


A. K. schrieb:
> Gibt es. Die PIC10/12. ;-)

In drei Bytes aber doch nicht ...
Dort ist der Speicher 12 Bit breit.


Gruß

Jobst

[Yalu X. (yalu) (Moderator)]

Jobst M. schrieb:
> In drei Bytes aber doch nicht ...

Wenn man ein Byte weiterhin als 8 Bit definiert, hat er schon recht.
Aber da das natürlich nicht ganz das ist, was ich meinte, und er wusste,
was ich meinte, hat er genau dies, ohne viel Worte zu verschwenden, mit
einem Smiley kundgetan :)

[Jobst M. (jobstens-de)]

Beim PIC12 würde ich immer einen Smiley dran setzen! ;-D


Gruß

Jobst

[Josef G. (bome)]

Yalu X. schrieb:

> 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 heißt. Damit trägt das V-Flag nach Ausführung
> dieses Befehls erstmals sein Kürzel zurecht.

Ich meine, das ist nicht richtig, wenn hier das Rechnen mit
Zweierkomplement-Zahlen gemeint ist. Das Overflow-Flag würde
sich errechnen als  V xor (Eingangs-Carry zu Bit7).

Es ist aber richtig, wenn man mit Offset-Zahlen rechnet,
wobei eine Offset-Zahl aus einer Zweierkomplement-Zahl
entsteht durch Negation des Vorzeichenbits.

[Josef G. (bome)]

Strubi schrieb:
> Spät des Abends, crasht die Kiste
> Der Fehler liegt an der Netzliste,
> Schuld hat a-synchrone Logik,
> wie auch Schleifen-Komb'natorik,

Wer das liest, wird denken, solche Fehler
seien bei meiner CPU schon mal aufgetreten.

Sind sie aber nicht.

[Josef G. (bome)]

Michael U. schrieb:
> Wenn ich das jetzt also ernst mehmen wollte, müßte ich
> mir ein offenbar zeimlich teures FPGA-Board beschaffen,

Altera DE0-Board (ohne nano), dazu eine D-Sub-Buchse
für RS232, unter 100 Euro. QuartusII 13.0-Sp1 kostenlos.

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

Immerhin: Conway's Game of Life.

[Le X. (lex_91)]

Josef G. schrieb:
>> 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?
>
> Immerhin: Conway's Game of Life.

Sag aber bitte fairerweise dazu dass es dein Game of Life nicht in 
Source-Form gibt sondern nur als Hexcode als Teil der Firmware 
irgendeiner Steckkarte.

Beitrag "Re: 8bit-Computing mit FPGA"
Beitrag "Re: 8bit-Computing mit FPGA"

Für Einsteiger (deine erklärte Zielgruppe) also wieder nix.

[Josef G. (bome)]

Le X. schrieb:
> dass es dein Game of Life nicht in
> Source-Form gibt sondern nur als Hexcode

auch als Disassembler-Listing.
Beitrag "Re: 8bit-Computing mit FPGA"

[Le X. (lex_91)]

Josef G. schrieb:
> auch als Disassembler-Listing.
> Beitrag "Re: 8bit-Computing mit FPGA"

Ich nehme meine Kritik zurück, du hast natürlich recht.
Das Listing habe ich glatt übersehen.

Damit ist nun auch Anfängern endlich geholfen!
https://www.mikrocontroller.net/attachment/301903/GOLcod.txt

[Rufus Τ. F. (rufus)]

Le X. schrieb:
> Damit ist nun auch Anfängern endlich geholfen!
> https://www.mikrocontroller.net/attachment/301903/GOLcod.txt

Eindeutig. Das liest sich fast so gut wie ein ... vom chinesischen ins 
Georgische übersetzter Busfahrplan.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Ab 3fe8 hab ich den Faden verloren...

[Josef G. (bome)]

Wolfgang R. schrieb:
> Ab 3fe8 hab ich den Faden verloren...

Ist halt nicht nur der eigentliche Iterations-Vorgang,
sondern auch das vorbereitende Löschen des Bildschirms und
Setzen einer Randmarkierung, die Kommunikation mit dem Benutzer
zur Auswahl der Spielfeldgröße, das Importieren des Startbildes,
der Iterationsvorgang in zweifacher Ausführung für zwei verschiedene
Auflösungen, das Anhalten und Weiterlaufenlassen, das Scrollen des
Bildes mit den Cursortasten, ..., da kommt schon einiges zusammen.

[Le X. (lex_91)]

Dann wären aber Kommentare und aussagekräftige Sprungmarken angebracht.
Dann wäre auch sofort ersichtlich welche Befehle deiner CPU im Verbund 
welche Funktionalität bewirken.

Ich weiß, das ist ein Disassembly.
Jo mei, wenn man alles von hinten durch die Brust ins Auge machen 
muss...

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Josef G. schrieb:
> Wolfgang R. schrieb:
>> Ab 3fe8 hab ich den Faden verloren...
>
> Ist halt nicht nur der eigentliche Iterations-Vorgang,
> sondern auch das vorbereitende Löschen des Bildschirms und
> Setzen einer Randmarkierung, die Kommunikation mit dem Benutzer
> zur Auswahl der Spielfeldgröße, das Importieren des Startbildes,
> der Iterationsvorgang in zweifacher Ausführung für zwei verschiedene
> Auflösungen, das Anhalten und Weiterlaufenlassen, das Scrollen des
> Bildes mit den Cursortasten, ..., da kommt schon einiges zusammen.

Du hast gemerkt, dass das ein Scherz von mir war?

Mal im Fast-Ernst: diese Form des disassemblierten Listings ist für 
Leute ohne Asperger-Syndrom incl. Inselbegabung nicht verarbeitbar, 
sorry.

[Yalu X. (yalu) (Moderator)]

Josef G. schrieb:
> Yalu X. schrieb:
> 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 heißt. Damit trägt das V-Flag nach Ausführung
>> dieses Befehls erstmals sein Kürzel zurecht.
>
> Ich meine, das ist nicht richtig, wenn hier das Rechnen mit
> Zweierkomplement-Zahlen gemeint ist. Das Overflow-Flag würde
> sich errechnen als  V xor (Eingangs-Carry zu Bit7).

Du hast völlig recht. Ich habe da ein paar Dinge durcheinandergebracht.

[Josef G. (bome)]

Josef G. schrieb:
> Es ist aber richtig, wenn man mit Offset-Zahlen rechnet,
> wobei eine Offset-Zahl aus einer Zweierkomplement-Zahl
> entsteht durch Negation des Vorzeichenbits.


Zum fehlenden Overflow-Flag und zum Rechnen mit Offset-Zahlen


Bei 1-Byte-Offsetzahlen gilt [P] = P-80.

Dabei sei P der positive Wert, wie er im Speicher
steht, und [P] sei die Zahl, welche gemeint ist.

V ist das Carry-Flag, U ist Bit7 des Akku.


Addition :

[A]+[B] = (A-80)+(B-80) = (A+B-80)-80

Damit kein Overflow vorliegt, muss A+B-80 im Bereich
00 .. ff liegen, und es gilt dann [A]+[B]=[A+B-80].

A+B muss also im Bereich 80 .. 17f liegen. Das ist genau
dann der Fall, wenn nach Addition A+B gilt (V xor U = 1).

Nach der Addition A+B erhält man das
Endergebnis A+B-80 durch Negation von U.


Subtraktion :

[A]-[B] = (A-80)-(B-80) = (A-B+80)-80

Damit kein Overflow vorliegt, muss A-B+80 im Bereich
00 .. ff liegen, und es gilt dann [A]-[B]=[A-B+80].

A-B muss also im Bereich -80 .. +7f liegen. Das ist genau
dann der Fall, wenn nach Subtraktion A-B gilt (V xor U = 0).

Letzteres sieht man aus folgendem:
X sei der positiv interpretierte Wert,
welcher nach der Subtraktion A-B im Akku steht.
Falls V=0 ist, dann gilt A-B = X
X muss also im Bereich 00 .. 7f liegen, dh. U muss 0 sein.
Falls V=1 ist, dann gilt A-B = X-100
X muss also im Bereich 80 .. ff liegen, dh. U muss 1 sein.

Nach der Subtraktion A-B erhält man das
Endergebnis A-B+80 durch Negation von U.

-----------

Wenn man also mit Offset-Zahlen statt mit Zweierkomplement-
Zahlen rechnet, dann braucht man kein Overflow-Flag. So hatte
ich mir das überlegt, und deshalb das Overflow-Flag weggelassen.
Oder steckt in meiner Rechnung irgendwo ein Fehler?

[Lars R. (lrs)]

Geht das nicht auch einfach mit
Bit7 xor Bit8
?

[Josef G. (bome)]

Lars R. schrieb:
> Geht das nicht auch einfach mit Bit7 xor Bit8 ?

Was ist das ?  Falls damit gemeint ist zu testen ob Overflow
vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich
U und V genannt habe, dann ist es ja genau das, was ich
geschrieben habe.

[Carl D. (jcw2)]

Josef G. schrieb:
> Lars R. schrieb:
>> Geht das nicht auch einfach mit Bit7 xor Bit8 ?
>
> Was ist das ?  Falls damit gemeint ist zu testen ob Overflow
> vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich
> U und V genannt habe, dann ist es ja genau das, was ich
> geschrieben habe.

Mit dem Unterschied, daß Lars Variant mit inhärenter Verständlichkeit 
gesegnet ist.

[Lars R. (lrs)]

Josef G. schrieb:
> Lars R. schrieb:
>> Geht das nicht auch einfach mit Bit7 xor Bit8 ?
>
> Was ist das ?  Falls damit gemeint ist zu testen ob Overflow
> vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich
> U und V genannt habe, dann ist es ja genau das, was ich
> geschrieben habe.

Overflow ist gemeint, aber:

Josef G. schrieb:

> Wenn man also mit Offset-Zahlen statt mit Zweierkomplement-
> Zahlen rechnet, dann braucht man kein Overflow-Flag. So hatte
> ich mir das überlegt, und deshalb das Overflow-Flag weggelassen.

Mit meiner Frage meinte ich: Ohne Erzeugen von "Offset", Rechnen in 
"Offset" und anschließender Negation. Einfach nur Bit7 xor Bit8.

[Lars R. (lrs)]

Carl D. schrieb:
> Josef G. schrieb:
>> Lars R. schrieb:
>>> Geht das nicht auch einfach mit Bit7 xor Bit8 ?
>>
>> Was ist das ?  Falls damit gemeint ist zu testen ob Overflow
>> vorliegt, und falls du mit Bit7 und Bit8 das meinst was ich
>> U und V genannt habe, dann ist es ja genau das, was ich
>> geschrieben habe.
>
> Mit dem Unterschied, daß Lars Variant mit inhärenter Verständlichkeit
> gesegnet ist.

Meiner Ansicht nach ist bereits der Sprachgebrauch ungewöhnlich und 
grenzwertig. Beides zusammen führt dazu, dass ich beim Lesen der 
Aussagen einen anderen, falschen Sinn verstehe. Dann verstehe ich nach 
einiger Zeit den wahren Sinn und bin der Ansicht, dass die Aussage 
falsch ist. Anschließend schaue ich die Aussage an und überlege, mit 
welcher Interpretation sie doch korrekt sein könnte.
Hinzu kommt, dass für eine prägnante, verständliche Beschreibung immer 
das am Genauesten passende Wort oder Zeichen gewählt wird. Das ist 
meiner Ansicht nach sehr häufig nicht der Fall, weshalb die 
Beschreibungen nicht prägnant und auch nicht verständlich sind.
Weiterhin kommt hinzu, dass für seit Jahrzehnten etablierte Begriffe 
neue Bezeichner eingeführt werden. Dafür sollte man immer sehr gute 
Gründe haben und mir persönlich reicht die gebotene Begründung "das 
spart 2 Zeichen tippen" nicht, um die daraus folgende schlechtere 
Verständlichkeit zu rechtfertigen.

Dies alles zusammen bringt mich immer wieder durcheinander (siehe oben) 
und es macht es beliebig schwer, überhaupt zu dem Punkt zu gelangen, an 
dem man Schwächen im Konzept erkennen und diskutieren kann. Beispiel:

> Nach der Subtraktion A-B erhält man das
> Endergebnis A-B+80 durch Negation von U.

Erstes Lesen:
-U = A-B+80

Zweites Lesen nochmal von oben:
Not(U) = A-B+80,
denn U ist ein Bit. Besser wäre "Invertieren von U". "Negation" ist nich 
falsch.

Drittes Lesen:
"V ist das Carry-Flag, U ist Bit7 des Akku."
Ergebnis = A-B+80,
U ist ein Bit,
U ist ein Bit von Ergebnis
U ist das 7. Bit
U ist MSB.

Die Aussage lautet demnach:
"Nach der Subtraktion A-B erhält man das Endergebnis A-B+80 durch 
Invertieren des MSB."

"MSB" ist bekannt und eindeutig. "Negation von MSB" wäre dann auch 
sofort verständlich.

Alternativ lässt sich der Sachverhalt in Prosa in dieser Kürze eben 
nicht korrekt ausdrücken. Dh, mehr Worte für die Beschreibung oder eine 
verständliche Gleichung.

Gut, weiter:

Viertes Lesen:
80 ist HEX, positiv, 8 Bit; also 80h

Fünftes Lesen:
"Endergebnis A-B+80"? Als Endergebnis der Subtraktion A-B möchte ich 
doch A-B haben, oder?

Achso... A und B sind Offsetzahlen und [A] und [B] sind die 
tatsächlichen, gemeinten Zahlen. Gut, die Zeichensetzung hier ist 
begrenzt. Trotzdem ist die Verwendung hier wieder dem Sprachgebrauch 
entgegen. Eine 20-Cent-Münze definiere ich zunächst nicht über ihre 
Legierung, sondern über die aufgeprägte Zahl.

Also, dies alles im Kopf behalten. Nun nur nicht versehentlich 
wohlwollend gedanklich etwas verdrehen, was mal nicht "verdreht" gemeint 
war, und: Post nochmal lesen, um zu schauen, was es mit den Offset auf 
sich hat.

An der Stelle habe ich (eigentlich schon viel zu spät) abgebrochen, kurz 
überlegt, wie man Overflow erkennt und als Frage hingeschrieben...

[Le X. (lex_91)]

Das Problem hast aber nur du weil du durch jahrzehntelange Erfahrungen 
vorbelastet bist.
Du bist aber nicht die Zielgruppe.

Für einen Einsteiger ist das alles sehr leicht verständlich ;-)

[Lars R. (lrs)]

Josef, was sagt diese Skizze aus?

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

In der Beschreibung zur CPU ist die Bedeutung für jeden Buchstaben 
angegeben. Aber die Skizze wird kommentarlos geboten. Mir fallen in der 
Skizze folgende Dinge auf:

. Eine Leerspalte zwischen P und Q.
. Eine Leerspalte zwischen S und X.
. Zwei Leerspalten zwischen Z und K sowie 4 oder 5 zwischen K und V.
. Horizontalstriche nicht unter V.
. V ist in der Skizze, U nicht, aber K trotzdem.
. A7 = U (Und ich dachte schon, U = A7, dh. U = MSB von A)
. Unter dem K stehen A und B; A und B stehen nicht oben.

Zu jedem aufgezählten Punkt: Warum?

[S. R. (svenska)]

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?

Weil nicht alles, was möglich ist, auch sinnvoll ist.
Deine Zielgruppe sind Anfänger,
    für die ist eine klare Struktur sinnvoll und notwendig.
Anders ausgedrückt: Verständlichkeit trumpft Effizienz.

[Josef G. (bome)]

Thema des Threads ist zwar die CPU, aber das Emulationsprogramm
wurde bereits erwähnt, und ich möchte darauf zurückkommen.
Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"

Ich habe auf der Seite Emul die Anleitung zum Emulationsprogramm
und zu den Beispieltexten überarbeitet. Vielleicht mag nochmal
jemand sich die Sache anschauen ...

[Michael U. (amiga)]

Hallo,

Josef G. schrieb:
> Ich habe auf der Seite Emul die Anleitung zum Emulationsprogramm
> und zu den Beispieltexten überarbeitet. Vielleicht mag nochmal
> jemand sich die Sache anschauen ...

und warum dann ein Link in einen anderen Foren-Thread und nicht zu genau 
zur Emul Webseite???

Gruß aus Berlin
Michael

[Josef G. (bome)]

Michael U. schrieb:
> und warum dann ein Link in einen anderen Foren-Thread
> und nicht zu genau zur Emul Webseite???

Kein anderer Thread, sondern eine anderer Beitrag in
diesem Thread. Aber bitte, hier der gewünschte Link:
http://www.bomerenzprojekt.de/Website/Emul.html

[Yalu X. (yalu) (Moderator)]

Geschafft!!!

Ich kann jetzt tatsächlich mit deinem Demo-Programm zwei Zahlen
addieren, subtrahieren, multiplizieren und dividieren :)

Diese Information, die du in deiner Dokumentation ergänzt hast, hat noch
gefehlt:

Bei OPA ist stets das Vorzeichen anzugeben, OPB ist ohne Vorzeichen.

In meiner Naivität hatte ich in früheren Versuchen für den ersten
Operanden (OPA) einfach eine Zahl eingegeben, bin aber nicht auf die
Idee gekommen, dass man da noch ein Vorzeichen (auch für positive
Zahlen) angeben muss.

Gewundert haben mich dann nur noch die (scheinbar) falschen Ergebnisse
bei der Multiplikation und Division. Den Grund dafür habe ich aber schon
erraten, bevor ich den nächsten Satz deiner Dokumentation las, denn

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

Bekomme ich jetzt einen Preis?

Ich bin ja vermutlich der Erste, der dein Hackerspiel geschafft hat.
Zwar nur den ersten Level und den auch nur mit ein paar Hints von dir,
aber immerhin. Der Schwierigkeitsgrad war wirklich nicht ganz ohne, und
ich habe garantiert nirgends gecheatet ;-)

[Jobst M. (jobstens-de)]

Yalu X. schrieb:
> Der Schwierigkeitsgrad war wirklich nicht ganz ohne, und
> ich habe garantiert nirgends gecheatet ;-)

Naja, für Anfänger halt ;-))

Gruß

Jobst

[Josef G. (bome)]

Falls jemand Schwierigkeiten hat, beim Testen zwischen dem
Konsolenfenster, in welchem das Emulationsprogramm läuft,
und der Anleitung auf der Website hin- und herzuschalten:

Vielleicht hilft es, die Anleitung mit der Maus zu kopieren
und in einer Textdatei zu sichern, und die Textdatei neben
dem Konsolenfenster anzuzeigen.

[Josef G. (bome)]

Yalu X. schrieb:
> Josef G. schrieb:
>> ...
>> 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. ...

Inkrementieren und Dekrementieren mit langer Distanz

IXL nn  inkrementiert X um nn+1
DXL nn  dekrementiert X um nn+1

Diese Befehle sind vor allem dazu da, dass man innerhalb
eines 256-Byte-Bereichs jedes Byte direkt erreichen kann.
Beim Z80 gab es dafür die Adressierungsart IX+d und IY+d.

Ich habe nun den Assembler überarbeitet. Man kann jetzt
Startposition und Zielposition innerhalb eines 256-Byte-
Bereichs angeben, die Differenz berechnet der Assembler.

IXL 3c.8c    ergibt    IXL 4f
DXL 8c.3c    ergibt    DXL 4f

IXL 8c.3c    ergibt    IXL af    (Start=008c Ziel=013c)
DXL 3c.8c    ergibt    DXL af    (Start=013c Ziel=008c)

Gleicher Wert für Start und Ziel ergibt IXL/DXL ff.

===============================================================

Die Seite bomerenzprojekt.de existiert nicht mehr.
Neue Website ist http://www.bo8h.de

Es wurde mir vorgeworfen, dass man alle Dateien
einzeln herunterladen und entpacken muss.

Auf der neuen Website kann man jetzt das gesamte
Projekt in einer einzigen zip-Datei herunterladen.

Informationen zum Assembler sind zu finden in der Datei
SYS-doku ziemlich am Ende (Kommandos =MASS,=EASS,=CASS),
und zur PC-Version in der Datei Emul.

[Route_66 H. (route_66)]

Josef G. schrieb:
> Informationen zum Assembler sind zu finden

Glaubst du echt, das jemand wirklich sucht?

[S. R. (svenska)]

Ich zitiere mal von der Startseite:

> Die CPU hat einen vollständigen Befehlssatz mit 256 OpCodes.
> Sie kann eine unbestimmte Anzahl 64KByte-Seiten adressieren
> und ist auf Einfachheit optimiert.

Eine "unbestimmte Anzahl 64 KB-Seiten" heißt, dass du unendlich viele 
Adressbits hast. Das glaube ich dir nicht.

> Sie hat keine Interrupts. Die Berechnung der Dauer
> von Befehlsfolgen durch Zählen von Zyklen ist einfach.

Das gilt nur für deterministische, datenunabhängige Befehlsfolgen. Schon 
für einen verkürzten Bubblesort kannst du keine exakte Laufzeit angeben, 
für das Traversieren einer Liste oder das Balancieren eines Baumes 
ebenfalls nicht.

Was du schreibst, ist nicht "einfach", sondern in der angegebenen 
Allgemeinheit schlicht gelogen.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Aufgrund des exorbitanten Sinnlosigkeitsfaktors wäre das sicher eine 
gute CPU für Kurt Bindl...

[Le X. (lex_91)]

Wolfgang R. schrieb:
> Aufgrund des exorbitanten Sinnlosigkeitsfaktors wäre das sicher eine
> gute CPU für Kurt Bindl...

Die Parallelen zwischen den beiden wurden ja schon öfter erkannt.
Wobei diese garnicht so eindeutig sind.

Josef G. hat nämlich eigentlich schon Ahnung von dem was er tut und ist 
technisch richtig fit.
Leider fehlen ihm andere Fähigkeiten, z.B. die Fähigkeit zur Erkenntnis, 
dass er sich in einer Sackgasse verrandt hat oder der Pragmatismus, mal 
einen Schritt zurück zu treten und die Situation neu zu beurteilen und 
gegebenenfalls bestehnde Lösungen wegzuwerfen und neu anzufangen.

Kurt B. dagegen ist einfach nur dumm, menschlich und fachlich.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

S. R. schrieb:
> Eine "unbestimmte Anzahl 64 KB-Seiten" heißt, dass du unendlich viele
> Adressbits hast. Das glaube ich dir nicht.

Es handelt sich um einen beliebten Irrtum, "unbestimmt" oder 
"unbegrenzt" mit "unendlich" gleichzusetzen. Vielmehr bezeichnen diese 
Begriffe eine beliebig große endliche Zahl. Das ist mathematisch gesehen 
ein gewaltiger Unterschied, da daraus auch folgt, dass z.B. Algorithmen, 
die auf Objekten mit solch einer Eigenschaft arbeiten, grundsätzlich 
auch terminieren können. Wenn Du also versuchst, hier Haarspalterei zu 
betreiben, solltest Du wenigstens selbst einigermaßen korrekte 
Begrifflichkeiten verwenden und Schlussfolgerungen betreiben.

Nichtsdestotrotz ist Josefs CPU außer für ihn selbst als Hobby nicht 
allzu sinnvoll bzw. brauchbar.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Le X. schrieb:
> Die Parallelen zwischen den beiden wurden ja schon öfter erkannt.
> Wobei diese garnicht so eindeutig sind.

Da stimme ich durchaus zu. Allerdings hat Wolfgang R. schon völlig 
korrekt geschrieben: "eine gute CPU für Kurt Bindl", und nicht etwa: 
"eine CPU wie von Kurt Bindl". Josef ist zwar etwas verbohrt, aber 
ungefährlich. Bei Kurt hingegen kann ich mir schon gut vorstellen, dass 
er irgendwann die BRD GmbH infragestellen uns als Reichsbürger durch die 
Welt rennen wird, weil er so seine eigenen Naturgesetze erlassen kann.

Es ist übrigens ziemlich erschreckend, wie viele (eher einfach 
gestrikte...) Juristen der Meinung sind, die Naturgesetze seien durch 
ein Gesetzgebungsverfahren oder per Dekret geschaffen worden und könnten 
daher auch beliebig geändert werden. Man schaue sich als Auswuchs dieser 
Ansicht das "Indiana Pi Bill" von 1897 an, ein Gesetz zur Festlegung des 
Wertes von Pi, welches das Repräsentatenhaus ohne Gegenstimme passierte 
und dessen Verabschiedung vom Senat nur verschoben, aber nicht 
eingestellt wurde.

[Cyblord -. (cyblord)]

Andreas S. schrieb:
> Es handelt sich um einen beliebten Irrtum, "unbestimmt" oder
> "unbegrenzt" mit "unendlich" gleichzusetzen. Vielmehr bezeichnen diese
> Begriffe eine beliebig große endliche Zahl. Das ist mathematisch gesehen
> ein gewaltiger Unterschied,

Ja. Aber es ist in der Praxis, also beim Schreiben eines 
Assembler-Programms, kein Unterschied. Es macht keinen Sinn, die Anzahl 
adressierbarer Seiten als "unbestimmt" anzugeben. Nicht bei einer realen 
CPU.

[S. R. (svenska)]

Andreas S. schrieb:
> Es handelt sich um einen beliebten Irrtum, "unbestimmt" oder
> "unbegrenzt" mit "unendlich" gleichzusetzen.

In der realen Welt ist der Unterschied zwischen "endlich, aber zu groß" 
und "unendlich" ziemlich egal. Auch 100000 Pages á 64 KB würde ich ihm 
ohne Weiteres nicht ab.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

War die letzte CPU ohne Interrupt nicht Intels 4004? Selbst der 
Nachfolger I4040 hatte bereits eine Interruptfunktion, weil es einfach 
sinnvoll ist...

[(prx) A. K. (prx)]

Wolfgang R. schrieb:
> War die letzte CPU ohne Interrupt nicht Intels 4004?

Manche kleine PICs haben keinen Interrupt.

[Uhu U. (uhu)]

Eine Ansammlung von Lachnummern: http://www.bo8h.de/Argumente/

Das sind Argumente aus Sicht eines Kopfrechners - aber Computer sind 
dazu entwickelt worden, das Kopfrechnen oder das Rechnen mit Papier und 
Bleistift einem Esel anzuvertrauen, der alles hinnimmt, was man ihm 
aufträgt.

Da ist ein gordischer Knoten in den Hirnwindungen. Wer schlägt ihn 
durch?

[(prx) A. K. (prx)]

Seine Vorliebe für das Hexadezimalsystem fand in den 60ern eine gewisse 
Entsprechung im Fliesskommaformat von IBMs 360er Architektur. Und da die 
heute noch fortlebt, gibt es das immer noch.

Es wird Josef aber wahrscheinlich nicht freuen, dass diese Rechner 
mittlerweile auch binäres IEEE-Format und dezimale Fliesskommarechnung 
beherrschen.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

A. K. schrieb:
> kleine PICs

das sind Microcontroller... nicht eigentlich CPUs... Aber da kann 
bestimmt trefflich darüber gestritten werden.

[Josef G. (bome)]

Cyblord -. schrieb:
> Es macht keinen Sinn, die Anzahl
> adressierbarer Seiten als "unbestimmt" anzugeben.

Die CPU zeigt auf den Steuerleitungen an, von welchem
der Adressregister P,X,Y,Z eine ausgegebene Adresse kommt.
Dadurch kann eine externe Logik jedem Adressregister eine
eigene Speicherseite zuordnen. Ausserdem kann die CPU
vier verschiedene Steuersignale ausgeben, welche die
externe Logik zu einer Seitenumschaltung für eines der
Adressregister veranlassen sollen. Beim Programmzähler P
geschieht das gleichzeitig mit einem Sprungbefehl,
so dass Sprünge in eine andere Seite möglich sind.

Die Register der externen Logik, welche eine Speicherseite
auswählen  (genauer: ihre nicht aktiven Schattenregister),
erhalten ihre Werte über IO-Befehle von der CPU. Die Breite
dieser Register hängt ab von der externen Logik und ist
nicht Teil der Definition der CPU, insofern ist die Zahl
der Speicherseiten unbestimmt.

[(prx) A. K. (prx)]

Wolfgang R. schrieb:
>> kleine PICs
>
> das sind Microcontroller... nicht eigentlich CPUs...

Microcontroller sind keine CPUs, haben aber mindestens eine CPU.

[Cyblord -. (cyblord)]

A. K. schrieb:
> Wolfgang R. schrieb:
>>> kleine PICs
>>
>> das sind Microcontroller... nicht eigentlich CPUs...
>
> Microcontroller sind keine CPUs, haben aber mindestens eine CPU.

Und unter CPU versteht man einfach landläufig etwas, das für ein 
"echtes" Computersystem gedacht ist und nicht Embedded eingesetzt wird. 
Gegenbeispiele lassen sich da sicher finden, aber ich denke so verstehen 
es die meisten die von CPU sprechen.

[Carl D. (jcw2)]

Josef G. schrieb:
> Die CPU zeigt auf den Steuerleitungen an, von welchem
> der Adressregister P,X,Y,Z eine ausgegebene Adresse kommt.
> Dadurch kann eine externe Logik jedem Adressregister eine
> eigene Speicherseite zuordnen. Ausserdem kann die CPU
> vier verschiedene Steuersignale ausgeben, welche die
> externe Logik zu einer Seitenumschaltung für eines der
> Adressregister veranlassen sollen. Beim Programmzähler P
> geschieht das gleichzeitig mit einem Sprungbefehl,
> so dass Sprünge in eine andere Seite möglich sind.
.
> Die Register der externen Logik, welche eine Speicherseite
> auswählen  (genauer: ihre nicht aktiven Schattenregister),
> erhalten ihre Werte über IO-Befehle von der CPU. Die Breite
> dieser Register hängt ab von der externen Logik und ist
> nicht Teil der Definition der CPU, insofern ist die Zahl
> der Speicherseiten unbestimmt.

Ich hab noch eine Z8001 CPU rumliegen, die ist auch so gebaut und hat 
sich bekanntermaßen gegen Intel durchgesetzt ;-)

[(prx) A. K. (prx)]

Cyblord -. schrieb:
> Und unter CPU versteht man einfach landläufig etwas, das für ein
> "echtes" Computersystem gedacht ist und nicht Embedded eingesetzt wird.

Diese Definition passt zum Mikroprozessor, nicht aber zur CPU.

Wobei "embedded" auch mit einem reinen Mikroprozessor arbeiten kann. Das 
ist heute aufgrund der Integrationsdichte nur relativ selten geworden. 
Adaptecs SCSI Controller für ISA hatte einen 8085 an Bord, etliche Cisco 
Router der 90er 68020 oder 68030.

[Uhu U. (uhu)]

A. K. schrieb:
> Wobei "embedded" auch mit einem reinen Mikroprozessor arbeiten kann. Das
> ist heute aufgrund der Integrationsdichte nur relativ selten geworden.

Langfristig werden die klassischen Mikroprozessoren wohl aussterben. Bei 
den PC-Prozessoren müssen eigentlich nur die peripheren Chips im 
Prozessor verschwinden, dann ist es passiert.

Gibt es eigentlich noch Bitslice-Prozessoren?

Vor dem Hintergrund könnte es aber auch eine geschickte Strategie von 
Josef sein, sich einen Platz im Museum der Zuspätgekommenen zu 
reservieren...

[Josef G. (bome)]

A. K. schrieb:
> Es wird Josef aber wahrscheinlich nicht freuen, dass
> diese Rechner mittlerweile auch binäres IEEE-Format

Versteh ich nicht. Was sollte ich dagegen haben?

[(prx) A. K. (prx)]

Du prognostiziert Hex als die Zukunft. Und bei IBM ist es statt dessen 
die Vergangenheit, während die Zukunft binär und dezimal ist.

[Josef G. (bome)]

Ich versteh nicht den Gegensatz zwischen hex und binär.

Binär ist das, was der Rechner intern macht.
Hex ist die menschliche Sprechweise darüber.

Da gibt es keinen Gegensatz.

[Josef G. (bome)]

A. K. schrieb:
> Seine Vorliebe für das Hexadezimalsystem fand in den 60ern eine
> gewisse Entsprechung im Fliesskommaformat von IBMs 360er Architektur.

Hab's mir jetzt angeschaut:
https://de.wikipedia.org/wiki/System/360

Da steht:
> Die wichtigsten Designkriterien waren:
> 32- oder 64-Bit-Gleitkommaworte mit hexadezimaler Basis.

Offenbar haben diese Rechner bei Gleitpunktzahlen
einen Exponenten zur Basis 16(dez) verwendet.

Etwas derartiges habe aber ich nie befürwortet. Die Basis 2 für
den Exponenten bei Gleitpunktzahlen habe ich nie infrage gestellt.

[(prx) A. K. (prx)]

Wenn das allgemein verwendete Zahlensystem auf Basis 16 arbeitet, wie du 
es prognostiziert, dann wäre es nur logisch, dass dies auch bei 
Fliesskommadarstellung erfolgt. Die Werte wären unmittelbar ohne 
Konvertierung lesbar.

Der Grund damals dürfte aber banaler gewesen sein. Der Barrel-Shifter 
für die Operandenanpassung bei Addition und Subtraktion muss nicht 
bitwise arbeiten, sondern nibbleweise. Das reduziert den Aufwand. Bei 
einem Rechner aus Einzeltransistoren durchaus ein Thema, heute aber 
uninteressant.

[Uhu U. (uhu)]

Josef G. schrieb:
> Etwas derartiges habe aber ich nie befürwortet. Die Basis 2 für
> den Exponenten bei Gleitpunktzahlen habe ich nie infrage gestellt.

Diese IBM-Fuzzies sind aber auch Ignoranten...

[Josef G. (bome)]

Uhu U. schrieb:
> Josef G. schrieb:
>> Etwas derartiges habe aber ich nie befürwortet. Die Basis 2 für
>> den Exponenten bei Gleitpunktzahlen habe ich nie infrage gestellt.
>
> Diese IBM-Fuzzies sind aber auch Ignoranten...

Versteh ich nicht.

Was hat deine Aussage mit meinem Beitrag zu tun?

[Josef G. (bome)]

Josef G. schrieb:
> Die Basis 2 für den Exponenten bei Gleitpunktzahlen
> habe ich nie infrage gestellt.

Gemeint war hier die interne Zahlendarstellung.

Im Zahlenstring bei Eingabe und Ausgabe wird man
natürlich den Exponenten zur Basis 16 verwenden.
Die Konvertierung geht ohne Rundungsfehler.

[Manfred F. (manfred_f)]

Josef G. schrieb:
> Ich sehe da eine große Ähnlichkeit.

Das ist mir schon klar. Du bis ja auch, wie sag ich das jetzt politisch 
korrekt, "anders".

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Was war noch mal das Problem, welches gelöst werden sollte?

[Uhu U. (uhu)]

Hier ist auch jemand mit dem Dezimalsystem unzufrieden: 
http://www.sueddeutsche.de/wissen/winkel-winkel-1.3676793

Allerdings will er nicht das Hexadezimalsystem...

[Josef G. (bome)]

Antwort dazu hier:
Beitrag "Re: Einführung des Hexadezimalsystems"

[Josef G. (bome)]

Auf meiner Website gibt es jetzt zum Download Informationen zum
internen Aufbau der CPU. Und es gibt ein C-Programm, welches zu
jeder Operation den internen Ablauf anzeigt.  Damit sollte es
möglich sein, den VHDL-Code nachzuvollziehen. Das Programm ist
auf Linux-PC getestet, sollte aber auch unter Windows laufen.

Siehe im Verzeichnis info die Datei CPU-arch.txt
und im Verzeichnis soft die Datei steu.c.txt
http://www.bo8h.de/Downloads/

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Ich habe gerade versucht, Deine sog. Dokumentation zu lesen, und es nach 
sehr kurzer Zeit sein lassen. Es ist die Mühe nicht wert, und Du wirst 
damit auch keine weiteren Anhänger für Deine CPU gewinnen können.

Wir haben Dir schon Unmengen an Tipps für die Dokumentation und eine 
Überarbeitung der CPU gegeben, aber Du ignorierst sie komplett. 
Allmählich ist das ganze doch schon ziemlich pathologisch.

[Alexander F. (alexf91)]

Zur CPU wurde eh schon vor einigen Jahren alles gesagt, aber warum haben 
alle Dateien *.txt als Endung?

[Josef G. (bome)]

Alexander F. schrieb:
> Zur CPU wurde eh schon vor einigen Jahren alles gesagt,

Das neue an dem C-Programm ist, dass es durch seinen an den
VHDL-Code angelehnten Quelltext den VHDL-Code nachvollziehbar
machen soll und dadurch Vorbehalte bei Leuten abbauen soll,
die dem VHDL-Code misstrauen.

> aber warum haben alle Dateien *.txt als Endung?

Mein Apple-Rechner, mit dem ich die Zip-Datei erstellt habe,
kennt das Suffix .vhd nicht, deshalb habe ich .txt angehängt.
Damit alles einheitlich ist, habe ich es auch bei den C-Texten
so gemacht. Ich dachte halt, wenn alle Dateien .txt-Dateien
sind, kann beim Komprimieren nichts schiefgehen.

[Uhu U. (uhu)]

Josef G. schrieb:
> Damit alles einheitlich ist, habe ich es auch bei den C-Texten
> so gemacht.

Das Argument ist wirklich klasse... Warum ersetzt du nicht jeden von 
Leerzeichen verschiedenen Buchstaben in deiner "Dokumentation" durch ein 
X oder ein u? Dann wäre alles noch viel einheitlicher.

[(prx) A. K. (prx)]

Uhu U. schrieb:
> Das Argument ist wirklich klasse... Warum ersetzt du nicht jeden von
> Leerzeichen verschiedenen Buchstaben in deiner "Dokumentation" durch ein
> X oder ein u? Dann wäre alles noch viel einheitlicher.

Deshalb gibts ja auch schon seit zig Jahren ein Betriebssystem, das 
keine verwirrenden Extensions braucht und vorne U und hinten X heisst.

[Uhu U. (uhu)]

A. K. schrieb:
> Deshalb gibts ja auch schon seit zig Jahren ein Betriebssystem, das
> keine verwirrenden Extensions braucht und vorne U und hinten X heisst.

Ich meinte "die Dokumentation", also den Inhalt, nicht die Dateinamen...

[Josef G. (bome)]

Der Thread hier ist zwar über die CPU, aber da auch mehrfach
vom Emulationsprogramm die Rede war, möchte ich noch auf
eine neue Version des Emulationsprogramms hinweisen:
Beitrag "Re: 8bit-Computing mit FPGA"

[Alexander F. (alexf91)]

Vielleicht solltest du zuerst mal ein Archiv erstellen, das nicht alle 
Dateien mit *.txt als Erweiterung enthält. Das hast du in den letzten 5 
Jahren nicht geschafft.

[Le X. (lex_91)]

Josef G. schrieb:
> möchte ich noch auf
> eine neue Version des Emulationsprogramms hinweisen:
> Beitrag "Re: 8bit-Computing mit FPGA"

Danke für den Link, hab schon lange auf ein Update gewartet

[Josef G. (bome)]

Alexander F. schrieb:
> Vielleicht solltest du zuerst mal ein Archiv erstellen,
> das nicht alle Dateien mit *.txt als Erweiterung enthält.

Ich vermute mal ganz stark, dass Leute, denen solche Dinge
wie die Dateiendungen wichtig sind, sich ohnehin nie für
das Projekt interessieren würden.

[Robert L. (lrlr)]

Ich vermute mal ganz stark, dass Leute, denen solche Dinge
wie die Dateiendungen nicht wichtig sind, sich ohnehin auch nie für
das Projekt interessieren würden.

[S. R. (svenska)]

Sagen wir's mal so... wenn der Autor sich nicht die Mühe gibt, sein 
Projekt angemessen zu präsentieren - und dazu zähle ich gebrauchbare 
Dokumentation - dann gibt er sich höchstwahrscheinlich auch keine Mühe 
beim Inhalt. Damit ist das Projekt mit hoher Wahrscheinlichkeit wertlos.

Aber gut, ich beurteile die Qualität von Quellcode unter anderem auch an 
eingestreuten Leerzeichen und Tabs am Zeilenende. Die sind ein Zeichen 
dafür, dass jemand die Zeile entweder zigmal bearbeitet oder in aller 
Hast hingeschrieben hat (also in beiden Fällen nicht sauber gearbeitet 
hat).

[Axel S. (a-za-z0-9)]

Wolfgang R. schrieb:
> Aufgrund des exorbitanten Sinnlosigkeitsfaktors wäre das sicher eine
> gute CPU für Kurt Bindl...

LOL

Ferner werden noch Freiwillige gesucht, die einen Brainfuck-Compiler
für die bo8 CPU implementieren (vorzugsweise self-hosted)

[Josef G. (bome)]

S. R. schrieb:
> Leerzeichen und Tabs am Zeilenende.

Gibt es bei mir nicht.

[Alexander F. (alexf91)]

Josef G. schrieb:
> S. R. schrieb:
>> Leerzeichen und Tabs am Zeilenende.
>
> Gibt es bei mir nicht.

Doch, gibt es:
soft/emul.c.txt
soft/steu.c.txt
vhdl/cpu.vhd.txt
vhdl/fcpu.vhd.txt

Dazu kommt noch die unglaublich hübsche Formatierung des C-Codes:

      if(st[0]=='s') { printf("\n(storno: #)  save/ Dateikennbuchstabe: ");        
      scanf("%4s",sr); name[7]=sr[0]; if(name[7]>96 && name[7]<123) {              
      datei = fopen(name,"w"); if(datei) { for (n=0; n<256; n++) {                 
      for(i=0; i<32; i++) { b=mem[1][0xa000+n*32+i]; h=((b>>4) & 15)+48;           
      if(h>57) h=h+39; b=(b & 15)+48; if(b>57) b=b+39; sr[2*i]= (char) h;          
      sr[2*i+1]= (char) b; } fprintf(datei,"%s\n",sr); } fclose(datei); }}}

Das wurde aber auch schon vor 5 Jahren kritisiert, also erwarte ich 
nicht, dass sich das in Zukunft ändert.

[Mod: C-Tags angepasst]

[Josef G. (bome)]

Alexander F. schrieb:
> Doch, gibt es:
> soft/emul.c.txt

Wo? Welche Zeile? Bitte nur aktuelle Version von meiner Website.

In älteren Versionen von cpu.vhd und fcpu.vhd hatte ich
eine Stelle gefunden, ist inzwischen geändert.

[Alexander F. (alexf91)]

Josef G. schrieb:
> Alexander F. schrieb:
>> Doch, gibt es:
>> soft/emul.c.txt
>
> Wo? Welche Zeile? Bitte nur aktuelle Version von meiner Website.
>
> In älteren Versionen von cpu.vhd und fcpu.vhd hatte ich
> eine Stelle gefunden, ist inzwischen geändert.

grep -rno '[[:blank:]]$' . 
./info/SYS-doku.txt:807: 
./info/English/En-Hardware.txt:244:
./info/English/En-CPU-docu.txt:52:
./info/English/En-SYS-docu.txt:217:
./info/English/En-SYS-docu.txt:755:
./info/English/En-SYS-docu.txt:801:
./info/Emul.txt:237:
./soft/emul.c.txt:21:
./soft/emul.c.txt:237:
./soft/steu.c.txt:755:
./soft/steu.c.txt:757:
./soft/steu.c.txt:763:
./vhdl/cpu.vhd.txt:394:
./vhdl/cpu.vhd.txt:742:
./vhdl/fcpu.vhd.txt:394:
./vhdl/fcpu.vhd.txt:742:

[Rufus Τ. F. (rufus)]

Alexander F. schrieb:
> Dazu kommt noch die unglaublich hübsche Formatierung des C-Codes:

Oh.

Sag mal, Josef, ist das wirklich so von Dir geschrieben worden, oder 
hast Du das durch einen Obfuscator geschickt, damit das so "kompakt" 
ist?

[(prx) A. K. (prx)]

Rufus Τ. F. schrieb:
> Sag mal, Josef, ist das wirklich so von Dir geschrieben worden, oder
> hast Du das durch einen Obfuscator geschickt, damit das so "kompakt"
> ist?

Ungefähr so sieht LF-separierter Code aus, wenn man ihn mit Notepad 
öffnet. Jedenfalls sehen die 2 *.c.txt Files, in die ich reinsah, zwar 
immer noch krass aus, aber nicht ganz so rechteckig.

     while(1) {

          printf("\n\n  -------------------------------");
          printf("\n  ########### (Ende:q) OpCode: ");
          scanf("%3s",KEY); if(KEY[0]=='q') break;
          if(KEY[0]>96) KEY[0]=KEY[0]-39; if(KEY[1]>96) KEY[1]=KEY[1]-39;
          n=((KEY[0]-48)*16 +KEY[1]-48) & 255; printf("\n"); m=2; getchar();
          printf("  -------------------------------\n\n");
          
     while(1) { x3=s[3][m][n]; x2=s[2][m][n]; x1=s[1][m][n]; x0=s[0][m][n];
     
       printf("  "); if(n<16) printf("0");
       printf("%x= %s  %s    N3  N2  N1  N0\n                   %s  %s  %s  %s\n\n",
                       n,mnem[n],phas[m],cond[x3],cond[x2],cond[x1],cond[x0]);

       for(k=4;k<98;k++) {if((k==12) || (!(m & 1) && (k==55)) || ((m & 1) && (k==88))) printf("\n");
       
         x=s[k][m][n]; if(x) printf("  %s  %s\n",cccc[x],steu[k]);} printf("\n\n");

       if((s[97][m][n] & 1) || (m==7)) break; if((n==0) && (m==3)) m=0; else m++;

       printf("  -------------------------------\n"); getchar();}}}

[Rufus Τ. F. (rufus)]

Auch so formatiert wäre so etwas für mich ein Grund, jemandem dringend 
ein ganz anderes Betätigungsfeld nahezulegen.

[(prx) A. K. (prx)]

Rufus Τ. F. schrieb:
> Auch so formatiert wäre so etwas für mich ein Grund, jemandem dringend
> ein ganz anderes Betätigungsfeld nahezulegen.

Deshalb ja auch bola:
https://www.mikrocontroller.net/articles/8bit-Computer:_bo8h#Die_Programmiersprache_bola

[Josef G. (bome)]

Das Listing von A.K. stammt aus steu.c
Die Anleitung dazu steht in CPU-arch.txt

[Josef G. (bome)]

Vielleicht könnte mal ein Moderator in dem Beitrag
Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
die Tags für den C-Code anpassen?

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Soweit kommt's noch...

[Josef G. (bome)]

Wolfgang R. schrieb:
> Soweit kommt's noch...

War als höfliche Bitte gemeint, auch wenn's nicht so
rüberkommt, wie mir nun nachträglich klar wird.

[Alexander F. (alexf91)]

Josef G. schrieb:
> Vielleicht könnte mal ein Moderator in dem Beitrag
> Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
> die Tags für den C-Code anpassen?

Ja, das habe ich leider übersehen.
Mehr Farbe macht den Code sicher lesbarer.

Vielleicht könntest du dein ganzes Projekt mal durch clang-format 
schicken.

[Frank M. (ukw) (Moderator)]

Josef G. schrieb:
> Vielleicht könnte mal ein Moderator in dem Beitrag
> Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"
> die Tags für den C-Code anpassen?

Habe ich gerade gemacht. Jetzt ist der Zeichensalat nicht mehr schwarz, 
sondern bunt. :)

Merke: C-Tags formatieren den Text nicht neu, sondern färben lediglich 
Schlüsselwörter, Strings etc. ein.

[Uhu U. (uhu)]

Josef G. schrieb:
> Alexander F. schrieb:
>> Doch, gibt es:
>> soft/emul.c.txt
>
> Wo? Welche Zeile? Bitte nur aktuelle Version von meiner Website.
>
> In älteren Versionen von cpu.vhd und fcpu.vhd hatte ich
> eine Stelle gefunden, ist inzwischen geändert.

Josef, du bist wirklich ein Herzchen... Um Leerzeichen am Zeilenende 
reißt du dir schier ein Bein aus, aber deine chaotische 
Code-Formatierung und die apokalyptische Dokumentation geht dir völlig 
am Allerwertesten vorbei.

Du hast wirklich einen sehr ausgeprägten Sinn für Nebensächlichkeiten, 
der aber auch - ich möchte es nicht verschweigen - eine sehr positive 
Seite hat: du häst damit alle nur halbwegs vernünftigen potentiellen 
Interessenten davon ab, sich länger, als zur Erlangung eines ersten 
Eindrucks mit deinem Zeugs auseinanderzusetzen.

Wärst du Buchhalter, wärst du selbst unter Deinesgleichen als 
weltfremder Pedant verschrieen...

[Josef G. (bome)]

Uhu U. schrieb:
> Um Leerzeichen am Zeilenende reißt du dir schier ein Bein aus,

Das Thema habe nicht ich angefangen, ich habe nur reagiert.
Beitrag "Re: Befehlssatz der bo8-CPU - was ist gut, was ist schlecht"

[Uhu U. (uhu)]

Josef G. schrieb:
> Uhu U. schrieb:
>> Um Leerzeichen am Zeilenende reißt du dir schier ein Bein aus,
>
> Das Thema habe nicht ich angefangen, ich habe nur reagiert.

Oh Gott, oh Gott... Wie oft bist du im Kindergarten sitzen geblieben?

[Yalu X. (yalu) (Moderator)]

Alexander F. schrieb:
> Dazu kommt noch die unglaublich hübsche Formatierung des C-Codes:
>
>       if(st[0]=='s') { printf("\n(storno: #)  save/ Dateikennbuchstabe: ");
>       scanf("%4s",sr); name[7]=sr[0]; if(name[7]>96 && name[7]<123) {
>       datei = fopen(name,"w"); if(datei) { for (n=0; n<256; n++) {
>       for(i=0; i<32; i++) { b=mem[1][0xa000+n*32+i]; h=((b>>4) & 15)+48;
>       if(h>57) h=h+39; b=(b & 15)+48; if(b>57) b=b+39; sr[2*i]= (char) h;
>       sr[2*i+1]= (char) b; } fprintf(datei,"%s\n",sr); } fclose(datei); }}}

Ja, der Code enthält viel zu viele Leerzeichen und anderes unnützes
Zeug. Am hässlichsten ist aber der rechte Flatterrand.

So sieht optimierter und sauber formatierter C-Code aus:

if(st[0]=='s'){printf("\n(\
storno: #)  save/ Dateiken\
nbuchstabe: ");scanf("%4s"\
,sr);name[7]=sr[0];if(name\
[7]>96&&name[7]<123){datei\
=fopen(name,"w");if(datei)\
{for(n=0;n<256;n++){for(i=\
0;i<32;i++){b=mem[1][0xa00\
0+n*32+i];h=(b>>4&15)+48;i\
f(h>57)h+=39;b=(b&15)+48;i\
f(b>57)b+=39;sr[2*i]=h;sr[\
2*i+1]=b;}fprintf(datei,"%\
s\n",sr);}fclose(datei);}}}

;-)

[Rufus Τ. F. (rufus)]

Einige Variablennamen wie "datei" und "name" sind unnötig lang, hier 
würde ein "d" und ein "n" völlig ausreichen.

Man könnte auch die unnötig langen Namen der Dateifunktionen 
(fopen/fprintf/fclose) mit entsprehchenden #defines sinnvoll abkürzen, 
um das ganze gleich viel übersichtlicher zu gestalten.

Die Zeilen in Deinem Formatierungsbeispiel sind eindeutig zu kurz, das 
ist Ressourcenverschwendung.

[Frank M. (ukw) (Moderator)]

Rufus Τ. F. schrieb:
> Einige Variablennamen wie "datei" und "name" sind unnötig lang,
> hier würde ein "d" und ein "n" völlig ausreichen.
> Man könnte auch die unnötig langen Namen der Dateifunktionen
> (fopen/fprintf/fclose) mit entsprehchenden #defines sinnvoll abkürzen,
> um das ganze gleich viel übersichtlicher zu gestalten.

Sinnvolle Abkürzungen wären zum Beispiel immer der letzte Buchstabe der 
jeweiligen Funktion. Den kann man sich ganz besonders gut merken:

#define e fclose
#define f fprintf
#define n fopen

Leider kollidiert das n mit Deinem Vorschlag, n für name zu verwenden.

Aber das ist kein Problem: Du nimmst dann einfach den vorletzten 
Buchstaben statt den letzten. Also m für name... passt!

[Rufus Τ. F. (rufus)]

Ich sehe: Wir verstehen uns.

Unterscheidet sich das Resultat eigentlich in der Lesbarkeit von den 
Opcodes der CPU, die das Zeug simulieren soll?

[Josef G. (bome)]

Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.

Und funktionieren tut's.

[Rufus Τ. F. (rufus)]

Josef G. schrieb:
> Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.

O nein. Unlesbares Zeug ist unwartbar. Daß es funktioniert, kann 
durchaus Zufall sein; Fehler in so einem Gemansche findet man eh' nie.

[G. P. (gpnt)]

Josef G. schrieb:
> Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.
>
> Und funktionieren tut's.

Hast du die CPU nicht für "Hobbyisten" gemacht?
Die "Hobbyisten" die ich kenne lesen sehr gerne Programmcode...

Mal im erst:
Klar können die meisten Leute hier im Forum deinen Datensalat so 
zurechtbiegen, dass sie was damit anfangen können (z.B. Dateiendungen 
ändern oder Code formatieren). Aber wer hat schon lust darauf?
Du gehst doch auch nicht übel-riechend, ungeduscht und mit zersausten 
Klamotten zur Familienfeier, nur weil du dir sicher bist, dass dich 
deine Familie immer noch liebt.

[Cyblord -. (cyblord)]

Josef G. schrieb:
> Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.

Die Funktion ist die ALLERMINDESTE Anforderung an Code. Wer sich allein 
damit zufrieden gibt, stellt keine besonderen Ansprüche an sich.

[Yalu X. (yalu) (Moderator)]

Rufus Τ. F. schrieb:
> Josef G. schrieb:
>> Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.
>
> O nein. Unlesbares Zeug ist unwartbar.

Für Josef vielleicht nicht. Und außer ihm wird vermutlich niemals jemand
Änderungen an dem Code vornehmen wollen.

Rufus Τ. F. schrieb:
> Daß es funktioniert, kann durchaus Zufall sein

Ob der Code funktioniert, kann außer Josef niemand beurteilen, da keiner
außer ihm weiß, was dessen Funktion überhaupt sein soll.

Deswegen sehe ich da keinerlei Probleme ;-)

[Falk B. (falk)]

@ Josef G. (bome) Benutzerseite

>Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.

OMG! Und da wir dich kennen, wissen wir, daß du das ernst meinst!
Mein Beileid!

[Le X. (lex_91)]

Josef G. schrieb:
> Entscheidend ist nicht die Lesbarkeit, sondern die Funktion.

In den 60igern des letzten Jahrhunderts vielleicht.

[Josef G. (bome)]

Das wegen seiner Formatierung kritisierte Programmstück:

      if(st[0]=='s') { printf("\n(storno: #)  save/ Dateikennbuchstabe: ");        
      scanf("%4s",sr); name[7]=sr[0]; if(name[7]>96 && name[7]<123) {              
      datei = fopen(name,"w"); if(datei) { for (n=0; n<256; n++) {                 
      for(i=0; i<32; i++) { b=mem[1][0xa000+n*32+i]; h=((b>>4) & 15)+48;           
      if(h>57) h=h+39; b=(b & 15)+48; if(b>57) b=b+39; sr[2*i]= (char) h;          
      sr[2*i+1]= (char) b; } fprintf(datei,"%s\n",sr); } fclose(datei); }}}

anders formatiert:

      if(st[0]=='s') {

          printf("\n(storno: #)  save/ Dateikennbuchstabe: ");
          scanf("%4s",sr); name[7]=sr[0];

          if(name[7]>96 && name[7]<123) {

              datei = fopen(name,"w");

              if(datei) {

                  for (n=0; n<256; n++) {

                      for(i=0; i<32; i++) {

                          b=mem[1][0xa000+n*32+i];
                          h=((b>>4) & 15)+48; if(h>57) h=h+39;
                          b=( b     & 15)+48; if(b>57) b=b+39;
                          sr[2*i]= (char) h; sr[2*i+1]= (char) b;
                          }

                      fprintf(datei,"%s\n",sr);
                      }

                  fclose(datei);
                  }
              }
          }

Funktion:
Wenn aus dem Menü "save" ausgewählt wurde, wird ein Dateikennbuchstabe
erfragt und der Inhalt der Seite E des Text-RAM als Hexdump gespeichert.

Das Programmstück ist ein winziger Teil des Gesamtprogramms.
Wenn man sich von der Funktion überzeugt hat, kommt man vielleicht auch
zu dem Schluss, dass es besser ist, das Programmstück in kompakter Form
zu speichern, weil es sonst den Gesamtcode nur unnötig aufbläht.

[Axel S. (a-za-z0-9)]

Frank M. schrieb:
> Aber das ist kein Problem: Du nimmst dann einfach den vorletzten
> Buchstaben statt den letzten. Also m für name... passt!

ROTFL BTC

[Rufus Τ. F. (rufus)]

Josef G. schrieb:
> Wenn man sich von der Funktion überzeugt hat, kommt man vielleicht auch
> zu dem Schluss, dass es besser ist, das Programmstück in kompakter Form
> zu speichern, weil es sonst den Gesamtcode nur unnötig aufbläht.

Nein. Tut man nicht.

So kann man das wenigestens ein bisschen lesen.

Das ändert allerdings auch nichts an der unterirdischen Qualität des 
"Codes".

> if(name[7]>96 && name[7]<123) {

Was bedeuten diese "magic numbers"? Warum 96? Warum nicht 43?

Mir ist klar, daß das ASCII-Codes sind. Aber warum schreibst Du dann 
nicht die zugehörigen Zeichen als Zeichenkonstanten da hin?
96 ist '@'. 123 ist '{'. Der Compiler versteht auch das, das ist 
äquivalent.

Und was ist mit Großbuchstaben?

Warum verwendest Du nicht einfach die Standardfunktion isalpha?

Das könnte man einfach so lesen:

> if (isalpha(name[7])) {

(Was passiert eigentlich mit name[0] bis name[6]? Ach ... nee, ich will 
das doch besser nicht wissen)

[Josef G. (bome)]

Rufus Τ. F. schrieb:
> Was passiert eigentlich mit name[0] bis name[6]?

Steht im Kopf bei der Variablen-Vereinbarung:

name[9]="emtext-0";

[Josef G. (bome)]

Rufus Τ. F. schrieb:
> Und was ist mit Großbuchstaben?

Da auf meiner Website die Dateien emtext-a, emtext-b, emtext-c
im Verzeichnis soft mitgeliefert werden, sollte dem Anwender
klar sein, dass Kleinbuchstaben erwartet werden.

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Für welches Problem noch mal ist eigentlich diese Lösung gedacht?

"Wenn das die Lösung sein soll, dann hätte ich gerne mein Problem 
wieder!"
(Beliebter Spruch bei meinen Entwicklerkollegen)

[Gu. F. (mitleser)]

Wolfgang R. schrieb:
> Für welches Problem noch mal ist eigentlich diese Lösung gedacht?

Man könnte MS fragen ob die ihre nächste Windows Version damit bauen 
wollen.
Das wäre dann das garantiert sicherste BS aller Zeiten.

[Josef G. (bome)]

Josef G. schrieb:
> Rufus Τ. F. schrieb:
>> Was passiert eigentlich mit name[0] bis name[6]?
>
> Steht im Kopf bei der Variablen-Vereinbarung:
>

> name[9]="emtext-0";
>

Sollte vollständig natürlich heissen

char name[9]="emtext-0";

[Josef G. (bome)]

Da die Akzeptanz des Emulationsprogramms offenbar vor allem
an der rechteckigen Formatierung eines kleinen Programmteils
scheiterte, habe ich diese nun geändert.

Zu der rechteckigen Formatierung war es vor sehr langer
Zeit gekommen, als ich den Quelltext ausdrucken wollte
und deshalb die Textbreite reduziert habe.

http://www.bo8h.de/Downloads/

[Alexander F. (alexf91)]

Josef G. schrieb:
> Da die Akzeptanz des Emulationsprogramms offenbar vor allem
> an der rechteckigen Formatierung eines kleinen Programmteils
> scheiterte, habe ich diese nun geändert.

Jetzt fehlt noch ein Makefile und normale Dateinamen.

[Josef G. (bome)]

Alexander F. schrieb:
> Makefile

Wie man das Programm compiliert, und überhaupt eine
ausführliche Anleitung zum Programm, steht auf der
Seite Emul.txt.

Wem das Testen der Beispielprogramme in emtext-a, emtext-b,
emtext-c zu aufwendig ist, der schaue sich weiter unten den
Abschnitt zu Conway's Game of Life an.

[Rufus Τ. F. (rufus)]

Josef G. schrieb:
> offenbar vor allem an der rechteckigen Formatierung eines
> kleinen Programmteils scheiterte,

Nein. Du hast die Kritik nicht verstanden.

[Falk B. (falk)]

@ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite

>> offenbar vor allem an der rechteckigen Formatierung eines
>> kleinen Programmteils scheiterte,

>Nein. Du hast die Kritik nicht verstanden.

Und du hast immer noch nicht Josef's medizinisches, praktisch unlösbares 
Problem verstanden.

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

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

Beitrag "Re: 8bit-Computing mit FPGA"

Beitrag "Re: Ein Vorschlag zur Intervall-Arithmetik"

[Uhu U. (uhu)]

Alexander F. schrieb:
> Josef G. schrieb:
>> Da die Akzeptanz des Emulationsprogramms offenbar vor allem
>> an der rechteckigen Formatierung eines kleinen Programmteils
>> scheiterte, habe ich diese nun geändert.
>
> Jetzt fehlt noch ein Makefile und normale Dateinamen.

Du bist wirklich maßlos. Jetzt ist Josef über seinen Schatten gesprungen 
und DU forderst schon wieder neue sportliche Höchstleistungen.

So geht das nicht, ein alter Mann ist kein D-Zug...

[Josef G. (bome)]

Alexander F. schrieb:
> normale Dateinamen

cp emul.c.txt emul.c
cp coka.txt coka
cp teca.txt teca

oder dasselbe mit mv statt cp.

[Uhu U. (uhu)]

Yalu X. schrieb:
> Dass ein Compiler

Welcher Compiler?

[Guido B. (guido-b)]

Uhu U. schrieb:
> Yalu X. schrieb:
>> Dass ein Compiler
>
> Welcher Compiler?

Öhem, könntest du mal richtig zitieren? War das ein Beitrag vor
20 Jahren?

[Uhu U. (uhu)]

Guido B. schrieb:
> Öhem, könntest du mal richtig zitieren? War das ein Beitrag vor
> 20 Jahren?

Öhem, bist du zu doof, den Rückwärtslink zu benutzen?

[Lars R. (lrs)]

Falk B. schrieb:
> @ Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
>
>>Nein. Du hast die Kritik nicht verstanden.
>
> Und du hast immer noch nicht Josef's medizinisches, praktisch unlösbares
> Problem verstanden.

Jedoch hat Rufus ganz sicher verstanden, dass Du der Ansicht bist, dass 
er das noch nicht verstanden hat. Das hast Du nur noch nicht verstanden. 
Deshalb schreibst Du immer wieder das Gleiche. Ein wenig so wie Josef.

[S. R. (svenska)]

Josef G. schrieb:
> Alexander F. schrieb:
>> normale Dateinamen
> cp emul.c.txt emul.c
> cp coka.txt coka
> cp teca.txt teca
> oder dasselbe mit mv statt cp.

Gute Idee. Warum lieferst du deinen Code nicht gleich auf diese Weise 
aus?

[Yalu X. (yalu) (Moderator)]

Uhu U. schrieb:
> Welcher Compiler?

GCC. Frag mich aber (mehr als eineinhalb Jahre danach) nicht nach der
Version.

[Guido B. (guido-b)]

Uhu U. schrieb:
> Guido B. schrieb:
>> Öhem, könntest du mal richtig zitieren? War das ein Beitrag vor
>> 20 Jahren?
>
> Öhem, bist du zu doof, den Rückwärtslink zu benutzen?

Öhem, sorry, das war in der Tat das Problem. Habs gefunden.

[Josef G. (bome)]

Die C-Quelldateien sind jetzt ohne Zusatz-Endung .txt

http://www.bo8h.de/Downloads/

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Josef G. schrieb:
> Die C-Quelldateien sind jetzt ohne Zusatz-Endung .txt

Endlich ist es so weit, und wir können durchstarten! Jetzt wird sich bo8 
durchsetzen, und in zwei Jahren kennt keiner mehr ARM, AVR und x86.

[Alexander F. (alexf91)]

Josef G. schrieb:
> Die C-Quelldateien sind jetzt ohne Zusatz-Endung .txt

Und warum benennst du die VHDL-Dateien nicht um?
Irgendwo kannst du in deinem Betriebssystem einstellen, welcher Dateityp 
mit welchem Programm geöffnet wird.

[Falk B. (falk)]

http://www.bo8h.de/Argumente/

"Angeblich leiden manche Menschen an Dyskalkulie. "

Und andere an, ähh. Ach was solls, das hatten wir alles schon ein 
Dutzend mal.

"Die Bailey-Borwein-Plouffe-Formel zur Berechnung von Pi ist
ein Argument für die Sonderstellung des Hexadezimalsystems."

WOW!

https://de.wikipedia.org/wiki/Bailey-Borwein-Plouffe-Formel

Na dann ist das Hexadezimalsystem ja ger nicht mehr aufzuhalten!

Naja, das ist vielleicht kein sonderlich intersantes Projekt für 
Techniker, dafür umso mehr für Psychiologen.

[Josef G. (bome)]

Vielleicht hat ja die umständliche Zeicheneingabe bei der alten Version
des Emulationsprogramms den Einen oder Anderen abgeschreckt.
Bei der neuen Version ist sie komplett neu.

Wer sich nicht für das Projekt interessiert, interessiert sich
vielleicht trotzdem für meine Implementierung von Game of Life.

Die Beschreibung dazu steht auf der Seite Emul.txt
am Ende der Beschreibung des Emulationsprogramms.

Man braucht dazu auch die Datei teca im aktuellen Verzeichnis.

Zur Eingabe des Kommandos 1.GOL drückt man 1^gol und dann Return.

Zuvor wechselt man mit shift-e in die Seite E und erstellt dort
im Bereich der ersten 64 Zeilen ein wenig Text. Zum angenehmeren
Arbeiten schiebt man mit shift-v Text und Cursor ein paar Zeilen
nach unten. Der Text dient als Startbild. Mit shift-e kehrt man
in die Seite C zurück und gibt dort das Kommando ein.

Nach Eingabe-Aufforderung SIZE drückt man 0 oder 1,
nach Eingabe-Aufforderung RULE drückt man 0.
Iterationen führt man aus mit Taste ^.

[Robert L. (lrlr)]

ich hab mir deinen Code NICHT angeschaut, nur das 1. beste File 
genommen:

x Beliebiges Beispiel:

t1oup  <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvs) or
          (s7 and s6 and z5 and z4 and z3 and z2 and z1 and s0 and ccvz) or
          (s7 and s6 and z5 and z4 and z3 and z2 and s1 and z0 and ccus) or
          (s7 and s6 and z5 and z4 and z3 and z2 and s1 and s0 and ccuz) or
          (s7 and s6 and z5 and z4 and z3 and s2 and z1 and z0 and ccas) or
          (s7 and s6 and z5 and z4 and z3 and s2 and z1 and s0 and ccaz) or
          (s7 and s6 and z5 and z4 and z3 and s2 and s1 and z0 and ccks) or
          (s7 and s6 and z5 and z4 and z3 and s2 and s1 and s0 and cckz) or
          (s7 and s6 and z5 and z4 and s3               and s0 and ccsz) or
          (s7 and s6 and z5 and z4 and s3        and s1        and ccsz) or
          (s7 and s6 and z5 and z4 and s3 and s2               and ccsz) ;
t1our  <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvz) or
          (s7 and s6 and z5 and z4 and z3 and z2 and z1 and s0 and ccvs) or
          (s7 and s6 and z5 and z4 and z3 and z2 and s1 and z0 and ccuz) or
          (s7 and s6 and z5 and z4 and z3 and z2 and s1 and s0 and ccus) or
          (s7 and s6 and z5 and z4 and z3 and s2 and z1 and z0 and ccaz) or
          (s7 and s6 and z5 and z4 and z3 and s2 and z1 and s0 and ccas) or
          (s7 and s6 and z5 and z4 and z3 and s2 and s1 and z0 and cckz) or
          (s7 and s6 and z5 and z4 and z3 and s2 and s1 and s0 and ccks) or
          (s7 and s6 and z5 and z4 and s3               and s0 and ccss) or
          (s7 and s6 and z5 and z4 and s3        and s1        and ccss) or
          (s7 and s6 and z5 and z4 and s3 and s2               and ccss) ;

Bin weiterhin schwer beeindruckt wie man sowas versteht und vorallem wie 
man eine Woche nachdem man es geschrieben hat, noch weiß was es macht.. 
geschweige denn einen Fehler finden würde..

aber: https://en.wikipedia.org/wiki/Duplicate_code

Falls du irgendwann mal in die Geschichtsbücher eingehen solltest, dann 
als der Mensch der mit maximalstem Aufwand das minnimalste Problem 
gelöst hast..



zum Editor: es gibt Telefonbuch dicke Threads über "ist vi besser als 
notepad"  bei deinem Editor wäre das ein Einzeiler ...

[Josef G. (bome)]

Robert L. schrieb:
> Duplicate_code

Schau mal genau hin:

t1oup  <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvs) or
t1our  <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvz) or

[Yalu X. (yalu) (Moderator)]

Josef G. schrieb:
> Schau mal genau hin:t1oup  <= (s7 and s6 and z5 and z4 and z3 and z2 and
> z1 and z0 and ccvs) or
> t1our  <= (s7 and s6 and z5 and z4 and z3 and z2 and z1 and z0 and ccvz)
> or

Ja, alle Operanden bis auf den letzten (also 89%) sind gleich, deswegen
Roberts Hinweis auf duplicate Code.

[Robert L. (lrlr)]

hier auch ein schönes beispiel

 punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b & 128) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &  64) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &  32) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &  16) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &   8) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &   4) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &   2) k=k+4;

   punkt[k].x = h; punkt[k+1].x = h+1; punkt[k+2].x = h; punkt[k+3].x = h+1;
   h=h+2; if(b &   1) k=k+4; }

[Cyblord -. (cyblord)]

Bin ich hier in der Rubrik "Quellcode aus der Hölle" gelandet?

[Robert L. (lrlr)]

Ich weiß nicht wie man das höflich formuliert. Aber jemand der solchen 
Code produziert und gleichzeitig eine Programmiersprache erfindet.

Ist halt schon irgendwie so, als ob jemand der glaubt Elektronen wären 
an Fixstellen in einem Atom würde versuchen einem Physiker die Welt zu 
erklären..

[Alexander F. (alexf91)]

Ich finde im ganzen Code keine Funktionen und der Inhalt von mass.c, 
dass.c und emul.c ist auch zu ca. 50% gleich.

Im VHDL Code ist es noch viel schlimmer. Da gibt es mehrere Dateien, die 
zu mehr als 90%, teilweise sogar 100% gleich sind.

[Le X. (lex_91)]

Robert L. schrieb:
> Aber jemand der solchen Code produziert und gleichzeitig eine
> Programmiersprache erfindet

Es geht ja nicht nur um den Code. Das iet ja nur ein Bruchstück des 
Problems.
Hier passt halt garnichts: der Code, das VHDL, die Sprache, das Konzept 
an sich, die Namen der Register und Befehle, die Doku.
Und allen vorran: die völlige Beratungsresistenz.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Robert L. schrieb:
> Bin weiterhin schwer beeindruckt wie man sowas versteht und vorallem wie
> man eine Woche nachdem man es geschrieben hat, noch weiß was es macht..
> geschweige denn einen Fehler finden würde..

Die von Josef für das von Dir zitierte Beispiel gewählte 
tabellenähnliche Form halte ich im konkreten Fall sogar für sehr 
übersichtlich, da die Art und Weise der Befehldekodierung ersichtlich 
wird.

> aber: https://en.wikipedia.org/wiki/Duplicate_code

Der Wikipedia-Artikel bezieht sich ausschließlich auf Duplicate Code im 
Bereich der Softwareentwicklung. In Deinem Beispiel geht es jedoch um 
eine Hardwarebeschreibung, bei der eine explizitere Schreibweise in 
manchen Fällen durchaus sinnvoll sein kann. Das Beispiel ist eben 
einfach eine Darstellung in disjunktiver Normalform. Ich sehe auch 
nicht, dass die Zusammenfassung des gemeinsamen Anteils "s7 and s6 and 
z5 and z4 and z3" die Lesbarkeit verbessern würde.

Der ansonsten ausgesprochenen Kritik an Josefs Projekt, Quellcode, 
Struktur, Dokumentation schließe ich mich natürlich an und habe solche 
auch selbst schon wiederholt geübt. Aber es bringt einfach nichts.

[(prx) A. K. (prx)]

Andreas S. schrieb:
> Die von Josef für das von Dir zitierte Beispiel gewählte
> tabellenähnliche Form halte ich im konkreten Fall sogar für sehr
> übersichtlich, da die Art und Weise der Befehldekodierung ersichtlich
> wird.

Die Übersichtlichkeit leidet eher darunter, dass es zum "Finde den 
Unterschied!" wird. Die Variablen sind sich optisch zu ähnlich.

[Josef G. (bome)]

Alexander F. schrieb:
> und der Inhalt von mass.c,
> dass.c und emul.c ist auch zu ca. 50% gleich.

Wäre es besser gewesen, ich hätte den gemeinsamen Teil nur einmal
im Download-File gespeichert und würde dann in der Dokumentation
zu den einzelnen Programmen beschreiben, wie man den gemeinsamen
Teil in die einzelnen Dateien hinein-kopieren muss?

Alexander F. schrieb:
> Im VHDL Code ist es noch viel schlimmer.
> Da gibt es mehrere Dateien, die zu mehr als 90%,

Hier gilt dasselbe wie beim C-Code.

> teilweise sogar 100% gleich sind.

Ist richtig bei ks3a.vhd und ks3e.vhd für das S3A- und
S3E-Board und hat den Grund, dass es die Dokumentation
vereinfacht und übersichtlicher macht.

[Alexander F. (alexf91)]

Josef G. schrieb:
> Wäre es besser gewesen, ich hätte den gemeinsamen Teil nur einmal
> im Download-File gespeichert und würde dann in der Dokumentation
> zu den einzelnen Programmen beschreiben, wie man den gemeinsamen
> Teil in die einzelnen Dateien hinein-kopieren muss?

Nein.
C unterstützt Funktionen: http://www.c-howto.de/tutorial/funktionen/

[Josef G. (bome)]

Robert L. schrieb:
> hier auch ein schönes beispiel

Dann mach doch mal einen Vorschlag, wie du es geschrieben hättest.

Ist übrigens ein zeitkritischer Teil des Programms,
wo man keine Schleifen gebrauchen kann.

[Josef G. (bome)]

Alexander F. schrieb:
> Nein.
> C unterstützt Funktionen: http://www.c-howto.de/tutorial/funktionen/

Und wie kriegt man den Code für die gemeinsame Funktion
in die drei einzelnen Programme?

[Alexander F. (alexf91)]

Josef G. schrieb:
> Alexander F. schrieb:
>> Nein.
>> C unterstützt Funktionen: http://www.c-howto.de/tutorial/funktionen/
>
> Und wie kriegt man den Code für die gemeinsame Funktion
> in die drei einzelnen Programme?

Du hast eine CPU und einen Emulator geschrieben, weißt aber nicht, wie 
man das macht? Sehr seltsam...

gcc -c function.c
gcc -c emul.c
gcc -o emul emul.o function.o

[Josef G. (bome)]

Alexander F. schrieb:
> weißt aber nicht, wie man das macht? Sehr seltsam...

Nein, das wusste ich tatsächlich nicht,
und ich verstehe es auch nicht.

Und wie sähe nach deinem Vorschlag die Dokumentation aus?
Wäre die nicht viel komplizierter als meine Dokumentation?

Und der Ablauf für den Anwender wäre auch komplizierter.

[Robert L. (lrlr)]

Josef G. schrieb:
> Robert L. schrieb:
>> hier auch ein schönes beispiel
>
> Dann mach doch mal einen Vorschlag, wie du es geschrieben hättest.
>
> Ist übrigens ein zeitkritischer Teil des Programms,
> wo man keine Schleifen gebrauchen kann.

zeitkritisch...

ok, lassen wird das mal einfach so stehen...


mit einem makro vielleicht.. dass du 8 mal aufrufst
der compilierte code wäre 100% der selbe

[Falk B. (falk)]

@ Le X. (lex_91)

>Es geht ja nicht nur um den Code. Das iet ja nur ein Bruchstück des
>Problems.
>Hier passt halt garnichts: der Code, das VHDL, die Sprache, das Konzept
>an sich, die Namen der Register und Befehle, die Doku.
>Und allen vorran: die völlige Beratungsresistenz.

Alles schon bekannt.

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

[Robert L. (lrlr)]

Josef G. schrieb:
> Wäre es besser gewesen, ich hätte den gemeinsamen Teil nur einmal
> im Download-File gespeichert und würde dann in der Dokumentation
> zu den einzelnen Programmen beschreiben, wie man den gemeinsamen
> Teil in die einzelnen Dateien hinein-kopieren muss?


#include  "function.c"

macht das selbe wie dein copy&past

und nein, das ist nicht "super", es beantwortet nur deine Frage..

[Josef G. (bome)]

Robert L. schrieb:
> #include  "function.c"

Ok, das ginge. Aber auch mit dieser Lösung müsste der
Anwender eine zusätzliche Datei ins aktuelle Verzeichnis
laden, und man müsste in der Dokumentation darauf hinweisen.

[Robert L. (lrlr)]

Josef G. schrieb:
> Robert L. schrieb:
>> #include  "function.c"
>
> Ok, das ginge. Aber auch mit dieser Lösung müsste der
> Anwender eine zusätzliche Datei ins aktuelle Verzeichnis
> laden, und man müsste in der Dokumentation darauf hinweisen.

keine Ahnung was du damit meinst
kannst ja

#include  "../shrd/function.c"

machen..


mein "Vorschlag" wäre, wenn überhaupt nur ein TEIL der Lösung,
und auch nur exemplarisch..

[Wolfgang R. (Firma: www.wolfgangrobel.de) (mikemcbike)]

Wenn DAS die Lösung sein soll, dann hätte ich gerne mein Problem zurück!

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Josef G. schrieb:
> Ok, das ginge. Aber auch mit dieser Lösung müsste der
> Anwender eine zusätzliche Datei ins aktuelle Verzeichnis
> laden, und man müsste in der Dokumentation darauf hinweisen.

Wie konnte sich dann z.B. Linux durchsetzen, bei dem alleine der Kernel 
schon aus etlichen tausend Dateien besteht?

Deine Argumentation ist vollkommener Unfug und eigentlich nur der 
Tatsache geschuldet, dass Du bis vor wenigen Tagen der Überzeugung 
warst, man müsse an sämtliche Dateinamen noch ein ".txt" anhängen, und 
der Verbreitung von Einzeldateien statt z.B. kompletter ZIP- oder 
tar-Archive, in denen sich der gesamte Projektbaum einschließlich 
Buildskripten, Makefile und Projektdateien der Entwicklungsumgebung(en) 
befindet. Oder eben gleich die Bereitstellung auf einem 
Versionskontrollsystem wie z.B. Git oder Subversion. Auch hierfür gibt 
es Unmengen an freiverfügbaren Diensten, und natürlich kann man auch 
seinen eigenen Server ins Internet "stellen".

[Uhu U. (uhu)]

Andreas S. schrieb:
> und der Verbreitung von Einzeldateien statt z.B. kompletter ZIP- oder
> tar-Archive, in denen sich der gesamte Projektbaum einschließlich
> Buildskripten, Makefile und Projektdateien der Entwicklungsumgebung(en)
> befindet.

Josef scheint ein neues Hobby entdeckt zu haben: den Sprung über den 
eigenen Schatten.

Hier: http://www.bo8h.de/Downloads/ gibts ein zip-Archiv mit vielen 
*.txt-Dateien, aber auch etlichen, ohne das obligatorische .txt am Ende 
- er scheint sich also doch noch etwas schwer zu tun, mit der neuen 
Sportart.

Vollends grotesk ist der Teilbaum __MACOSX: dort sind die *.txt-Dateien 
in einem Format abgespeichert, das mit "plain ASCII" herzlich wenig zu 
tun hat. Z.B. verweigert der Linux-Editor Pluma das Öffnen dieser 
Dateien von vorn herein, weil ungültige Zeichen drin stehen.

Zusammenfassend kann man wohl sagen, dass Josef auf dem Weg ist, das 
Konzept der Dateiendung zu begreifen. Man sieht an dem zip-Verzeichnis 
ganz deutlich, wie er noch immer mit sich ringt...

Aber egal, er hat ja erst mal ein ganz fundamentales Problem zu lösen:

Josef, du musst einfach mehr Anlauf nehmen - Überlichtgeschwindigkeit 
muss man schon haben, wenn man den Schatten überwinden will, ohne über 
den Schatten der eigenen Beine zu stolpern.

[Josef G. (bome)]

Uhu U. schrieb:
> Vollends grotesk ist der Teilbaum __MACOSX:

Das Verzeichnis ist offenbar ein Artefakt des Kompressions-
Verfahrens, ich weiss nicht wo das herkommt.

Das originale Verzeichnis bo8h-2018-04-22 enthält die Datei
version.txt und die Unterverzeichnisse info, soft, vhdl, und
sonst nichts. Daraus habe ich auf meinem Apple die zip-Datei
erstellt. Wenn ich die zip-Datei auf meinem Apple entpacke,
erhalte ich wieder das Original-Verzeichnis.

Wenn ich die zip-Datei auf meinem Linux-PC entpacke, finde
ich auch dieses merkwürdige __MACOSX -Verzeichnis. Ich habe
es auf meinem Linux-PC einfach gelöscht, und alles scheint
dann normal zu funktionieren.

[Josef G. (bome)]

Aber anscheinend haben ja auch andere Leute hier die zip-Datei
auf ihrem Rechner entpackt. Merkwürdig, dass niemand sonst von
diesem merkwürdigen __MACOSX -Verzeichnis berichtet hat.

[Alexander F. (alexf91)]

Josef G. schrieb:
> Aber anscheinend haben ja auch andere Leute hier die zip-Datei
> auf ihrem Rechner entpackt. Merkwürdig, dass niemand sonst von
> diesem merkwürdigen __MACOSX -Verzeichnis berichtet hat.

Ich bin mir ziemlich sicher, dass fast jeder dieses Verzeichnis gesehen 
hat. Es ist einfach nur das kleinste Problem bei deinem Projekt, also 
hat es niemand erwähnt.
Das Verzeichnis enthält irgendwelche Metadaten und kann problemlos 
entfernt werden:
https://stackoverflow.com/a/13665552

[Robert L. (lrlr)]

__MACOSX

enthält jede ZIP Datei die auf einem iMac erstellt wurde

google liefert dazu fast 1000000 Einträge..

[Josef G. (bome)]

Danke für die Info.

Habe schon befürchtet, ich hätte ein Virus verbreitet.