Olivetti P6060

Das ist das Gerät, so wie ich sie auf der CC aus Dresden (!) vorbeigebracht bekommen habe. Da kann jetzt erstmal dirkt damit Spaß haben. Hoffe ich jedenfalls. Dabei sind rund 50 Disketten mit Software aus der Baubranche vom ursprünglichen Besitzer und wohl auch Software vom letzten Besitzer, außerdem das originale deutsche Betriebs und Programmierhandbuch und ein Handbuch für den nicht mehr erhaltenen externen Plotter. Kaufpreis so wie sie jetzt da steht im Jahr 1975 lag bei 35.000 DM, das entspricht etwa einem damaligen Mercedes 280SE, optional gab es auch eine Grafikkarte mit Monitor, 80x25 Zeichen und grafikfähig, was den Verkaufspreis verdoppelte. Die P6060 war der erste Tischcomputer der Welt mit eingebautem Floppylaufwerk.

Sonst wäre wahrscheinlich auch Raffzahn daran interessiert.

Auch an den Disks...

Zitat von dirkt

Die 8-Zoll Floppies sind im IBM/360-Format. Die Systemfloppy enthält drei Datasets für das System, nämlich P6FWR (mit Versionsnummer) für die Resident Firmware (MIkrocode),

P6FWO für die Overlay-Firmware, und P6FSW für das eigentliche Betriebssystem in IBM/360-Maschinensprache. Das Betriebsystem ist in Module untergliedert, die dynamisch geladen werden.

Für die Benutzerdaten gibt es ein weiteres Partioned Dataset namens P6FSYS.

Woher hast du diese Informationen?

1978 hab ich am Wirtschaftsgymnasium auf so einem System BASIC gelernt.

Aus Neugier habe ich eine Diskette mitgenommen und in eine IBM 3741 gesteckt.

Es gab nur eine Fehlermeldung dass die Diskette ungültig sei.

Eine VTOC konnte ich nicht erkennen.

Ich habe die gleiche Frage wie Pyewacket : trotz intensiver Suche konnte ich keinen Hinweis finden, dass der 6060 Prozessor den IBM /360 Maschinencode emuliert. Das würde doch nur Sinn machen, wenn Olivetti Softwarelizenzen von IBM für /360 Software genommen hätte.

Zu den eingangs genannten Patenten ist zu sagen, dass sie außerhalb USA nie erteilt wurden, sondern im Zustand der Offenlegung bis zur Zurücknahme verharrten. Das ist nicht unüblich, Firmen machen das, wenn die Erfindungshöhe zweifelhaft ist. Man hat dann zwar keinen Patentschutz (in Europa), aber es schafft einen Stand der Technik, den andere nicht für eigene Patente nutzen können.

Roland

So wie mir das Raffzahn erklärt hat, geht es mehr um die internen Peripherie Busse.

Aber vielleicht will er hier ja Licht in unser Halbwissen werfen?

Auf Archive.org gibts eine ganze Menge Doku zur P6060, blöd ist nur, wenn man auf der Hauptseite danach sucht, wird sie nicht gefunden. dirk und ich haben die uns aber schon gesichert. Ich habe aber noch nicht rein geschaut, dirk aber schon, daher hat er diese Erkenntnisse.

Wenn man aber per Google sucht und das Ergebnis auf archive.org reduziert, wird man fast schon erschlagen... klick

Zitat von 1ST1

Wenn man aber per Google sucht und das Ergebnis auf archive.org reduziert, wird man fast schon erschlagen... klick

Die hatte ich auch gefunden, sind aber auf italienisch.

Beim durchblättern ist mir die Ähnlichkeit des Befehlssatzes mit IBM 360 auch aufgefallen.

Warum das so gemacht wurde weiss ich nicht. Schaut man sich den IBM5100 ff an arbeiten die auch nach

diesem Prinzip. Vielleicht hatte Olivetti das BASIC irgendwo dazugekauft?

dirkt vermutet, dass Olivetti noch "was größeres" vor hatte, was IBM /360 kompatibel sein hätte sollen.

