Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.micro.16k
Subject: Re: 16032 MMU query
Message-ID: <3098@utzoo.UUCP>
Date: Mon, 18-Jul-83 16:41:28 EDT
Article-I.D.:    utzoo.3098
Posted: Mon Jul 18 16:41:28 1983
Date-Received: Mon, 18-Jul-83 16:41:28 EDT
References: <3062@utzoo.UUCP>
Organization: U of Toronto Zoology
Lines: 25

My question about the 16032 MMU aborting read-modify-write operations
to a read-only page early enough to permit restarting has been answered,
in a slightly unexpected way.  A couple of days after I posted the query,
the local National technical man called me!  Seems the folks at HQ had
noticed my question but had felt that the reply should go through more
formal channels than the net.  So, the definitive answer is...

There is one and only one problem with instruction restarts on a read-
modify-write to a read-only page.  If the operand is unaligned (the
16032 does not insist on words being word-aligned) and straddles the
boundary between a read-write page and a read-only page, the part that's
in the read-write page may get modified in potentially unrecoverable
ways before the attempt to alter the other part aborts the operation.
If your operands are properly aligned (16-bit words on 16-bit boundaries,
32-bit words on 32-bit boundaries), as they should be anyway for best
performance, everything's fine and copy-on-write memory management will
work perfectly.

(I would suspect that there is still a problem with an operation whose
operands overlap, but that is such an obscene pathological case that
I refuse to worry about it.)
-- 
				Henry Spencer
				U of Toronto
				{allegra,ihnp4,linus,decvax}!utzoo!henry