🚀 go-pugleaf

Mel Wilson wrote:

> 
>    There was no typical use for the Repeat Linked (RPL)
> instruction.  Nobody of my acquaintance ever found a use for
> it, and we tried.  Rather than adding an increment, It would
> load the operand address for the next repetition from the
> high-order 18 bits of the current operand.  You were pretty
> much stuck with testing bits in the low-order half of the
> word, and any possible application always seemed to need a
> little more.

I use it for the memory allocator in the single segment (unpaged,
small-model) C library, also in the print image writers for
the list of overstruck characters.
> 
>    The repeat instructions always ran with interrupts
> inhibited because there was no way to save enough processor
> state to restart the instruction after an interrupt.  This
> caused trouble trying to run GCOS code in a Multics system:
> a page-fault turns out to be, fundamentally, an interrupt
> you don't dare inhibit.  Native Multics programs never used
> RPT, RPD or RPL; the newer Extended Instruction Set
> instructions could do the same things, arguably better.  I
> never saw enough of virtual-memory GCOS to know if it had
> another solution.

Essentially repeats are not used in that mode.  The NS mode C
memory allocator uses essentially the same data structure
as the SS mode one, but uses a loop instead of an RPL.
I sometimes debate restoring the repeats and taking a user
level fault since although the repeat can't be restarted,
I know where the algorithm can.  However, it is probable
that I really should investigate a completely different
algorithm.