Rational 1000 på kryds og tværs

Den Rational 1000 computer som Terma har doneret til Datamuseum.dk er underlig og jo mere man graver, jo underligere bliver den.

Når man kigger på en moderne computer, indeholder den en frygtelig masse tilpasningslag. F.eks udfører moderne CPU'er ikke de instruktioner der står i deres manualer, de oversætter dem til et internt instruktionssæt fordi det er den eneste måde at parallelisere de fundamentale begrænsninger, som f.eks antallet af registre. Det betyder at dem der skriver compilere skal tænke over ikke bare det instruktionssæt de skal producere kode med, men også den interne arkitektur af den CPU der skal udføre koden. Det er, for at sige det, noget rod.

Ca. en gang hver tiende år er der nogen der får nok af de "alt for komplexe instruktionssæt" og opfinder et "nyt simpelt instruktionssæt" og hvis det bliver en success, kommer marketingafdelingen snart og siger "Kunderne kræver en instruktion der kan ...".

Det skete for IBM's S/360, det skete for Intels x86, det skete for Motorolas 68K, det skete for MIPS, det er sket for ARM, det er i fuld gang for AMD64 og inden længe begynder det for RiscV.

De forsøg der har været på at starte med "fulkomne" eller "omfattende" instruktionssæt har langt hen ad vejen klaret sig bedre, i den forstand at de ikke er blevet meget værre og i større grad har bevaret deres orden og arkitektur hen ad vejen, her kunne man nævne Digitals VAX, CCI Power6/32 (aka "Tahoe") og lidt afhængig af om man kigger på det rå antal instruktioner eller på deres ortogonale arkitektur, hører 68K egentlig til her.

Der er også folk der har prøvet meget skæve ting, Intels iAPX432 var f.eks en (temmelig) objektorienteret arkitektur, og Linn (som i: Sondek grammofonen) byggede deres egen helt specielle "Numerik" processor lidt efter samme idegrundlag.

Helt ude i yderbanen finder vi så Rational 1000 computeren, der internt blev kaldt en "MISC" arkitektur: "Massive Instruction Set Computer". Ikke fordi den har pokkers mange instruktioner når det kommer til stykket, men de får en masse fra hånden.

Grunden til at vi ikke har kunnet finde nogen manual på instruktionssættet, er at det ikke blev anset for et supporteret interface, der findes simpelthen ikke nogen assembler til R1000. Computeren er bygget til at udføre Ada programmer og ada-compileren spytter de koder ud, som compiler-teamet har aftalt med mikrokode-teamet, instruktioner der så koncist som muligt kommunikerer hvad der skal ske.

Vi har dog fundet en disassembler i et binært kodesegment[1], for det kan debuggeren godt og så finder vi ud af at der f.eks er instruktioner der hedder:

Execute Heap_Access,Adaptive_Balanced_Tree_Lookup

og

Action Heap_Access,Diana_Put_Node_On_Seq_Type

Manglen på dokumentation af sådanne instruktioner gør det lidt op ad bakke at skrive en software emulator for en R1000 på normal vis.

Men vi har diagrammerne, vi har ihvertfald én version af nogle diagrammer, vi har mikrokoden, så må det i stedet blive en emulering på mikrokodeniveau.

Mikrokodefilen ligger som en fil i "I/O Controllerens" filsystem og indeholder hele mikrokoden, til alle kortene som en stor binær blob. Formatet er ikke dokumenteret, vi har lidt dokumentation på de individuelle korts mikrokode, men ikke på hvordan det er pakket i filen.

IOC'en er en 68020 service processor for hoved-cpu'en, den er ansvarlig for bootstrap og derefter sørger den for I/O til disk/tape/LAN osv.

Bootstrap foregår ved at mikrokoden downloades til den "diagnostic processor" der sidder på hvert kort via en multidrop RS-232 forbindelse.

Baseret på Karl Stenerud's "Musashi" emulator til 68K familien, har vi nu lavet en emulator for IOC'en og den kommer så langt at den kan download'e mikrokoden til en meget primitiv emulering af diag-processorne, så lad os tale lidt om dem:

På hvert af de bageplade-store printkort sidder der en 8052 microcontroller, som har fingrene i alt på kortet. Michael Druke, som designede hardwaren, kalder dem for hans "Diagnostic Archipelago", fordi de som en øgruppe i Stillehavet omringer hele kortet med testpunkter.

Og nej, det er ikke JTAG, denne design beslutning blev taget ca. fem år inden det Philips' Bleeker startede blev til JTAG i 1990 og JTAG har ikke nogen distribueret intelligens.

