Programmed code generation (was: Self-modifying code)

[Ed Nather]

In article <5262 at june.cs.washington.edu>, pardo at june.cs.washington.edu (David Keppel) writes:
> 
> Let me rephrase my position.  There is nothing architecturally weird
> about programs that generate their own code.  Doing so does not cause
> any problems on any machines that I am aware of, although few
> OPERATING SYSTEMS support this.
> 

And no LANGUAGES that I'm aware of.  But that's the whole point. CAN they?

[ separate I-D cache arguments omitted, thus excising the neat idea
  of a "snoopy" cache ]
 
> Assume that you have an algorithm that is, say, 1000 instructions and
> that each instruction takes 4 cycles to execute (must be a RISC :-).
> One particular part of it, 10 instructions, is written as
> self-modifying code.  It can also be written as 100 instructions of
> non-self-modifying (static) code.  

I wouldn't use self-generated code in such a case, I'd do it the way you
suggest.  But in a different case:

The algorithm has 1000 or so set-up instructions, which generate a small,
fast loop that is executed for each and every pixel displayed on a screen,
but which must do different things to each pixel depending on current
program conditions -- maybe 10 or 12 decisions that can be folded into
perhaps 4 or 5 instructions, but which would require 10 or 12 branch
instructions (plus the executed instructions) for every pass, learning 
over and over (and over, and over) what the constraining program conditions 
are.  And how many pixels are there on a screen?  Well, lots -- 1024 X 1024 
is almost obsolete now :-).

The alternative, to have a separate (static) loop for each possibility,
will run you out of space very quickly if the program conditions that make
sense are combinatorial in nature -- the commonest case.  And a few hundred
copies of *nearly* the same loop would not be easy to maintain.

I believe we can agree (can we?) that some useful conditions can arise where
self-generated code can be very useful.  The term "self-modifying code" 
is, I think, a mis-nomer, implying a loop which changes itself into something
else, which then ... 

But if code generation is kept separate from code execution (which might well
be a reasonable condition to impose in any formal description), I doubt any
serious confusion would arise, and I can't see that much would be lost.  Thus
the term "self-generating" code might be better, or perhaps even "programmed
code generation."  That makes it sound less scary.

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