Where should the type information be: in tags and descriptors 430

On Fri, 08 Apr 2005 15:23:57 +1200, Brian Boutel

I also would love to read it again; I may even have some of it in storage someplace, but not readily accessible.

For me it has been about 18 years since I was seriously and directly involved in the innards of A-Series. IIRC, brian's description is essentially correct, but I would like to add a comment or two.

Essentially all data tags (even valued) are set by "ordinary" user program instructions. Other tags, as mentioned, result from executing various kinds of specialized operators - these do not simply set the tag, but are designed to butture (when used properly) that the resulting descriptor, indirect reference word, or control word is valid and secure. The "used properly" part is why only "certified" compilers are allowed to mark files as code files.

Data descriptors, as brian says, are usually built as part of the operation (mediated by OS routines) of allocating memory; however, copy descriptors and "overlay" descriptors can also be generated by code, allowing the same memory to be accessed in different ways (within limits). Some effects, like the tagging of double precision operands in arrays, are handled (if memory serves) on transfer by means of special bits in the descriptors. I am not 100% sure on this.

Static data is a special case. IIRC, it is stored in code files in recognizable ways that allows its tags to be set properly when the data in memory is initialized.

The main problem I am having with remembering the details of all this is that I seem to remember that for some purposes a "special" form of disk IO (and disk file format) was used, in which the tags were also stored (in a not-totally-obvious way) in the disk file, and loaded with the contents of the file. I can no longer remember exactly what the uses for this were. It might have been used for code files (for the static data scenario, at least). It may have also been used for virtual memory (for data, not code: there was no need to write code segments out to backing storage, since all code was non-modifiable and re-entrant; it could just be re-read from the original code file when needed) and for "swap files" - I think the latter would have included disk images of end stacks, so would have had to provide some way to capture tag values on disk. The non-swap virtual memory case isn't so clear, since most data segments that could contain non-operand tags were probably marked as "save" (or at least, "resident") by the virtual memory system, so they would not been written to backing storage.

I would really enjoy having somebody with more recent (or, at least, more solid) memories about this helping refresh mine.

BTW, if it hasn't been mentioned already, the special role of code files in the security scheme meant that such files could only be copied (for "library maintenance" purposes - backup, restoration, or duplication) by means of routines embedded in (or, at least, running as part of) the OS; and, such routines needed to support various mechanisms to control (especially and most problematically) the transfer of files between systems (either by networking or by means of tape, moving of disks, etc.). This winds up involving non-trivial trust issues. I think a modern certificate and digital signature mechanism could be used to radically improve what was done at the time I was involved, but I don't know if any such mechanisms have been implemented for these systems.

One final comment on the security aspects of tag-based architecture, as exemplified by the A-Series: more advanced and secure mechanisms (beyond those in the e-mode architecture) were, in fact, possible, and were, in fact, in the process of being designed back in the 1980's (and maybe into the early 90's); there was a goal to greatly reduce the dependency on the compilers as part of the "trusted software base" (in Orange Book terms). AFAIK, no significant aspects of this design work were implemented, as the economic viability of further customized architectural mechanisms (especially any requiring custom hardware support) became debatable due to the ascendancy of "commodity" CPUs.

Jeff Rosenberg