henry@utzoo.UUCP (Henry Spencer) (07/02/83)
I have a question about an obscure point of the 16032's memory
management. I'm aware that there is more recent documentation
than the stuff mentioned below, but the versions I have seen don't
shed any light on the matter.
I have two documents describing the NS16032: a datasheet
dated April 1982, and a manual about a year older. The
manual says that there are two restrictions on instruction
restart after a memory-management abort:
A. Cannot restart after aborting a write to a readonly page.
B. Cannot restart an instruction with overlapping operands.
The datasheet mentions neither of these restrictions, but
does mention three of its own:
1. If FLT hasn't been hit, the abort signal must strike
before the end of Tmmu.
2. If FLT has been hit, the abort signal must strike before
FLT is turned off, and the abort will not be done
until it's turned off.
3. Read-modify-write accesses must never be aborted during
the write part (the cpu helpfully provides enough
information so you can catch them earlier).
Since the manual did not deign to discuss electrical matters,
it's no surprise that 1+2 were not mentioned there. But A+B
are rather different from 3. Furthermore, the datasheet for
the MMU does not mention whether it complies with ANY of 1-3.
The definitions of one or two of its status bits do have an
ominous sound, since they imply that R-M-W accesses can be
aborted during the W part. Does anybody know what the story
is? Surely the MMU must comply with 1+2 at least, but the
datasheet I have says nothing about abort timing. Compliance
with 3 would be VERY NICE for the software, and the MMU does
appear to have all the necessary information to do it right.
Replies by mail, please; I will summarize for the net if there is
interest.
Henry Spencer
U of Toronto
{allegra,ihnp4,linus,decvax}!utzoo!henryhenry@utzoo.UUCP (Henry Spencer) (07/18/83)
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