Number of displayed for double precision variables in sdbg64

I wanted to compare the FTN95 arithmetik arithmetik in 32 and 64 bit mode. Therefore I performed a test with a very elemental test program:

Program x64x32
Double Precision :: a, b, c

a = atan(1.0d0) / 2.0d0
b = a / 3.0d0
c = sqrt(b)
write (*,*) a, b, c

end

The values for a, b and c as shown in the sdbg64 variable window are reduced to an inappropriate number of decimal digits, e.g. 'B = 0.1309'. The number of digits internally used seems instead to be ok, as the write command provides the more precise result '0.13089969300'. Am I the first user faced to this problem? No results are found when searching in the 64-bit forum!

It look like it prints them to six places. I will look at improving that.

Robert, may I request that when improving the display of real variable values you consider giving the user the choice of

 (i) how many significant digits to display, and 

 (ii) scientific notation or hexadecimal IEEE representation

Thanks.

hexadecimal IEEE representation

Is that the hexadecimal representation of the bytes that make up the number? Why would you want (to show) that?

Robert,

I have run into a large number of instances where there is a programmer error or a compiler/library error where it was only by diving into the disassembly/register display that I could find out what the exact nature of the bug was. Here is one example.

program tst
implicit none
real x,dx
x = 1.0
dx = 1e-8
x = x-dx   ! naively, I expect x to be < 1.0 after this
call sub(x)
print *,x

contains
   subroutine sub(y)
   real y
   if(y < 1.0)then
      y = y+0.1  ! I am perplexed as to why this is not executed
   endif
   return
   end subroutine
end program

Mistakenly, I expected the program to print '1.10000', but it prints '1.00000'. To investigate, I compile with /64 /debug and run inside SDBG64. Just before the CALL, I look at the value of x, and I see 'X=1' in the Variables panel. Hovering the mouse pointer over 'x' in the source panel also displays 'x=1'. No decimal point, no zeros after the decimal point. Puzzled, I want to see if/why x is exactly 1. I open the registers panel, but I only see 'XMM8 = 1.000000'. Why is the value exactly equal to 1? Is it? Let me check by looking at the hexadecimal display of the contents of XMM8, and see if it is, really, 3F80 0000! Oops, I can't! I am stuck, and I have to run the FTN95-generated EXE in some other debugger to look at the register value.

Had SDBG64 shown me hexadecimal displays of XMM (and CPU) register contents, I could have backtracked to the statement X = X - dX and investigated why X did not become < 1.

This is a made-up example, so the naiveté trap is plainly visible.

You can see the hex by right clicking the variable and selecting 'memory dump at variable'.

Quoted from Robert You can see the hex by right clicking the variable and selecting 'memory dump at variable'.

True, and that is sometimes enough, but often the latest value of a real variable is available only in an XMM register and the corresponding memory will not be updated until many instructions later.

There can also be subexpressions whose values can be examined only in XMM registers because these subexpressions, not being variables, have no corresponding memory locations at all.

mecej4,

In your example, a better option would be to inspect 'y - 1.0'. Is that approach available in SDBG64 ?

It is a shame there is not more information available on how round-off can present.

In your example, a better option would be to inspect 'y - 1.0'. Is that approach available in SDBG64 ?

Yes. In SDBG64, select Tools - Command_Prompt. The command 'PRINT y-1.0' can then be entered. This is a useful feature, but it is applicable only to named variables. If one could also enter, say, 'PRINT $XMM8-1.0', that would address my request.

You can use registers in expressions although not xmm type registers. The xmm collection of registers can contain up to four real4s, 2 real8s or a combination. To make them accessible we may have to come up with some names.

xmm0 for first real xmm0d for first double xmm0_1 seems natural for the second real but it clashes with the kind syntax

Thanks, Robert, and I recognise the issue that you raised regarding names for portions of the XMM registers.

Instead of _1, etc., one could use the mnemonics used in the XMM instructions, using suffixes 'h','l','s' and 'd' (as in MOVHLPS, etc.)

In passing, can we use the X87 names FP0-FP7 in expressions displayed in 32-bit SDBG?

There is no way in sdbg to refer to the floating point stack

There is a new version of sdbg64 which can be downloaded via the sticky post of the support forum. It will display variables at their full resolution. You can also use the xmm registers in expressions. xmm0..xmm16 refer to the real4 version of the register. xmm0d..xmm16d refers to the real8 (double) representation.