Symbolics

"Sean 'Captain Napalm' Conner" <spc(a)armigeron.com> wrote: 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