Self-modifying code

[Ed Nather]

In article <5254 at june.cs.washington.edu>, pardo at june.cs.washington.edu (David Keppel) writes:
> [ What about that self-modifying code ]
> nather at astro.as.utexas.edu (Ed Nather) writes:
> > "horrid"
> 

Tsk tsk -- out of context, like the movie ad that quotes a reviewer who said:
"This movie is a great waste of time -- it's insipid, boring, and stupid.  I've
never seen anything like it."

The ad quoted:   "...great...I've never seen anything like it."

I said the practice "...was formally declared horrid ...", NOT that *I* thought 
it was.  I don't think that.

> Some reasons NOT to write S-M (Self Modifying or Sado-Masochistic) code:
> + It's machine dependent (we already knew that).

Assembly code does tend to be machine dependent, all right -- but C was 
designed to give the programmer the same facility, but with better control and
better discipline.  It works quite well for those things it covers.  It is, in
some reasonable sense, portable.  A good compiler could generate self-modifying
code to suit, I'm sure.  What we lack is the formal discipline for using it
wisely and well.

> + Read-only (e.g., code) pages may be shared.

Only in a time-sharing system.  Most real-time control programs can't tolerate
such an environment for lots of reasons, mostly due to critical timing 
requirements.  Anyway, if generated code is treated as "executable data" this 
whole point becomes irrelevant.

> + Some machines have sperate I and D spaces.  It's not inconceivable
>   that different machines in the same family will have different
>   memory models.

Not a problem.  Generated executable code changes, just like any other variable
values, and can be treated the same way.

> + Many machines use seperate instruction and data caches.  Instruction
>   caches can be made much simpler (= smaller = faster) by not
>   requiring them to pay attention to the data bus.  Writing to a
>   memory location is not guaranteed to update the I cache, thus you
>   may or may not execute the modified instruction.  Next week's model
>   may have a large enough cache that this week's code breaks.
> 

Again, not a problem.  You don't take the generated code out of the I cache,
but out of the D cache, since it can (by definition) change.

> Good enough?

Sorry, no.  I've heard LOTS of arguments against programs that generate their
own code, and all of them -- so far as I am aware -- assume the "proper" answer
in generating arguments to show the answer is proper.  Be honest: suppose you
*had* to do it this way, but needed a formal discipline to keep it clean and
understandable, and *fast.*  Couldn't you find a reasonable way?

"It's unclean because ... well, because it's so ... so ... UNCLEAN!"

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