Xref: utzoo comp.lang.c:11244 comp.arch:5419 Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!cornell!uw-beaver!uw-june!pardo From: pardo@june.cs.washington.edu (David Keppel) Newsgroups: comp.lang.c,comp.arch Subject: Re: Self-modifying code Summary: Architectural Restrictions Rule Keywords: self-modifying code, generate-and-execute Message-ID: <5254@june.cs.washington.edu> Date: 11 Jul 88 00:22:58 GMT References: <3353@cognos.UUCP> <619@goofy.megatest.UUCP> <429@uwovax.uwo.ca> <2972@geac.UUCP> <12330@ut-sally.UUCP> Reply-To: pardo@cs.washington.edu (David Keppel) Organization: U of Washington, Computer Science, Seattle Lines: 28 [ What about that self-modifying code ] nather@astro.as.utexas.edu (Ed Nather) writes: > "horrid" [ hard to write, understand, maintain ] > >But it's really needed -- if you have to watch an animated display >of data on a CRT all night long that blinks and flickers, you learn >very quickly that techniques to get display refresh faster than the >human flicker-frequency can save lots of pounding headaches. If >they are "forbidden" techniques that require a descent into >assembly coding, so be it. Headaches hurt. Some reasons NOT to write S-M (Self Modifying or Sado-Masochistic) code: + It's machine dependent (we already knew that). + Read-only (e.g., code) pages may be shared. + Some machines have sperate I and D spaces. It's not inconceivable that different machines in the same family will have different memory models. + Many machines use seperate instruction and data caches. Instruction caches can be made much simpler (= smaller = faster) by not requiring them to pay attention to the data bus. Writing to a memory location is not guaranteed to update the I cache, thus you may or may not execute the modified instruction. Next week's model may have a large enough cache that this week's code breaks. Good enough? ;-D on ( Compiler hints won't save you here ) Pardo