URL
https://opencores.org/ocsvn/w11/w11/trunk
Subversion Repositories w11
[/] [w11/] [tags/] [w11a_V0.61/] [doc/] [ECO-026-div.txt] - Rev 27
Go to most recent revision | Compare with Previous | Blame | View Log
$Id: ECO-026-div.txt 579 2014-08-08 20:39:46Z mueller $
Scope:
Introduced in release w11a_V0.61
Affects: all w11a systems
Symptom summary:
The div instruction gave wrong results in some corner cases when either
divisor or quotient were the largest negative integer (100000 or -32768):
1. wrong q and r when dd=n*(-32768), dr=-32768 with n even
2. V=1 set when division solvable and proper result is q=-32768
Background:
The PDP-11/70 (KB11-C) and the w11a use very different division algorithms.
Both use a non-restoring divide.
- The KB11-C uses a straight forward 2 quadrant core algorithm for positive
dividends and positive or negative divisors. Negative dividends are first
converted to positive, the results later corrected. This leads to quite
complex implementation with 35 micro states.
- The w11a uses a 4 quadrant algorithm which directly allows positive and
negative dividends and divisors. The qbit logic is much more complex in
this case. Advantage is that the whole divide algorithm can be implemented
with only 6 states in the main sequencer.
In twos complement integer arithmetic, as used in the pdp11 and almost all
contemporary computers, the range of positive and negative numbers is
different, for 16 bit for example
oct 100000 to 077777
dec -32768 to +32767
so the smallest negative number has no positive counterpart. Trying to negate
the smallest negative number leads to the same number
mov #100000, r0
neg r0 --> r0 = 100000; V=1
These special properties of the largest negative number easily lead to corner
cases which require special treatment, both the KB11-C and the w11a divide
algorithms need special rules and checks for this.
Summary of issues:
1. when dividend was dd=n*(-32768) with an even n and the divisor was
dr=-32768 the old w11a algorithm returned wrong quotient and remainder
values and V=0 status.
2. for all divisions which result in a quotient of -32768 the old w11a
algorithm set the overflow (V=1) condition. Since in this case the
destination registers were not updated and still contained the
dividend, software not checking the V code saw wrong quotient and
remainder values.
Fixes:
- Issue 1: wrong q and r for dd=n*(-32768), dr=-32768 with n even.
- the corner case is detected in state s_opg_div by testing that divisor
is 0100000 and low order part of dividend is zero. When detected, the
qbit logic is modified and quotient and remainder corrections are done
unconditionally.
- Issue 2: V=1 set when division solvable and proper result is q=-32768.
The divide core algorithm calculates the correct q and r, only the
overflow testing was incorrect.
The old algorithm had two overflow abort conditions
- a check that bit 31 and 30 of the dividend are equal
- a check after the first division cycle
The new algorithm now has three overflow abort conditions
- the bit 31/30 check on the dividend was too restrictive. Valid divisions
with dd=(-32768)*(-32768)+n and dr=-32768 giving q=-32768 and r=n would
be rejected. The 31/30 check is now only applied when the divisor is not
equal 0100000
- the division abort condition in the first division cycle was completely
revised, this avoids that solvable divisions are aborted at this stage
- the first two conditions don't catch all overflow situations. The
remaining ones all have after the quotient correction stage q>0 when
a negative quotient is expected. A third overflow check was added to
s_opg_div_sr to handle these cases.
Side effects:
- the old implementation guaranteed that the destination registers were
unchanged in case of overflow. The new does not, the overflow check in
s_opg_div_sr is done after the quotient is stored, and storing remainder
is not suppressed in case of overflow. So both q and r regs are changed.
- with additional states it could be guaranteed that destination registers
are never updated in case of overflow. See proviso below.
- the pdp-11/70 KB11-C in most cases keeps destination registers unchanged
in case of overflow, but also has a late check after one register has
been modified.
- the J11 never updates registers in case of overflow. A case like
0,177777 / 177777 were w11a now updates regs is known from J11
diagnostics to not update in J11.
- simh always preserves the destination registers in case of overflow.
!! the pdp11 processor handbook considers the destination registers as !!
!! undefined in case of division overflow, so the w11a behavior is OK. !!
Provisos:
- the behavior after V=1 aborts of a div instruction is now different in
- w11a --> regs updated under some rare conditions
- KB11-C --> regs updated under some rare conditions
but in cases different from w11a
- 11/44 --> regs updated under some conditions (see v7_longdivide_bug.txt)
- J11 --> regs never updated
- simh --> regs never updated
--> that can lead to spurious failures in original DEC diagnostics when
they test the complete response
--> even though the current w11a behavious is full within specs it is unclear
whether all software tolerates this, especially non-DEC OS. Unix V7 is
known to have an issue with ldiv and CPUs not preserving regs, see
http://minnie.tuhs.org/PUPS/v7_longdivide_bug.txt
--> Only further studes can show whether it is worth the effort and the
slow down of 1-2 cycles to guarantee preserved registers.
Go to most recent revision | Compare with Previous | Blame | View Log