super, danke ! Das führt schon mal weiter. Und in der Tat: der 6060 Assembler ist bzgl. Syntax dem /360 Assembler sehr sehr ähnlich. Und der Maschinencode ist (nach kurzer Durchsicht geschätzt) zu 75% binärkompatibel zum /360 Code. Es gibt aber auch deutliche Differenzen, die der anderen Architektur der 6060 geschuldet sind (zB Stack-Kommandos) - interessante Maschine !

Roland

Roland_t29 , denk nochmal über das Angebot nach, Dirk ist auch dafür... Du hast ja dann gleich den Dirk, der sich drum kümmert...

Das größte Problem ist halt etwa 1m² Platz wo sie stehen kann und was bei geschätzt 40kg nicht zusammenbricht.

Zitat von Pyewacket

Warum das so gemacht wurde weiss ich nicht. Schaut man sich den IBM5100 ff an arbeiten die auch nach

diesem Prinzip. Vielleicht hatte Olivetti das BASIC irgendwo dazugekauft?

Die IBM 5100 emuliert die /360 bzw eine /3 komplett, da das APL bzw BASIC von den jew. Plattformen übernommen wurde - so macht das Sinn. Dadurch ist die 5100 aber trotz 16 Bit 2 MHz Prozessor wegen der vielen Emulations-Layers sehr langsam

Roland

Zitat von 1ST1

Roland_t29 , denk nochmal über das Angebot nach, Dirk ist auch dafür... Du hast ja dann gleich den Dirk, der sich drum kümmert...

Das größte Problem ist halt etwa 1m² Platz wo sie stehen kann und was bei geschätzt 40kg nicht zusammenbricht.

so verführerisch das ist, wir schaffen das platzmäßig nicht adäquat. Unsere IBM 5100 musste auch schon von ihrem angestammten Platz weichen, weil wir Platz brauchen

Roland

Zitat von dirkt

Weil ich hier Diskimages habe, und die entsprechenden Teile extrahieren kann, und es bis jetzt den IBM-Formaten folgt, zumindest laut IBM-Dokumentation.

Allerdings ist alles ASCII statt EBCDIC, und ich bin mir auch nicht sicher, ob alle Felder so mit Daten belegt sind, dass es eine IBM versteht. Ich habe auch keine echten IBM/360 Images zum Vergleichen.

Aber das Ganze sieht schon verdammt so aus also ob sie mindestens mal das Bootstrapping mit Hilfe einer IBM gemacht hätten.

Wenn das ASCII ist wundert es mich nicht dass die 3741 die Diskette nicht erkannt hat.

Eine genaue Beschreibung wie die einzelnen Sektoren initialisiert sind kann man hier finden. Die angegebenen HEX Werte stimmen bei ASCII nur bedingt..

http://www.bitsavers.org/pdf/ibm/floppy/GA21-9182-3_Diskette_General_Information_Manual_Sep77.pdf

Zitat von horniger

So wie mir das Raffzahn erklärt hat, geht es mehr um die internen Peripherie Busse.

Aber vielleicht will er hier ja Licht in unser Halbwissen werfen?

Jaja, immer mich mit reinziehen. Ok, gut, ich bin spezialisiert in Halbwissen:))

Und nein, es ist nicht der Peripheriebus, sondern die CPU die die P606x /360 kompatibel macht.

Der Peripheriebus ist der wie er zuerst für dieP102 verwendet wurde. Und ja, P102, nicht P101. Die P102 war eine weniger bekannte Weiterentwicklung für die Britische Armee und andere Kunden mit viel Kleingeld. Der Bus wurde anschließend bei den P6xx verwendet, der P606x (es gab noch eine erweiterte P6066, erkennbar am grauen Gehäuse), den BCS und den Bankensystemen verwendet.

Zitat von Roland_t29

Ich habe die gleiche Frage wie Pyewacket : trotz intensiver Suche konnte ich keinen Hinweis finden, dass der 6060 Prozessor den IBM /360 Maschinencode emuliert. Das würde doch nur Sinn machen, wenn Olivetti Softwarelizenzen von IBM für /360 Software genommen hätte.

