Extremely CISC instructions

[Eric Smith]

On Mon, Aug 23, 2021 at 6:38 PM Tom Stepleton via cctalk <
cctalk at classiccmp.org> wrote:

> For the sake of illustration to folks who are not necessarily used to
> thinking about what computers do at the machine code level, I'm interested
> in collecting examples of single instructions for any CPU architecture that
> are unusually prolific in one way or another.
>

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.