View previous topic :: View next topic |
Author |
Message |
Thomas
Joined: 18 Feb 2005 Posts: 56 Location: Gummersbach, Germany
|
Posted: Thu Mar 10, 2022 6:51 pm Post subject: 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:
Code: | 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! _________________ Thomas |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Fri Mar 11, 2022 9:42 am Post subject: |
|
|
It look like it prints them to six places. I will look at improving that. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Fri Mar 11, 2022 9:54 am Post subject: |
|
|
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. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Fri Mar 11, 2022 10:02 am Post subject: |
|
|
> hexadecimal IEEE representation
Is that the hexadecimal representation of the bytes that make up the number? Why would you want (to show) that? |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Fri Mar 11, 2022 5:04 pm Post subject: |
|
|
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.
Code: | 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. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Fri Mar 11, 2022 5:17 pm Post subject: |
|
|
You can see the hex by right clicking the variable and selecting 'memory dump at variable'. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Fri Mar 11, 2022 6:13 pm Post subject: Re: |
|
|
Robert wrote: | 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. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2593 Location: Sydney
|
Posted: Sat Mar 12, 2022 1:05 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Sat Mar 12, 2022 3:24 pm Post subject: |
|
|
Quote: | 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. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Tue Mar 15, 2022 9:55 am Post subject: |
|
|
You can use registers in expressions although not xmm type registers. The xmm collection of registers can contain up to four real*4s, 2 real*8s 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 |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1897
|
Posted: Tue Mar 15, 2022 1:51 pm Post subject: |
|
|
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? |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Thu Mar 17, 2022 9:19 am Post subject: |
|
|
There is no way in sdbg to refer to the floating point stack |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 450 Location: Manchester
|
Posted: Sat Mar 19, 2022 1:29 pm Post subject: |
|
|
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 real*4 version of the register. xmm0d..xmm16d refers to the real*8 (double) representation. |
|
Back to top |
|
|
|