Discussion:
Zaks, Programming the Z80
(zu alt für eine Antwort)
Nils M Holm
2019-11-19 19:15:42 UTC
Permalink
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von

Rodney Zaks, "Programming the Z80"

uebrig? Als PDF habe ich es, aber nachschlagen auf Papier ist
einfach bequemer! Ich will es auch nicht geschenkt haben!

Ich schreibe gerade CP/M code fuer einen Amstrad NC100 und
meine Z80-Kenntnisse sind etwas rostig. :)
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Rainer Knaepper
2019-11-20 09:04:00 UTC
Permalink
Post by Nils M Holm
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von
Rodney Zaks, "Programming the Z80"
uebrig?
Sorry, weitestgehend zerfleddert, vergilbt und mit Notizen
vollgekrakelt. Mithin nicht vorzeigbar...


Rainer
--
Post by Nils M Holm
scsi hat einfach nicht das richtige preis/leistungsverhaeltnis.
Ja, das Argument kommt immer, weil es das einzige pro IDE ist,
was stimmt.
(Juergen Thorweger in de.comp.hardware.cpu+mainboard.intel)
Nils M Holm
2019-11-20 09:34:45 UTC
Permalink
Post by Rainer Knaepper
Post by Nils M Holm
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von
Rodney Zaks, "Programming the Z80"
uebrig?
Sorry, weitestgehend zerfleddert, vergilbt und mit Notizen
vollgekrakelt. Mithin nicht vorzeigbar...
Das uebliche Schicksal eines exzellenten Nachschlagewerks!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Kay Martinen
2019-11-20 13:26:41 UTC
Permalink
Post by Nils M Holm
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von
Rodney Zaks, "Programming the Z80"
Sorry, nur die 6502 Ausgaben.
Post by Nils M Holm
uebrig? Als PDF habe ich es, aber nachschlagen auf Papier ist
einfach bequemer!
e-Book?
Post by Nils M Holm
Ich schreibe gerade CP/M code fuer einen Amstrad NC100 und
meine Z80-Kenntnisse sind etwas rostig. :)
Eine Opcode-tabelle reicht nicht? :) Sind doch nicht so viele...


Kay
--
Sent via SN (Eisfair-1)
Nils M Holm
2019-11-20 15:02:44 UTC
Permalink
Post by Kay Martinen
e-Book?
Blaettern in E-Books macht immernoch keinen Spass! Ich finde
Sachen 10x scheller auf Papier.
Post by Kay Martinen
Post by Nils M Holm
Ich schreibe gerade CP/M code fuer einen Amstrad NC100 und
meine Z80-Kenntnisse sind etwas rostig. :)
Eine Opcode-tabelle reicht nicht? :) Sind doch nicht so viele...
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!

Aber: ja, eine Tabelle waere ein Anfang!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Bernd Laengerich
2019-11-20 15:26:53 UTC
Permalink
Post by Nils M Holm
Aber: ja, eine Tabelle waere ein Anfang!
Viele zum Aussuchen:

http://www.z80.info/#BASICS_INST

Bernd
Nils M Holm
2019-11-20 17:58:27 UTC
Permalink
Post by Bernd Laengerich
Post by Nils M Holm
Aber: ja, eine Tabelle waere ein Anfang!
http://www.z80.info/#BASICS_INST
Sieht vielversprechend aus! Danke!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
olaf
2019-11-20 16:04:27 UTC
Permalink
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
Ich glaub der war sogar doppelriesig weil es eine grosse Menge von
"geheimen" Instruktionen gab.

Mein Buch ist im uebrigen im guten Zustand und wird nicht
hergegeben. :)

Olaf
Gerrit Heitsch
2019-11-20 16:30:57 UTC
Permalink
Post by olaf
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
Ich glaub der war sogar doppelriesig weil es eine grosse Menge von
"geheimen" Instruktionen gab.
Die gabs auch beim 6502.

Sehe ich das richtig, daß der Z80 keine absolute Adressierung hat
sondern immer indirekt über Register gehen muss, oder habe ich was in
der Befehlsreferenz überlesen?

Gerrit
Peter Heitzer
2019-11-20 17:10:41 UTC
Permalink
Post by Gerrit Heitsch
Post by olaf
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
Ich glaub der war sogar doppelriesig weil es eine grosse Menge von
"geheimen" Instruktionen gab.
Die gabs auch beim 6502.
Sehe ich das richtig, daß der Z80 keine absolute Adressierung hat
sondern immer indirekt über Register gehen muss, oder habe ich was in
der Befehlsreferenz überlesen?
Register sind immer im Spiel, aber Quelle oder Ziel kann eine absolute
Adresse sein.
ld (1234),a
z.B. speichert den Inhalt des Akkus an Adresse 1234
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Gerrit Heitsch
2019-11-20 17:21:02 UTC
Permalink
Post by Peter Heitzer
Post by Gerrit Heitsch
Post by olaf
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
Ich glaub der war sogar doppelriesig weil es eine grosse Menge von
"geheimen" Instruktionen gab.
Die gabs auch beim 6502.
Sehe ich das richtig, daß der Z80 keine absolute Adressierung hat
sondern immer indirekt über Register gehen muss, oder habe ich was in
der Befehlsreferenz überlesen?
Register sind immer im Spiel, aber Quelle oder Ziel kann eine absolute
Adresse sein.
ld (1234),a
z.B. speichert den Inhalt des Akkus an Adresse 1234
Ok, dann hatte ich das überlesen. Geht auch absolut indiziert wie beim
6502 mit z.B.

STA $4000,Y

Speichert den Inhalt des Akkus in der Adresse die sich aus der Addition
von $4000 mit dem Inhalt des Y-Registers ergibt.

Gerrit
Nils M Holm
2019-11-20 18:06:04 UTC
Permalink
Ok, dann hatte ich das ?berlesen. Geht auch absolut indiziert wie beim
6502 mit z.B.
STA $4000,Y
Speichert den Inhalt des Akkus in der Adresse die sich aus der Addition
von $4000 mit dem Inhalt des Y-Registers ergibt.
16-Bit-Adresse plus 8-Bit-Register kann der Z80 nicht, dafuer aber
16-Bit-Register plus 8-bit displacement:

ld (ix+n),a

speichert A in der Speicherzelle mit der Adresse IX (16-bit) + n (8-bit).
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Ignatios Souvatzis
2019-11-20 19:48:12 UTC
Permalink
Post by Nils M Holm
Ok, dann hatte ich das ?berlesen. Geht auch absolut indiziert wie beim
6502 mit z.B.
STA $4000,Y
Speichert den Inhalt des Akkus in der Adresse die sich aus der Addition
von $4000 mit dem Inhalt des Y-Registers ergibt.
16-Bit-Adresse plus 8-Bit-Register kann der Z80 nicht, dafuer aber
ld (ix+n),a
speichert A in der Speicherzelle mit der Adresse IX (16-bit) + n (8-bit).
Kurz: zu jedem 8080-Befehl, der M benutzt (bzw. in z80-syntax: (hl) gibt
es einen prefix DD bzw. FD, der daraus stattdessen IX bzw. IY benutzt und
als 3. Byte (WIMRE) den Addressoffset.

-is
--
A medium apple... weighs 182 grams, yields 95 kcal, and contains no
caffeine, thus making it unsuitable for sysadmins. - Brian Kantor
Andreas Kohlbach
2019-11-20 20:10:35 UTC
Permalink
Post by Peter Heitzer
Post by Gerrit Heitsch
Post by olaf
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
Ich glaub der war sogar doppelriesig weil es eine grosse Menge von
"geheimen" Instruktionen gab.
Die gabs auch beim 6502.
Sehe ich das richtig, daß der Z80 keine absolute Adressierung hat
sondern immer indirekt über Register gehen muss, oder habe ich was in
der Befehlsreferenz überlesen?
Register sind immer im Spiel, aber Quelle oder Ziel kann eine absolute
Adresse sein.
ld (1234),a
z.B. speichert den Inhalt des Akkus an Adresse 1234
Z80 Opcode finde ich sehr elegant im Gegensatz des des 6502. Wo der 6502
LDA und STA braucht, macht der Z80 beides mit LD.

Auch scheint der Z80 "Primitives" zu haben. Man füllt zum Beispiel für
eine Suche nach einem Wert im Speicher mehrere Register mit Werten und
ruft einen Opcode (kein Firmwarecode, wie beim C64) auf. Der läuft dann
solange, bis der Wert gefunden oder der Range überrannt wurde. Keine
Ahnung, ob der m86k das schon konnte. Sonst dürfte der 8086 der Erste
gewesen sein, der das konnte.
--
Andreas

https://news-commentaries.blogspot.com/
Gerrit Heitsch
2019-11-20 20:15:31 UTC
Permalink
Post by Andreas Kohlbach
Post by Peter Heitzer
Post by Gerrit Heitsch
Post by olaf
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
Ich glaub der war sogar doppelriesig weil es eine grosse Menge von
"geheimen" Instruktionen gab.
Die gabs auch beim 6502.
Sehe ich das richtig, daß der Z80 keine absolute Adressierung hat
sondern immer indirekt über Register gehen muss, oder habe ich was in
der Befehlsreferenz überlesen?
Register sind immer im Spiel, aber Quelle oder Ziel kann eine absolute
Adresse sein.
ld (1234),a
z.B. speichert den Inhalt des Akkus an Adresse 1234
Z80 Opcode finde ich sehr elegant im Gegensatz des des 6502. Wo der 6502
LDA und STA braucht, macht der Z80 beides mit LD.
Auch scheint der Z80 "Primitives" zu haben. Man füllt zum Beispiel für
eine Suche nach einem Wert im Speicher mehrere Register mit Werten und
ruft einen Opcode (kein Firmwarecode, wie beim C64) auf. Der läuft dann
solange, bis der Wert gefunden oder der Range überrannt wurde.
Wird der von einem IRQ unterbrochen? Wenn ja, wie merkt sich der Z80 den
aktuellen Stand? Und wie effizient war der Befehl?

Gerrit
Nils M Holm
2019-11-20 20:52:55 UTC
Permalink
Post by Gerrit Heitsch
Auch scheint der Z80 "Primitives" zu haben. Man f?llt zum Beispiel f?r
eine Suche nach einem Wert im Speicher mehrere Register mit Werten und
ruft einen Opcode (kein Firmwarecode, wie beim C64) auf. Der l?uft dann
solange, bis der Wert gefunden oder der Range ?berrannt wurde.
Wird der von einem IRQ unterbrochen? Wenn ja, wie merkt sich der Z80 den
aktuellen Stand? Und wie effizient war der Befehl?
Die "block" instructions (wie LDIR -- LoaD, Increment, Repeat) werden
nicht von einem maskierbaren Interrupt (INT) unterbrochen. Daher teilen
manche Programme laengere Block-Operationen in "Haeppchen" auf,
typicherweise zu 256 bytes, damit zwischendurch Interrupts verarbeitet
werden koennen.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Michael van Elst
2019-11-20 21:42:53 UTC
Permalink
Post by Gerrit Heitsch
Wird der von einem IRQ unterbrochen? Wenn ja, wie merkt sich der Z80 den
aktuellen Stand? Und wie effizient war der Befehl?
LDI/LDD kopieren ein Byte.

LDIR/LDDR wiederholen den Befehl einfach, bis der Zähler (Registerpaar BC)
auf Null ist. Das geschieht einfach dadurch, dass der PC zurückgesetzt wird.
Es sind also einfach Interrupts möglich, und bei jedem Byte gibt es den
Overhead den Befehl neu zu laden. Macht also ingesamt 3 reads + 1 write
pro Byte.

Eine selbstgebaute Schleife kann schneller sein, wenn ein 8bit-Zähler
ausreicht, ansonsten gewinnt der Blocktransfer-Befehl.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Rainer Knaepper
2019-11-21 07:44:00 UTC
Permalink
Post by Michael van Elst
Post by Gerrit Heitsch
Wird der von einem IRQ unterbrochen? Wenn ja, wie merkt sich der
Z80 den aktuellen Stand? Und wie effizient war der Befehl?
LDI/LDD kopieren ein Byte.
LDIR/LDDR wiederholen den Befehl einfach, bis der Zähler
(Registerpaar BC) auf Null ist. Das geschieht einfach dadurch, dass
der PC zurückgesetzt wird. Es sind also einfach Interrupts möglich,
und bei jedem Byte gibt es den Overhead den Befehl neu zu laden.
Macht also ingesamt 3 reads + 1 write pro Byte.
Eine selbstgebaute Schleife kann schneller sein, wenn ein
8bit-Zähler ausreicht,
DJNZ

Immer gern genommen ;-)

