Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mordor.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!amdcad!lll-crg!mordor!ehj
From: ehj@mordor.UUCP (Eric H Jensen)
Newsgroups: net.arch
Subject: Re: Addressing modes (really self-modifying code)
Message-ID: <5690@mordor.UUCP>
Date: Thu, 27-Feb-86 14:00:56 EST
Article-I.D.: mordor.5690
Posted: Thu Feb 27 14:00:56 1986
Date-Received: Sat, 1-Mar-86 17:36:56 EST
References: <546@tekcrl.UUCP> <426@utastro.UUCP> <906@megaron.UUCP>
Reply-To: ehj@mordor.UUCP (Eric H Jensen)
Distribution: net
Organization: S-1 Project, LLNL
Lines: 24

In article <906@megaron.UUCP> rogerh@megaron.UUCP (Roger Hayes) writes:
>(Oh, no -- I've lost my reference for this!
> If anyone knows what goes in the blank ("[]") below,
> send me mail, thanks. -rh)
>
>This (self-modifying code) is the way [] does a bitblt; the
>entry code checks for the base cases, otherwise it builds
>custom code to do the bitblt and then jumps to it.  Very
>clever -- the case to build the code is larger than the 
>case within the bitblt would be, but performance is much
>higher because the code that's built can be optimal.


I would argue that this is not self-modifying code - new code is being
generated, the old code is not being modified.  We use this technique
to speed up our hardware simulator.  The user can tell the simulator
to generate code for every node in the net that will gather, operate
on, and scatter the data bits associated with that node.  The
resulting simulation is REAL fast.

-- 
eric h. jensen        (S1 Project @ Lawrence Livermore National Laboratory)
Phone: (415) 423-0229 USMail: LLNL, P.O. Box 5503, L-276, Livermore, Ca., 94550
ARPA:  ehj@angband    UUCP:   ...!decvax!decwrl!mordor!angband!ehj