Warum? Auch andere können Software schreiben. An der Stelle sollte man nicht vergessen, dass die Geschichte von Olivetti extrem ... aeh, sagen wir mal vielfältig war. So gab es auch eine Zeit als Mainframehersteller. Das brachte nur die äußerst bemerkenswerte ELEA 9003 / 6001 Ende der 50er Jahre, sondern auch /360 kompatible Rechner in den 60ern und 70ern. Dazwischen die ELEA 9004 und 4001, jeweils inkompatible miteinander und vorherigen und späteren Modellen. Ich wills jetzt nicht behaupten, aber dieser Wildwuchs kann durchaus mit ein Grund gewesen sein warum Olivetti sich ende der 70er aus dem Geschäft verabschiedete.

Zitat von Pyewacket

Zitat von 1ST1

Wenn man aber per Google sucht und das Ergebnis auf archive.org reduziert, wird man fast schon erschlagen... klick

Die hatte ich auch gefunden, sind aber auf italienisch.

Beim durchblättern ist mir die Ähnlichkeit des Befehlssatzes mit IBM 360 auch aufgefallen.

Warum das so gemacht wurde weiss ich nicht. Schaut man sich den IBM5100 ff an arbeiten die auch nach

diesem Prinzip. Vielleicht hatte Olivetti das BASIC irgendwo dazugekauft?

Da Olivetti bereits /360artige Mainframes im program hatte macht es auf jeden Fall 1974 viel Sinn auch den ersten Desktop auf Basis einer CPU nach /360 Art zu bauen. Und nein, nicht weil man irgendwo Software zukaufte - dass war meines Wissens alles Eigenentwicklung - sondern weil man die Hardwareentwicklung eh schon im Haus hat.

Zitat von 1ST1

dirkt vermutet, dass Olivetti noch "was größeres" vor hatte, was IBM /360 kompatibel sein hätte sollen.

Fast. Olivetti hatte VORHER schon was /360 kompatibles im Program

Zitat von Roland_t29

super, danke ! Das führt schon mal weiter. Und in der Tat: der 6060 Assembler ist bzgl. Syntax dem /360 Assembler sehr sehr ähnlich. Und der Maschinencode ist (nach kurzer Durchsicht geschätzt) zu 75% binärkompatibel zum /360 Code. Es gibt aber auch deutliche Differenzen, die der anderen Architektur der 6060 geschuldet sind (zB Stack-Kommandos) - interessante Maschine !

Olivetti hat natürlich wie eigentlich alle damaligen Herstelle von /360 kompatiblen Rechnern eigene Erweiterungen. Ähnlich wie NEC in ihrer V20, oder AMD mit AMD 64 in der x86 Welt eigene Erweiterungen hatte. Siemens hatte z.B. auch einige sehr interessante Erweiterungen in ihren X-CPU. U.A. auch stackartige Befehle - aber nicht nur einen sondern gleich 2 verschiedene Ansätze. Letztendlich hat es die IBM ja auch vorgemacht. Zum einen gab es über die Jahre eine ganze reihe von /360 basierten Entwicklungen, zum anderen natürlich eine schier unglaubliche Anzahl von Erweiterungen für die eigentlichen /360 /370 /390/ etc. Wer sich mal die aktuellen Z-Series anschaut, der wird nie wieder behaupten dass ein Pentium eine CISC CPU ist :))

Kompatibilität in dem Bereich bedeutete immer nur dass der /360 (bzw. /370) User-Mode-Befehlssatz der gleiche ist wie bei der IBM Hauptlinie. Das heist, dass Kunden die man von IBM abgeworben hat ihre User-Land Programme mit geringem Aufwand auf Siemens, Olivetti, Hitachi, Amdahl, etc. portieren konnten. Am Umgekehrten weg hatte keiner dieser Hersteller irgend ein Interesse.

Nicht Vergessen, der Mainframemarkt bestand und besteht bis heute fast komplett aus Individual-Programmen.

Wenn man also /360 Kompatibilität in dem Bereich messen will, dann ist die Frage nicht wieviel Anteil hat der /360-gleiche Teil an der Maschine, sondern wieviel % des nicht privilegierten /360 Befehlssatz ist 1:1 vorhanden. Ich hab jetzt nicht nochmal nachgeschaut, aber in meiner Erinnerung geht das bei der P6060 gegen 100%

Zitat von Roland_t29

Zitat von 1ST1

Roland_t29 , denk nochmal über das Angebot nach, Dirk ist auch dafür... Du hast ja dann gleich den Dirk, der sich drum kümmert...

