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 

FTN95 64-bit beta test
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Oct 01, 2015 2:18 am    Post subject: Reply with quote

I am surprised that you do not use SDBG. Does PLATO use its own debugger?

And what is the /Trace_back and how it is used?
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Oct 01, 2015 3:13 am    Post subject: Reply with quote

Dan,

/Trace_Back does not exist. I think it would be a good subset of /DEBUG. I was suggesting an alternative to /DEBUG that might be used in conjunction with /OPT, as areas of code that impact on run time performance can benefit from /OPT, especially real*8 calculations.

Regarding SDBG, I typically use other strategies. Some coding approaches performs differently with /CHECK, such as ALLOCATE. Should I again mention /IMPLICIT_NONE !!

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Oct 01, 2015 7:44 am    Post subject: Reply with quote

Plato does not have its own debugger. It spawns SDBG.

Both the 32 bit and 64 bit versions provide a trace back when an exception is raised but you do need to use /explist in order to identify the line in the source where the error occurred.

The trace provides an offset for the offending assembler instruction whilst the "explist" shows the lines of the code with their corresponding offsets.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Oct 01, 2015 9:05 am    Post subject: Reply with quote

Paul,

Yes you are correct. The trace back is being provided with offset addresses.
This will identify the call sequence. You just have to identify the line of code from the /explist.
So Dan, you are not totally in the dark, but you could be appealing for bad light. (cricket reference).
This is better than I remembered, but it is easier to use /debug than /explist.

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Oct 01, 2015 9:39 pm    Post subject: Reply with quote

OK, let's check /explist as i suspect i will be first to really used it with all underlying consequences Smile. Taking my program above,compiling it with /explist and running. We get floating point divide error. Here is saved from screen the file error.txt

Code:
Floating point divide by zero
Floating point co-processor fault at address 00401034

 00401000 main [+0034]

eax=00000000   ebx=0000401e   ecx=00000001
edx=000000fe   esi=00402000   edi=0360fce8
ebp=0360fce0   esp=0360fca8   IOPL=0
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00010212 [NC OP NZ SN DN NV]

 00401034  fstp     [ebp-0x10]
 00401037  wait     
 00401038  lea      eax,[00404000]

First how to understand confusing numbers
00401034 and
00401000 main [+0034]

And here is the listing file generated by /explist

Code:

Compiler Options in Effect:
    COLOUR DELETE_OBJ_ON_ERROR EXPLIST LINK MINIMISE_REBUILD  NO_QUIT NON_STANDARD SINGLE_THREADED
   

   0001   a=1                                                                                    AT 0
 ; Start of SUBROUTINE MAIN@

      00000000(3/1/1)            push      ebp
      00000001(4/1/1)            mov       ebp,esp
      00000003(5/1/1)            push      ebx
      00000004(6/1/1)            push      esi
      00000005(7/1/1)            push      edi
      00000006(8/1/1)            push      eax
      00000007(9/1/1)            lea       ecx,2
      0000000d(10/1/1)           push      ecx
      0000000e(11/1/1)           lea       edi,[ebp+8]       ; Get command line arguments
      00000011(12/1/1)           push      edi
      00000012(13/1/1)           call      __FTN95INIT1_
      00000017(14/1/1)           add       esp,=8
      0000001a(15/1/1)           sub       esp,=24           ; Adjusted later if temporaries allocated
      00000020(16/3/2)           mov       A,Z'3f800000'
   0002   b=0                                                                                    AT 27
      00000027(17/3/5)           mov       B,=0
   0003   c=a/b                                                                                  AT 2e
      0000002e(18/4/9)           fld       A
      00000031(19/4/9)           fdiv      B
      00000034(20/3/10)          fstp      C
      00000037(21/3/10)          wait     
   0004   print*, c                                                                              AT 38
      00000038(22/4/17)          lea       eax,2
      0000003e(23/3/14)          push      eax
      0000003f(24/4/15)          lea       ecx,-32234_2
      00000045(25/3/14)          push      ecx
      00000046(26/3/14)          push      eax
      00000047(27/3/14)          mov       Temp@3,eax
      0000004a(28/3/14)          mov       Temp@4,ecx
      0000004d(29/3/14)          call      WSF1@@
      00000052(30/3/14)          add       esp,=12
      00000055(31/4/22)          lea       edi,1
      0000005b(32/3/19)          push      edi
      0000005c(33/4/20)          lea       eax,C
      0000005f(34/3/19)          push      eax
