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