Rainer
--
Hip ist FreeBSD, wer SuSE hat ist eh ein Luser und soll
besser beim Original aus Redmond bleiben, allenfalls ein
handgeschnitztes Debian mit mundgemaltem TCP/IP Stack ist
akzeptabel... (Joachim Neudert in ger.ct)
Bernd Laengerich
2019-11-20 21:29:23 UTC
Permalink
Post by Andreas Kohlbach
Z80 Opcode finde ich sehr elegant im Gegensatz des des 6502. Wo der 6502
LDA und STA braucht, macht der Z80 beides mit LD.
????

LD A,(HL) und LD (HL),A sind ZWEI Opcodes: 7E und 77.
LD A,(1234) und LD (1234),A sind ZWEI Opcodes: 3A und 32.
LD C,B und LD B,C sind ZWEI Opcodes: 48 und 41.
[...]

Daß eine Assemblersprache Mnemonics mehrfach benutzt, sagt nichts über
die Opcodes aus.

Bernd
Andreas Kohlbach
2019-11-21 19:58:23 UTC
Permalink
Post by Bernd Laengerich
Post by Andreas Kohlbach
Z80 Opcode finde ich sehr elegant im Gegensatz des des 6502. Wo der 6502
LDA und STA braucht, macht der Z80 beides mit LD.
????
LD A,(HL) und LD (HL),A sind ZWEI Opcodes: 7E und 77.
LD A,(1234) und LD (1234),A sind ZWEI Opcodes: 3A und 32.
LD C,B und LD B,C sind ZWEI Opcodes: 48 und 41.
[...]
Daß eine Assemblersprache Mnemonics mehrfach benutzt, sagt nichts über
die Opcodes aus.
Natürlich, Mnemonics, sorry.

Vielleicht noch der Tipp für den, der zu viel Zeit hat und den 6502 schon
programmiert hat, dass er am Z80 seine Freude haben wird.
--
Andreas
Ralf Kiefer
2019-11-21 22:33:05 UTC
Permalink
Post by Andreas Kohlbach
Vielleicht noch der Tipp für den, der zu viel Zeit hat und den 6502 schon
programmiert hat, dass er am Z80 seine Freude haben wird.
*grusel* Und immer Ctrl-C drücken ...

Nene, vorher vertiefe ich 6802/6809 und dann werde ich mich irgendwann
mit dem RCA 1802 beschäftigen. Der hat einen ähnlich chaotischen
Befehlssatz.

Gruß, Ralf
Andreas Kohlbach
2019-11-22 17:06:44 UTC
Permalink
Post by Ralf Kiefer
Post by Andreas Kohlbach
Vielleicht noch der Tipp für den, der zu viel Zeit hat und den 6502 schon
programmiert hat, dass er am Z80 seine Freude haben wird.
*grusel* Und immer Ctrl-C drücken ...
?
Post by Ralf Kiefer
Nene, vorher vertiefe ich 6802/6809 und dann werde ich mich irgendwann
mit dem RCA 1802 beschäftigen. Der hat einen ähnlich chaotischen
Befehlssatz.
Der 6809 hat SEX für Sign EXtend. *g*
--
Andreas
Kay Martinen
2019-11-20 21:12:39 UTC
Permalink
Post by Nils M Holm
Post by Kay Martinen
e-Book?
Blaettern in E-Books macht immernoch keinen Spass! Ich finde
Sachen 10x scheller auf Papier.
Äh, ja. Geht mir auch so. Ich dachte halt es gäbe inzwischen bessere die
evtl. auch PDF's kommentieren könnten - oder so was.
Post by Nils M Holm
Post by Kay Martinen
Post by Nils M Holm
Ich schreibe gerade CP/M code fuer einen Amstrad NC100 und
meine Z80-Kenntnisse sind etwas rostig. :)
Eine Opcode-tabelle reicht nicht? :) Sind doch nicht so viele...
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt. Hat der 6502 m.E. nach nicht. Von dem guten Dutzend
Adressierungsarten ganz zu schweigen... <duck und wech> :-)

Kay
--
Sent via SN (Eisfair-1)
Chr. Maercker
2019-11-21 08:58:18 UTC
Permalink
Post by Kay Martinen
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt.
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Post by Kay Martinen
Hat der 6502 m.E. nach nicht. Von dem guten Dutzend
Adressierungsarten ganz zu schweigen...
Zusätzlich zu dem, was der 8080 kann, hat der Z80 nur die beiden
Indexregister. Hab ich aber nie genutzt, der Befehlscode für indexierte
Adressierung ist länger und die Vorteile halten sich in Grenzen.
--
CU Chr. Maercker.
Andreas Kohlbach
2019-11-21 20:12:23 UTC
Permalink
Post by Chr. Maercker
Post by Kay Martinen
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt.
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Bei Controllern sollte sich auch IN und OUT anbieten. Das kennt der 6502
AFAIK nicht.
--
Andreas
Bernd Laengerich
2019-11-21 20:13:56 UTC
Permalink
Post by Andreas Kohlbach
Bei Controllern sollte sich auch IN und OUT anbieten. Das kennt der 6502
AFAIK nicht.
Da es beim 6502 nur memory mapped IO gibt, erübrigen sich natürlich auch
Befehle für nicht existente Features :)

Bernd
Gerrit Heitsch
2019-11-21 20:15:40 UTC
Permalink
Post by Andreas Kohlbach
Post by Chr. Maercker
Post by Kay Martinen
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt.
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Bei Controllern sollte sich auch IN und OUT anbieten. Das kennt der 6502
AFAIK nicht.
Nein, beim 6502 ist alles memory-mapped. Finde ich jetzt nicht so
schlecht weil man so eben alle Befehle für I/O verwenden kann.

Gerrit
Kay Martinen
2019-11-21 21:41:53 UTC
Permalink
Post by Andreas Kohlbach
Post by Chr. Maercker
Post by Kay Martinen
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt.
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Hm, Bit-test Befehle hatten die ersten AFAIR noch nicht, da musste man
das mit Shift-Befehlen und Status-Tests machen. Mit der CMOS-Variante
gab es die aber. An ein XOR erinnere ich jetzt nicht.
Post by Andreas Kohlbach
Bei Controllern sollte sich auch IN und OUT anbieten. Das kennt der 6502
AFAIK nicht.
Nun, auch wenn er oft und gern als Controller eingesetzt wurde, er war
eine Allzweck-CPU. Und bei der gibt es keinen IO-Adressraum und damit
auch keine notwendigkeit für IN und OUT Befehle. Dafür kann man alle
sinnvollen Adressierungsarten auch auf die Register der memory-mapped
IO-Chips los lassen.


Kay
--
Sent via SN (Eisfair-1)
Ralf Kiefer
2019-11-21 22:33:06 UTC
Permalink
Post by Kay Martinen
Hm, Bit-test Befehle hatten die ersten AFAIR noch nicht, da musste man
das mit Shift-Befehlen und Status-Tests machen. Mit der CMOS-Variante
gab es die aber.
Nur der von Rockwell, die anderen nicht. Aber diese Befehle dann
richtig, komplex und vollständig auf der Zero page.

Der BIT-Befehl aus allen 6502-CPUs hatte immerhin die Möglichkeit 3
Flags gleichzeitig zu verändern: N, Z und insbesondere V. Daher haben
alle 65xx-Peripherie-Chips ihr Interrupt-Flag im höchstwertigen Bit vom
Statusregister.
Post by Kay Martinen
An ein XOR erinnere ich jetzt nicht.
Das war in jedem 6502 drin.


Gruß, Ralf
Rainer Knaepper
2019-11-21 23:53:00 UTC
Permalink
Post by Ralf Kiefer
Post by Kay Martinen
An ein XOR erinnere ich jetzt nicht.
Das war in jedem 6502 drin.
Gab es CPUs ohne XOR?

Ernstgemeinte Frage, ich kenne nur drei Familien ein bisken, und die
haben das alle.

Rainer
--
Post by Ralf Kiefer
Wieso soll man eigentlich blöde, faule oder doofe Menschen
nicht als solche bezeichnen dürfen?
Weil Verallgemeinerungen, Pauschalurteile und Vorurteile blöde und doof
sind und von fauler Denkweise zeugen. (Harald Lodan in d.a.r.d)
olaf
2019-11-22 07:13:09 UTC
Permalink
Post by Rainer Knaepper
Gab es CPUs ohne XOR?
Gott! Diese verwoehnte Jugend heutzutage. Schau dir mal einen ST6 an.
Der hatte noch nicht mal OR, geschweige denn XOR.
Ich glaube er hatte noch nichtmal NOP.

Olaf
Peter Heitzer
2019-11-22 07:59:21 UTC
Permalink
Post by olaf
Post by Rainer Knaepper
Gab es CPUs ohne XOR?
Gott! Diese verwoehnte Jugend heutzutage. Schau dir mal einen ST6 an.
Der hatte noch nicht mal OR, geschweige denn XOR.
Ich glaube er hatte noch nichtmal NOP.
NOP gibt es. Ich habe gerade nachgeschaut. Und Bit Setz/Rücksetzbefehle.
AND und Komplement gibt es auch. Damit lassen sich alle logischen Operationen
nachbilden. Der Befehlssatz ist erfreulich übersichtlich; nur 31 Befehle.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
olaf
2019-11-22 09:23:12 UTC
Permalink
Post by Peter Heitzer
NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
Post by Peter Heitzer
Und Bit Setz/Rücksetzbefehle.
AND und Komplement gibt es auch. Damit lassen sich alle logischen Operationen
nachbilden.
Ich weiss. Ich hab mir damals dafuer ja einen Forthcompiler geschrieben
und bin in dem Zusammenhang darauf gestossen.
Post by Peter Heitzer
Der Befehlssatz ist erfreulich übersichtlich; nur 31 Befehle.
Arbeitest du im Marketing? :-D

Olaf
Peter Heitzer
2019-11-22 11:45:39 UTC
Permalink
Post by olaf
Post by Peter Heitzer
NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
Laut ST6 Programming Manual
https://www.st.com/content/ccc/resource/technical/document/programming_manual/4d/05/d1/a5/a0/9e/40/8b/CD00004606.pdf/files/CD00004606.pdf/jcr:content/translations/en.CD00004606.pdf

gibt es NOP
Post by olaf
Post by Peter Heitzer
Und Bit Setz/Rücksetzbefehle.
AND und Komplement gibt es auch. Damit lassen sich alle logischen Operationen
nachbilden.
Ich weiss. Ich hab mir damals dafuer ja einen Forthcompiler geschrieben
und bin in dem Zusammenhang darauf gestossen.
Post by Peter Heitzer
Der Befehlssatz ist erfreulich übersichtlich; nur 31 Befehle.
Arbeitest du im Marketing? :-D
Nein, aber wenn ich mir x86 ansehe, dann sind mir wenige verständlich Befehle
doch lieber. Für reine Controlleranwendungen reichen die 31 Befehle.

