Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!unisoft!cjohnson
From: cjohnson@unisoft.UUCP (Christopher Lyle Johnson)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Summary: The performance win may not always exist.
Keywords: Caching problems, mmu's, S&M, etc.
Message-ID: <1217@unisoft.UUCP>
Date: 15 Jul 88 00:03:02 GMT
Reply-To: cjohnson@binary.UUCP (Christopher Lyle Johnson)
Organization: UniSoft Systems, 6121 Hollis St., Emeryville, CA 94608
Lines: 41

As has been already pointed out, one of the problems with self
modifying code stems from separate instruction and data caches.
Even on Harvard architectures, if it is possible to mark an area
of code with a cache inhibit bit SM code doesn't cause too many
problems.  In kernel mode or on systems where user processes can
access the mmu, SM code may make sense in certain situations.  
I have no major aesthetic complaint if the performance win is
large enough.

Of course, if the code isn't cached, perhaps the win is less
significant.  If we want to toggle the don't cache bit (i.e. set
while modifying the code, clear after the code is written), it
may be difficult to claim a performance win for non-supervisor
processes.  If it takes two system calls per SM operation, the
overhead is pretty high.

(If it is faster to flush the caches, that may be an option,
but there may be very little control over the granularity.  How
would you implement a 'flush_address(base, bounds)' system call
on your favorite mmu/cache system?)

However..., if a user process can't get to the mmu the operating
system has a bit of a problem.  I guess the trick is to write
protect program text and execute protect the data.   Of course,
this causes a execute protect fault on the modified code page(s).
The kernel could then flush the caches and write protect the
page.  Again, this is a lot of overhead.

(Yes, I know some mmus don't have an execute protect mode.  Work
arounds may exist, eg. the function code mode on the 030.  Ugh.)

All in all, a person had better have a good reason for writing
self modifying code.  In some cases the performance win from
the code may be lost in overhead.  There are many other facets
to this problem, too.

					Cheers,
					    cj*

=========================================================
This message does not reflect the views of
UniSoft Corp but this sentence does.