Xref: utzoo comp.lang.c:11271 comp.arch:5433
Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ut-sally!nather
From: nather@ut-sally.UUCP
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Keywords: self-modifying code, generate-and-execute
Message-ID: <12360@ut-sally.UUCP>
Date: 12 Jul 88 14:49:28 GMT
References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <33441@yale-celray.yale.UUCP>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 44

In article <33441@yale-celray.yale.UUCP>, lisper-bjorn@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@astro.as.utexas.edu