problem with s_floating multiplication MULS

[scruty]

A lot already works well in es40 which is really appreciated and I'd like to commend the developer(s)!

apart from $analyse/disk/repair/conf, where I'd recommend NOT to repair, if errors are shown when running under es40, es40 is actually more accurate than a "real alpha" in s_float arithmetic, but this could lead to incompatibility issues. I checked the multiply s_floating (MULS) instr:

MULS F7,F8,F9

on es40 with

F7 loaded with LDS from memory value 02081CEA;
DBG shows the F7 value as
s_float = 0.1000000E-36
t_float=0.999999991097579E-037
hex 3EC0C6F7A0000000

F8 loaded with LDS from memory value 0360637BD;
DBG shows the F8 value as
s_float = 0.2000000E-05
t_float = 0.199999999495049E-005
hex 3841039D40000000    

gives a reproducible result in F9 of hex 00000011E0000000 (or hex 08F in s_float memory format, i.e. after a STS F9,...; DBG shows the s_float memory value as 0.2003857E-42), while

DBG> examine/s_float F9
%F9:     0.0000000E+00
DBG> examine/s_float F9
%F9:     0.379306747635042E-312

note also, the t_float register value is different from in memory s_float value, while s_ and t_float values correspond in case of F7 and F8.

on a real alpha the MULS result with the above operands is zero and STS F9,... stores hex 0.

here are the register values after the MULS F7,F8,F9 on a real alpha; [es40 and real alpha running same version of openvms (v8.3) & debugger]:

exa/s_float f7,f8.f9
%F7:      0.2000000E-05
%F8:      0.1000000E-36
%F9:      0.0000000E+00

exa/s_float f7,f8.f9
%F7:      0.199999999495049E-005
%F8:      0.999999991097579E-037
%F9:      0.000000000000000

exa/quad/hex
%F7:      3EC0C6F7A0000000
%F8:      3841039D40000000
%F9:      0000000000000000

I'll also look into f, d, g floating arithmetic where I guess similar issues.

[scruty]

are all alphas created equal?

to find out, would someone please verify the described behaviour on a newer real alpha. my two real alpha workstations work well but are more than 10 years old.

0.2000000E-05  * 0.1000000E-36 shouldn't be zero with s_floating on a real alpha, since quote from http://en.wikipedia.org/wiki/IEEE_754
(for single precision):

The positive and negative numbers closest to zero (represented by the denormalized value with all 0s in the Exp field and the binary value 1 in the Fraction field) are

    ±2−149 ≈ ±1.4012985×10−45

[scruty]

I checked the result on a real AlphaServer DS20 and it is zero too. the smallest number (closest to zero) given above is for non-normalized numbers only.

while mathematically the es40 emulator is not wrong, it neverthelss delivers more precision than a real alpha. I can't judge if that needs to be fixed; if yes, there might just be a normalization missing in MULS/MULT.