Self-modifying code

[Ed Nather]

In article <2972 at geac.UUCP>, daveb at geac.UUCP (David Collier-Brown) writes:
> In article <429 at uwovax.uwo.ca> 16012_3045 at uwovax.uwo.ca (Paul Gomme) writes:
> [discussion of execute-only code segments]
> >	Besides, I thought that self-modifying code was (a) extremely difficult
> >to write, and (b) considered poor programming practice.
> 
>   Yes, it is and it is.
> 

This practice was formally named "horrid" about the time the GOTO was
banished, and for the same reasons: it's *very* hard to figure out what
is going on if either practice is exhibited unconstrained.  Yet the idea
of "self-modifying code" was one of the great motivators for encoding
instructions in the same form as data, and holding them in the same kind
of memory.  Prior to that time, "instructions" were mostly wires on a
plugboard and were hard to change in software.

It did take a long time and a lot of thought to make the GOTO really
unnecessary -- it's still hidden in C but not much used -- yet a similar
effort has not been applied to self-modifying code, and I've always
wondered why.  My guess -- and it's only a guess -- is that there has
not been much emphasis on real-time, time-critical programming techniques
in most CS departments, so the need to get maximal speed from a particular
chunk of hardware was not evident.

But it's really needed -- if you have to watch an animated display of data
on a CRT all night long that blinks and flickers, you learn very quickly
that techniques to get display refresh faster than the human flicker-frequency
can save lots of pounding headaches.  If they are "forbidden" techniques
that require a descent into assembly coding, so be it.  Headaches hurt.

Are the seeds of a new religion hidden here?

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