DEC PDP-11 - erster Computer ohne spezielle I/O Befehle?

ui schrieb:
> Und: Gabs den dann bei den
> Konkurrenzprodukten extra I/O Instruktionen?

TI 990: Getrennte Befehle für I/O-Space, 1 Bit breiter Datenbus.

Data General Nova: Separate I/O-Befehle aber keine einfache 
Adressierung, sondern an Kanalwerke erinnernd.

Naja, was soll ich sagen. Wie haette man denn IO sonst machen wollen ? 
Das macht man ja heute noch so. Ein UART Register ist auf einer 
Speicherstelle. Und wird wie Memory adressiert.

Sapperlot W. schrieb:
> Naja, was soll ich sagen. Wie haette man denn IO sonst machen wollen ?

IBM 360: selbständig arbeitende Kanalwerke mit DMA. Der Prozessor 
steuert das Kanalwerk.

CDC 6600: separater I/O-Rechner (multithreaded) mit Zugang zum Speicher, 
kein I/O-Zugriff durch Hauptrechner.

Sapperlot W. schrieb:
> Naja, was soll ich sagen. Wie haette man denn IO sonst machen wollen ?
> Das macht man ja heute noch so. Ein UART Register ist auf einer
> Speicherstelle. Und wird wie Memory adressiert.

Nö, Intel hat schon immer getrennte Auswahlleitungen für Speicher und 
I/O angeboten. Und das ist bis heute so geblieben in unzähligen PC aka 
'IBM Kompatiblen'.

Wird I/O in PCs heute nicht überwiegend über Datenadressen angesprochen?

Icke schrieb:
> Selbst der AVR hat noch getrennte I/O Befehle (IN, OUT, SBI, CBI), auch
> wenn sich I/O (in uCs mit SRAM) auch memory-mapped (LDS, STS) ansprechen
> läßt oder sogar angesprochen werden muss.

Die IN/... sind nur deshalb I/O-Befehle, weil sich in deren Kurzform der 
Datenadresse zufällig die I/O befindet. Etliche AVRs haben da sogar ein 
paar Bytes RAM drin, damit man mit CBI/SBI elegant Flags implementieren 
kann.

A. K. schrieb:
> Wird I/O in PCs heute nicht überwiegend über Datenadressen angesprochen?

Kann man machen, muss aber nicht. An z.B. PCI Slots liegen I/O-, 
Speicher- und Konfiguration Auswahlsignale an:
https://en.wikipedia.org/wiki/Conventional_PCI#PCI_address_spaces

Traditionell sind bis heute die grundlegenden Register von z.B. 
Grafikkarte, Onboard Quäker und UART immer noch im I/O Space. Auch die 
Chipset Register sind normalerweise im I/O Space, ebenso die RTC usw.

Icke schrieb:
> Selbst der AVR hat noch getrennte I/O Befehle (IN, OUT, SBI, CBI), auch
> wenn sich I/O (in uCs mit SRAM) auch memory-mapped (LDS, STS) ansprechen
> läßt oder sogar angesprochen werden muss.

AVRs sind konsequent memory mapped, mit ein paar zusätzlichen Befehlen 
für platzsparende Adressierung.

Icke schrieb:
> Immerhin sind die speziellen I/O Befehle schneller

Klar. Bei IN/OUT vs LDS/STS ganz simpel weil kürzer, 1 Wort statt 2. Das 
war bei 6500/6800ern mit RAM und I/O in der zero page auch nicht 
anders.

> und das Manipulieren von I/O Bits sehr viel schneller

Das ändert nichts daran, dass die I/O memory mapped ist. Es gibt eben 
nur zusätzliche Befehle für einen eng begrenzten Adressbereich. Etwas 
besonders ist jene optimierte AVR-Mikroarchitektur, die für diese 
read/modify/write Befehle keine separaten Zyklen mehr verwendet.

Es gibt also spezielle Befehle, aber keine Adressraumtrennung.

Matthias S. schrieb:
> Nö, Intel hat schon immer getrennte Auswahlleitungen für Speicher und
> I/O angeboten.

Bei 8051 nicht. Wahrscheinlich auch nicht bei 8096, i860, i960, ...

Auch wenn die Auswahlleitungen von I/O und RAM unterschiedlich sind, 
liegen die IO immer noch am selben Adress- und Datenbus, und man kann's 
immer noch so einbauen wie man's will.

DMA Kanaele kann man auch nehmen. Heute sind DMA Kanaele auch am selben 
Bus, der Buscontroller unterhaelt einfach noch ein paar zusaetzliche 
Zaehler und Controleinheiten.

Sapperlot W. schrieb:
> Auch wenn die Auswahlleitungen von I/O und RAM unterschiedlich sind,
> liegen die IO immer noch am selben Adress- und Datenbus, und man kann's
> immer noch so einbauen wie man's will.

Der CDP1802 hat nicht nur spezielle I/O-Befehle, sondern auch getrennte 
Adressleitungen für I/O.

