🚀 go-pugleaf

>>  There was no such thing as a "file" in Multics. Everything was a segment,
>> mappable into virtual memory via a system call.
>
>Incorrect.  While a process can directly invoke a supervisory routine to make
>a segment known to a process, the normal method was via a hardware fault

"Normal" in what sense?  If you wanted to get at a segment by a name
*specified at run time*, which many many commands would, you had to
call the system.  In fact, the dynamic linker code that responded to
those faults would, I believe, find the name of the segment being
referenced and call the hardcore supervisor routine to map in in, so
ultimately to get a segment into a process' address space *somebody*
has to call the system to do it.

> The process of making a segment (procedure or data) known takes a rather
> lengthly discussion to describe all of the mechanics involved (omitted here).
> It is not done by a "system call" but a hardware trap.

Not really that lengthy.  An instruction that made an external
reference would do so through a pointer in the process' "combined
linkage section".  The pointer in question was initially a Fault Tag
2 pointer.  That would cause a trap to the linker.  The linker would
use that pointer to find the name of the segment in which the
location being referenced existed, and use the standard hardcore
supervisor call to get a pointer to that segment.

(This routine was called "hcs_$initiate_refname", or something like
that, if I remember correctly.  The name that was used for the
segment was called a "reference name".  To translate such a name to a
segment, the supervisor searched your search path, which was a list
of directories, for a file with the given name as a file name.
Actually, an entry in the search path could refer to the Known
Segment Table, which was a table that recorded all the segments that
had already been "initiated" by "hcs_$initiate_refname".)

If the reference were not to some offset from the base of the segment
as a whole, but to an offset from a particular entry point in that
segment (i.e., the segment is an object module), the linker would
look for the entry point in the segment's symbol table and modify the
pointer to point to that entry.  In either case, it would then
replace the FT2 pointer with the new pointer.  (I forget whether it
snapped any other links to that segment or entry point or not.)

>Basically, a reference to a segment <k> (by symbolic name) that does not
>have a valid segment number assigned [(i.e.) its ITS (Indirect To Segment)
>word "snapped" in the process combined linkage segment for this ring],

If you're talking about an unsnapped link, when I was using Multics
at school, they weren't ITS pointers at all, they were FT2 pointers.
(Organick's book also describes it this way.)  The trap didn't occur
because the segment number was invalid, but because the pointer was
one that always caused traps when a reference was made through it.
Did they stop using FT2 pointers in a later version of Multics?

>Also, conventional I/O was possible via DIMs (Device Interface Modules),
>that is another topic definitely.

If I remember correctly, you could (if you felt so inclined) call the
low-level device driver routines directly.  They didn't, however,
have device-independent interfaces.  The DIMs provided the
device-independent interfaces; they generally didn't run in a
privileged ring, but called the low-level I/O routines which did.
There was also a DIM that referred to segments, so you could do the
equivalent of "write" calls to files (which merely meant that the DIM
copied data into the segment) or to devices.  (Actually, the DIM
supported "multi-segment files", which were files that could be
larger than a segment.  They were implemented as directories
containing multiple segments that contained pieces of the data in the
file.