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