Hallo, ich sitze aktuell an einer Arbeit und lies dazu einige (teilweise sehr alte) Veröffentlichungen. Z.B. Formal Requirements for Virtualizable Third Generation Architectures von Popek und Goldberg. Dabei bin ich auf folgenden Satz gestossen: " In the DEC PDP-11, I/O devices are treated as memory ceils and I/o operations are performed by doing the proper memory transfer to the appropriate cell. " Jetzt frage ich mich: War den DEC der erste Computer, bei dem I/O Zugriffe über Register eines linearen Speicher gemacht wurden? Oder war es der erste kommerziell erfolgreiche? Und: Gabs den dann bei den Konkurrenzprodukten extra I/O Instruktionen?
:
Verschoben durch User
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.
:
Bearbeitet durch User
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. Das man das heute so mamcht ist mir Bewusst. Aber heute != 1970er... Die Frage war ja ob das Konkurrenzprodukte anders gemaacht haben und: A. K. schrieb: > IBM 360: selbständig arbeitende Kanalwerke mit DMA. > > CDC 6600: separater I/O-Rechner (multithreaded) mit Zugang zum Speicher, > kein I/O-Zugriff durch Hauptrechner. A. K. schrieb: > 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. Offensichtlich lässt sich diese Frage mit ja beantworten! Danke für die Hinweise!
ui schrieb: > A. K. schrieb: >> 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. > > Offensichtlich lässt sich diese Frage mit ja beantworten! Danke für die > Hinweise! Häh, wie beweisen dir zwei Nennungen das pdp-11 der erste war? Schon mal den Apollo Guidance Computer betrachtet? Oder die Rechner der Wang Laboratories?
Bitwurschtler schrieb: > Häh, wie beweisen dir zwei Nennungen das pdp-11 der erste war? Schon mal > den Apollo Guidance Computer betrachtet? Oder die Rechner der Wang > Laboratories? Ich suche ja nicht nach einem Beweis. Ich habe nur gefragt, was denn zu der Zeit so üblich war. Wenn du dazu was weißt, dann sag es!
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?
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. 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.
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.
A. K. schrieb: > AVRs sind konsequent memory mapped, mit ein paar zusätzlichen Befehlen > für platzsparende Adressierung. Immerhin sind die speziellen I/O Befehle schneller (IN/OUT 1 Takt vs. LDS/STS 2 Takte) und das Manipulieren von I/O Bits sehr viel schneller (1 od. 2 Takte vs. 5 Takte).
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, ...
:
Bearbeitet durch User
Beitrag #5014795 wurde vom Autor gelöscht.
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.
:
Bearbeitet durch User
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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.