Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ucbvax!pasteur!ames!ptsfa!ihnp4!ihlpg!tainter
From: tainter@ihlpg.ATT.COM (Tainter)
Newsgroups: comp.arch
Subject: Re: self-modifying code
Message-ID: <4914@ihlpg.ATT.COM>
Date: 27 Feb 88 03:11:08 GMT
References: <486@taux01.UUCP> <4007@megaron.arizona.edu> <1415@thorin.cs.unc.edu>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 25

In article <1415@thorin.cs.unc.edu>, ohbuchi@unc.cs.unc.edu (Ryutarou Ohbuchi) writes:
> 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.

I did preciesly this.  It gave me a nice compact and fast routine.

The only alternatives I could come up with were:
--separate code for each operation jumped to through a jump table
	This was optimally fast but hugh.
--calling subroutines through jump tables
	This was good on space but relatively slow since it amounted to
	retesting the opcode inside the loop
--a sort of hybrid of the above
	This still came out quite large.

My self modifying code used a template into which it copied instructions
for the various operations.  This gave a near optimal tight loop for each
of the operations in a nice compact form.
 
> Ryutarou Ohbuchi	"Life's rock."   "Climb now, work later." and, now,

--j.a.tainter