Sapperlot W. schrieb:
> Auch wenn die Auswahlleitungen von I/O und RAM unterschiedlich sind,
> liegen die IO immer noch am selben Adress- und Datenbus, und man kann's
> immer noch so einbauen wie man's will.

Man sollte hier sehr deutlich zwischen Bussen und Adressräumen 
unterscheiden. Die IOs können durchaus mit dem Speicher zusammen dort 
hängen, aber ohne die speziellen IO-Befehle gibt es ggf. keine 
Möglichkeit, sie anzusprechen.

Streng genommen ist es aber auch bei der Speicheradressräumen nicht 
anders. Bei Prozessoren, die sich an die Harvard-Architektur anlehnen, 
sind Programm- und Datenadressräume streng voneinander getrennt. 
Allerdings werden sie bei den meisten Universalprozessoren extern wieder 
zusammengeführt und nicht einmal mehr über separate Steuerleitungen 
unterschieden. Nur Caches werden teilweise separat realisiert.

Einige ältere Prozessoren haben die Trennung sogar noch strenger 
durchgeführt. Beim Philips PCB5010/5011 gab es sogar komplett getrennte 
Adressräume und externe Busse für Programmspeicher, ROM-Daten, X-Daten 
und Y-Daten. Letzteres bedeutet, dass bei Rechenoperationen streng 
zwischen erstem und zweitem Parameter unterschieden wurde. Ergebnisse 
konnten wahlweise in den Speicher im X- oder Y-Adressraum geschrieben 
werden. Für nur zu lesende Daten gab es dann ein Koeffizienten-ROM, z.B. 
für Sinustabellen o.ä..

Bei mir zuhause liegt aber noch eine halbfertige, selbstentwickelte 
Einsteckkarte für ISA-Steckplätze herum. Irgendwann werde ich versuchen, 
die 3,5"-Disketten mit der Entwicklungsumgebung auf einem alten Rechner 
einzulesen. Davon werde ich es dann abhängig machen, ob ich mir 
irgendwann als Rentner oder so den PCB5011 noch einmal herausholen 
werde. Das dauert aber noch rund zwanzig Jahre.

Die Prozessorarchitektur hat sich aber nicht wirklich durchgesetzt. 
Vielleicht wurde sie ja von Josef G. entwickelt. ;-)

Andreas S. schrieb:
> Bei Prozessoren, die sich an die Harvard-Architektur anlehnen,
> sind Programm- und Datenadressräume streng voneinander getrennt.
> Allerdings werden sie bei den meisten Universalprozessoren extern wieder
> zusammengeführt und nicht einmal mehr über separate Steuerleitungen
> unterschieden. Nur Caches werden teilweise separat realisiert.

Das beschreibt ein Szenario mit teilweise getrennten Bussen aber 
gemeinsamem Adressraum.

Man kann Harvard an Adressräumen oder Datenbussen festmachen. Letzteres 
führte jenseits von Harvard Mark I recht schnell zu Problemen.

> Einige ältere Prozessoren haben die Trennung sogar noch strenger
> durchgeführt. Beim Philips PCB5010/5011 gab es sogar komplett getrennte
> Adressräume und externe Busse für Programmspeicher, ROM-Daten, X-Daten
> und Y-Daten. Letzteres bedeutet, dass bei Rechenoperationen streng
> zwischen erstem und zweitem Parameter unterschieden wurde.

Bei DSPs sind komplizierte Fälle mit mehreren internen Datenbussen und 
einer Kopplung derer an Positionen im Opcode nicht so selten.

A. K. schrieb:
> Wird I/O in PCs heute nicht überwiegend über Datenadressen
> angesprochen?

Der PCI-Bus wird über I/O-Befehle (Ports 0xCF8 und 0xCFC) konfiguriert. 
Obwohl die Karten I/O anbieten können, ist das eher eine 
Kompatiblitätssache (für die IDE- und VGA-Ports).

Die ganzen "klassischen" PC-Devices werden alle über I/O-Befehle 
angesprochen (PIC, PIT, KBC), wobei deren neuere Varianten (APIC, HPET) 
memory-mapped sind.

S. R. schrieb:
> Der PCI-Bus wird über I/O-Befehle (Ports 0xCF8 und 0xCFC) konfiguriert.

Das ist aber nur das Mapping des Configuration Space in die 
PC-Architektur. Der Configurations Space ist auf dem PCI-Bus aber 
eigentlich normaler Speicher, nur halt mit IDSEL (und speziellen 
R/W-Kommandos) qualifiziert. Das hätte man auf dem PC auch direkt per 
Memory-Mapping einbinden können, wenn das aufgrund der vielen möglichen 
Devices nicht soviel Speicher geklaut hätte...

Georg A. schrieb:
>> Der PCI-Bus wird über I/O-Befehle (Ports 0xCF8 und 0xCFC) konfiguriert.
> Das ist aber nur das Mapping des Configuration Space in die
> PC-Architektur.

