Self-modifying code

[David Keppel]

[ What about that self-modifying code ]
nather at 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