Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!brutus.cs.uiuc.edu!apple!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <46730@bbn.COM>
Date: 10 Oct 89 19:13:27 GMT
References: <1080@mipos3.intel.com>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 29

In article <1080@mipos3.intel.com> jpoon@mipos2.intel.com (Jack Poon~) writes:
>Greetings,
>
>Could any experts out there educate me WHY and HOW does self-modifying code use?
>What the advantage of using self-modifying code that non-self-modifying code
>cannot achieve?

I'm not an expert, but I figured I'd answer anyway.

There are many examples of self-modifying code.  Perhaps the most
common is for code to change the value of an immediate operand.  This
would be an advantage, if memory space were very tight.  However, it
is discouraged mainly because modern processors often have deep
prefetching of instructions, if not instruction caches, and it can be
difficult to detect if a normal write could write data that has
already been prefetched.  So, newer architectures have specified
unpredictable behavior when this is done.

Yet there are uses for self-modifying code.  Some spreadsheet programs
compile on-the-fly to improve execution speed (the difference between
compiled and interpreted code), and some bitblt's as well.  Debuggers
often write jumps or traps into the instruction stream, to make
single-stepping and breakpoints work.

All architectures do have some kind of facility to make instruction-
space writes work; there's a sequence that clears instruction
prefetchers and instruction caches.  Often a supplier will furnish a
system service that a user program can call.
-Stan