"Sean 'Captain Napalm' Conner" <spc_at_armigeron.com> wrote:
> -spc (The Intel 432 was a tagged architecture---meant for OOP programming
> but it never caught on ... )
Indeed. It was somewhat non-traditional even as tagged architectures went.
Rather than tagging every memory location, memory was considered as objects.
Each object has a type, which can either be a hardware-interpreted system
type (such as Processor, Process, Port, Context, Domain) or a software-
defined type.
In a given Context (procedure/function invocation), software can only access
objects for which that context has an access descriptor (AD). The AD is a
capability, which means that it controls the access rights to the object
pointed to. For instance, objects have hardware-interpreted read and write
rights, as well as other rights that vary depending on the object type.
Each object is divided into two parts, the data part and the access part.
The access part contains ADs only. The data part can not contain ADs.
The instruction set does not even provide any method whereby software
could attempt to store an AD into the data part, or data into the access
part.
This split between ADs and data means that the software can never try
to dereference other data as if it were an AD, nor can it corrupt an
AD by overwriting it with random data. (There's no inherent protection
against writing the "wrong" AD over the "right" one, if you have write
rights to the segment.)
The architecture is really quite elegant. The big problems with it are:
1) It's slow, due largely to the limits of the 1975-1981 technology
used in the implementation. For instance, on the already-large
dice, there was not room for instruction or data caches, although
there was a small cache for segment information. Also, the data
path between the two chips that made up the general data processor
was too narrow.
2) The architecture doesn't map well to languages like C. It would
be possible to implement a fully standards-compliant C compiler
for the 432, but it is likely that the vast majority of existing
real-world C code would not run correctly on the system, because
most large C programs make architectural assumptions beyond what
the C standard requires the platform to guarantee.
I've put some information about the iAPX 432 on my web site:
http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/
As I think I've stated here before, I'm looking for ANY 432-related
materials (documentation, software, chips, boards, systems, etc.).
I've started work on a 432 simulator, but I expect it will take a long
time to complete, and if I am unable to obtain a complete copy of
the 432 cross-development software, I will be unable to verify the
correctness of the simulator. So if you have anything, please let
me know.
Thanks!
Eric
Received on Tue Feb 29 2000 - 16:46:54 GMT