soccer jersey forums.silverfrost.com :: View topic - Number of displayed for double precision variables in sdbg64
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Number of displayed for double precision variables in sdbg64

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
Thomas



Joined: 18 Feb 2005
Posts: 56
Location: Gummersbach, Germany

PostPosted: Thu Mar 10, 2022 6:51 pm    Post subject: Number of displayed for double precision variables in sdbg64 Reply with quote

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
View user's profile Send private message Visit poster's website
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Fri Mar 11, 2022 9:42 am    Post subject: Reply with quote

It look like it prints them to six places. I will look at improving that.
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Mar 11, 2022 9:54 am    Post subject: Reply with quote

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
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Fri Mar 11, 2022 10:02 am    Post subject: Reply with quote

> 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
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Mar 11, 2022 5:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Fri Mar 11, 2022 5:17 pm    Post subject: Reply with quote

You can see the hex by right clicking the variable and selecting 'memory dump at variable'.
Back to top
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Fri Mar 11, 2022 6:13 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2593
Location: Sydney

PostPosted: Sat Mar 12, 2022 1:05 pm    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Sat Mar 12, 2022 3:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Tue Mar 15, 2022 9:55 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1897

PostPosted: Tue Mar 15, 2022 1:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Thu Mar 17, 2022 9:19 am    Post subject: Reply with quote

There is no way in sdbg to refer to the floating point stack
Back to top
View user's profile Send private message Visit poster's website
Robert



Joined: 29 Nov 2006
Posts: 450
Location: Manchester

PostPosted: Sat Mar 19, 2022 1:29 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group