Diag-processoren kan bruges "in vivo" når kortet sidder i maskinen eller in vitro når man fejlsøger et enkelt kort på arbejdsbordet. Det sidste er specielt smart når hvert kort har fat i en håndfuld 64 bit brede busser.

I praksis foregår det ved at man downloader et "experiment" til 8052'eren, som fortolker byteværdierne som kommandoer.

Jeg behøver ikke sige at vi heller ikke har nogen dokumentation på det "instruktionssæt", vel ? [2]

Status lige nu er at jeg har gennemskuet den overordnede protokol imellem IOC og diag-8052'eren nok til at IOC'en tror den har download'et mikrokoden og det initielle indhold af registrene i R1000 CPU'en.

Ved hjælp af dette har jeg kunnet gennemskue hvilke bytes der går til hvilket kort og efter at have rodet med det nogle dage kan jeg nu producere plots som dette:

Illustration: Poul-Henning Kamp

Der viser hvorledes mikroinstruktionerne til addition og subtraktition af floats hænger sammen.

De enkelte instruktioner ser f.eks således ud:

 2860:  
 seq_cond_sel            0a VAL.ALU_LT_ZERO(late)  
 seq_en_micro             0  
 seq_latch                1  
 fiu_len_fill_lit        74 zero-fill 0x34  
 fiu_len_fill_reg_ctl     1 Load Literal     Load Literal  
 fiu_load_oreg            1 hold_oreg  
 fiu_oreg_src             0 rotator output  
 fiu_tivi_src             4 fiu_var  
 typ_alu_func            1a PASS_B  
 typ_b_adr               16 CSA/VAL_BUS  
 typ_c_adr               3b GP 0x4  
 typ_c_mux_sel            0 ALU  
 val_a_adr               15 ZERO_COUNTER  
 val_alu_func            1a PASS_B  
 val_b_adr               05 GP 0x5  
 ioc_adrbs                2 typ  
 ioc_fiubs                1 val  
 ioc_tvbs                 2 fiu/val

Så vidt jeg kan forstå situationen, så tror vores IOC emulator at R1000 CPU'en er startet og den prøver at sende et "svar" via den FIFO, hvor R1000 normalt beder om I/O operationer, for at downloade de første kodesegmenter til RAM, så R1000 CPU'en får noget at tygge på.

Et eller andet sted i mikrokodens 15444 instruktioner er der altså en bootloader af en art. Jeg håber at disassembleringen af download-programmet der kører på IOC'en giver et hint om hvor.

Det betyder også at noget af det første vi skal have implementeret er R1000's RAM lager og her er R1000 decideret genial.

I en almindelig computer, som f.eks en PC, arbejdet programmet i et "logisk addresserum" af en eller anden art.

Disse addresser oversættes fra "logiske" til "fysiske" addresser via en træ-struktur af tabeller ("page-tables") i RAM og først derefter kan man tilgå den faktiske lokation i RAM man gerne vil have.

Det er, for at sige det rent ud: Pissesløvt.

Det har det altid været, uanset hvem der har implementeret det og hvad enten de har lavet pagetabellerne den ene eller den anden vej.

For at fedte sig uden om langsomheden er der alle mulige caches involveret, ikke bare L1, L2, L3 og L4, men også "Page Lookaside Buffers" og meget andet gejl og selvom det er imponerende hvor hurtigt det faktisk går på moderne hardware[3], så er det stadig noget klamp og en permanent kilde til "side-channel" attacks.

Men det er faktisk værre end som så: En ting er den mapning mellem logiske og fysiske RAM addresser som kernen skal holde styr på, den skal også holde styr på mapningen mellem de fysiske RAM addresser og de tilhørende logiske filsystems addresser[4] og for at det ikke skal være løgn, skal den også holde styr på mapningen mellem de logiske filsystems addresser ("3. block i /bin/ls") og den fysiske addresse på disken ("sektor 0x194240-194243").

R1000 har droppet alt det skrammel og har i princippet ikke noget RAM lager som vi kender det, men kun et L1 Cache og hvis der ikke er plads der, må det ud på disken - og det hele kører i logiske addresser.

Programmet arbejdet i et segment, det har et nummer, det nummer er første sektor disken.

Når programmet prøver at læse eller skrive en lokation i segmentet, sendes en 67bit bred addresse afsted, indeholdende segmentet, segmentets type, sidenummeret (= sekventielle sektornumre), hvilket 128bit ord i siden og hvilket bit i dette 128bit ord.

