Extremely CISC instructions

On Mon, Aug 23, 2021 at 6:38 PM Tom Stepleton via cctalk < cctalk at classiccmp.org> wrote: The Intel iAPX 432 General Data Processor was, for its time (1981), one of the CISCiest processors, though these days the x86 has far outpaced it for sheer architectural complexity. A single GDP instruction could allocate a new object, which required dealing with a two-level object table as well as a storage resource object (SRO) and memory claim object (MCO). Another instruction could send a message object to a port object. The latter, in particular, could result in an arbitrary number of additional message sends, because each time a message is sent to a port, it could unblock a processor or a surrogate waiting to receive from that port, which would then cause a send of that object to its dispatching or forwarding port, which could cause another send, etc. Each send could only cause one additional send, so it was tail recursion and didn't require a stack or consume additional storage. 432 GDP instructions were bit-aligned in an instruction object, and occupied anywhere from 6 to 344 bits. The 432 GDP was too complex to be implemented on a single chip using ~1979 fab technology, so it was split into two chips, the 43201 Instruction Unit and the 43202 Execution Unit. In the 432's timeframe (1981-1985), I think only the IBM System/38 processor and perhaps the Fairchild Symbol might reasonably have been considered CISCier than the 432. The Fairchild Symbol was a one-off system that implemented a high level language compiler in HARDWARE (not microcode!). The 432 was a dismal failure. The P7 (code name) processor was to some degree a successor to the 432, though it was much different. The P7 processor became the BiiN processor, which was mostly a RISC but with some microcoded object instructions similar to those of the 432, and with tagged memory to provide a capability architecture. BiiN failed as well, but stripped of the object operations and memory tagging, the processor became the i960, which was successful as an embedded processor. (Later there were a few i960 variants that added back the memory tagging, and perhaps the object operations, and were sold for military use.) Although there are many reasons for the failures of both the 432 and the P7/BiiN processor, one they had in common was that their advanced architectural features were especially suited to high level languages, such as Ada, and very poorly suited to low level languages, such as C. As everyone knows, the world chose to standardize on C. The P7, and later the i960, could run C code perfectly well, but C code couldn't easily take advantage of the advanced architectural capabilities of the P7/BiiN processor.