Das größte Problem ist halt etwa 1m² Platz wo sie stehen kann und was bei geschätzt 40kg nicht zusammenbricht.

so verführerisch das ist, wir schaffen das platzmäßig nicht adäquat. Unsere IBM 5100 musste auch schon von ihrem angestammten Platz weichen, weil wir Platz brauchen

Oh, ich wüsste da einen Platz - direkt neben unserer 5110 :))

Ansonsten, die P6060 ist ein wirklich bemerkenswerter Rechner - und durchaus zusammen mit einer P652 darstellbar (beide verwenden die Gleiche I/O).

Zitat von dirkt

Zitat von Pyewacket

Wenn das ASCII ist wundert es mich nicht dass die 3741 die Diskette nicht erkannt hat.

Aus dem Link habe ich ja die Beschreibung, wie es aussehen soll

Und ich weiß, dass es zumindest bei z/OS da auch irgendwelche ASCII-Varianten gibt; aber keine Ahnung, ob es die damals auch schon gab. Und evtl. haben sie den Bootstrap auch noch mit EBCDIC gemacht, und der wurde dann irgendwann mit der ASCII-Version ersetzt, sobald sie die Entwicklung auf die P6060 selbst verschoben haben. Aber das sind natürlich alles nur Spekulationen.

Nicht vergessen dass die /360 ursprünglich für die Arbeit mit ASCII gedacht war. Erst mit der /390 wurde der ASCII Modus rausgeworfen. Wobei das eigentlich nur beim Packen/Entpacken eine Rolle spielt. Für alles andere ist es eh egal welchen Code man verwendet.

Was die Entwicklung anbelangte, so erfolgte die wohl eher auf Olivetti's eigenen /360artigen Mainframes :))

Ansonsten ist die Verwendung von ASCII Daten(strukturen) auf IBM- 8 Zoll Disketten weder was besonderes noch auf Kompatible beschränkt. EBCDIC ist nur Standard wenn die Disketten auf 3740 Data Entry Systemen beschrieben wurde, bzw. zu deren Arbeitsablauf kompatibel sein sollte. Terminalsysteme (im allgemeinen unter 3270 subsumiert) gab es sowohl in EBCDIC als auch ASCII varianten - letztere schrieben auch ASCII auf lokale Disketten

Zitat von horniger

Sonst wäre wahrscheinlich auch Raffzahn daran interessiert.

Auch an den Disks...

Ja, durchaus - wobei mehr noch als an den Disks sind es Handbücher und Zubehör. Wir haben z.B. zwar den original Monitor (gruseliges Blechteil, aber im richtigen Farbton), aber nicht den 'Grafikzusatz' welcher über den I/O Bus angeschlossen war.

Nur diese beiden Handbücher, plus eben die Disketten. Diese P6060 war wohl schon immer genau so. Vor Jahren war mal eine in Bingen/Rhein in eBay mit Monitor, aber halt auch eben nicht gerade "geschenkt"...

Zitat von dirkt

Bis jetzt habe ich nur das Standardhandbuch plus ein Handbuch für den Plotter gesehen (der Plotter selbst ist nicht mehr vorhanden). An optionalen Karten ist nichts drin außer der Karte für den Plotter (vermutlich IPSO).

Also wohl keine große Ausbeute in dieser Richtung.

Nun, z.B. das Plotterhandbuch haben wir nicht - ansonsten nehmen wir natürlich auch großzügerweise auch das ganze Gerät :))

Würd aber verstehen wenn Du da lieber selbst mit speilst. Ist ein phantastisches Teil.

Ich hoff Du kommst mal dazu das Bücher zu scannen.

Was ich höchst spannend fände, wenn ihr euch mal die Arbeit machen würde, Puce1 und Puce2 zu reversenegineeren, ist ja alles TTL und damit eigentlich durchschaubar.

Zitat von Raffzahn

Nicht vergessen dass die /360 ursprünglich für die Arbeit mit ASCII gedacht war. E

Das ist wohl eines der vielen Märchen die man sich erzählt.

Als ich Mainframe Assembler lernte wurde das Bit auch mal kurz angesprochen. Der Referent von IBM meinte das dieses Feature bei keinem IBM Programmprodukt verwendet würde und ihm sei auch keine Anwendungen bekannt die das verwenden.

