The iAPX 432 and block languages (was Re: RTX-2000 processor PC/AT add-in card (any takers?))

[Eric Smith]

On Mon, Apr 10, 2017 at 3:39 PM, Sean Conner <spc at conman.org> wrote:

>   What about C made it difficult for the [Intel iAPX] 432 to run?
>

The iAPX 432 was a capability based architecture; the only kind of pointer
supported by the hardware was an Access Descriptor, which is a pointer to
an object (or a refinement, which is a subset of an object).  There is no
efficient way to do any kind of pointer arithmetic, even with refinements.

In the Release 1 and 2 architectures, objects were either Access Objects,
which could contain Access Descriptors (pointers to objects), or Data
Objects, whcih could NOT contain Access Descriptors. As a result,
architectural objects were often used in pairs, with the Access Object
having an Access Descriptor at a specific offset (generally 0) pointing to
the corresponding Data Object.

In the Release 3 architecture, a single object could have both an Access
Part and a Data Part, with basically the same restriction: the Access Part
can only store Access Descriptors, and the Data Part can NOT store Access
Descriptors.

As a consequence, a C pointer to a structure containing both pointer and
non-pointer data would have to be represented as a composite of:
   1)  an Access Descriptor to the containing object
   2)  an offset into the data object or data part, for the non-pointer
data, and the non-Access-Descriptor portion of any pointers
   3)  an offset into the access object or access part, for the Access
Descriptor portion of any pointers
The architecture provides no assistance for managing this sort of pointer;
the compiler would just have to emit all the necessary code.

However, C requires that it be possible to cast other data types into
pointers. The 432 can easily enough let you read an access descriptor as
data, but it will not allow you to write data to an access descriptor. That
will raise an exception. It would take really awful hacks in the operating
system to subvert that, and would be insanely slow. (On a machine that was
already quite slow under normal conditions.)  You can't even cast an Access
Descriptor (which occupies 32 bits of memory) to uint32_t, then cast it
back unmodified, e.g., to store a pointer into an intptr_t then put it back
in a pointer.

It would almost certainly be more efficient to implement C on the 432 by
simply allocating a single large array of bytes as the memory for the C
world, and implementing pointers only as offsets within that C world.  This
would preclude all access from C code to normal 432 objects, except by
calling native libraries through hand-written glue. It would effectively be
halfway to an abstract C machine; the compiler could emit a subset of
normal 432 machine instructions that operate on the data.

Note that the 432 segment size is limited to 64KB. Accessing an array
larger than that, such as the proposed C world, is expensive. You have to
have an array of access descriptors to data objects of 64KB (or some other
power of 2) each. Release 1 and 2 provide no architectural support for it,
so the machine code would have to take C virtual addresses and split them
into the object index and offset.  Release 3 provides an instruction for
indexing a large array in this fashion; IIRC the individual data objects
comprising the array are 2KB each.

  -spc (Curious here, as some aspects of the 432 made their way to the 286
>         and we all know what happened to that architecture ... )
>

The only siginificant aspect of the 432 that made it into the 286 was the
use of 64KB segments, and that had already been done (badly) in the 8086.

The 432 architects went on to design a RISC processor that eliminated most
of the drawbacks of the 432, but still supported object-oriented
addressing, type safety, and memory safety, but using 33-bit word with one
bit being the tag to differentiate Access Descriptors from data. This
became the BiiN machine, which was unsuccessful. With the tag bit and
object-oriented instructions removed, it became the i960; the tag bit and
object-oriented instructions were later offered as the i960MX. The military
used the i960MX, but it is unclear whether they actually made use of the
tagging.

Eric