[TUHS] A Reiser tour de force

[Jon Steinhart]

David Barto writes:
> 
>
>
> > On Apr 1, 2022, at 8:59 AM, Douglas McIlroy <douglas.mcilroy at dartmouth.edu> wrote:
> > 
> > The recent discussion about Research choosing BSD's paging over
> > Reiser-London's brought to mind a stunning program by Reiser that
> > Research did adopt.
> > 
> > A critical primitive in the Blit terminal was bitblt (block transfer
> > of a rectangular area). It was used ubiquitously, for example to
> > refresh data when window-stacking changed, to move data within a
> > window, or to pop up a menu.. The display memory was word-oriented, so
> > bitblt was fraught with niggling details about bit alignment and
> > overlap of source and destination. A general bitblt subroutine was a
> > rats' nest of conditionals--grossly inefficient for important special
> > cases like scrolling.
> > 
> > Bitblt got refined (i.e. elaborated) several times before Reiser did
> > away with it entirely. Instead he wrote a just-in-time generator of
> > optimal code. Thousands of distinct variants, which varied in size
> > from 16 to 72 bytes, could be produced by the same 400 lines of
> > assembler code.
> > 
> > Doug
>
> Does this exist for the rest of us to study?
>
> 	David

It's not insanely complicated by modern standards.  Without any knowledge
of other work, I did the same thing for a 68020 based graphics system where
the JIT code went into the I-cache and was amazingly fast for its day.

If I remember correctly, things started with an outer-loop test to see
if there were overlapping regions to determine whether to go forward
to backwards to avoid having the destination trash the source.

Then, there was an inner loop test for whether or not the left edge
was on a word boundary, the right edge was on a word boundary, or
whether or not both edges were inside of the same word.  Depending
on the results the generated inner loop code had left edge handling,
non-edge handling, and right edge handling code.

Finally, code was generated plugging in whatever was needed for the
op-code.

Maybe this is just a semantic nit, but to me this is just a better
implementation of bitblt, not doing away with it.

Jon