Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Re: Self-modifying code
Message-ID: <5100031@ccvaxa>
Date: Wed, 19-Mar-86 23:20:00 EST
Article-I.D.: ccvaxa.5100031
Posted: Wed Mar 19 23:20:00 1986
Date-Received: Sat, 22-Mar-86 06:11:46 EST
References: <4254@dartvax.UUCP>
Lines: 25
Nf-ID: #R:dartvax.UUCP:4254:ccvaxa:5100031:000:1075
Nf-From: ccvaxa.UUCP!aglew    Mar 19 22:20:00 1986


>/* Written  3:20 am  Mar  6, 1986 by chuck@dartvax.UUCP in ccvaxa:net.arch */
>/* ---------- "Re: Self-modifying code" ---------- */
>> We DO have the formal discipline to use self-modifying code:
>> it's called incremental compilation.
>> 
>> For some specific instance of a general routine with all sorts of
>> ifs depending on parameters values, take a general prototype with all
>> the ifs in it, compile only the parts you need into a buffer, and then
>> execute that buffer.
>
>How does this differ (conceptually) from invoking a subroutine which has 
>its own local memory and passing it parameters?
>
>Chuck Simmons     chuck@dartvax

The difference is that the maximum number of ifs are evaluated at compile time
rather than run time. Obviously, it isn't the only type of compilation 
possible. My point is that the concepts underlying `self-modifying code'
are portable at the macro level of subroutines, rather than at the micro level
of fields in instructions.

Andy "Krazy" Glew. Gould CSD-Urbana. 
USEnet: ...!ihnp4!uiucdcs!ccvaxa!aglew
ARPAnet: aglew@gswd-vms