Path: utzoo!censor!geac!jtsv16!uunet!cs.utexas.edu!usc!merlin.usc.edu!usc.edu!raulmill
From: raulmill@usc.edu (Raul Deluth Rockwell)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <RAULMILL.89Nov14133156@usc.edu>
Date: 14 Nov 89 21:31:56 GMT
References: <1080@mipos3.intel.com> <2630@gandalf.UUCP>
Sender: news@merlin.usc.edu
Organization: University of Southern California, Los Angeles, CA
Lines: 21
In-reply-to: carr@gandalf.UUCP's message of 20 Oct 89 21:03:51 GMT

The original message of this thread seems to have expired, so I may be
way off base, but here is what appears to be a fragment of the
question:

In article <1080@mipos3.intel.com>, jpoon@mipos2.intel.com (Jack Poon~) writes:
> 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?

In short, incremental compilers, linking loaders, debuggers and
similar system tools use self-modifying code.  It is quite possible to
have a situation where rapid allocation and deallocation of memory
will run into cache corruption.

Of course with classic environments (unix & c for example), this isn't
much of a problem, or it can be hacked around by flushing the entire
cache.  But to exclude fast/tight loader design because somebody
decided that that is a 'poor programming practice' seems rather silly.

--