Ram kortet har som alle andre cache's et "tag" og et "data" store hvor tag-store ved hvad det faktisk er der ligger i data-store.

Dengang Intel lancerede deres første 2104 dynamiske RAM, på hele 4096x1 bits, havde de et problem: Med 12 adresseben, 3 forsyningsspændinger, GND, CE, WR og Data-in og Data-out skulle der bruges et 20 bens hus og det havde Intel ikke udstyr til.

Men fordi selve RAM'array'en er todimensional skal den faktisk ikke bruge alle 12 addressebits til at begynde med, først skal den bruge 6 til at vælge "række" og først senere skal den så bruge de andre 6 til at vælge "kolonne" og derfor kan addresserne multiplexes på kun 6 ben uden at der spildes nogen tid.

Illustration: Poul-Henning Kamp

Michael Druke's genistreg er at give DRAM'chippene den del af addressen der er indenfor en side først, og samtidig slå op i et lille hurtigt statisk RAM "tag-store" der kunne nå at levere den 'variable' del af addressen inden RAM chippene skal bruge den.

Nettoresultatet er at hele baladen med at oversætte fra logiske til fysiske addresser ingen tid tager: RAM kortets cache funktion gør det samtidig med at RAM chippene laver første halvdel af deres interne arbejde.

Det er simpelthen ufatteligt smart gjort og man kan kun begræde at vi idag lever i det kvantebukseben, hvor det er helt utænkeligt at gøre det igen, fordi alle operativsystemer har "nogle millioner" linier kode for meget til at køre på så smart hardware.

Ohh well...

phk

PS: Ja, der kommer en opdatering om datamuseum.dk så snart vi har noget at fortælle :-/

[1] Et herligt eksempel på "bootstrapping" :-)

[2] Vi krydser fingre for at et af kortene i reservedelsbunken har en 8052 der ikke er maskeprogrammeret, så vi kan læse programmet ud.

[3] Hvilket minder mig om at jeg skal have skrevet om vores ESO projekt.

[4] Filsystem kan i den forbindelse godt være en swap-paritition, kernen skal stadig holde styr på hvor ting havner.

Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Nis Schmidt

Under min tid i Frankrig havde jeg en kollega, som var "helt pjattet" med ADA-sproget. Næsten ligegyldigt hvad man spurgte ham om falt talen hurtigt på ADA - og så gik den dag;-)

Fandt en muligvis interessant tekst:

Evaluation of the Rational Environment Peter H. Feller Susan A. Dart Grace Downey / July 1988 på:

https://apps.dtic.mil/sti/pdfs/ADA198934.pdf

  • 1
  • 0
#2 Nis Schmidt

UNLIMITED, UNCLASSIFIED "t" SECURITy CLASSIFICATION OF THIS PAGE

I doccen er der hints om CMU; et muligt sted for "yderligere info" om R1000;-)

Da det nu er uklassificeret, vil jeg tro at alle relevante informationer kan skaffes - i det omfang de stadig eksisterer.

  • 1
  • 0
#4 Klavs Klavsen

Der laves jo alle mulige eksperimentielle ARM udgaver for tiden.. Et design oplæg, til at implementer det i ARM - kunne muligvis fange nogle af "de rigtige folks" interesse.. især hvis man kan spekulere på hvilken performance det vil kunne give? Jeg tror nu godt Open Source "hardware driverne/memory håndteringslag" i Linux/FreeBSD etc. kernerne, hvis metoden kunne påvises at have tilstrækkelige gevinster? idealist er man vel altid :)

  • 0
  • 0
#5 Poul-Henning Kamp Blogger

Sagtens! Det kræver bare du har det nødvendige antal millioner til at få lavet en ASIC...

I starten kunne man begynde med at simulere det i en stor FPGA vil jeg tro.

PS: Netop vedrørende interessante ARM varianter, se dette: https://developer.arm.com/architectures/cpu-architecture/a-profile/morello Det er min gode ven Robert Watson der er hjernen bag det, hvis der er nogle danske forskere der vil indover bør de sende ham en email.

  • 1
  • 0
#6 Michael Cederberg

Det er rigtigt smart ... men ...

Det er simpelthen ufatteligt smart gjort og man kan kun begræde at vi idag lever i det kvantebukseben, hvor det er helt utænkeligt at gøre det igen, fordi alle operativsystemer har "nogle millioner" linier kode for meget til at køre på så smart hardware.

