Self-modifying code (really Blit graphics)

[Doug Gwyn]

In article <2079 at u1100a.UUCP> krohn at u1100a.UUCP (Eric Krohn) writes:
>In article <8239 at brl-smoke.ARPA> gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>] As a significant example of C's efficiency for graphics programming,
>] virtually all the code in the Blit, DMD (5620), and MTG (630)
>] bitmapped terminals was written in C, and their graphics operations
>] are extremely fast.  No self-modifying code was necessary.
>Virtually all?  Yes.  The most critical?  No.
>The bottom-most level of all screen updates is the infamous
>bitblt function.  A 1982 BTL memo by John Reiser tells about the on-the-fly
>code generation done by bitblt to achieve rather good performance on the
>original Blit.  I've assumed that similar code was carried forward to the 630
>and the 5620 (even with the CPU switch).

Rob tells me that the 5620 doesn't use this trick.  (There is a chance
that the 630 does; I don't know.)  In the Feb 1985 Pike & Locanthi paper
in SP&E (V15, p131-151) they explain how this trick was done.  They also
mention that the savings over their best C version average about 20%.
Of course, bitblt is "bottleneck code", so every little bit helps, but
on-the-fly generation of instructions isn't essential (the first three
Blit bitblt() implementations were all written in C).

That was admittedly a risky example; bottleneck code is often made
to use some trick to speed things up.