In einer Facebookgruppe in der ich die Frage gestellt hat kennt auch niemand Software die das verwendet.

Zitat von Pyewacket

Zitat von Raffzahn

Nicht vergessen dass die /360 ursprünglich für die Arbeit mit ASCII gedacht war. E

Das ist wohl eines der vielen Märchen die man sich erzählt.

Als ich Mainframe Assembler lernte wurde das Bit auch mal kurz angesprochen. Der Referent von IBM meinte das dieses Feature bei keinem IBM Programmprodukt verwendet würde und ihm sei auch keine Anwendungen bekannt die das verwenden.

In einer Facebookgruppe in der ich die Frage gestellt hat kennt auch niemand Software die das verwendet.

Wieso Märchen? Das gab es und die Hardware unterstützte es, habs selbst ausprobiert Anfang der 80er. Als die /360 entworfen wurde war ASCII noch in der Entwicklung und IBM der hauptsächlichen Treiber für den Standard. ASCII sollte eigentlich mit der 370 kommen um gleich von Anfang erst garnicht die Codeprobleme der Lochkarten- und 6-Bit-Zeit zu wiederholen. Der Standard wurde aber nicht schnell genug entschieden und EBCDIC daher als Zwischenlösung entworfen (vor der /360 verwendet IBM 6 bit Codes).

Wie jeder weis ist Zwischenlösung nur ein Synonym für Dauerlösung :))

Sache ist halt aber auch, dass es keinen großen Unterschied für die Software macht da damit ausschließlich die Funktion von PACK/UNPK beeinflusst wird, also ob der Zonenteil 3 oder F sein soll. Alles andere das Codes betrifft wird eh mit Befehlen gemacht in denen der Code nicht vorgegeben ist.

Was Anwendungen anbelangt, so hat man zur Handhabung von ASCII eh immer eigene Routinen gehabt die dann so oder so einen TR verwendet haben um das Ergebnis für die Ausgabe vorzubereiten.

Also, kein Märchen, nur ein netter Tanz der Geschichte.

Zitat von Raffzahn

Zitat von Roland_t29

Das führt schon mal weiter. Und in der Tat: der 6060 Assembler ist bzgl. Syntax dem /360 Assembler sehr sehr ähnlich. Und der Maschinencode ist (nach kurzer Durchsicht geschätzt) zu 75% binärkompatibel zum /360 Code. Es gibt aber auch deutliche Differenzen, die der anderen Architektur der 6060 geschuldet sind (zB Stack-Kommandos) - interessante Maschine !

Wenn man also /360 Kompatibilität in dem Bereich messen will, dann ist die Frage nicht wieviel Anteil hat der /360-gleiche Teil an der Maschine, sondern wieviel % des nicht privilegierten /360 Befehlssatz ist 1:1 vorhanden. Ich hab jetzt nicht nochmal nachgeschaut, aber in meiner Erinnerung geht das bei der P6060 gegen 100%

Sodala, jetzt hab ich doch nachgeschaut und muss mich entschuldigen, 100% sind es ganz sicher nicht. Selbst 70 nur mit Einschränkung darauf dass FP halt generell nicht dabei ist.

Der Vergleich des P6066-Handbuch mit dem /360 Befehlssatz schaut aus als wenn da keine /360 sondern eher eine /120 Kompatibilität wäre:

Von den 147 Befehlen der verschiedene /360 (-20 nicht eingerechnet) beherrscht die P6066 'nur' 66.

Was fehlt sind

- Alle FP Befehle

- Alle BCD Befehle

> Daher nur 120 der 360 Grad

Und vom Integer-Befehlssatz fehlen

- Alle Doppelregisterbefehle (LPDR, DDR, etc.)

- Multiplikation und Division (M,MH,MR und D,DH,DR)

Natürlich auch alle Befehle mit Bezug zur Hardware bzw. zur Trennung von OS und Anwendung

- Hardware/Privileg (TS, SVC, SPM, SSK, etc.)

- I/O Befehle (SOI, TCH, etc.)

Ich kann mir meine Fehleinschätzung jetzt nur so erklären, dass fast alles davon Befehle sind die ich in 30+ Jahren /370 Assembler praktisch nie gebraucht habe - mal die BCD Befehle ausgenommen - und ich da dann an den Rest garnicht mehr gedacht habe. Sorry.

