Xref: utzoo comp.lang.c:11324 comp.arch:5478 Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!mailrus!husc6!cs.utexas.edu!ut-sally!nather From: nather@ut-sally.UUCP (Ed Nather) Newsgroups: comp.lang.c,comp.arch Subject: Re: Programmed code generation (was: Self-modifying code) Keywords: self-modifying code, generate-and-execute Message-ID: <12381@ut-sally.UUCP> Date: 14 Jul 88 15:21:07 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <5262@june.cs.washington.edu> Organization: U. Texas CS Dept., Austin, Texas Lines: 52 In article <5262@june.cs.washington.edu>, pardo@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@astro.as.utexas.edu