Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: Self-modifying code (really Blit graphics)
Message-ID: <8249@brl-smoke.ARPA>
Date: 29 Jul 88 01:42:10 GMT
References: <12330@ut-sally.UUCP> <225800044@uxe.cso.uiuc.edu> <8239@brl-smoke.ARPA> <2079@u1100a.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22

In article <2079@u1100a.UUCP> krohn@u1100a.UUCP (Eric Krohn) writes:
>In article <8239@brl-smoke.ARPA> gwyn@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.