[Simh] Problems with HSA in H316

[Adrian Wise]

Hi

I ran the Verification and Test program, O16-11T1, for the High Speed 
Arithmetic on H316 on simh and it turned up a few detailed problems.

The first is in the handling of the most significant bit of the B 
register (B1) in some of the double precision instructions.

In double precision add and subtract (DAD and DSB) and also in multiply 
(MPY), B1 is always cleared at the end of the operation. Note that the 
double precision integer format on these machines is a 31-bit (not 
32-bit) value, where the sign is in the sign bit of the A register, the 
30-bit magnitude spans the two 15-bit magnitude fields of the A (MSB) 
and B (LSB) registers, and the sign bit of the B register is unused.

Double precision load, however, does not force B1 to zero (it is simply 
loaded from memory).

The second problem is that the normalization operation (NRM) is 
incorrectly implemented. Currently the code continues to shift while the 
top two bits of the A register *differ* where it should shift while they 
are the *same* (i.e. *until* they differ). Also the code shifts (if the 
argument is zero and cannot be normalized) until the shift count is 
strictly greater than 32 where it should have stopped at 32.

The third problem concerns the handling of the shift counter in the 
normalization operation (NRM) and by the instruction that transfers the 
shift count, typically produced by NRM, in to the A register (SCA).

This is one of the ugliest areas of the series-16 instruction set, and 
isn't helped by much of the documentation being incorrect. The problem 
centres on confusion as to whether 5 or 6 bits are used for the shift 
count value. I suspect (with little actual evidence) that this is 
because the 16-bit machines only need 5-bits for this, but the hardware 
design was inherited from the earlier 24-bit machines where 6 bits would 
have been required.

At the conclusion of the NRM operation, the shift count that was 
required to normalize the value in the A and B registers is transferred 
into a register that is described in the software manuals as the "shift 
count". The value will always be in the range 0 to 31 (5 bits) but six 
bits are placed in the "shift count" register. This is so even if you 
try to normalize the value zero, which would run forever except that the 
hardware stops when the counter reaches the value 32, but the top bit of 
the six is discarded and in this case the "shift count" would be set to 
zero. In all cases bit 11 of the "shift count" is cleared.

However, the SCA instruction transfers the lower *six* bits of the 
"shift count" to the A register and forces the upper 10 bits to zero. If 
the value in the "shift count" is the result of a NRM operation then in 
fact the upper 11 bits will be zero - 10 bits forced to zero by SCA and 
the 11th by the NRM operation as it placed its result in the "shift 
count" register.

If an interrupt is taken between the NRM and SCA instructions, then it 
is quite possible that the machine state will be saved. In this case the 
"input keys" instruction, INK, will also transfer six bits of the "shift 
count" to the A register (like SCA) but at the end of the interrupt 
service routine the "output keys" instruction, OTK, will transfer just 5 
bits back to the "shift count" setting bit 11 of the "shift count" to 
zero (just like the original SCA did).

In the actual hardware there is no true *architectural* register 
provided for the "shift count" value produced by the NRM operation. 
Instead the value is placed in the 'E' register which is not really a 
piece of architectural state at all. It is the bank of slave latches 
provided for the B register to provide what the contemporary hardware 
descriptions call "pulse dodging" - it holds the value formerly in the B 
register when it is modified, by a shift instruction for example, and 
placed back into the B register. The 'E' register is analogous to the 
'D' register which provides the equivalent function at the output of the 
ALU.

The 'E' register's normal function is to be loaded with the value in the 
B register in any instruction that is going to load a value back into 
the B register (IAB, the long shift instructions, MPY, DIV, and the 
double-precision operations) but these instructions generally modify all 
16 bits of the E register.

The Verification and Test program, O16-11T1, exploits this other way of 
placing data into the "shift count" in order to test it independently of 
the operation of SCA. It uses the interchange A and B instruction, IAB, 
to put values into the "shift count". But it expects that it can write 
all of the 6 bits that it can subsequently test with a SCA or INK 
instruction.

Hopefully this long-winded explanation explains the various masking 
operations applied to the "sc" value - sometimes 077, sometimes 037, 
which otherwise look rather random.

The attached patch file corrects these issues. Note that this patch file 
is relative to the code in h316_cpu.c on the "Interim Corrections" page:

http://simh.trailing-edge.com/interim.html

(It is independent of my recent patch for the X register operation - 
they can be applied in either order.)

Once patched simh will cleanly run the Verification and Test
program for the High Speed Arithmetic operation, O16-11T1, which may be 
downloaded from here:

http://www.series16.adrianwise.co.uk/software/source/VT/O16-11T1/O16-11T1_slst.ptp

The attached "do" file, boot_O16-11T1 will run it.

If you take the V3.8-1 release, replace h316_cpu.c by the one from the 
interim page, referenced above, and then apply both my earlier 
XR_patchfile and the HSA_patchfile attached here then you end up with 
the h316_cpu.c and h316_defs.h attached to this message.

Adrian

-- 
Adrian Wise
http://www.series16.adrianwise.co.uk
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: HSA_patchfile
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20111119/2bd367be/attachment-0004.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: boot_O16-11T1
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20111119/2bd367be/attachment-0005.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h316_cpu.c
Type: text/x-csrc
Size: 62986 bytes
Desc: not available
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20111119/2bd367be/attachment-0002.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: h316_defs.h
Type: text/x-chdr
Size: 9717 bytes
Desc: not available
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20111119/2bd367be/attachment-0002.h>