..........
..........
   0005   end                                                                                    AT 80



Now we have one more difference. Why both addresses in first file do not coincide with this one? The closest related line is

Code:

0003   c=a/b                                                                                  AT 2e
00000034(20/3/10)          fstp      C


which is not
Code:

00401034  and
00401000 main [+0034]
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Fri Oct 02, 2015 2:10 am    Post subject: Reply with quote

No need for confusion here! Let's use your example and work things out. The first piece of information is in the error report:
Code:

Floating point co-processor fault at address 00401034

  00401000 main [+0034]

Remember, a fault occurs after the instruction is executed. The processor does not know whether the next instruction in the pipeline will or will not cause a fault. Therefore, the address given is the value of EIP after the fault occurred. It is easy to back up one instruction using an EXPlist, but the fault handler may not be able or care to disassemble the code and figure out how many bytes to go back. We look up main+0034 in the EXPlist, and go back one instruction, which gives us the FDIV. In fact, the first line in the error message said "...divide by zero", so the instruction had better be a floating point division. If your code is 80X87 code, the instruction is FDIV.

Many instructions use EIP- (or RIP-) relative addresses for jump and call instructions, and use the same convention to express offsets. Here is an example:
Code:

  00401070: E8 2B 0A 00 00     call        00401AA0
  00401075: 83 C4 24           add         esp,24h

Again, take the address of the instruction after the CALL, and subtract that from the address of the CALL target: 401AA0 - 401075, which is 000A2B, which is why the four bytes of the address in the instruction, in little-endian order, are 2B, 0A, 00, 00. See those bytes in the instruction bytes field?

The error handler has already computed the offset from the beginning of the routine (main) by taking the EIP value, 401034H and subtracting the load address of that routine, which is 401000H; that is the _0034 that it reported.

All these numbers are hexadecimal. On old machines, these might have been displayed in octal, but octal is no longer suitable when word sizes are not multiples of 3-bits.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Oct 02, 2015 5:04 am    Post subject: Reply with quote

Thanks mecej4, now things are more clear. I mean, now i see more clearly that this is a total darkness Smile and with my uncountable errors i make this way of debugging will not be a fun to do. I think Silverfrost has to accelerate implementing at least offending line reporting if not the full debugger.

Last edited by DanRRight on Thu Oct 08, 2015 6:59 am; edited 1 time in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Oct 02, 2015 8:17 am    Post subject: Reply with quote

Mecej4,

I understand that you may find this hexadecimal arithmetic straight-forward, but I'll also wait for reporting of line numbers in the code.
Since we changed to ISO base 10 units, I will now only accept decimal line numbers !
I prefer to think about what the bug may be in the Fortran, rather than finding it listed in assembler code.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Oct 07, 2015 2:20 am    Post subject: Reply with quote

So ...

Dan can see clearly now the pain has come

He can see all obstacles in his code

..... :O)

https://www.youtube.com/watch?v=b9Hiti5CDNM

To cheer you up Dan, while you're doing your Stevie Wonder impressions in the quicksand, remember you're standing on the backs of lesser mortals like myself who are nowhere near understanding this conversation !!! We rely on you to drag us out at the end !

Regarding "I think Silverfrost has to accelerate implementing at least offending line reporting if not the full debugger" , I do find it incredible that a beta version has been released with what I'd consider to be a fundamental requirement missing. But then again I'm not a programmer with a scedule to meet/recover. No doubt decisions have had to be made along the way.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed Oct 07, 2015 8:20 am    Post subject: Reply with quote

John

I don't know if I should try to explain Dan's misunderstanding about the aims and objectives of the 64 bit beta release. I have stated these earlier (probably in this thread), but you provoke me to make the main point again.

The 64 bit beta release does not include 64 bit debugging facilities but the 32 bit debugging facilities are still in place. So, for at little while, users should do their development in "32 bit" mode, and only use the 64 bit feature for the final release version.

Putting it a different way, we have extended the existing compiler FTN95 by adding a new command line option /64 which has the effect of producing 64 bit object code. When not using /64, FTN95 works exactly as before.

You will find that Dan manages to combine being one of our strongest supporters with being our most vocal critic. If we conversed in Spanish things might be different.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Oct 08, 2015 1:28 am    Post subject: Reply with quote