Die 5 Bit Displacement bei relativen Sprungbefehlen sind allerdings schon
etwas wenig. Der 8048 hatte aber nicht mal relative Sprungbefehle.
Der ST6 kann sogar subtrahieren. Allerdings sehe ich gerade, daß es keine
Befehle gibt, die Carry beim Addieren berücksichtigen. 16 Bit Addition
muss man also durch Überspringen des Inkrementierbefehls für das höherwertige
Byte implementieren.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Andreas Kohlbach
2019-11-22 17:17:43 UTC
Permalink
Post by olaf
Post by Peter Heitzer
NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
NOP macht nichts und der program counter geht zur nächsten Adresse. Ich
wollte das aber nicht als Sprungbefehl bezeichnen.
--
Andreas
Gerrit Heitsch
2019-11-22 17:22:27 UTC
Permalink
Post by Andreas Kohlbach
Post by olaf
Post by Peter Heitzer
NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
NOP macht nichts und der program counter geht zur nächsten Adresse. Ich
wollte das aber nicht als Sprungbefehl bezeichnen.
Man kann das aber mit einem Sprungbefehl emulieren.

Ok, beim 6502 braucht der NOP 1 Byte und 2 Zyklen, der JMP hingegen 3
Byte und 3 Zyklen.

Gerrit
Kay Martinen
2019-11-22 18:50:12 UTC
Permalink
Post by Gerrit Heitsch
Post by Andreas Kohlbach
  >NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
NOP macht nichts und der program counter geht zur nächsten Adresse. Ich
wollte das aber nicht als Sprungbefehl bezeichnen.
Man kann das aber mit einem Sprungbefehl emulieren.
Ein Unbedingter Sprung setzt den Programcounter auf eine neue Adresse.
NOP macht das auch, nur ist die neue Adresse implizit kodiert mit +1
Ergo: Sprungbefehl. ;-)
Post by Gerrit Heitsch
Ok, beim 6502 braucht der NOP 1 Byte und 2 Zyklen, der JMP hingegen 3
Byte und 3 Zyklen.
Mit ein Grund weshalb man Schleifen mit einem Bestimmten Timing mit NOPs
realisieren kann.


Kay
--
Sent via SN (Eisfair-1)
Gerrit Heitsch
2019-11-22 20:30:47 UTC
Permalink
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Andreas Kohlbach
  >NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
NOP macht nichts und der program counter geht zur nächsten Adresse. Ich
wollte das aber nicht als Sprungbefehl bezeichnen.
Man kann das aber mit einem Sprungbefehl emulieren.
Ein Unbedingter Sprung setzt den Programcounter auf eine neue Adresse.
NOP macht das auch, nur ist die neue Adresse implizit kodiert mit +1
Ergo: Sprungbefehl. ;-)
Post by Gerrit Heitsch
Ok, beim 6502 braucht der NOP 1 Byte und 2 Zyklen, der JMP hingegen 3
Byte und 3 Zyklen.
Mit ein Grund weshalb man Schleifen mit einem Bestimmten Timing mit NOPs
realisieren kann.
Ja, aber eben nicht auf den Zyklus genau. Wenn man das will braucht man
auch noch JMP eben weil der eine ungerade Anzahl Zyklen braucht. Mit JMP
und NOP in Kombination kann man alles ausser 1 Zyklus Verzögerung
realisieren.

Gerrit
Peter Heitzer
2019-11-25 11:23:50 UTC
Permalink
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Andreas Kohlbach
  >NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
NOP macht nichts und der program counter geht zur nächsten Adresse. Ich
wollte das aber nicht als Sprungbefehl bezeichnen.
Man kann das aber mit einem Sprungbefehl emulieren.
Ein Unbedingter Sprung setzt den Programcounter auf eine neue Adresse.
NOP macht das auch, nur ist die neue Adresse implizit kodiert mit +1
Ergo: Sprungbefehl. ;-)
Post by Gerrit Heitsch
Ok, beim 6502 braucht der NOP 1 Byte und 2 Zyklen, der JMP hingegen 3
Byte und 3 Zyklen.
Mit ein Grund weshalb man Schleifen mit einem Bestimmten Timing mit NOPs
realisieren kann.
Ja, aber eben nicht auf den Zyklus genau. Wenn man das will braucht man
auch noch JMP eben weil der eine ungerade Anzahl Zyklen braucht. Mit JMP
und NOP in Kombination kann man alles ausser 1 Zyklus Verzögerung
realisieren.
Obacht beim 6502 (und auch anderen CPUs). Relative Sprünge dauern unterschiedlich
lang, wenn eine Seitengrenze überschritten wird. Beim klassischen 6502 wird
man die aber wohl nicht verwenden, da der keinen unbedingten relativen Sprung
beherrscht. BRA gibt es AFAIK erst bei den CMOS Typen.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Andreas Kohlbach
2019-11-23 15:38:58 UTC
Permalink
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Andreas Kohlbach
  >NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
NOP macht nichts und der program counter geht zur nächsten Adresse. Ich
wollte das aber nicht als Sprungbefehl bezeichnen.
Man kann das aber mit einem Sprungbefehl emulieren.
Ein Unbedingter Sprung setzt den Programcounter auf eine neue Adresse.
NOP macht das auch, nur ist die neue Adresse implizit kodiert mit +1
Ergo: Sprungbefehl. ;-)
Auch jeder andere setzt den Counter auf eine neue Adresse. So wie INX
beim 6502. Im Gegensatz zum NOP könnten sich bei der Anwendung von INX
aber Flags ändern.

Zumindest die deutsche und englische Wikipedia Seiten dazu erwähnen weder
"Sprung" noch "jump".
--
Andreas
You know you are a redneck if
your dad walks you to school because you are both in the same grade.
Rainer Knaepper
2019-11-23 19:25:00 UTC
Permalink
Post by Kay Martinen
Ein Unbedingter Sprung setzt den Programcounter auf eine neue
Adresse. NOP macht das auch, nur ist die neue Adresse implizit
kodiert mit +1 Ergo: Sprungbefehl. ;-)
Nach der Definition ist /jeder/ Befehl ein Sprungbefehl, denn die
Folgeadresse ist überall implizit kodiert mit +n.

Rainer
--
Holleri dudödeldi diridiri dudeldö
Kay Martinen
2019-11-23 23:38:24 UTC
Permalink
Post by Rainer Knaepper
Post by Kay Martinen
Ein Unbedingter Sprung setzt den Programcounter auf eine neue
Adresse. NOP macht das auch, nur ist die neue Adresse implizit
kodiert mit +1 Ergo: Sprungbefehl. ;-)
Nach der Definition ist /jeder/ Befehl ein Sprungbefehl, denn die
Folgeadresse ist überall implizit kodiert mit +n.
Schon klar. Aber JEDER Befehl; außer NOP; KANN die Prozessor-register
beeinflussen. Sprungbefehle tun das nicht; nur mit PC; und darum ist
m.E. NOP eben AUCH ein Sprungbefehl mit +1

Wenn man "Sprung" allerdings als "größer als 1" definiert dann fällt NOP
raus. Und man darf nicht vergessen das die normalen Befehle den PC ja
nicht "bewusst" manipulieren, sondern das dies von der Inneren CPU-Logik
vorgegeben ist den nachfolgenden Befehl zu laden.

Ja, mir ist klar das ich damit meinem oben gesagten irgendwie
wiederspreche. Wozu die Korinten, NOP ist schlichtweg nur ein "NO
Operation" und das sagt doch schon genug.

Kay
--
Sent via SN (Eisfair-1)
Michael van Elst
2019-11-24 06:34:37 UTC
Permalink
Post by Kay Martinen
Ja, mir ist klar das ich damit meinem oben gesagten irgendwie
wiederspreche. Wozu die Korinten, NOP ist schlichtweg nur ein "NO
Operation" und das sagt doch schon genug.
Bis auf die Seiteneffekte...
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Stefan Reuther
2019-11-24 10:36:02 UTC
Permalink
Post by Kay Martinen
Post by Rainer Knaepper
Post by Kay Martinen
Ein Unbedingter Sprung setzt den Programcounter auf eine neue
Adresse. NOP macht das auch, nur ist die neue Adresse implizit
kodiert mit +1 Ergo: Sprungbefehl. ;-)
Nach der Definition ist /jeder/ Befehl ein Sprungbefehl, denn die
Folgeadresse ist überall implizit kodiert mit +n.
Schon klar. Aber JEDER Befehl; außer NOP; KANN die Prozessor-register
beeinflussen. Sprungbefehle tun das nicht; nur mit PC; und darum ist
m.E. NOP eben AUCH ein Sprungbefehl mit +1
Und was ist mit dem Sprungbefehl 'djnz'?
Post by Kay Martinen
Ja, mir ist klar das ich damit meinem oben gesagten irgendwie
wiederspreche. Wozu die Korinten, NOP ist schlichtweg nur ein "NO
Operation" und das sagt doch schon genug.
Der Punkt ist halt: es gibt viele Möglichkeiten, nichts zu tun, genauso,
wie es viele Möglichkeiten gibt, viel zu reden und wenig zu sagen.

Die Frage ist halt, wo man seine Scheuklappen hinsetzt, um das "nichts"
zu beurteilen. Auf modernerem Silizium zählen 'jmp' und 'nop' wenigstens
den Cycle Counter hoch. Auf dem Z80 dürfte das R-Register eine ähnliche
Funktion haben. Da schaut man nur normalerweise nicht hin.


Stefan
Kay Martinen
2019-11-24 15:11:08 UTC
Permalink
Post by Stefan Reuther
Post by Kay Martinen
Post by Rainer Knaepper
Post by Kay Martinen
Ein Unbedingter Sprung setzt den Programcounter auf eine neue
Adresse. NOP macht das auch, nur ist die neue Adresse implizit
kodiert mit +1 Ergo: Sprungbefehl. ;-)
Nach der Definition ist /jeder/ Befehl ein Sprungbefehl, denn die
Folgeadresse ist überall implizit kodiert mit +n.
Schon klar. Aber JEDER Befehl; außer NOP; KANN die Prozessor-register
beeinflussen. Sprungbefehle tun das nicht; nur mit PC; und darum ist
m.E. NOP eben AUCH ein Sprungbefehl mit +1
Und was ist mit dem Sprungbefehl 'djnz'?
Ist der nicht Z80 Spezifisch? Kenne ich nicht, "jump if not zero"...
aber WAS<>0?
Post by Stefan Reuther
Post by Kay Martinen
Ja, mir ist klar das ich damit meinem oben gesagten irgendwie
wiederspreche. Wozu die Korinten, NOP ist schlichtweg nur ein "NO
Operation" und das sagt doch schon genug.
Der Punkt ist halt: es gibt viele Möglichkeiten, nichts zu tun, genauso,
wie es viele Möglichkeiten gibt, viel zu reden und wenig zu sagen.
Du kennst unsere Politiker also? Manche von denen kommen mir vor als
liefen auf ihnen

:loop
OUT 'blabla'
JMP :loop

und der Erbauer hat als Abbruchbedingung nur einen Interrupt vorgesehen.
Der leider nie eingeleitet wird, oder als

:INT
REM "Geh kacken"
iRET

Definiert ist. :-)
Post by Stefan Reuther
Die Frage ist halt, wo man seine Scheuklappen hinsetzt, um das "nichts"
zu beurteilen. Auf modernerem Silizium zählen 'jmp' und 'nop' wenigstens
den Cycle Counter hoch. Auf dem Z80 dürfte das R-Register eine ähnliche
Funktion haben. Da schaut man nur normalerweise nicht hin.
Cycle Counter macht WAS. Befehlezyklen zählen? Oder Schleifendurchläufe?


Kay
--
Sent via SN (Eisfair-1)
Andreas Kohlbach
2019-11-24 17:59:11 UTC
Permalink
Post by Kay Martinen
Post by Stefan Reuther
Und was ist mit dem Sprungbefehl 'djnz'?
Ist der nicht Z80 Spezifisch? Kenne ich nicht, "jump if not zero"...
aber WAS<>0?
Das ist ein "Makro". Man füllt ein (oder zwei?) Register mit einem
Wert, ruft dann djnz auf. Er dekrementiert eines der Register und loopt
solange, bis dieses Register 0 ist. IIRC.

