🚀 go-pugleaf

thorinn@diku.dk (Lars Henrik Mathiesen) writes:
:   0) The programmer model contains a processor status register, with
:      rapidly changing contents; it is only visible on interrupts, and
:      with a special instruction, but it still has to be synchronized.

The PSW is not visible except as a value that can be restored after an
interrupt.  An interrupt causes the pipeline to drain, so there are a
few cycles available during which the value can synchronize.

:   1) ``Skip-on-condition'' sets a nullification bit in this PSR;
:      nullification depends on the ALU results of one instruction, and
:      prevents all programmer-visible effects of the next --- including
:      data cache move-in, as far as I can see.

At the worst, this would mean that instructions that can nullify the
following instruction would have to run more slowly, and that
nullification would be less useful, but I don't think the situation is
that bad.  The data cache move-in problem you describe, for example,
isn't really any worse than a sequence of two instructions where the
first generates an address and the second uses it to load a word of
data.

:   2) The instructions that support multiprecision and BCD arithmetic
:      have carry bits in the status register as implicit arguments.

This is a problem, but only because the status register acts as an data
bottleneck, limiting the number of multiprecision operations that can be
performed in parallel.  This is the real problem with the nullification
operations, by the way.

:   3) Changes to the virtual memory mapping of the instruction stream
:      are guaranteed to take effect within 8 instructions.

This is only relevant to operations which affect the virtual memory
mappings, so that the OS can predict when translations will be valid.
Without some such guarantee, the OS would not know when to return to
virtual mode.  Since the effects are limited primarily to the TLB miss
path--code which gets optimized to particular processors, anyway--this
aspect of the architecture would be easy to modify should it pose a
problem.

--bob--
Not an HP spokesperson, but still an HP employee.