Hah, Spanish. For internal use i apply Russian.

I think and hope my support and critics are reasonable. They reflect actual contrasts of this compiler over the quarter century of its development. It is the best one with many things but trails the worst ones in others. Good though is that things are moving forward where it was missing.

It always deserved to have much larger adoption rates. To me it was always way the best one, years ahead of all others. But systematic funding of other compilers in major markets like the US over decades shifted it into the shadows. Plus possibly UK developers feel kind of inferiority complex with respect to US and do not push their products. But hope with the new features added and massive debugging campaign over the past decade after making compiler affordable the company will finally take more aggressive stance in the market.


Last edited by DanRRight on Thu Oct 08, 2015 7:05 am; edited 1 time in total
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Thu Oct 08, 2015 2:45 am    Post subject: Reply with quote

Dan,

I agree, as FTN95 has probably the best error checking of any compiler I have used.

The new /64 features, especially the ability to have individual common blocks larger than 2gb, should be seen as a significant new feature. All other 64_bit compilers I have tested do not support this feature.

What it means is that existing F95 code can be easily expanded to 64-bit by providing larger arrays, without the need for major code changes that adopting ALLOCATE can require. This is the case while existing arrays can utilise I*4 subscripts, which will be typical in the short term for most existing physical memory configurations. ( 16gb for real*8 arrays )

I think the ease of converting is a big selling point for using FTN95 /64 with existing F77 and F95 code.

Based on my experience, this can be a very easy path to solving larger problems in a larger memory space for little effort.
I did this with my clearwin+ based graphics program, which I converted to use 2.9 gb of memory with the change of a few parameter declarations. I compiled and linked 230 .f95 files using /64 in one night, with the only significant changes being 1) identifying and changing window handles to I*8 and 2) updating the @link.txt file for SLINK64.
The get_filtered_file@ problem is now gone!
This is a program that I had not spent a lot of time restructuring for 64 bit, which other compilers require converting to ALLOCATE array structures.

For those who are memory constrained with clearwin+ programs, this will be a very welcome improvement.

Paul's suggestion of using /32 with a smaller data-set for debugging can be a good approach, although I think a lot of Dan's problems with clearwin+_32 do relate to memory squeeze associated with virtual graphics regions. These disappear with /64, ie the /32 and /64 programs will not perform the same, so these types of errors will not perform the same with and without /debug.

Based on my Beta testing, I recommend /64 as worth adopting when available.

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Oct 08, 2015 6:44 am    Post subject: Reply with quote

I love this company ! Not MS of course
https://www.youtube.com/watch?v=f__n8084YAE


Just make me
/64 and with the 64bit debugger ASAP, I need to load 100GB of data any PIC code nowadays generates. (By the way, I am much less interested with 64bit Clearwin, John)

OpenMP and MPI compatibility and multithreading debugging and

/optimize to be in par with other compilers. i do not need to beat them, major and most cost consuming is still the DEVELOPMENT SPEED, depth of error checking and features where this compiler is a Godzilla, not the run speed. But the speed improvement will be welcome
Back to top
View user's profile Send private message
Emanuele



Joined: 21 Oct 2009
Posts: 77
Location: Bologna (Italy)

PostPosted: Tue Oct 13, 2015 4:18 pm    Post subject: Re: Reply with quote

PaulLaidler wrote:

A new "backend" has been to added to FTN95.exe for "x64" to go alongside the existing backends for "Win32" and ".NET". These backends generate the relevant assembly instructions for each platform.


The 64 bit version works also for .NET or it is only a "Win64"?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Oct 13, 2015 5:13 pm    Post subject: Re: Reply with quote

Emanuele wrote:


The 64 bit version works also for .NET or it is only a "Win64"?


As I understand it:

There are three target classes: win32, win64 and .NET. For each there is a dedicated back end. All target classes share the same front end. Presumably, the front end produces some kind of intermediate language which is the same for all targets. The back ends reads this intermediate language code and output the corresponding x86, x64 and CLR objects.

Thus, the question regarding 64-bit for .NET may not be meaningful. There are other external issues: does the CLR virtual machine/interpreter translate .NET code to x86 instructions or x64 instructions? Are all support DLLS available?


Last edited by mecej4 on Tue Oct 13, 2015 6:33 pm; edited 1 time in total
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 3 of 9

 
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