jer@peora.UUCP (J. Eric Roskos) (03/03/86)
> I can't see how you could effectively manage a POLICY of > "self-modifying code is okay" in a statically linked environment. > > [ ... a lot of arguments based on how they do things nowadays ... ] > > I would opt for effcient indexed address modes and instructions that > keep the requirement for konstant operands to a minimum (i.e. the > amount to shift by for the shift instruction). Aren't these the items > that made self modifing code passe? The funny (strange or interesting) thing about this is, "what is `code'?" You have to define that first. Suppose you modify immediate operands... then that's self-modifying code. But if you take an identical instruction sequence, except that it uses a register operand instead of an immediate operand, then that's *not* self-modifying code. But really all you've done is displace part of the code -- the part that's variable -- out of the stream of data read in by the instruction fetches and into a separate area, so that each person can have their own copy of it. So really all we're talking about here is separating "parts of the program that are modified during execution" from the parts that aren't. So cases in which "self-modifying code" turn out to be more efficient than code that's "not self-modifying" are really just cases where that separation wasn't done correctly, or where the instruction set didn't allow it to be done. (By way of example of the latter, I recall that on the 6502 some of the addressing modes tend to encourage "self-modifying code," whereas on the 6800 (which the 6502 is a convoluted derivative of) the same modes don't encourage that, simply because of the width of an index register: you can't easily move 16-bit indices out of the instruction stream because of the 6502's 8-bit index registers.) To sum up, my point is that almost *any* program really has "self-modifying code," it's just that well-designed programs separate the parts that get modified from the parts that don't; or, in the context of this newsgroup, well-designed instruction sets make programs that use that separation the more (or an equally) efficient alternative to not separating the two. -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCUR.UUCP CCUR DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642 LOTD(5)=O "... And what you thought you came for Is only a shell, a husk of meaning From which the purpose breaks only when it is fulfilled If at all. Either you had no purpose Or the purpose is beyond the end you figured And is altered in fulfilment. There are other places ..." -- T. S. Eliot, "Little Gidding"