Self-modifying code

[nather at ut-sally.UUCP]

In article <33441 at yale-celray.yale.UUCP>, lisper-bjorn at CS.YALE.EDU (Bjorn Lisper) writes:
> 
> I guess there are situations with extreme performance requirements where
> self-modifying code is justified. It would be interesting to see what a
> semantics for self-modifying programs would look like. 

I agree.  That was the whole point of my original posting -- to see if someone
with a talent for languages could ignore the current prejudice against this
practice, and see what might be done.  If there's really no way to do it in a
reasonable manner, fine -- but just *saying* it's awful doesn't *make* it awful.

> The first [source of uncleanliness] is
> the difficulty for a human mind to trace what's going on in a self-modifying
> program. 

I think this arises because of the two different intellectual "levels" involved:
what the program is doing which generates the instructions (by analogy with the
instruction generator in a compiler) and what those instructions are going to
do when they are executed.  These *must* be kept completely separate or massive
confusion results.  But if the written code is approached with full awareness
of this requirement, the confusion vanishes -- in my experience, anyway.

> The second is an advantage read-only data (e.g. non-self-modifying
> code) has to writable data: read-only data can be accessed asynchronously,
> in any order, even concurrently, without any constraints. Therefore
> read-only is "clean" in a concurrent environment. 

I believe self-modifying code was condemned long before concurrent environments
were even possible.  This may be a disadvantage, but *no* techinque exists
without trade-offs.  I think we can live with this one.

> An example apart from code
> is data bases, where read-only data don't have to be locked during
> transactions.

OK, but I'm not sure this is relevant here.  I do, however, appreciate your
keeping "data" plural.  It happens so rarely nowdays ...


-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
{backbones}!{noao,ut-sally}!utastro!nather
nather at astro.as.utexas.edu