Xref: utzoo comp.lang.c:11259 comp.arch:5424 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mandrill!gatech!bloom-beacon!husc6!yale!lisper-bjorn From: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Keywords: self-modifying code, generate-and-execute Message-ID: <33441@yale-celray.yale.UUCP> Date: 11 Jul 88 21:30:08 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <5254@june.cs.washington.edu> <12357@ut-sally.UUCP> Sender: root@yale.UUCP Reply-To: lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) Organization: Yale University Computer Science Dept, New Haven CT 06520-2158 Lines: 47 In article <12357@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes: >In article <5254@june.cs.washington.edu>, pardo@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