Ändert aber nichts daran, dass man I/O-Befehle benutzen muss, um 
PCI-Geräte zu enumerieren und zu konfigurieren. :-) Benutzen tut man 
sie danach in aller Regel memory-mapped.

S. R. schrieb:
> Ändert aber nichts daran, dass man I/O-Befehle benutzen muss, um
> PCI-Geräte zu enumerieren und zu konfigurieren.

Aber eben nur auf dem PC... Der PCI-Bus selbst hat zwar auch 
IO-Kommandos (sonst wäre er für die PC-Architektur nicht durchsetzbar 
gewesen), die sind aber aber mindestens seit PCIe "deprecated".

Georg A. schrieb:
> Das hätte man auf dem PC auch direkt per
> Memory-Mapping einbinden können, wenn das aufgrund der vielen möglichen
> Devices nicht soviel Speicher geklaut hätte...

Die kleinen Adressräume waren wohl auch die maßgeblichen Gründe für die 
Trennung von Speicher- und I/O-Adressen - genau wie für die 
Harvard-Architektur auch.

Dass es dann Leute gab, die aus der Not eine Tugend machen wollten, ist 
ein anderes Thema.

Sapperlot W. schrieb:
> Heute sind DMA Kanaele auch am selben Bus,

Heute ist es eher so, dass es bei Rechnern jenseits von CPU-Kern und 
Speichermodulen überhaupt keine Busse mehr gibt. PCIe ist kein Bus, 
sondern Punkt zu Punkt.

Der Z80 kann sogar 64K als I/O ansprechen.
Dokumentiert sind zwar nur 256, wei beim 8080.

Wenn aber ein i/o zugriff via out(c)/in(c) aktiv ist, wird auch das 
B-register auf dem Bus gelegt.

also

LD b , HI(nn)
ld c , nn and $FF

out(c),n

Der ZX-Spectrum und auch Zx81 machten davonn gebrauch.

Gerade die undokumentierten befehle des Z80 waren so oft in verwendung, 
daß kein nachbau darauf verichten durfte/konnte.

Michael F. schrieb:
> Der ZX-Spectrum und auch Zx81 machten davonn gebrauch.

AFAIR beim Lesen der Tastaturmatrix. Damit konnte man die die zu lesende 
Spalte über B auswählen. Hat ein paar externe FFs gespart, die ULA hätte 
ohnehin keine Pins mehr dafür gehabt...

Michael F. schrieb:
> Wenn aber ein i/o zugriff via out(c)/in(c) aktiv ist, wird auch das
> B-register auf dem Bus gelegt.

Dies galt nicht nur für OUT (c),r bzw. IN r,(C), sondern auch für OUT 
(n), A bzw. IN A,(n).

> out(c),n

Diesen Befehl gab es nie. Alle I/O-Befehle mit C als Adresse erforderten 
ein weiteres Register für die Daten. Die unmittelbare Adressierung war 
nur mit dem Akkumulator möglich, d.h. OUT (n),A bzw. IN A,(n). Die 
komplexen I/O-Befehle INI, INIR, IND, INDR, OUTI, OTIR, OUTD, OTDR 
arbeiteten ausschließlich mit Register C, wobei B aber auch nicht als 
Adresserweiterung nach Belieben zur Verfügung stand, sondern als 
Schleifenzähler verwendet wurde. Mir ist nicht bekannt, ob es jemals 
irgendeine(n) Peripheriebaustein oder -baugruppe gegeben hat, die 
bewusst den (herunterzählenden) Schleifenzähler B zur Adressierung 
verwendet haben.

Bemerkenswert finde ich, dass fast alle anderen Schleifenbefehle mit BC 
statt B arbeiteten, außer DJNZ, welcher auch nur B statt BC verwendete.

> Gerade die undokumentierten befehle des Z80 waren so oft in verwendung,
> daß kein nachbau darauf verichten durfte/konnte.

Damals(tm) waren meine größten Träume, bei einem Mikroprozessor einen 
undokumentierten Befehl zu finden oder ein neues Elementarteilchen 
(Schweigstillion) zu entdecken und damit berühmt zu werden. Eben so, wie 
andere Leute Rockstar werden wollten.

Andreas S. schrieb:
> Schweigstillion

Leider ist das Teilchen so leise, dass es keiner gehört hat...

ja ist richtig das n ist das register.

http://z80-heaven.wikidot.com/instructions-set:out

Die sogenannte undokumentierten befehle wurden sehr schnell zu 
standardbefehlen.

Bei einem Z180 wurde der befehlsinterpreter überarbeitet, so das eben 
nicht alle undokumentierten mehr laufen.

Ich binn beim schreiben meines Z80emus auf die problematik ( vor 16 
jahren ) gestoßen.

Andreas S. schrieb:
>> out(c),n
>
> Diesen Befehl gab es nie. Alle I/O-Befehle mit C als Adresse erforderten
> ein weiteres Register für die Daten.

Fast alle: IN (C) und OUT (C),0 nicht.
Ok, offiziell sind die nicht.