Problemet med moderne CPU'er er selvfølgeligt at de også har en del caching i CPU og at cachen af gode grunde sker på fysiske memory adresser. En sådan mapping RAM skulle således ligge on-chip og være lige så hurtig som level 1 cache.

Læg oveni af page-tabellerne skal dække et 64-bit adresse rum som kun er sparsomt befolket. Et simpel lookup i hurtig RAM vil således kræve en meget meget stor RAM. Læg oveni at man bruger page-tabellerne access control og shared memory.

Vi er rigtigt langt nede i kvantebuksebenet men måske er der en multiverden hvor ovenstående er løst.

  • 0
  • 0
#7 Poul-Henning Kamp Blogger

Læg oveni af page-tabellerne skal dække et 64-bit adresse rum som kun er sparsomt befolket. Et simpel lookup i hurtig RAM vil således kræve en meget meget stor RAM. Læg oveni at man bruger page-tabellerne access control og shared memory.

Ja, der er rigtig mange ting galt med page-table/trees modellen :-)

For så vidt access-control, så tror jeg vejen frem er den "capability" model som Robert arbejder med, det er på høje tide at CPUen lærer at holde styr på hvad der er pointere og hvad ikke er.

Når den kan det bliver rigtig meget af det skrammel vi bruger som workaround idag overflødigt.

Problemet med moderne CPU'er er selvfølgeligt at de også har en del caching i CPU og at cachen af gode grunde sker på fysiske memory adresser.

Uhm, det er langt fra altid tilfældet og så vidt jeg lige kan gennemskue faktisk undtagelsen nu om dage.

Den eneste "gode" grund til at have fysiske addresser i de nære caches er hvis man kan genbruge dem på tværs af contexts, men da det korrekte navn for det fænomen er "information leak" er gode i anførselstegn.

  • 3
  • 0
#8 Michael Cederberg

Den eneste "gode" grund til at have fysiske addresser i de nære caches er hvis man kan genbruge dem på tværs af contexts, men da det korrekte navn for det fænomen er "information leak" er gode i anførselstegn.

Jeg kan ikke lige overskue L1 og L2 caches i denne sammenhæng. Men i de multiprocessor setups jeg kender bruges fysiske adresser i kommunikationen mellem processorer. Som jeg oplever det så er det nødvendigt hvis cache coherency protocoller skal være effektive da der ellers bliver scalability problemer. Jeg tror også at der kan bliver problemer omkring writeback sådan at ikke alt skal skrives til RAM med det samme.

Uhm, det er langt fra altid tilfældet og så vidt jeg lige kan gennemskue faktisk undtagelsen nu om dage.

Nu er det godt nok længe siden, men jeg er ganske sikker på at cachen x86++ processorer i praksis er organiseret omkring fysiske adresser og så noget mystisk noget omkring lookup på den del af adressen som er den samme for fysiske og virtuelle adresser.

  • 0
  • 0
#9 Nis Schmidt

Verdens første IDE? Næppe, men tak til PHK for R1000 pegeren.

En anden tidlig IDE var det sæt DCL (Digital Command Language) procedurer jeg udviklede i 1982, for at overkomme at de tidlige versioner af VMS ikke havde nogen ”command line editing” facilitet; den kom først i V3.0 svjh. Min IDE var til integration af VAX/DBMS med F77 og GPGS, hvor man slap for de lange command lines, fordi udvikling var menu-styret med EDT-editoren, compilere og linker.

Fandt forresten også ”ADA301551.pdf” fra 1995, som kan googles. Heri kan man også se lidt af ”slægtskabet”, mellem de forskellige platforme. Så kom jeg i tanke om at PHK sikkert har støvsuget nettet for Rational doccies;-)

  • 1
  • 0
#10 Poul-Henning Kamp Blogger

Verdens første IDE? Næppe, men tak til PHK for R1000 pegeren.

Uhm, digitals DCL har intet der er bare i nærheden af hvad R1000 præsterer?

R1000 opbevarer koden i et semantisk træ (I Diana format) hvilket f.eks tillader at du retter en enkelt linie uden at skulle recompilere alt muligt andet, fordi den kan se at det vil være uden (interface-)effekt for alle der refererer dette stykke kode gennem dets interfaces.

  • 3
  • 0
#14 Kim Strandgaard Andreasen

Det er så en noget bizar definition, alt den stund at APL ikke giver programmøren den minste support eller hjælp baseret på semantisk forståelse af programmet ?

