Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site dg_rtp.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!rti-sel!dg_rtp!throopw
From: throopw@dg_rtp.UUCP
Newsgroups: net.arch
Subject: Re: Addressing modes (conditional branches)
Message-ID: <202@dg_rtp.UUCP>
Date: Thu, 6-Mar-86 18:44:32 EST
Article-I.D.: dg_rtp.202
Posted: Thu Mar  6 18:44:32 1986
Date-Received: Sat, 8-Mar-86 21:24:37 EST
References: <546@tekcrl.UUCP> <426@utastro.UUCP> <5681@mordor.UUCP> <1106@mit-eddie.UUCP> <5705@mordor.UUCP>
Lines: 43

>> [discussion of self-modifying code for conditional branching]

> [discussion of effect of self-modification on address space]
> So to rectify the situation when you fork, you bring in
> a clean copy of the executable.

Uh... I'm not sure what "fork" does on whatever OS *you're* talking
about, but in Unix(*), the fork(2) system call does *not* (repeat *not*)
want to bring in a "clean copy" of the executable.  The address space
*as* *modified* *by* *the* *parent* must be seen by the child.  On the
other hand, it is clear that memory containing modifiable bits, code or
not, cannot be in the "text" or "shareable" segment (unless special
fault-driven mechanisms are available for revocation of sharing).

> You mentioned a copy on write scheme. Maybe on a machine that allows a
> physical page to be mapped to more than one virtual page this could be
> done right, but on a machine like the latest IBM risc a physical page
> can only be mapped to one virtual page (this saves a (pipeline
> stage) or (gobs of hardware) for determining if you hit or not) you
> are forced to copy the executable into a new segment.

Interesting.  The IBM risc can't do shared text segments?  How odd.
Or perhaps by "a physical page can only be mapped to one virtual page"
you mean "all virtual pages that are mapped to a given physical page
must have the same virtual address"?  This latter interpretation would
allow shared text, while the original doesn't seem to.

> But the above really doesn't get at the issue.  If performance is a
> goal, the hardware is going to be slower (or more expensive) if it has
> to deal with self-modifying code even if the software can handle it.

I agree that this is so for *some* classes of hardware, and that these
classes of hardware include most widely-known-to-be-practical
high-performance designs.  Thus, though I think that some of what you
said in getting to your conclusion is inaccurate, I agree with your
conclusion.

> eric h. jensen    ehj@angband    ...!decvax!decwrl!mordor!angband!ehj
--
* Unix is a trademark of ATT
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!dg_rtp!throopw