Re: New assembly language instructions to support OO languages?

Being an ex-Pr1mate, the discussion of segmentation and indirection is
quite interesting. The 50 series had both segmentation and
(recursive) indirection in both V-mode and I-mode. I don't think it
had segmentation in the "earlier" modes, S & R-mode.


As someone mentioned, it was important that the segments were large
enough, e.g. all the physical memory could fit in 1 segment. Those
modes had some other interesting features, hardware rings and pointers
that could address to the bit level, although the instructions could
only access at byte level granularity--I believe traps to bit-level
emulation were supported. On the downside, pointers (at 48 bits) were
larger than integers (at 32 bits). There was a 32 bit pointer format
in those modes, but it couldn't address bytes. That wasn't a problem
for PL/I or Pascal, but for C it was an issue.


Thus, at the time we got interested in supporting C and Unix, the
architecture got rethought with an I*-mode. To make C function well,
we needed a 32 bit pointer that could address bytes. Fortunately, a
quick hack on the existing 32 bit pointer format sufficed for that.
The top bit had previously been reserved for defining whether the
pointer was 48-bit or 32-bit. If one wrote 32 bits into a 48-bit
pointer where the extra 16 bits were set to describe offset, by 1
byte. A 32 bit pointer, without the top bit set addressed a 16 bit
aligned entity, and one with the top bit set addressed aa byte aligned
quantity. Thus, one was 1 rotate away from a normal C pointer.


Notably, at the same time, we were receiving insights from the RISC
machine developers. The advantages of a large general purpose
register set were well-known. However, our chief architect, Mark
Johnson, also caught some of the more subtle points. And indirection,
which had been supported in all the prior architectures was dropped.
The argument was that indirection takes just as long as an extra load
instruction and the compilers know how many levels of indirection are
needed, so generating those loads is not a burden, and it gave them 1
extra bit in the instructions.


About 25 years later, I found myself working for a different computer
company. It was interesting to hear the tales of how the flagship
architecture for this one also had rings and segmentation, although
both had fallen out of favor and were being slowly relegated to older
"modes".


However, more interesting for me was the architecture of the "network
processor" that was being built. It reminded me a lot of the CDC 6600
with the division between CPU and PPU's, which were organized in a
barrel.


What is relevant to this dicussion is that the PPU equivalent has
indirection in its instruction set. The point being that the
instruction space for these machines is limited and there is no
virtual memory on them, because they are device controller level
machines and need to have near-real-time response to deal with
interrupts. Thus, the code space savings of an indirect bit is very
valuable. Worth noting is that the indirection can override some
additional parts of the instruction, so it is half-way to an execute
instruction.


Finally, a half-dozen years after that, I am working on something
instruction-set-like. We are careful not to refer to it as an
instruction set, nor describe the part as programmable. However,
certain places in the descriptions we have features where we can
usefully use an indirection-like concept. Our interesting wrinkle is
that we have in several places put these indirectable quantities in
separate memories to make certain that we can keep the pipeline
running at full speed. Our memory is slower than our processor and if
we had to do two accesses to the same memory we could cut our
processor speed by at least half due to stalls waiting for the memory.
The strangeness of the different special purpose memory banks is not
relevant since noone will be programming the device and the software
which does configure it knows what those special banks are for and how
to map the problem onto them.


Hope this was interesting,
-Chris


******************************************************************************
Chris Clark Internet: christopher.f.clark@compiler-resources.com
Compiler Resources, Inc. or: compres@world.std.com
23 Bailey Rd Web Site: http://world.std.com/~compres
Berlin, MA 01503 voice: (508) 435-5016
USA fax: (978) 838-0263 (24 hours)

Return to the comp.compilers page.
Search the comp.compilers archives again.