http://www.keil.com/support/man/docs/is51/is51_djnz.htm
--
Andreas
Nils M Holm
2019-11-24 18:06:58 UTC
Permalink
Post by Kay Martinen
Post by Stefan Reuther
Und was ist mit dem Sprungbefehl 'djnz'?
Ist der nicht Z80 Spezifisch? Kenne ich nicht, "jump if not zero"...
aber WAS<>0?
Das ist ein "Makro". Man f?llt ein (oder zwei?) Register mit einem
Wert, ruft dann djnz auf. Er dekrementiert eines der Register und loopt
solange, bis dieses Register 0 ist. IIRC.
Zumindest auf den Z80 ist das eine Instruktion. Sie dekrementiert das
Register B und fuehrt dann einen relativen Sprung zu einem 8-bit offset
aus, wenn B nicht 0 ist.
http://www.keil.com/support/man/docs/is51/is51_djnz.htm
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Michael van Elst
2019-11-24 20:35:44 UTC
Permalink
Post by Nils M Holm
Post by Andreas Kohlbach
Wert, ruft dann djnz auf. Er dekrementiert eines der Register und loopt
solange, bis dieses Register 0 ist. IIRC.
Zumindest auf den Z80 ist das eine Instruktion. Sie dekrementiert das
Register B und fuehrt dann einen relativen Sprung zu einem 8-bit offset
aus, wenn B nicht 0 ist.
Und ändert dabei keine Flags, was oft ganz praktisch ist.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Andreas Kohlbach
2019-11-24 17:19:50 UTC
Permalink
Post by Stefan Reuther
Post by Kay Martinen
Schon klar. Aber JEDER Befehl; außer NOP; KANN die Prozessor-register
beeinflussen. Sprungbefehle tun das nicht; nur mit PC; und darum ist
m.E. NOP eben AUCH ein Sprungbefehl mit +1
Und was ist mit dem Sprungbefehl 'djnz'?
Interessant! Er ist zwar ein Sprungbefehl. Wird aber im Loop ausgeführt,
der Flags beeinflussten wird.
--
Andreas
Stefan Reuther
2019-11-22 17:22:35 UTC
Permalink
Post by olaf
Post by Peter Heitzer
NOP gibt es. Ich habe gerade nachgeschaut.
Bist du das sicher? Ist natuerlich schon LANGE her das ich die Teile
programmiert habe, aber ich meine NOP war da in Wahrheit ein
Sprungbefehl auf die naechste Adresse.
Beim Marktführer ist NOP ein Exchange des Akkumulators mit sich selber.
Das ist jetzt keine sonderliche Innovation.
Post by olaf
Post by Peter Heitzer
Der Befehlssatz ist erfreulich übersichtlich; nur 31 Befehle.
Arbeitest du im Marketing? :-D
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.


Stefan
Kay Martinen
2019-11-22 18:53:24 UTC
Permalink
Post by Stefan Reuther
Post by olaf
Arbeitest du im Marketing? :-D
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.

No RISC, Be CISC.

Kay
--
Sent via SN (Eisfair-1)
Gerrit Heitsch
2019-11-22 20:32:06 UTC
Permalink
Post by Kay Martinen
Post by Stefan Reuther
Post by olaf
Arbeitest du im Marketing? :-D
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.
Flatmemory ist nicht das Problem. Spekulative Ausführung ist es. Nimm
einen Atom N270 und die Probleme sind keine mehr. Leider ist er etwas
langsamer.

Gerrit
Kay Martinen
2019-11-22 22:29:55 UTC
Permalink
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Stefan Reuther
Post by olaf
Arbeitest du im Marketing? :-D
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.
Flatmemory ist nicht das Problem. Spekulative Ausführung ist es.
Hmm. Du meinst selbst die Isolierung jedes Prozesses in seinem Eigenen
Ring 3 Segment dessen Descriptor ein Schreiben untersagt (Code-segment)
und ein Ausführen von Daten verhindert (ExecuteDisable war später) -
außer man wäre im Ring 0, würde nicht verhindern das ein Anderer Prozess
verworfene Ergebnisse der Sprungvorhersage deines Prozesses abgreifen
könne - sogar aus Ring 0 heraus? Es fällt mir schwer zu glauben das
Intel es SO weitgehend verkackt haben soll.

Zumindest hab ich es bisher so wahrgenommen das die Seitenkanal-angriffe
erfolgreich sein können weil der Hauptspeicher doch quasi nur ein
einziges großes Segment ist.

Ein Segmentierter Speicher mit den Schutzmöglichkeiten der
Descriptoren-tabellen (wie Datensegment: nicht ausführbar, Codesegment:
nicht beschreibbar) würde allerdings etliche Schädlinge m.E. schlicht
zum Platzen bringen. Gut, das Programmieren wäre wieder deutlich
schwieriger. Aber für mich sieht es so aus als ob die seit dem 386
eingebauten Features mutwillig brach liegen.
Post by Gerrit Heitsch
Nimm
einen Atom N270 und die Probleme sind keine mehr. Leider ist er etwas
langsamer.
Logisch. In-Order Architekturen müssen ja langsamer sein, aber IMHO auch
nicht so viel. Codeoptimierung darauf könnte helfen oder? Oder wissen
die ganzen Compiler heute nicht mehr was Segmente sind?

Gibt es In-Order CPUs die mit über 3 GHz Takt laufen - so wie die Top
Chips von Intel/AMD? Wenn nein, warum nicht? Was hindert die, das
Marketing? [Huch. Der Kreis schließt sich] ;)

Ich habe übrigens mehrere Atom im Einsatz. Aktuell laufen ein Tablet und
ein Mediaserver damit.

Kay
--
Sent via SN (Eisfair-1)
Gerrit Heitsch
2019-11-23 06:32:03 UTC
Permalink
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Stefan Reuther
Post by olaf
Arbeitest du im Marketing? :-D
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.
Flatmemory ist nicht das Problem. Spekulative Ausführung ist es.
Hmm. Du meinst selbst die Isolierung jedes Prozesses in seinem Eigenen
Ring 3 Segment dessen Descriptor ein Schreiben untersagt (Code-segment)
und ein Ausführen von Daten verhindert (ExecuteDisable war später) -
außer man wäre im Ring 0, würde nicht verhindern das ein Anderer Prozess
verworfene Ergebnisse der Sprungvorhersage deines Prozesses abgreifen
könne - sogar aus Ring 0 heraus? Es fällt mir schwer zu glauben das
Intel es SO weitgehend verkackt haben soll.
Es kommt drauf an wann sie den Test auf 'darf der das?' machen. Erfolgt
er nach der spekulativen Ausführung hat das schon seine Spuren im Cache
hinterlassen selbst wenn das Ergebnis selbst wegen 'nein, darf er nicht'
verworfen wird. Diese Spuren kannst du auswerten und damit an die
fraglichen Daten kommen.

So ein Test kostet Zeit, also würde es mich nicht wundern wenn der
parallel zur Ausführung laufen würde.

Und ja, Intel hat sehr viel verkackt. Irgendwo müssen die
Performancevorteile gegenüber AMD ja hergekommen sein. Schau dir an
welche Bugs nur Intel hat.
Post by Kay Martinen
Ein Segmentierter Speicher mit den Schutzmöglichkeiten der
nicht beschreibbar) würde allerdings etliche Schädlinge m.E. schlicht
zum Platzen bringen. Gut, das Programmieren wäre wieder deutlich
schwieriger. Aber für mich sieht es so aus als ob die seit dem 386
eingebauten Features mutwillig brach liegen.
Segmentierung gab es schon vorher, aber das war fürchterlich. Wer sich
das Modell ausgedacht hat muss von seinem Dealer besonders schlechtes
Kraut bekommen haben.

Flatmemory plus MMU ist da schon besser, wenn richtig implementiert.
Post by Kay Martinen
Post by Gerrit Heitsch
Nimm
einen Atom N270 und die Probleme sind keine mehr. Leider ist er etwas
langsamer.
Logisch. In-Order Architekturen müssen ja langsamer sein, aber IMHO auch
nicht so viel. Codeoptimierung darauf könnte helfen oder? Oder wissen
die ganzen Compiler heute nicht mehr was Segmente sind?
Die sind schon deutlich langsamer. Gut, der N270 in meinem Netbook von
2008 besonders, aber auch sonst ist der Unterschied deutlich.

Gerrit
Stefan Reuther
2019-11-23 11:10:13 UTC
Permalink
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Stefan Reuther
Post by olaf
Arbeitest du im Marketing? :-D
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.
Flatmemory ist nicht das Problem. Spekulative Ausführung ist es.
Hmm. Du meinst selbst die Isolierung jedes Prozesses in seinem Eigenen
Ring 3 Segment dessen Descriptor ein Schreiben untersagt (Code-segment)
und ein Ausführen von Daten verhindert (ExecuteDisable war später) -
außer man wäre im Ring 0, würde nicht verhindern das ein Anderer Prozess
verworfene Ergebnisse der Sprungvorhersage deines Prozesses abgreifen
könne - sogar aus Ring 0 heraus? Es fällt mir schwer zu glauben das
Intel es SO weitgehend verkackt haben soll.
So wie ich diesen Angriff verstanden habe, ist es die Tatsache, dass
hier überhaupt spekuliert wird, die Spuren in den Caches hinterlässt.
Dabei ist vollkommen Wumpe, ob der Cache mit linearen Adressen,
physischen Adressen oder Segment-Adressen organisiert ist: jede
Cacheline kann eine andere Cacheline verdrängen, und das kann man
beobachten.
Post by Kay Martinen
Ein Segmentierter Speicher mit den Schutzmöglichkeiten der
nicht beschreibbar) würde allerdings etliche Schädlinge m.E. schlicht
zum Platzen bringen. Gut, das Programmieren wäre wieder deutlich
schwieriger. Aber für mich sieht es so aus als ob die seit dem 386
eingebauten Features mutwillig brach liegen.
Wir haben ja nun "write disable" Features in den Pagetables, aber es
gibt noch genug Möglichkeiten, damit rumzuferkeln ("return to libc" zum
Beispiel).

Als jemand, der mit segmentierter Adressierung aufgewachsen ist, meine
ich, dass Programmieren gar nicht mal viel schwerer werden würde,
solange ich weiterhin Segmente mit >64k haben darf.


Stefan
Kay Martinen
2019-11-23 12:32:12 UTC
Permalink
Post by Stefan Reuther
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Stefan Reuther
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.
Flatmemory ist nicht das Problem. Spekulative Ausführung ist es.
Hmm. Du meinst selbst die Isolierung jedes Prozesses in seinem Eigenen
Ring 3 Segment dessen Descriptor ein Schreiben untersagt (Code-segment)
und ein Ausführen von Daten verhindert (ExecuteDisable war später) -
außer man wäre im Ring 0, würde nicht verhindern das ein Anderer Prozess
verworfene Ergebnisse der Sprungvorhersage deines Prozesses abgreifen
könne - sogar aus Ring 0 heraus? Es fällt mir schwer zu glauben das
Intel es SO weitgehend verkackt haben soll.
So wie ich diesen Angriff verstanden habe, ist es die Tatsache, dass
hier überhaupt spekuliert wird, die Spuren in den Caches hinterlässt.
Dabei ist vollkommen Wumpe, ob der Cache mit linearen Adressen,
physischen Adressen oder Segment-Adressen organisiert ist: jede
Cacheline kann eine andere Cacheline verdrängen, und das kann man
beobachten.
Gibt es nicht schon seit Jahren getrennte Daten- und Code-Caches in den
Prozessoren? Gut, da es primär wohl um die code-caches geht... wäre eine
Erweiterung der Idee vielleicht den cache zu segmentieren in die
Verschiedenen Privileg-ebenen. Und wenn es nur Ring 0 und Ring 3 gäbe,
dann kann zumindest kein userprozess daten eines kernelprozesses
abgreifen. Oder was meinst du?
Post by Stefan Reuther
Post by Kay Martinen
Ein Segmentierter Speicher mit den Schutzmöglichkeiten der
nicht beschreibbar) würde allerdings etliche Schädlinge m.E. schlicht
zum Platzen bringen. Gut, das Programmieren wäre wieder deutlich
schwieriger. Aber für mich sieht es so aus als ob die seit dem 386
eingebauten Features mutwillig brach liegen.
Wir haben ja nun "write disable" Features in den Pagetables, aber es
gibt noch genug Möglichkeiten, damit rumzuferkeln ("return to libc" zum
Beispiel).
Du meinst das NX/EVP/DEP Feature der Paging-unit. So weit ich noch
erinnere wird die Adressübersetzung damit noch ein wenig komplizierter.
Mag das mit ein Grund gewesen sein das man Flatmemory nutzt um es zu
entkomplizieren? Und dann mit ASLR gleich wieder zu verkomplizieren.