Er det ikke noget, der er kommet til, siden forkortelsen IDE blev opfundet? I den forstand, at det er et samlet miljø, hvor programmet skrives, redigeres, afprøves, debugges, og afvikles, synes jeg godt, at APL kvalificerer. Men hører der mere til definitionen (altså den oprindelige), har du måske ret - jeg har ikke autorativ viden om det. Men at kalde det en bizar definition synes jeg nu nok er at stramme diskussionen lidt.

  • 0
  • 0
#15 Poul-Henning Kamp Blogger

Er det ikke noget, der er kommet til, siden forkortelsen IDE blev opfundet? I den forstand, at det er et samlet miljø, hvor programmet skrives, redigeres, afprøves, debugges, og afvikles, synes jeg godt, at APL kvalificerer.

Der er bestemt gået inflation i begrebet "IDE": Idag kaldes enhver editor med syntax-highlighting og en funktionstast der starter compiler/debugger/program for et "IDE".

Der hvor R1000 skiller sig ud, er at IDE'et ikke bare forstår den overfladiske syntax af Ada, det forstår semantikken af Ada.

Det tydeligste udtryk er at R1000's "Environment" ikke arbejder på filniveau.

I stort set alle andre miljøer, retter du et eller andet, gemmer "filen", recompilerer "filen" til en ny binær "fil" osv.

I R1000 retter du en definition, et statement eller et udtryk og så bliver kun det du har rettet recompileret, fordi det semantiske overblik kan afgøre at det er tilstrækkeligt.

At de overhovedet kunne gøre dét i 1980'erne, skyldes naturligvis i stor grad at Ada sproget både er meget formelt og meget stringent, ikke mindst mht. interfaces.

Sammenligningen med APL finder jeg meget problematisk, fordi APL fundamentalt set er en kommando-fortolker for et fortolket sprog, hvilket er en helt anden boldgade, men mest fordi jeg ikke kender til nogen APL implementeringer der har skyggen af semantisk analyse til at blande sig i brugerinterfacet.

  • 2
  • 1
#16 Nis Schmidt

Syntax high lighting var ikke så almindeligt i VMS før V3.0.

Al den stund at der - for det meste - kun var to "farver" at gøre godt med: lys og mørke; Rational R1000 var et helt andet bæst, bygget som udviklingsterminal til "non-mips" VAX/VMS systemer - og senere andre; navnlig såkaldte "kritiske" systemer. Fx er Boeing 777 FCS (flight control system) bygget med en R1000.

Meget teknisk viden er senere gået tabt og der er ikke mange af vores seniorer tilbage med den viden. MS/intel har "arvet" noget af den. Det ses tydeligst i deres compilere i "incremental" mode.

Kilder

  • 1
  • 0
#18 Poul-Henning Kamp Blogger

Rational R1000 var et helt andet bæst, bygget som udviklingsterminal til "non-mips" VAX/VMS systemer

Æhhh.... nu er vi vist helt ude i hampen her ?

Rational skrev deres IDE i Ada og til Ada og opdagede til deres gru at selv de hurtigste implementeringer af Ada, DG's Ecclipse, ikke magtede at afvikle det fornuftigt. Derfor byggede de deres egen hardwareplatform og de hentede folkene til det fra DG.

VAX og VMS har absolut intet med det at gøre.

  • 4
  • 1
#19 Poul-Henning Kamp Blogger

Du flytter målstolperne. Du skrev "den første", hvilket er skudt (meget) forkert.

Kun hvis man til "IDE" medregner Emacs-macroer, funktionstaster der starter compileren og syntax-highlighting.

Hvis man, som jeg, insisterer på at der er et minimum af semantisk programmørstøtte, f.eks noget så trivielt som en klasse-browser, er Rationals Environment ca. 10 år forud for alle andre.

  • 5
  • 1
#21 Nis Schmidt

Det svarer til Windowsernes: FreeBSD er ikke noget operativsystem, for det mangler en grafisk shell.

Fair must be fair. BSD, ATT og de andre benytter mig bekendt X11. Godtnok havde FreeBSD ikke gui-understøttet install i 2003, men det kan senere være kommet til senere.

Da DEC i juni '88 holdt "windowing" seminar i München var MS/Windows V2.0 det eneste kørende window-system (Machintosh var ikke med endnu, men det kom før Network University i 1990:) Det var noget rod, fx fyldte "Hello World" askillige sider, men det var kørende, mens de andre var klippe-klistre præsentationer.

Jeg ved det, for jeg holdt MS/W præsentationen ;-)

  • 2
  • 0
#22 Lars Skovlund
  • 0
  • 0
Log ind eller Opret konto for at kommentere