Xref: utzoo comp.lang.c:11271 comp.arch:5433 Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bloom-beacon!tut.cis.ohio-state.edu!cs.utexas.edu!ut-sally!nather From: nather@ut-sally.UUCP Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Keywords: self-modifying code, generate-and-execute Message-ID: <12360@ut-sally.UUCP> Date: 12 Jul 88 14:49:28 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <33441@yale-celray.yale.UUCP> Organization: U. Texas CS Dept., Austin, Texas Lines: 44 In article <33441@yale-celray.yale.UUCP>, lisper-bjorn@CS.YALE.EDU (Bjorn Lisper) writes: > > 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. I agree. That was the whole point of my original posting -- to see if someone with a talent for languages could ignore the current prejudice against this practice, and see what might be done. If there's really no way to do it in a reasonable manner, fine -- but just *saying* it's awful doesn't *make* it awful. > The first [source of uncleanliness] is > the difficulty for a human mind to trace what's going on in a self-modifying > program. I think this arises because of the two different intellectual "levels" involved: what the program is doing which generates the instructions (by analogy with the instruction generator in a compiler) and what those instructions are going to do when they are executed. These *must* be kept completely separate or massive confusion results. But if the written code is approached with full awareness of this requirement, the confusion vanishes -- in my experience, anyway. > 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. I believe self-modifying code was condemned long before concurrent environments were even possible. This may be a disadvantage, but *no* techinque exists without trade-offs. I think we can live with this one. > An example apart from code > is data bases, where read-only data don't have to be locked during > transactions. OK, but I'm not sure this is relevant here. I do, however, appreciate your keeping "data" plural. It happens so rarely nowdays ... -- Ed Nather Astronomy Dept, U of Texas @ Austin {backbones}!{noao,ut-sally}!utastro!nather nather@astro.as.utexas.edu