Ich denke wenn man den Segmentierten Speicher korrekt implementiert wäre
ASLR überhaupt nicht mehr nötig. WENN die CPU es auch richtig machen
würde (Privileg-level vorab prüfen z.B.).
Post by Stefan Reuther
Als jemand, der mit segmentierter Adressierung aufgewachsen ist, meine
ich, dass Programmieren gar nicht mal viel schwerer werden würde,
solange ich weiterhin Segmente mit >64k haben darf.
Also seit späteren 386/486 ist die Granularity m.W. umschaltbar und
deckt GB große Segmente ab. Aber das Betrifft ja nur die
Segmente/Descriptoren. Was die Paging-unit darunter aktuell drauß macht
weiß ich jetzt nicht. Regulär waren mal 4kB Pagesize. Da gab es doch
sicher auch Erweiterungen. SLAT, Mehrstufige PT oder gar EPT?

Meine Güte. Was für ein Wort-dickicht. Darin soll man sich nicht
verlaufen... :-/

Kay
--
Sent via SN (Eisfair-1)
Gerrit Heitsch
2019-11-23 14:52:28 UTC
Permalink
Post by Kay Martinen
Post by Stefan Reuther
Post by Kay Martinen
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Stefan Reuther
RISC ist doch schon seit Jahren was Besseres als das böse CISC vom
Marktführer.
Das hat uns immerhin so schöne sachen gebracht wie Meltdown, aushebelung
des Speicherschutzes weil alle welt lieber mit Flatearth ähh Flatmemory
arbeiten mag. U.s.w. SCNR.
Flatmemory ist nicht das Problem. Spekulative Ausführung ist es.
Hmm. Du meinst selbst die Isolierung jedes Prozesses in seinem Eigenen
Ring 3 Segment dessen Descriptor ein Schreiben untersagt (Code-segment)
und ein Ausführen von Daten verhindert (ExecuteDisable war später) -
außer man wäre im Ring 0, würde nicht verhindern das ein Anderer Prozess
verworfene Ergebnisse der Sprungvorhersage deines Prozesses abgreifen
könne - sogar aus Ring 0 heraus? Es fällt mir schwer zu glauben das
Intel es SO weitgehend verkackt haben soll.
So wie ich diesen Angriff verstanden habe, ist es die Tatsache, dass
hier überhaupt spekuliert wird, die Spuren in den Caches hinterlässt.
Dabei ist vollkommen Wumpe, ob der Cache mit linearen Adressen,
physischen Adressen oder Segment-Adressen organisiert ist: jede
Cacheline kann eine andere Cacheline verdrängen, und das kann man
beobachten.
Gibt es nicht schon seit Jahren getrennte Daten- und Code-Caches in den
Prozessoren?
Nur beim L1-Cache, L2 und L3 sind üblicherweise gemeinsam.



Gut, da es primär wohl um die code-caches geht... wäre eine
Post by Kay Martinen
Erweiterung der Idee vielleicht den cache zu segmentieren in die
Verschiedenen Privileg-ebenen. Und wenn es nur Ring 0 und Ring 3 gäbe,
dann kann zumindest kein userprozess daten eines kernelprozesses
abgreifen. Oder was meinst du?
Doch, denn der Angriff passiert über Timing. Es macht einen Unterschied
ob ein bestimmter Speicherbereich im Cache schon vorhanden ist oder ob
der Cache-Controller ihn dort hinladen muss. Diesen Unterschied kann man
per Software messen.

Das ganze ist ziemlich komplex und hier nicht mal kurz beschrieben, ich
muss das auch jedesmal von vorne lesen. Die einzig wirklich sichere
Möglichkeit das zu verhindern wäre auch beim Cache einen Rollback zu
machen wenn ein Befehl nicht hätte ausgeführt werden dürfen. Die dazu
nötige Logik dürfte interessant sein.
Post by Kay Martinen
Ich denke wenn man den Segmentierten Speicher korrekt implementiert wäre
ASLR überhaupt nicht mehr nötig. WENN die CPU es auch richtig machen
würde (Privileg-level vorab prüfen z.B.).
Wenn die CPU das machen würde hätten wir diverse Probleme nicht. AMD tut
es meist und ist deshalb eben auch langsamer. Intel hat auf
Geschwindigkeit optimiert und jetzt eine Menge Ärger.

Vor der Ausführung checken bedeutet eben mehr Zeitaufwand als Prüfung
und Befehl parallel laufen zu lassen, am Ende zu prüfen und im Falle von
'darf er nicht' nur das Ergebnis zu verwerfen.

Um bei alten Computern zu bleiben... Ist wie der Trick bei einem EPROM
das /CE-Signal fest auf GND zu legen und nur über /OE zu steuern. So
laufen die internen Abläufe im EPROM und die Logik die entscheidet ob
das EPROM überhaupt gemeint ist parallel. Falls ja schaltet /OE nur die
Ausgangstreiber frei, falls nein passiert nichts. Vorteil: Das EPROM
kann langsamer sein da die Zeit von 'Adresse gültig' bis 'Daten auf dem
Bus' nicht mehr die Summe aus Logiklaufzeit plus Zugriffszeit EPROM ist
sondern kleiner. Nachteil: Das EPROM ist dauernd aktiv, das System
braucht damit mehr Strom.
Post by Kay Martinen
Also seit späteren 386/486 ist die Granularity m.W. umschaltbar und
deckt GB große Segmente ab. Aber das Betrifft ja nur die
Segmente/Descriptoren. Was die Paging-unit darunter aktuell drauß macht
weiß ich jetzt nicht. Regulär waren mal 4kB Pagesize. Da gab es doch
sicher auch Erweiterungen. SLAT, Mehrstufige PT oder gar EPT?
Huge Pages gibt es auch schon länger. Je nach CPU können das 2 MB oder
auch 1 GB sein. Hört sich nach einer guten Idee an, kann aber auch
ziemlich ins Auge gehen da man solche Pages nicht exklusiv benutzt und
damit immer auch 4 KB Pages im Speicher zu finden sind. Wenn jetzt ein
Prozess eine neue Page mit 2 MB oder 1 GB anfordert aber im Speicher
kein so großer Block am Stück frei ist ist erst einmal Aufräumen und
Verschieben angesagt. Und schon ist der Performancevorteil beim Teufel.
Deshalb wird dieses Feature oft abgeschaltet.

Gerrit
Stefan Reuther
2019-11-24 10:47:33 UTC
Permalink
Post by Kay Martinen
Post by Stefan Reuther
So wie ich diesen Angriff verstanden habe, ist es die Tatsache, dass
hier überhaupt spekuliert wird, die Spuren in den Caches hinterlässt.
Dabei ist vollkommen Wumpe, ob der Cache mit linearen Adressen,
physischen Adressen oder Segment-Adressen organisiert ist: jede
Cacheline kann eine andere Cacheline verdrängen, und das kann man
beobachten.
Gibt es nicht schon seit Jahren getrennte Daten- und Code-Caches in den
Prozessoren? Gut, da es primär wohl um die code-caches geht... wäre eine
Erweiterung der Idee vielleicht den cache zu segmentieren in die
Verschiedenen Privileg-ebenen. Und wenn es nur Ring 0 und Ring 3 gäbe,
dann kann zumindest kein userprozess daten eines kernelprozesses
abgreifen. Oder was meinst du?
Wenn, dann müsste man nach Prozessen segmentieren. Es geht ja auch und
vor allem darum, dass sich zwei Prozesse, die aus Prozessorsicht den
gleichen Privileg-Level haben (z.B. zwei VMs zweier Kunden) nicht
gegenseitig sehen und stören können. Und dann kann ja innerhalb der VM
auch noch sowas wie Docker laufen und sicheren und unsicheren Code des
gleichen Kunden separieren sollen. Nur die Ringe können das nicht
auseinanderhalten.

Und dann gibt's mit Sicherheit wieder Seitenkanal-Angriffe, wenn ich aus
dem Cache-Timing ablesen kann, wieviele Prozesse die anderen Kunden auf
dem VM-Host haben.
Post by Kay Martinen
Post by Stefan Reuther
Post by Kay Martinen
Ein Segmentierter Speicher mit den Schutzmöglichkeiten der
nicht beschreibbar) würde allerdings etliche Schädlinge m.E. schlicht
zum Platzen bringen. Gut, das Programmieren wäre wieder deutlich
schwieriger. Aber für mich sieht es so aus als ob die seit dem 386
eingebauten Features mutwillig brach liegen.
Wir haben ja nun "write disable" Features in den Pagetables, aber es
gibt noch genug Möglichkeiten, damit rumzuferkeln ("return to libc" zum
Beispiel).
Du meinst das NX/EVP/DEP Feature der Paging-unit.
Ja, sorry.
Post by Kay Martinen
So weit ich noch erinnere wird die Adressübersetzung damit noch ein
wenig komplizierter. Mag das mit ein Grund gewesen sein das man
Flatmemory nutzt um es zu entkomplizieren? Und dann mit ASLR gleich
wieder zu verkomplizieren.
Das "execute disable"-Bit macht die Hardware nicht viel komplizierter,
das ist nur ein zusätzlicher Check.
Post by Kay Martinen
Ich denke wenn man den Segmentierten Speicher korrekt implementiert wäre
ASLR überhaupt nicht mehr nötig. WENN die CPU es auch richtig machen
würde (Privileg-level vorab prüfen z.B.).
ASLR soll auch verhindern helfen, dass jemand gezielt per Buffer
Overflow Pointer in einen Prozess injiziert. Sofern wir unsere
Softwarequalität nicht in den Griff kriegen, brauchen wir das auch
weiterhin.
Post by Kay Martinen
Post by Stefan Reuther
Als jemand, der mit segmentierter Adressierung aufgewachsen ist, meine
ich, dass Programmieren gar nicht mal viel schwerer werden würde,
solange ich weiterhin Segmente mit >64k haben darf.
Also seit späteren 386/486 ist die Granularity m.W. umschaltbar und
deckt GB große Segmente ab.
Yep, das geht seit dem 386.

Das, was am segmentierten Modell Schmerzen gemacht hat, waren die
Verrenkungen, die für Datenstrukturen >64k notwendig waren (und
nachfolgend die Verrenkungen, die für Gesamtdatenmengen >640k notwendig
waren).

Aber sobald ich ein 'malloc(1000000)' machen kann, bin ich zufrieden.
Werden die Pointer halt etwas dicker, das macht der Compiler für mich,
fertig. Dass ein Pointer nicht in 32 Bit passen muss, haben wir bei der
Umstellung auf 64 Bit gelernt.


Stefan
Chr. Maercker
2019-11-22 06:21:31 UTC
Permalink
Post by Kay Martinen
Nun, auch wenn er oft und gern als Controller eingesetzt wurde, er war
eine Allzweck-CPU. Und bei der gibt es keinen IO-Adressraum und damit
auch keine notwendigkeit für IN und OUT Befehle. Dafür kann man alle
sinnvollen Adressierungsarten auch auf die Register der memory-mapped
IO-Chips los lassen.
Was bedeutet Memory-mapped konkret? IO-Ports werden wie Speicher
adressiert. Sind damit einfach Teil ein und desselben Adressraums oder
läuft es so, dass Daten, die auf bestimmte RAM-Adressen geladen werden,
an (wie vordefinierte?) IO-Ports weitergeleitet werden bzw. von ihnen
beim Input genutzt werden?
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
--
CU Chr. Maercker.
Michael van Elst
2019-11-22 06:38:29 UTC
Permalink
Post by Chr. Maercker
Was bedeutet Memory-mapped konkret? IO-Ports werden wie Speicher
adressiert.
Genau.
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Machen eigentlich alle, ein kleiner zusätzlicher I/O-Adressraum
ist auch unpraktisch und ein grosser ist nicht anders als ein
Adressbit.

