2020-12-30 A pile of PostScript
My continued digging through the backup-tape has uncovered a pile of postscript files:
⟦0035e76eb⟧ Remote Compilation Facility - Release Information - Release_1_0_3 ⟦05988f7ca⟧ Insight - Installation Procedure - Release_1_0_1 ⟦07d905c09⟧ Rational Insight - Release Information - Rev1_3_0 ⟦0d71b57c2⟧ Rational Access Description - 0.8.0 Release ⟦17d276e59⟧ Rational Environment Release Information - Release D_12_7_3 ⟦2024a9fe1⟧ Remote Compilation Facility - Release Information - Release_1_2_2 ⟦23a53e39b⟧ Rationale for the Proposed Standard for a Generic Package of Primitive Functions for Ada ⟦3def193b1⟧ Rational Compilation Integrator - Release Information - Release 2_0_5 ⟦3e2ba7e34⟧ Rational Access - Quick-Reference Guid - Version 0.8.0 ⟦4734617e8⟧ Remote Compilation Facility - IBM RISC System/6000 Extension - Release Information - Release 1_1_0 ⟦4a1330c8b⟧ Guide to Machine Initilization - Release D_12_6_5 ⟦4b29253db⟧ "Usage" besked, titel: "!TOOLS.DOCUMENT_FORMAT" ⟦526cacf42⟧ Beskadiget ⟦5606b9f32⟧ Rational Style Guide - 0.5.0 Draft ⟦56ef92f1d⟧ Beskrivelse af analyse facilitet ⟦5717463c9⟧ Remote Compilation Facility - IBM RISC System/6000 - Release 1_0_2 ⟦68d16b503⟧ grafisk plot af kodestruktur ⟦6b572a63f⟧ Rational Compilation Integrator - IBM RISC System/6000 Extension - Release 2_0_2 ⟦6c03d64ae⟧ Rational Environment Release Information - D_10_20_2 Release ⟦6f08c03d9⟧ grafisk plot af kodestruktur ⟦74abeabc7⟧ Rational Compilation Integrator - Alsys i386 LynxOS Extension - Release information - Release 2_0_2 ⟦7af8d1531⟧ Proposed Standard for a Generic Package of Elementary Functions for Ada - Draft 1.2 ⟦83ca2b315⟧ Rational Environment - Rational Access - X Windows Interface - Revision 0.3.0 ⟦87a275cc6⟧ Rational X Library: Ada/C Interface Differences ⟦89aa031be⟧ Trunkeret ⟦8ba0d59a4⟧ Trunkeret ⟦91f816da9⟧ Command and Function Description - Alpha Draft ⟦944c90873⟧ Rational X Interface Release Information - Rev10_7_2 Release ⟦96d5ccb79⟧ Rational Access - Information Plan - Review Draft ⟦9893505e2⟧ Proposed Standard for a Generic Package of Primitive Functions for Ada - Draft 1.0 ⟦99c4458da⟧ Rational Environment Release Information - D_12_1_1 Release ⟦9b096c96a⟧ Rational Environment Release Information - D_12_2_4 Release ⟦9f8116908⟧ Rational X Library - Release Information - Rev6_0_0 Release ⟦a7b6d3dd8⟧ Rational TestMate - Release Information - Rev2_2_0 Release ⟦abf32a77e⟧ grafisk plot af kodestruktur ⟦b81506409⟧ Rational Environment Release Information - D_12_6_5 Release ⟦bde810949⟧ Rationale for the Proposed Standard for a Generic Package of Elemntary Functions for Ada ⟦d39cd8235⟧ Del af keyboard template ? ⟦d4766a43e⟧ grafisk plot af kodestruktur ⟦db6de3cc4⟧ grafisk plot af kodestruktur ⟦f404e5d35⟧ Rational Environment Release Information - D_12_5_0 Release ⟦f46a1a629⟧ Rational Access - Release Information - Release 1_0_1 ⟦fdf4d8787⟧ Kun ordet "Information"
The "weird" non-links on the left are identifiers in the AutoArchaeologist excavation of the backup tape.
Archaeologically ⟦96d5ccb79⟧ is probably the most interesting, Fil:Rational Access Information Plan.pdf.
2020-12-17 You are in a creepy maze of objects, none of them byte-aligned
The R1000 card-cage contains a total of 7 printed circuit boards:
|1||Mem2||Memory 2 (32 meg)|
|2||Mem0||Memory 0 (32 meg)|
|3||FIU||Field Isolation Unit|
(From R1000 Hardware Overview)
The Ada language was originally designed for embedded systems, in particular for embedded systems in, around and in control of military weapons, and it dates back where state-of-the-art in radiation-hardened microcomputers was the RCA1802 and a few kilobytes of ROM and RAM was the norm, so being parsimonious with memory space is deeply embedded in the genes of Ada.
For instance, when you define:
subtype MISSILE_NUMBER is INTEGER range 1 .. 8;
The Ada compiler will know that only three bits will be needed to store that type.
And five bits saved here and four bits saved there, it adds up.
The R1000 is a true-blooded Ada computer, so the fundamental unit of addressing is a bit, and just because your field may happen to be 16 bits wide, does not mean that it is going to be aligned at a 16-bit boundary. (There is a notable exception: Instructions are 16 bit wide and must be aligned to 16 bit boundaries.)
This is where the FIU comes into the picture: When an instruction requires 27 bits starting at a particular address, the FIU carves them out of however many 128 bit hardware words they may span.
This is a complication when reverse-engineering the R1000, both as a mental exercise and a practical matter.
Take for instance this object, which lives in block# 0xd4852:
┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ 0002360000001581843521480400000000000000000205100000001000000400 0001ea000000001000000a24001180d485440000201fe6040000201fd6240000 202002540000201fcde4001160d2bca4001160d2bcb4001160d2bcc400002020 4c94001160d2bcd4001160d22e940000201faf34001160d2bce4000020204e34 001160d2bd540000201fb6f4000020204f84001160d2bd640000202002e40000 202002a4001160d2a6540000201fef9400002020508400002020511400002020 56b40000202056e40000202004740000202004440000202057f4000020205814 0000202005540000202059040000202059840000201fedc40000201fd6c40000 20205a540000201fef24000020205db4001160d2bd74001160d2bd84001160d2 bd940000201fd5d4000020206074001160d2bda4001160d184a4000020206ce4 001160d2980400088015b524001160d2bdd40000201fefd40000202070e40011 60d27864001160d2bde4001160d2bdf40000201f92a4001160d2be040000201f f8240000202071c40000202075c4000020207614001160d286b4000020208394 001160d2b7d40000202084740000202084840000202084940000201fd6140000 202084f4001160d1b4440000201fc454001160d2be14001160d22c0400002020 85740000201f90540000202004040000201f9bc40000202085b40000201ff774 001160d22eb40000202085f40000202086040000202086740000202086840000 202086940000202086b4001180d488140000202087140000201fd75400002020 87340000201ff7d40000201fdb54000020208774001060571ea400106049f734 00106049aab400106049aad4001060675fd4001080be6514001080be65340010 80be1dd4001080c02cc4001080be6554001160cbef14001160cbf7d4001160cc 2f24001160cbece4001160cbeb04001160ccb04000000000[…]
If you squint a little bit, it is quite obvious that there are structural diagonal stripes.
One way to fiddle around with such structure is to join the lines to a single long unbroken line, look at that in a window which wraps the line, and then adjust the width of the window with the mouse.
If one does that here, a window 36 characters wide show the pattern clearly as three distinct columns
┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ 000236000000158184352148040000000000 00000002051000000010000004000001ea00 0000001000000a24001180d485440000201f e6040000201fd6240000202002540000201f cde4001160d2bca4001160d2bcb4001160d2 bcc4000020204c94001160d2bcd4001160d2 2e940000201faf34001160d2bce400002020 4e34001160d2bd540000201fb6f400002020 4f84001160d2bd640000202002e400002020 02a4001160d2a6540000201fef9400002020 50840000202051140000202056b400002020 56e400002020047400002020044400002020 […]
36 characters × 4 bits per character / 3 columns = 48 bits per column
Most right-thinking computer people would expect that to be 16+32 bits or possibly 3×16 bits or even 6 bytes, but no, it is actually 28+20 bits.
For now take my word that the array starts 316 bits into the data structure:
┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ ┌ 000236000000158184352148040000000000 00000002051000000010000004000001ea00 0000001000000a2 4001180 d4854 4000020 1fe60 4000020 1fd62 4000020 20025 4000020 1fcde 4001160 d2bca 4001160 d2bcb 4001160 d2bcc […]
That wasn't too bad, so what about the first 316 bits ? Here is my guess:
Notice how neither the value of the `objid` nor the `blockno` fields appear in the hexdump above.
If you look carefully, you might notice that 2×0x236 = 0x46c, this is essentially the first 1-bit wide field "dividing" the `objid` by two:
0x46c0000002b03 << 3 = 0x23600000015818
The `blockno` on the other hand is shifted two bits:
0xd4852 << 2 = 0x352148
Full disclosure: All the fields named `hdr%d` are white spots on the map. I have no idea if have assigned the right widths, or for that matter what they mean.
They have these precise values in all instances of this particular structure I have found yet.
My theory is that they may actually be a type-descriptor, because the last two, 0x1 and 0xa2, would describe the index range for the array of 162 elements, each 48 bit wide which follows.
Of those 48 bits, I have no idea what the first 28 bit means, but I the last 20 bit is a block number.
This is going to take some time, and I'm going to become a LOT better at mental hexadecimal arithmetic before we are done.
2020-12-12 Things to do in Covid-19 Lockdown
Try as we will, realistically we cannot keep our R1000 machine running forever, which puts us under a tacit obligation to write a "software-R1000" to keep the "Environment" alive when its hardware eventually gives up the ghost.
By now I have lost track of how many different computers I have written more or less comprehensive emulations of, and the general recipe has always been to start with the "Programmers Reference Manual" or whatever it happens to be called.
It is not obvious to what extent such a manual ever existed for the R1000, we certainly do not have it. What we do have is an abstract Ada description of the instruction, and a pair of example printouts, containing some kind of assembly listing of two trivial Ada programs, in the Guru Course 01 slides.
Try as I might, I cannot get the Ada description to deliver the actual bit-patterns of the instructions, if this description is authentic and not just for example, there must be one or more pieces of (Ada-)code which translates this description into 16 bit instruction-words.
Nonetheless, the Ada description helps a lot, in that it gives the names of all the instructions and the sizes of many of the argument fields in them, so for instance when it tells us (p36 right bottom):
[...] type PC_Offset is new Integer range -2 ** 10 .. 2 ** 10 -1; [...]
and (p38 left bottom):
[...] when Jump [...] => Relative : Pc_Offset [...]
and one of the listings (p88, top right) tells us:
[...] 35 0023: 7801 JUMP 1 [...]
Then it is a good guess that the Programmers Reference manual would have described the JUMP instruction as:
┌───────┬───────┬───────┬───────┐ JUMP pcrel │0 1 1 1│1 X X X│X X X X│X X X X│ └───────┴───────┴───────┴───────┘
Various bits of evidence indicates that the listings in the Guru Course are produced by the Ada compiler during compilation. If so, we should be able tease out the encoding of a lot of instructions by writing and compiling Ada programs that causes the compiler to emit the instructions in question.
But right now the R1000 and the rest of our collection is inaccessible, due to the Covid-19 lockdown.
So I sit at home, and try to wring as much information and as many clues as possible out of the documentation we have, and try it out on the code segments on the data media in our bitarchive.
One thing I have found out is that the listings in the Guru Course are not comprehensive, for instance on p43 left top:
[...] 27 001B: 4800 SHORT_LITERAL 0 28 001C: 0093 EXTENSION 147 29 001D: 0033 EXTENSION 6, 3 ;;; push full address of a location in current code segment [...]
Try as I might, I cannot puzzle an instruction which pushes an absolute address in the code-segment out of the Ada specification.
The fact that the compiler also does not know the name of this instruction makes me suspect that it has been added to the microcode and compiler, as an optimization, at such a late date, that nobody felt like recompiling everything from scratch, leaving the Ada description out of date.
Facit can Twist again.
Per opened the Facit Twist, found a broken piece of plastic and saw it as an excuse to use his 3D-printer.
Booted the R1000 yesterday, came up fine, but the Facit showed the "landscape" in both orientations.