Re: [TUHS] A Reiser tour de force

[Jon Steinhart <jon@fourwinds.com>]

Steffen Nurpmeso writes:
> Jon Steinhart wrote in
>  <202204011726.231HQFm03349496@darkstar.fourwinds.com>:
>  |David Barto writes:
>  |>> On Apr 1, 2022, at 8:59 AM, Douglas McIlroy <douglas.mcilroy@dartmouth.e\
>  |>> du> 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
>  ...
>  |>> 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.
>  ...
>  |> Does this exist for the rest of us to study?
>  ...
>  |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.
>  ...
>
> Only to add that "modern standard" C libraries define
> "overlapping" by means of exclusivity, meaning that memcpy(x,
> &x[1], 1) is an invalid overlapping that requires memmove() to be
> used.

Uh, yeah, but not relevant at least to the code I did which was written
in C but generated machine code, not calls to library functions.