Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!hao!gatech!mcnc!thorin!unc!ohbuchi
From: ohbuchi@unc.cs.unc.edu (Ryutarou Ohbuchi)
Newsgroups: comp.arch
Subject: Re: self-modifying code
Message-ID: <1415@thorin.cs.unc.edu>
Date: 25 Feb 88 14:18:19 GMT
References: <486@taux01.UUCP> <4007@megaron.arizona.edu>
Sender: news@thorin.cs.unc.edu
Reply-To: ohbuchi@unc.UUCP (Ryutarou Ohbuchi)
Organization: University Of North Carolina, Chapel Hill
Lines: 25

rogerh@arizona.edu (Roger Hayes) write
>Someone (Rob Pike?) used self-modifying code to do bitblits.  The
>general case bitblit code did a case analysis to construct the optimal
>program for that particular blit, then jumped to the constructed
>program.  Worked quite well, as I recall.

It was for Blit bitmap graphics terminal, originally driven by 68000, and
later by WE32000.  It is more like a very special compiler than a 
self-modifying code.  The BitBlt code does case analysis, and generate
small 'code', and pass control to it (well, it is a self modifying code,
in some sense...).  The small code is without various case analysis
(BitBlt is not so simple, if special cases are considered), and faster
than the code with all the 'if' statements. 
I beleave the same technique is used for Microsoft Window's BitBlt code.
They generate code in (I thoght) stack segment, and branch to it.  It was
fairly nasty code because of 64K segment on 80X86s, if frame buffer
size exceeds 64K.

==============================================================================
Any opinion expressed here is my own.
------------------------------------------------------------------------------
Ryutarou Ohbuchi	"Life's rock."   "Climb now, work later." and, now,
			"Life's snow."   "Ski now, work later."
ohbuchi@cs.unc.edu	<on csnet>
Department of Computer Science, University of North Carolina at Chapel Hill
==============================================================================