Aber die P6066 bietet auch eine gaze Reihe richtig netter Erweiterungen die einiges ausgleichen, oder sogar besser machen - gerade für einen Desktoprechner - die /360 ist halt mit ihrer Blockorientierung zwar extrem performant, aber nur wenn man nicht Bytefummeln will.

Erweiterungen:

- Stack

Der schon erwähne Stack mit Befehlen ähnlich ENTER/LEAVE beim x86, aber auch parameterzugriff (SP:BP relative Adressierung bei x86)

- Rechnen im Speicher mit variabel langen (1..16 Byte) Integer

Alle Rechenbefehle gibt es in einer Speicher-Speicher Version für vorzeichenbehaftete und vorzeichenlose Zahlen mit variabler Länge. Eigentlich wie die BCD Befehlen der /360 aber halt binär. Da wie diese mit 2 Längenangaben kann man problemlos zahlen verschiedener länge miteinander verknüpfen. Spart viel platz wenn man nicht jedes +1 als ein 4 byte Wort ablegen muss :))

Die Befehle können praktisch alle weggefallenen Doppelregisterbefehle ersetzen - und sogar länger.

- Konvertierungen

ASCII kann in Integer oder Float und zurück gewandelt werden

Für das Float-Format gibt es zwar dann keine Maschinenbefehle, aber es hat die interessante Eigenschaft sich die führenden Nullen merken zu können - das heißt man kann immer sehen wie große das in Textform war/sein soll. Hab ich so noch nirgends gesehen.

- Suche in Tabellen

Das ist ein besonderes Schmankerl. Es gibt zwei Funktionen die in einen Eintrag in einer Liste suchen können:

SES - Sequential Search und DIS - Dictomic Search

Beide arbeiten gegen eine Tabelle mit Zeilenläne 1..16 Byte und einem Schlüsselbegriff von 1..16 Zeichen am Anfang der Zeile. SES durchsucht die Tabelle sequentiell, wohingegen DIS mit halbierender Suche vorgeht. Letzteres richtig schnell (O(log n)), dafür muss die Tabelle natürlich gemäß dem Schlüssel sortiert sein. Bei BASIC gibts gleich mehrere Stellen wo das riesig helfen kann, z.B. Schlüsselwörter zu token wandeln, Token zu Adresse wandeln oder Variablen suchen.

- Sonstiges

- Z.B. ein Pärchen das ein Zeichen in einem Speicher suchen kann (ala strlen() in C) oder gleiche Zeichen überlesen.

- Testen ob ein ASCII Zeichen ein Buchstabe, Ziffer oder Sonderzeichen ist.

- Ausbreiten von Zeichen

- MVC mit variabler Länge

Das sind teilweise Sachen die dann erst die 370 auch hatte - aber halt anders.

Es juckt einem direkt in den Fingern damit zu programmieren :))

Ansonsten hat das Buch auch einige offensichtliche Fehler und Ungereimtheiten

So hat SRL und BCTR den gleichen Opcode (06), as nicht sein kann

Überhaupt liegen alle SxA und SxL Befehle ohne ersichtlichen Grund an anderer Stelle (02/03/04/06).

Auch ist Für TRT der Opcode D0 angegeben, was bei der /360 aber DD wär, gleichzeitig liegt auf DD einer der neuen Konvertierungen. Ein dreher der ebenfalls keinen Sinn macht.

Dazu kommen dann einige Schreibfehler in den Befehlsnamen und andere Kleinigkeiten.

Ich würde also empfehlen die Angaben in dem Buch mit Vorsicht zu genießen :))

Zitat von dirkt

Zitat von Raffzahn

Überhaupt liegen alle SxA und SxL Befehle ohne ersichtlichen Grund an anderer Stelle (02/03/04/06).

Meine bisherige Vermutung ist, dass sie die Opcodes eine bisschen zusammengequetscht haben, um die Dekodierung im Mikrocode zu vereinfachen. Wenn man mal eine Tabelle macht, sieht man, dass von nur neun Werte von den 16 des High-Nibbles benutzt werden. Aber um das zu überprüfen müsste ich erstmal den Mikrocode verstehen.

Noe, dazu reicht es die einfache Struktur der /360 Befehle zu sehen:

