On Mon, Apr 10, 2017 at 3:39 PM, Sean Conner <s...@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