Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!think!snorkelwacker!spdcc!merk!xylogics!cloud9!jjmhome!m2c!umvlsi!dime!yodaiken
From: yodaiken@freal.cs.umass.edu (victor yodaiken)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <6364@dime.cs.umass.edu>
Date: 6 Nov 89 15:27:37 GMT
References: <1080@mipos3.intel.com> <2630@gandalf.UUCP>
Sender: news@dime.cs.umass.edu
Reply-To: yodaiken@freal.cs.umass.edu (victor yodaiken)
Organization: University of Massachusetts, Amherst
Lines: 26

In article <2630@gandalf.UUCP> carr@gandalf.UUCP (Dave Carr) writes:
>In article <1080@mipos3.intel.com>, jpoon@mipos2.intel.com (Jack Poon~) writes:
...
>> What the advantage of using self-modifying code that non-self-modifying code
>> cannot achieve?
>
[stuff about 80186 i/o deleted]

>Another thing that pops to mind, is when your software may contain lots of 
>options, and spends most of its time testing option flags and skipping
>around unused options.  Why not have the software create the software
>without the options in!  You would need the software in a run-time locatable
>format, but this is certainly feasible.
>

The Synthesis operating system, by Henry Massilin and Carlton Pu of
Columbia University is an amazing example of this method. System calls and
system operations which will be computed repeatedly are compiled on the
fly. For example, when a process "opens" a file, the system generates code
for reading and writing that particular file, eleminating several layers of
switches. Context switch code is also compiled for each process. Basically
code generation is used to do constant propagation. Interesting to see
how this work might do on a machine with a deep pipline. Probably ok, since
compliations saves 100's of instruction executions.

If there is interest, I'll try to dig up the reference.