Da bei modernen Prozessoren aber eine ganze Speicherhierarchie
existiert, wird jetzt per MMU entschieden, dass die I/O-Adressen
anders behandelt werden (kein Caching, kein Prefetch, eventuell
Zugriff auf einzelne Bytes, etc...).

Logischer wären vielleicht eigene I/O-Befehle, die die Details des
Zugriffs steuern, aber zwischen Befehlsausführung und Speicherzyklen
liegt so ein grosser Abstand, dass man das erst ganz zum Schluss
macht.
--
--
Michael van Elst
Internet: ***@serpens.de
"A potential Snark may lurk in every tree."
Rainer Knaepper
2019-11-22 11:37:00 UTC
Permalink
Post by Michael van Elst
Logischer wären vielleicht eigene I/O-Befehle, die die Details des
Zugriffs steuern,
... die z.B. out-of-order-excecution bzw. besser deren Verhinderung
automagisch berücksichtigen...

Rainer (der kein Programmierer ist, nur in einem früheren Leben mal an
der Entwicklung von Geräten mit Z80-Steuerung beteiligt war und heute
hobbymäßig noch ein wenig mit Attiny und Konsorten spielt. Aus dieser
Perspektive erscheint vieles in modernen Systemen doch schnell als
Voodoo ;-) )
--
Ist ein interessantes neurologisches Phänomen: auf der einen
Seite reklamiert niemand defekte kommerzielle Software, auf der
anderen Seite kaufen die gleichen Leute kommerzielle Software,
weil man da ja Gewährleistung hat. (Michael Bode in ger.ct)
Gerrit Heitsch
2019-11-22 15:03:24 UTC
Permalink
Post by Chr. Maercker
Post by Kay Martinen
Nun, auch wenn er oft und gern als Controller eingesetzt wurde, er war
eine Allzweck-CPU. Und bei der gibt es keinen IO-Adressraum und damit
auch keine notwendigkeit für IN und OUT Befehle. Dafür kann man alle
sinnvollen Adressierungsarten auch auf die Register der memory-mapped
IO-Chips los lassen.
Was bedeutet Memory-mapped konkret? IO-Ports werden wie Speicher
adressiert. Sind damit einfach Teil ein und desselben Adressraums
Ja.
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Dazu gibt es Label im Assembler. Vorteil ist eben, daß man alle Befehle
auch auf I/O anwenden kann.

Gerrit
Peter Heitzer
2019-11-25 11:37:07 UTC
Permalink
Post by Gerrit Heitsch
Post by Chr. Maercker
Post by Kay Martinen
Nun, auch wenn er oft und gern als Controller eingesetzt wurde, er war
eine Allzweck-CPU. Und bei der gibt es keinen IO-Adressraum und damit
auch keine notwendigkeit für IN und OUT Befehle. Dafür kann man alle
sinnvollen Adressierungsarten auch auf die Register der memory-mapped
IO-Chips los lassen.
Was bedeutet Memory-mapped konkret? IO-Ports werden wie Speicher
adressiert. Sind damit einfach Teil ein und desselben Adressraums
Ja.
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Dazu gibt es Label im Assembler. Vorteil ist eben, daß man alle Befehle
auch auf I/O anwenden kann.
Sofern die I/O alles unterstützt. BIT beim 6502 funktioniert bei einem
reinen Ausgabeport, z.B. ein 74x374 nicht.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Ralf Kiefer
2019-11-25 12:16:17 UTC
Permalink
Post by Peter Heitzer
Sofern die I/O alles unterstützt. BIT beim 6502 funktioniert bei einem
reinen Ausgabeport, z.B. ein 74x374 nicht.
Ein Lesebefehl auf einen Ausgabeport zu nehmen ist hier nicht optimal.
Umgekehrt genauso.

Gruß, Ralf
Peter Heitzer
2019-11-25 13:25:37 UTC
Permalink
Post by Ralf Kiefer
Post by Peter Heitzer
Sofern die I/O alles unterstützt. BIT beim 6502 funktioniert bei einem
reinen Ausgabeport, z.B. ein 74x374 nicht.
Ein Lesebefehl auf einen Ausgabeport zu nehmen ist hier nicht optimal.
Umgekehrt genauso.
Das sieht man dem Befehl nicht auf den ersten Blick an, Stichwort
Read/Modify/Write.

Mit einer 6522 VIA und auf Ausgang geschaltetem Port dürfte es aber funktionieren,
da hier das Portregister gelesen wird.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Klemens Krause
2019-11-25 13:34:00 UTC
Permalink
Post by Ralf Kiefer
Post by Peter Heitzer
Sofern die I/O alles unterstützt. BIT beim 6502 funktioniert bei einem
reinen Ausgabeport, z.B. ein 74x374 nicht.
Ein Lesebefehl auf einen Ausgabeport zu nehmen ist hier nicht optimal.
Umgekehrt genauso.
Ein 73x374 ist ja kein Peripheriebaustein, sondern einfach ein 8-Bit-
Latch. Beim 6522 kann man den Wert, den man in einen als Ausgang program-
mierten Port reingeschrieben hat auch wieder zurücklesen.

Aber es gibt noch ein paar Unterschiede in der Befehlssatzphilosophie
zu berücksichtigen:
Ein LD A,(addr) beeinflusst die Statusbits nicht.
Bei den Motorolen und MOSteken setzt ein LDA sowohl das Z (zero), als auch
das S (sign) im Statuswort, das O (overflow) wird rückgesetzt.
Auch der Befehl IN A,port beeinflusst die Statusbits nicht, (Kompatibilität
zum 8080?), wohingegen IN reg,(C) die Statusbits beeinflusst.

Und weiterhin: bei den beiden (6xyy) arbeitet der BIT-Befehl anders als bei den
Zilogiern: Der Bit-Befehl ist ein AND-Befehl, bei dem der Akku nicht verändert
wird, sondern nur die Status-Bits gesetzt werden. Damit kann man Masken
verwenden, um mehrere Bits gleichzeitig auf 0 zu testen.
Beim Z80 wird dagegen ein Bit ausgewählt, entweder in einem Register, oder
im Speicher, addressiert über (HL). Der wert dieses Bits wird invertiert in
das Z-Flag übertragen.

Klemens

Kay Martinen
2019-11-22 15:59:05 UTC
Permalink
Post by Chr. Maercker
Post by Kay Martinen
Nun, auch wenn er oft und gern als Controller eingesetzt wurde, er war
eine Allzweck-CPU. Und bei der gibt es keinen IO-Adressraum und damit
auch keine notwendigkeit für IN und OUT Befehle. Dafür kann man alle
sinnvollen Adressierungsarten auch auf die Register der memory-mapped
IO-Chips los lassen.
Was bedeutet Memory-mapped konkret? IO-Ports werden wie Speicher
adressiert. Sind damit einfach Teil ein und desselben Adressraums
Jepp. Üblicherweise in einem Höheren Bereich unter den System-ROMs damit
man zwischen Zeropage und Stack und dem Video-RAM einen möglichst
durchgehend freien Bereich für Programme hat.
Post by Chr. Maercker
oder läuft es so, dass Daten, die auf bestimmte RAM-Adressen geladen werden,
an (wie vordefinierte?) IO-Ports weitergeleitet werden bzw. von ihnen
beim Input genutzt werden?
Nein, dir Register der IO-Chips sind direkt als Speicherzellen
erreichbar. Und es hängt allein von der Adressdekodierung des Jew.
Systems ab wo und in welcher Abfolge die im Speicher auftauchen.

Manche Chips erforderten aber auch eine Spezialbehandlung. So konnte der
VDC (80Zeichen-Modus) im C-128 nur durch zwei Register angesprochen
werden, ein Daten- und ein Index-register. Und man mußte eines davon
lesen, den Status prüfen und konnte erst Schreiben wenn er Bereit war.
Werte auslesen war auch Tricky. Man mußte den Indexwert des
Zielregisters übergeben, AFAIR noch ein Bit setzen und dann warten um
das Ergebnisbyte im Datenregister abholen zu können.
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Du hast nie mit dem C-64 Programmieren versucht oder? Oder mit dem
C-128, einem 6504 EMUF oder dem COBOLD von Heise/c't?

Bei C-64/128 konntest du das Memory-layout mit IO-Registern der CPU
umschalten. Z.b. ROM->RAM kopieren, dann das ROM weg schalten und im
laufendem System das jetzt schreibbare ROM patchen.

Beim 128'er kannst du außerdem Bankswitching machen, RAM Blöcke
ein/aus-blenden, BASIC-ROM oder gar den IO-Bereich weg schalten (meine
ich) und mehr.

Der Vorläufer VIC-20 hat es noch komplizierter gemacht. Selbst nur mit
wenigen kB RAM ausgestattet änderte sich sein Speicher-layout nicht nur
mit der Größe und Zahl der RAM-Cartridges (es gab 3,5kB+- SuperExpander,
8kB und 16kB) sondern auch in Abhängikeit von eingesteckten Spiele
Kassetten (war beim C-64 ähnlich. Siehe EXROM-Leitung) und je nach dem
war das Video-ram auf einmal an einer ganz anderen Stelle und man mußte
in einer Zeropage-adresse erst nach dessen Startpunkt suchen.
BTW. Das Video-ram war auch teil des Adressraums. Nur beim VDC des 128
nicht.

Bei meinem COBOLD gab es ein kleines PROM das den Adressdekoder machte
und auch den IO-Chips ihr CS (Chip-Select) lieferte.

Und der EMUF war bewusst minimal mit nicht kompletter Adressdekodierung
gebaut. Was bedeutete das die IO-Adressen mehrfach gespiegelt im
Adressraum vor kamen. Man konnte darauf ein Programm für eine
Zielplattform bauen und gleich die IO-Range nutzen die dort gültig sein
wird. Las ich damals fasziniert hatte aber leider nie einen in die
Finger bekommen.

Aus heutiger Sicht alles ganz schön umständlich, kompliziert aber
irgendwie auch flexibel so das man auch sagen könnte "MMU's? Tool für
Weicheier" ;-)


Kay
--
Sent via SN (Eisfair-1)
Gerrit Heitsch
2019-11-22 16:47:42 UTC
Permalink
Post by Kay Martinen
Aus heutiger Sicht alles ganz schön umständlich, kompliziert aber
irgendwie auch flexibel so das man auch sagen könnte "MMU's? Tool für
Weicheier" ;-)
Im Schaltplan des EMUF-232 (den ich mir mal auf Lochraster nachgebaut
habe) wird der 74LS138 als MMU bezeichnet. Dabei tut er nichts anderes
als zwischen $8000 und $BFFF acht Blöcke mit je 2KB zu dekodieren. Zwei
davon sind von den zwei 6522 VIAs und dem 6551 UART belegt, der Rest ist
frei für eigenes.

Auch sonst ist nicht viel Logik nötig, ein 74LS04, ein 74LS00 und der
übliche 555 für den Reset.

Gerrit
Andreas Kohlbach
2019-11-22 17:40:34 UTC
Permalink
Post by Kay Martinen
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Du hast nie mit dem C-64 Programmieren versucht oder? Oder mit dem
C-128, einem 6504 EMUF oder dem COBOLD von Heise/c't?
Das Gefühl habe ich auch. Er ist ein Z80 bzw. U880 Mensch. ;-)

