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