Self-modifying code

[Eric Green]

in article <4776 at killer.UUCP>, chasm at killer.UUCP (Charles Marslett) says:
> In article <33441 at yale-celray.yale.UUCP>, lisper-bjorn at CS.YALE.EDU (Bjorn Lisper) writes:
>> Another related issue is that self-modifying code cannot be executed
>> directly from ROM. Executing programs in ROM is an important memory-saving
>> technique in small, diskless, special-purpose systems.
> 
> Actually, I always thought that ROM was much more important as a way of
> eliminating the need to load the code and as a way of guaranteeing non-
> self-modifying-ness.  Usually ROM code is larger (thus memory-consuming)
> than RAM-loaded code. 

Uh, I don't know what systems you're talking about, but for the small
microcontrollers that I've used -- the ROM is assembled to be placed
in the memory map at an absolute location. That is, it takes up the
same amount of space whether it's in ROM or RAM (in fact, one of my
favorite hardware designs is a little SRAM card that I use to spoof
ROM for prototyping purposes).  As for re-using memory buffers etc.,
those are always in RAM, so those are always re-usable -- no matter
where your executable is loaded. 

32K bytes of ROM costs about 1/4th of what 32K bytes of static RAM
costs (not to mention the eliminating-need-to-load). Note that these
are dedicated control systems using 6502's, Z-80's, and 6809's, which
have a total address space of 64K -- so 32K of ROM is a heckuva lot.

> Seriously, newer architectures have reduced the difference (to 0 perhaps),
> but the emphasis on RISC these days may resurrect self-modifying code --
> a RISC-er technique is not known to mankind!  (:-D}===<<).

Actually, RISC may be the stake-in-the-heart of self-modifying code.
RISC technology overcomes the increased memory bandwidth requirement
by using enhanced cache technology, 256-byte-at-a-time prefetch from
page-mode DRAM's, heavy pipelining, and every other trick in the book.
Most of which are quite contrary to the thought of self-modifying
code. Another RISC trick is to use the saved silicon for extra
registers, and have the compilers keep as many valus as possible in
the CPU registers. You can always do a one-word memory-indirect load
off of a register much faster than you can do a "memory-write(the
address into the instruction) memory-read(the address part of the
modified instruction) memory-read" triplet (which is at least three
two-word instructions, as vs. a single one-word instruction, on a
machine where one cycle = one word processed).

But, I HAVE done self-modifying code on a 6502-based microcontroller
(out of sheer necessity). I still make an occasional enhancement to
that software, over 3 years later, as new applications arise, and have
had no problems with readability. After all, in assembly on a
microcontroller, you have to save the address somewhere, and the
fact that the "somewhere" happens to be inside an assembly language
instruction makes little difference. The argument against
self-modifying code lies elsewhere besides readability.

--
Eric Lee Green    ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
          Snail Mail P.O. Box 92191 Lafayette, LA 70509              
       MISFORTUNE, n. The kind of fortune that never misses.