Bei Interesse in den 6502 (scheint alles viel einfacher als beim Z80) und
zu viel Zeit hat Herr Zaks auch dazu ein Buch geschrieben. Zum
Programmieren würde ich den VICE Emulator empfehlen, der verschiedene
Commodore Computer emulieren kann, und dort vielleicht den C64
wählen. Weil VICE einen Assembler eingebaut hat, den man jeder Zeit
mittels ALT-h aufrufen kann.
--
Andreas
Kay Martinen
2019-11-22 17:55:44 UTC
Permalink
Post by Andreas Kohlbach
Post by Kay Martinen
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Du hast nie mit dem C-64 Programmieren versucht oder? Oder mit dem
C-128, einem 6504 EMUF oder dem COBOLD von Heise/c't?
Das Gefühl habe ich auch. Er ist ein Z80 bzw. U880 Mensch. ;-)
Dann ist er doch OnTopic. Und wir... :)
Post by Andreas Kohlbach
Bei Interesse in den 6502 (scheint alles viel einfacher als beim Z80) und
zu viel Zeit hat Herr Zaks auch dazu ein Buch geschrieben. Zum
Ich weiß. Das habe ich. Und "6502 Anwendungen" vom gleichen Autor.
Post by Andreas Kohlbach
Programmieren würde ich den VICE Emulator empfehlen, der verschiedene
Commodore Computer emulieren kann, und dort vielleicht den C64
wählen. Weil VICE einen Assembler eingebaut hat, den man jeder Zeit
mittels ALT-h aufrufen kann.
Wäre für nebenher mal eine Idee. Mein C-128 hat allerdings auch einen
Maschinensprache Monitor eingebaut. IMHO wenn man beim Starten RUN/STOP
drückt landet man direkt da drin.

Kay
--
Sent via SN (Eisfair-1)
Andreas Kohlbach
2019-11-22 18:25:42 UTC
Permalink
Post by Kay Martinen
Post by Andreas Kohlbach
Programmieren würde ich den VICE Emulator empfehlen, der verschiedene
Commodore Computer emulieren kann, und dort vielleicht den C64
wählen. Weil VICE einen Assembler eingebaut hat, den man jeder Zeit
mittels ALT-h aufrufen kann.
Wäre für nebenher mal eine Idee. Mein C-128 hat allerdings auch einen
Maschinensprache Monitor eingebaut. IMHO wenn man beim Starten RUN/STOP
drückt landet man direkt da drin.
Ich gehe davon aus, dass Christoph keine Hardware besitzt, die eine 6502
CPU hat. Daher der Hinweis auf den Emulator.
--
Andreas
Ralf Kiefer
2019-11-22 18:02:44 UTC
Permalink
[...] hat Herr Zaks auch dazu ein Buch geschrieben.
Ich glaube, daß der davon lebte Bücher zu schreiben. Da gibt's noch
mehr. Ich hatte hier schon mal einen Blick auf den relevanten Teil
meines Bücherregals gezeigt:
Loading Image...

Das Z80-Buch brauche ich allerdings noch, nur um einer Nachfrage
zuvorzukommen :-)

Gruß, Ralf
Kay Martinen
2019-11-22 18:46:22 UTC
Permalink
Post by Ralf Kiefer
[...] hat Herr Zaks auch dazu ein Buch geschrieben.
Ich glaube, daß der davon lebte Bücher zu schreiben.
Scheint mir auch so.
Post by Ralf Kiefer
http://www.ralf-kiefer.de/TEMP/Stilleben.jpg
Das Z80-Buch brauche ich allerdings noch, nur um einer Nachfrage
zuvorzukommen :-)
Kannst du gerne Behalten wenn es nur um mich ginge (ich weiß, das tut es
nicht) :-)

Mich fasziniert eher ganz links der "Mac Bathroom Reader"... Was soll
das sein. Ein Buch das man NUR im Bad lesen kann/soll (Pfurzlyrik)? Von
Macbeth hab ich schon gehört, von Mac Bath noch nicht. Oder geht's um
einen Badezimmer-scanner (==reader)?

SCNR.

Kay
--
Sent via SN (Eisfair-1)
Michael Graf
2019-11-22 21:53:46 UTC
Permalink
Post by Kay Martinen
Mich fasziniert eher ganz links der "Mac Bathroom Reader"...
Ich war auch neugierig:

"The way cool Mac book you can read anywhere."

https://archive.org/details/mac_The_Mac_Bathroom_Reader_1994

Viele Grüße
Michael
Ralf Kiefer
2019-11-22 23:37:58 UTC
Permalink
Post by Kay Martinen
Mich fasziniert eher ganz links der "Mac Bathroom Reader"... Was soll
das sein.
Offensichtlich lesen US-Amerikaner ganz gerne auf der Toilette(!), wenn
sie dort ein wenig verweilen. Ich glaube, daß der ganze Hamburger-Mist
und das viele Fast Food nicht gerade verdauungsförderlich ist und sie
dort zum Lesen von Büchern kommen. Aber ich schweife ab ... :-) Und
dann lesen sie Kurzgeschichten.

In diesem Buch sind kleine Anekdoten und wahre Geschichten aus der
Macintosh-Entwicklungszeit abgedruckt. Liest sich spannend, wenn man mit
den Macs und ihrer Entwicklung aus den 1980er Jahren zu tun hat(te).

Gruß, Ralf
Andreas Kohlbach
2019-11-23 15:25:52 UTC
Permalink
Post by Ralf Kiefer
[...] hat Herr Zaks auch dazu ein Buch geschrieben.
Ich glaube, daß der davon lebte Bücher zu schreiben. Da gibt's noch
mehr. Ich hatte hier schon mal einen Blick auf den relevanten Teil
Sind das Neukäufe, oder aus den 1970er bzw. 1980ern? Dass bei einiges ein
Jahr aufgedruckt ist, hat nichts zu sagen.
Post by Ralf Kiefer
http://www.ralf-kiefer.de/TEMP/Stilleben.jpg
Oh, er hat auch eines zu CP/M gemacht. Interessant.
--
Andreas
Nils M Holm
2019-11-23 20:14:46 UTC
Permalink
Post by Andreas Kohlbach
Oh, er hat auch eines zu CP/M gemacht. Interessant.
Das "CP/M Handbook (with MP/M)" von Zaks war das CP/M Buch
schlechthin damals, ausser natuerlich Johnson-Laird's
"Programmer's CP/M Handbook", aber das war eher fuer
Programmierer waehrend das Buch von Zaks eher fuer
Anwender war. Trotzdem hat Zaks' Buch viele interessante
technische Detals enthalten!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Fritz
2019-11-24 15:03:49 UTC
Permalink
Post by Nils M Holm
Post by Andreas Kohlbach
Oh, er hat auch eines zu CP/M gemacht. Interessant.
Das "CP/M Handbook (with MP/M)" von Zaks war das CP/M Buch
schlechthin damals, ausser natuerlich Johnson-Laird's
"Programmer's CP/M Handbook", aber das war eher fuer
Programmierer waehrend das Buch von Zaks eher fuer
Anwender war. Trotzdem hat Zaks' Buch viele interessante
technische Detals enthalten!
http://oldcomputers-ddns.org/public/pub/manuals/a_programmers_cpm_handbook_(1983).pdf
--
Andreas Kohlbach
2019-11-24 17:21:29 UTC
Permalink
Post by Nils M Holm
Post by Andreas Kohlbach
Oh, er hat auch eines zu CP/M gemacht. Interessant.
Das "CP/M Handbook (with MP/M)" von Zaks war das CP/M Buch
schlechthin damals, ausser natuerlich Johnson-Laird's
"Programmer's CP/M Handbook", aber das war eher fuer
Programmierer waehrend das Buch von Zaks eher fuer
Anwender war. Trotzdem hat Zaks' Buch viele interessante
technische Detals enthalten!
Ich habe mal das PDF "Mastering CP/M" geholt. Beim dritten Kapitel bin
ich ausgestiegen, weil es mir dort schon zu heftig zur Sache ging. :-)
--
Andreas
Nils M Holm
2019-11-24 18:03:29 UTC
Permalink
Post by Andreas Kohlbach
Post by Nils M Holm
Das "CP/M Handbook (with MP/M)" von Zaks war das CP/M Buch
schlechthin damals, ausser natuerlich Johnson-Laird's
"Programmer's CP/M Handbook", aber das war eher fuer
Programmierer waehrend das Buch von Zaks eher fuer
Anwender war. Trotzdem hat Zaks' Buch viele interessante
technische Detals enthalten!
Ich habe mal das PDF "Mastering CP/M" geholt. Beim dritten Kapitel bin
ich ausgestiegen, weil es mir dort schon zu heftig zur Sache ging. :-)
Habe ich mal gesehen, aber nie reingeguckt. Nach Zaks und Johnson-Laird
gibt es, glaube ich, nicht mehr viel ueber CP/M zu lesen (zumindest bis
Version 2.2). Das "Programmer's CP/M Handbook" anthaelt eine ausfuehrliche
Beschreibung aller Datenstrukturen (FCBs, etc) und BDOS und BIOS calls,
sowie eine Anleitung zum modifizieren des BIOS. Da bleiben wirklich kaum
noch Fragen offen!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Ralf Kiefer
2019-11-24 13:14:48 UTC
Permalink
Post by Andreas Kohlbach
Sind das Neukäufe, oder aus den 1970er bzw. 1980ern?
1980 bis 1984. Die sind im Laufe der Jahre bei mir "hängengeblieben",
denn so was tut man nicht zum Altpapier. Ich selbst hatte mir damals ein
68000-Buch gekauft.


Gruß, Ralf
Andreas Kohlbach
2019-11-24 17:27:03 UTC
Permalink
Post by Ralf Kiefer
Post by Andreas Kohlbach
Sind das Neukäufe, oder aus den 1970er bzw. 1980ern?
1980 bis 1984. Die sind im Laufe der Jahre bei mir "hängengeblieben",
denn so was tut man nicht zum Altpapier. Ich selbst hatte mir damals ein
68000-Buch gekauft.
Vielleicht hast du den zukünftigen Nostalgie-Faktor damals schon erkannt.

Ich nicht, und beim ersten Umzug Bücher wie Data Beckers C64 Intern zum
Altpapier gegeben. Schon wenige Jahre später bereute ich das.
--
Andreas
Kay Martinen
2019-11-24 19:24:10 UTC
Permalink
Post by Andreas Kohlbach
Post by Ralf Kiefer
Post by Andreas Kohlbach
Sind das Neukäufe, oder aus den 1970er bzw. 1980ern?
1980 bis 1984. Die sind im Laufe der Jahre bei mir "hängengeblieben",
denn so was tut man nicht zum Altpapier. Ich selbst hatte mir damals ein
68000-Buch gekauft.
Vielleicht hast du den zukünftigen Nostalgie-Faktor damals schon erkannt.
Ich nicht, und beim ersten Umzug Bücher wie Data Beckers C64 Intern zum
Altpapier gegeben. Schon wenige Jahre später bereute ich das.
Schändlich! Das wird bestraft mit einer Nacht lang "Gyroscope" Spielen.
:-) Na gut, das nicht-mehr-vorhandene Buch ist Strafe genug. Einmal
Aussetzen!

Ich hab nix zu bereuen. Die ganzen Schlecht gedruckten Data Däcker
Schwarten liegen hier immer noch. AFAIR sogar ein C-64 intern obwohl ich
nie einen hatte. Bin vom VIC-20 direkt zum C-128 gewechselt. Und
Latürnicht kaufte man sich DAS "Buch zum Film" ähh Computer. :)

Kay
--
Sent via SN (Eisfair-1)
Ralf Kiefer
2019-11-24 22:32:48 UTC
Permalink
Post by Andreas Kohlbach
Vielleicht hast du den zukünftigen Nostalgie-Faktor damals schon erkannt.
Es gab "schon immer" Bücher, die man nicht wegwerfen sollte. Die einen
kann man am Autor erkennen, die anderen am Verlag. Addison-Wesley oder
O'Reilly standen immer ganz oben die Qualität betreffend, Data Becker
eher nicht so.

