Self-modifying code

[Bjorn Lisper]

In article <12357 at ut-sally.UUCP> nather at ut-sally.UUCP (Ed Nather) writes:
>In article <5254 at june.cs.washington.edu>, pardo at june.cs.washington.edu
(David Keppel) writes:
>> [ What about that self-modifying code ]
....
>> Some reasons NOT to write S-M (Self Modifying or Sado-Masochistic) code:
....
>> + Read-only (e.g., code) pages may be shared.
>
>Only in a time-sharing system.  Most real-time control programs can't tolerate
>such an environment for lots of reasons, mostly due to critical timing 
>requirements.  Anyway, if generated code is treated as "executable data" this 
>whole point becomes irrelevant.

There are time-sharing systems that can handle critical tasks (e.g.
real-time applications with strict timing requirements) well. These systems
have the possibility to give tasks priorities. A critical task can be given
a high priority to enable it to meet its time limits. Such a system may very
well have code that is shared.

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.

>> Good enough?
>
>Sorry, no.  I've heard LOTS of arguments against programs that generate their
>own code, and all of them -- so far as I am aware -- assume the "proper"
>answer in generating arguments to show the answer is proper.  Be honest:
>suppose you *had* to do it this way, but needed a formal discipline to keep
>it clean and understandable, and *fast.*  Couldn't you find a reasonable way?
>
>"It's unclean because ... well, because it's so ... so ... UNCLEAN!"

I guess there are situations with extreme performance requirements where
self-modifying code is justified. It would be interesting to see what a
semantics for self-modifying programs would look like. Regarding the
"uncleanliness" I think there are two main sources for this. The first is
the difficulty for a human mind to trace what's going on in a self-modifying
program. The second is an advantage read-only data (e.g. non-self-modifying
code) has to writable data: read-only data can be accessed asynchronously,
in any order, even concurrently, without any constraints. Therefore
read-only is "clean" in a concurrent environment. An example apart from code
is data bases, where read-only data don't have to be locked during
transactions.

Bjorn Lisper