|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Oct 01, 2015 2:18 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Oct 01, 2015 3:13 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Thu Oct 01, 2015 7:44 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Oct 01, 2015 9:05 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Oct 01, 2015 9:39 pm Post subject: |
|
|
OK, let's check /explist as i suspect i will be first to really used it with all underlying consequences . 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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Fri Oct 02, 2015 2:10 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Fri Oct 02, 2015 5:04 am Post subject: |
|
|
Thanks mecej4, now things are more clear. I mean, now i see more clearly that this is a total darkness 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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Oct 02, 2015 8:17 am Post subject: |
|
|
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 |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Wed Oct 07, 2015 2:20 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Wed Oct 07, 2015 8:20 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Oct 08, 2015 1:28 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu Oct 08, 2015 2:45 am Post subject: |
|
|
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 |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Oct 08, 2015 6:44 am Post subject: |
|
|
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 |
|
|
Emanuele
Joined: 21 Oct 2009 Posts: 77 Location: Bologna (Italy)
|
Posted: Tue Oct 13, 2015 4:18 pm Post subject: Re: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1886
|
Posted: Tue Oct 13, 2015 5:13 pm Post subject: Re: |
|
|
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 |
|
|
|
|
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
|