Gruß, Ralf
Peter Heitzer
2019-11-25 11:45:24 UTC
Permalink
Post by Andreas Kohlbach
Post by Kay Martinen
Post by Chr. Maercker
Es mag zwar die Programmierung vereinfachen, aber mir wäre die
Verwexlungsmöglichkeit zwischen Speicher und Peripherie suspekt. Ist
aber evtl. Geschmacks- bzw. Gewöhnungssache.
Du hast nie mit dem C-64 Programmieren versucht oder? Oder mit dem
C-128, einem 6504 EMUF oder dem COBOLD von Heise/c't?
Das Gefühl habe ich auch. Er ist ein Z80 bzw. U880 Mensch. ;-)
Wobei AFAIR auch bei div. Z80 Homecomputern mit Memory Mapped I/O gearbeitet wurde.
Die klassischen I/O Bausteine wie CTC, PIO und SIO werden aber nur via I/O Befehle
angesprochen.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Ralf Kiefer
2019-11-25 12:16:18 UTC
Permalink
Post by Peter Heitzer
Die klassischen I/O Bausteine wie CTC, PIO und SIO werden aber nur via I/O
Befehle angesprochen.
Hier liegt eine AppleBus-Karte mit einem MK3801, also einem "Serial
Timer Interrupt Controller" für die Z80-Welt von Mostek. Daneben eine
weitere AppleBus-Karte mit einem 8250. Das klappt auch mit der 65xx-Welt
:-)


Gruß, Ralf
Peter Heitzer
2019-11-25 13:33:33 UTC
Permalink
Post by Ralf Kiefer
Post by Peter Heitzer
Die klassischen I/O Bausteine wie CTC, PIO und SIO werden aber nur via I/O
Befehle angesprochen.
Hier liegt eine AppleBus-Karte mit einem MK3801, also einem "Serial
Timer Interrupt Controller" für die Z80-Welt von Mostek. Daneben eine
weitere AppleBus-Karte mit einem 8250. Das klappt auch mit der 65xx-Welt
:-)
Natürlich wurden und werden Z80 oder 8080 Bausteine auch in Fremdsystemen
verwendet.
Ich meinte, ich habe in Z80 Systemen noch nicht gesehen, daß eine SIO memory
mapped angeschlossen wurde.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Gerrit Heitsch
2019-11-22 15:01:08 UTC
Permalink
Post by Kay Martinen
Post by Chr. Maercker
Post by Kay Martinen
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt.
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Hm, Bit-test Befehle hatten die ersten AFAIR noch nicht, da musste man
das mit Shift-Befehlen und Status-Tests machen. Mit der CMOS-Variante
gab es die aber. An ein XOR erinnere ich jetzt nicht.
Der 6502 hat den BIT-Befehl. Der ist etwas eingeschränkt, aber durchaus
sinnvoll zu verwenden. Bit 7 und Bit 6 der getesteten Adresse landen in
den Statusregisterbits für Negativ (7) und Overflow (6). Klug designte
I/O hat also Status-Bits entweder auf Bit 6 oder 7.

Gerrit
Peter Heitzer
2019-11-25 11:56:02 UTC
Permalink
Post by Gerrit Heitsch
Post by Kay Martinen
Post by Chr. Maercker
Post by Kay Martinen
Post by Nils M Holm
Nicht viele?!? Im Vergleich zum 6502 war der Z80 Befehlssatz *riesig*!
IMHO werden da Befehle für High- und Low- Teil von Registern aber auch
getrennt gezählt.
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Hm, Bit-test Befehle hatten die ersten AFAIR noch nicht, da musste man
das mit Shift-Befehlen und Status-Tests machen. Mit der CMOS-Variante
gab es die aber. An ein XOR erinnere ich jetzt nicht.
Der 6502 hat den BIT-Befehl. Der ist etwas eingeschränkt, aber durchaus
sinnvoll zu verwenden. Bit 7 und Bit 6 der getesteten Adresse landen in
den Statusregisterbits für Negativ (7) und Overflow (6). Klug designte
I/O hat also Status-Bits entweder auf Bit 6 oder 7.
Wie z.B. ein HD44780 kompatibles LCD. Leider finden sich auch in Beispielen,
die so ein Display direkt an den Speicherbus hängen,
http://www.6502.org/mini-projects/optrexlcd/lcd.htm
solche Programmzeilen:

; *** Wait for LCD busy bit to clear
; registers preserved
LCDBUSY PHA
LCDBUSY0 LDA LCD0 ;read from LCD register 0
AND #$80 ;check bit 7 (busy)
BNE LCDBUSY0
PLA
RTS

Da hätte ein BIT LCD0 auch gereicht.
--
Dipl.-Inform(FH) Peter Heitzer, ***@rz.uni-regensburg.de
Chr. Maercker
2019-11-22 06:15:45 UTC
Permalink
Post by Andreas Kohlbach
Post by Chr. Maercker
Der Z80 kennt fast nur 8Bit-Befehle. Ausnahmen sind einige wenige
16Bit-Befehle wie INC HL oder ADD HL,DE. DAA kann man evtl. als
4Bit-Befehl betrachten. Was den Z80-Befehlssatz ziemlich aufbläht, sind
die vielen Ein-Bit-Befehle. Für den Einsatz als Controller sind die
bisweilen recht nützlich. Beim 8080 muss man sie mit XOR <mask>
nachbilden, analog wahrscheinlich beim 6502.
Bei Controllern sollte sich auch IN und OUT anbieten. Das kennt der 6502
AFAIK nicht.
Die Motorola-Derivate unterscheiden nicht zwischen Hauptspeicher und
IO-Ports, alles Teile des gleichen Adressraumes. Haben auch andere
Hersteller gemacht, mir ist aber lieber, wenn schon am Befehl erkennbar
ist, ob Daten zuwischen Hauptspeicher oder Peripherie ausgetauscht werden.
--


CU Chr. Maercker.
K. Krause
2019-11-25 10:44:53 UTC
Permalink
Um mal wieder auf den Ausgangspunkt zurückzukommen:
Hast Du denn inzwischen einen brauchbaren Zaks erhalten, oder ist das
hier komplett untergegangen?


On 22.11.19 07:15, Chr. Maercker wrote:
...
Post by Chr. Maercker
Die Motorola-Derivate unterscheiden nicht zwischen Hauptspeicher und
IO-Ports, alles Teile des gleichen Adressraumes. Haben auch andere
Hersteller gemacht, mir ist aber lieber, wenn schon am Befehl erkennbar
ist, ob Daten zuwischen Hauptspeicher oder Peripherie ausgetauscht werden.
--
Das kann man auch über Variablennamen kenntlich machen.
Ich werde ja keinen Assemblercode schreiben, in dem z. B. ein I/O-Port
"LOOPCOUNTER" heisst und eine Variable im Speicher "PORT_A".


Was meistens nicht erwähnt wird: kein Z80-Systemdesigner ist gezwungen,
die I/O-Befehle und die damit verbundene Hardware zu verwenden.
Natürlich kann man mit dem Z80 auch Memory-Mapped-IO machen.
Man hat die Wahl. :-)
Bei 6xyy-Systemen hat man sie nicht. :-(
Mir sind auch schon kommerzielle Z80-Systeme untergekommen, in denen
68xx-Peripherie verbaut worden war.

Klemens
Nils M Holm
2019-11-25 11:23:44 UTC
Permalink
Post by K. Krause
Hast Du denn inzwischen einen brauchbaren Zaks erhalten, oder ist das
hier komplett untergegangen?
Bisher ein follow-up von jemandem, der mal nachsehen wollte und das
Angebot von Michael, das aber leider auf Deutsch waere. D.h., nein,
bisher habe ich kein definitives Angebot ueber ein Englisches Exemplar
bekommen.

Ich wuerde es ja auch antiquarisch kaufen, aber da finde ich nur Angebote
aus UK und USA, und da koennen die Lieferzeiten um Weihnachten herum schon
abenteuerlich sein!
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Bernd Laengerich
2019-11-25 12:03:02 UTC
Permalink
Post by Nils M Holm
Ich wuerde es ja auch antiquarisch kaufen, aber da finde ich nur Angebote
aus UK und USA, und da koennen die Lieferzeiten um Weihnachten herum schon
abenteuerlich sein!
Unter ZVAB bekommt man nur deutsche Exemplare zu Fantasiepreisen.
Da könnte man schon überlegen das PDF ausdrucken und binden zu lassen.

Bernd
Nils M Holm
2019-11-25 13:33:31 UTC
Permalink
Post by Bernd Laengerich
Post by Nils M Holm
Ich wuerde es ja auch antiquarisch kaufen, aber da finde ich nur Angebote
aus UK und USA, und da koennen die Lieferzeiten um Weihnachten herum schon
abenteuerlich sein!
Unter ZVAB bekommt man nur deutsche Exemplare zu Fantasiepreisen.
Da k?nnte man schon ?berlegen das PDF ausdrucken und binden zu lassen.
Etwas besseres als Copythek-Bindung darf es schon sein, und da ist man
dann doch recht schnell wieder im Bereich der Fantasiepreise fuer ein
Einzelexemplar!

Wenn ich hier keins bekomme, bestelle ich eben eine Ausgabe in den USA.
Die kommt zwar evtl erst naechstes Jahr an, aber besser spaet als nie! :)
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Bernd Laengerich
2019-11-25 12:08:28 UTC
Permalink
Post by K. Krause
Mir sind auch schon kommerzielle Z80-Systeme untergekommen, in denen
68xx-Peripherie verbaut worden war.
Klassiker sind die Nutzung eines 6850 ACIA und eines 6845 CRT-Controllers.

Bernd
Ralf Kiefer
2019-11-25 12:16:18 UTC
Permalink
Post by K. Krause
Mir sind auch schon kommerzielle Z80-Systeme untergekommen, in denen
68xx-Peripherie verbaut worden war.
Der 6845 hat's "sogar" auf eine große Generation von ISA-Karten
geschafft: die Hercules-Karte.

Gruß, Ralf
Hans-Juergen Lukaschik
2019-11-21 08:51:10 UTC
Permalink
Hallo Nils,

am Dienstag, 19 November 2019 19:15:42
Post by Nils M Holm
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von
Rodney Zaks, "Programming the Z80"
uebrig?
Ich muss mal nachsehen. Könnte sein, dass das hier noch rum liegt.

MfG Hans-JÃŒrgen
--
http://lukaschik.de/rezepte/
www.fischereiverein-rietberg.net
Fischrezepte: www.fischereiverein-rietberg.net/?category_name=rezepte
SeefischREZ: www.fischereiverein-rietberg.net/?category_name=seefisch
Nils M Holm
2019-11-21 12:02:59 UTC
Permalink
Post by Hans-Juergen Lukaschik
am Dienstag, 19 November 2019 19:15:42
Post by Nils M Holm
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von
Rodney Zaks, "Programming the Z80"
uebrig?
Ich muss mal nachsehen. K?nnte sein, dass das hier noch rum liegt.
Das waere echt cool! Wenn, dann schreib' mir, was Du dafuer haben
willst! (Mail in der signature funktioniert!)
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Michael Engel
2019-11-22 18:47:00 UTC
Permalink
Post by Nils M Holm
Hat zufaellig jemand eine einigermassen gut erhaltene Ausgabe von
Rodney Zaks, "Programming the Z80"
uebrig? Als PDF habe ich es, aber nachschlagen auf Papier ist
einfach bequemer! Ich will es auch nicht geschenkt haben!
Ich könnte mit der deutschen Übersetzung dienen, die liegt wegen
Umzug eh grade auf dem "will ich das behalten?"-Stapel... Wenn ich
mich recht erinnere, war die nicht sonderlich grausam :-).

-- Michael
Nils M Holm
2019-11-22 20:46:29 UTC
Permalink
Ich k?nnte mit der deutschen ?bersetzung dienen, die liegt wegen
Umzug eh grade auf dem "will ich das behalten?"-Stapel... Wenn ich
mich recht erinnere, war die nicht sonderlich grausam :-).
Danke, aber ich spekuliere immernoch auf eine Englische Ausgabe! :)
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Loading...