Die ersten 2 bit des Opcodes geben Befehlslänge/Typ an

00: 2 Byte mit RR, d.h. das 2. Byte enthält 2 Register als Operanden

01: 4 Byte mit RX, d.h. erster Operand ist ein Register, 2. Operand ist eine indizierte Speicheradresse

10: 4 Byte mit RS oder SI, d.h. ein Register und eine Speicheradresse oder ein Immediate und eine Speicheradresse

11: 6 Byte mit SS, d.h. zwei Speicheradressen.

Ein paar Ausreißer sind dann entsprechend Ihrer Struktur in einer der 4 Gruppen verpackt - z.B. der SVC mit seinem 8 bit immediate in RR (0A).

Sinn dieser Struktur ist dass bereits das Statisising erkennen kann wie viele Halbworte zu dem Befehl gehören und welche Operanden bereitzustellen sind und wie die zu adressieren sind wenn es Speicheroperanden sind. Alles ohne komplexe Dekodierung, rein aus den ersten 2 Bit. Damit lässt sich die Pipelinesteuerung ganz einfach mit wenigen Logikgattern aufbauen. Es gibt nur einen Befehl der nicht ins Schema passt (SVC) und wenige bei denen der Speicherzugriff nicht nötig ist (LA aber auch die 4 Shifts), was aber entweder eh nicht stört (SVC) oder nur den Speicherzugriff unterdrücken muss.

In der Praxis schaut das dann z.B. beim Oder so aus:

16 -> 2 Byte OR - Oder Register mit Register

56 -> 4 Byte O - Oder Register mit Speicher

96 -> 4 Byte OI - Oder Speicherbyte mit Immediate (8 bit)

D6 -> 6 Byte OC - Oder zwei Speicherbereiche mit 1..256 Byte Länge

Amdahl war halt wirklich gut.

(Richtig chaotisch wirds erst mit /390 und den Unmengen an Spezialformaten)

Und als ich das hier gerade im Kopf formuliert habe war mir auch klar warum die 4 Shiftbefehle nach 02/etc. verlegt wurden: Olivetti hat die Behandlung von Konstante + Registerinhalt für die Stellenanzahl weggelassen und nur eine 4 bit konstante vorgesehen. Damit geht halt nur 1-16 stellen schiften, dafür auch nur 2 bytes - und dann müssen sie natürlich in den 00xxxxxx Codebereich, damit die Dekodierung einfach bleibt.

Nach dem das geklärt ist, passt wieder alles. Die 606x ist (mit den genannten Einschränkungen) /360-Komaptibel.

Zitat von dirkt

Ein weiterer Aspekt ist, das alle Unterschiede zum /360 Befehlsatz natürlich gegen evtl. Ürheberklagen geholfen hätten.

Das war kein Thema. Weder damals noch heute. IBM hat mit seinen Patenten gearbeitet - und dabei hauptsächlich auch nur mit der Drohung dass ein Rechtsstreit _sehr_ lange und _sehr_ teuer wird und der andere das vielleicht gewinnt aber nicht überlebt. :)).

Zitat von dirkt

Es gibt auch diverse I/O-Befehle, die im Handbuch nicht dokumentiert sind, und die ich noch nicht verstehe.

Die scheinen eine vereinfachte Form der IO Struktur der /360 zu sein. So gibt es z.B. keine Verkettung und die Adresse liegt an anderer Stelle, ist dafür aber 32 Bit und Canal/Gerätenummer steht im CCW. Auch enthält der Befehl gleich die CCW Adresse, es gibt also kein CAW. Auch sind die Kanal und Gerätenummern Fix vergeben, d.h. die oberen 4 bit der Nummer ist der Kanal (die Baugruppe) und die unteren 3 das Gerät an dem Kanal. Wobei da schleuder ich noch ein bisschen, weil entweder hat Olivetti da geast und jeder seriellen Schnittstelle ZWEI Kanalnummern gegeben (anstelle Geräte) oder ich kapier die Beispiele nicht.

Zitat von dirkt

SRL hat in den von mir benutzten Quellen übrigens Opcode 08, und nicht 06.

Noch mal Nachgeschaut, hast recht, mit genug Vergrößerung wird auch auf meinem Laptop eine 8 draus. Macht auch sinn, siehe oben.