Welcome to our forums
Paul,
I have checked the sizes of the object files involved and all object files involved have positive sizes.
Would it help installing the newest release? Both ftn95.exe and slink64.exe of the installation I currently use (beta 3) are dated to 03.01.2016.
If yes, could you please send me the corresponding link?
Thanks, Dietmar
Dietmar
I can not get your sample to fail on my machine so I am assuming that the problem has gone away.
As far as I know beta 3 is the last release. Hopefully it won't be long before the next release if you can manage for now.
Paul
Paul,
the major point of my request was that I cannot link against all the object files I would like to (because the linker creates an exception) and that this does not seem to be related to the object files involved.
Hence I stripped my application down and came to the point where I could create an executable again. However, this executable created an exception when calling seconds_since_1980@ concerning that routine get_time was missing.
File sample3.for shows the situation.
IMPLICIT NONE
real (kind=2) DT
character*1 C1
CALL SECONDS_SINCE_1980@(DT)
write(*,*) 'DT=',DT
!+ wait for input
read(*,*) C1
stop
end
Compiling this code to produce a 32 bit executable via command
ftn95 sample3.for /link
creates executable sample3.exe which works as expected. However, creating a 64 bit executable from the same code using command
ftn95 /64 sample3.for /link
results in a 64 bit executable sample3.exe which creates the exception mentioned above.
Regards, Dietmar
I have an application using 32bit with Clearwin+
Just starting on an EU-funded R&D project which will standardise on 64bit applications (with other participants coding their apps in C++, C#, and C), and will need to add some new functionality. I would like to be able to port directly to a 64bit version. Is there yet a full 64bit version of Clearwin+ ?
If not, then I may have to bite the bullet and do a lot of re-coding using Visual Studio. I'd really rather not do this, as there seems quite a steep learning curve for someone who has never used VS before.
Alternatively I could just blag it and develop everything in 32bit, hoping nobody will notice!
Yes 64 bit ClearWin+ has been available for some time and is thoroughly tested. 64 bit FTN95 is at beta 3 release and the first full release is expected very soon. It is probably best for you to use 64 bit ClearWin+ with FTN95 but it can be used with third party compilers if necessary.
Many thanks, Paul. Will purchase an update licence very soon. Need to get ducks in a row first. I plan to continue with your FTN95. Have been very happy with it so far, and especially with the responsive support!
An application being ported from 32 bit to 64 bit makes use of function GET_WKEY1@. When linking this application with slink64 symbol GET_WKEY1@ is marked as not defined.
Is this function supported by the 64 bit ftn95 environment (beta 3)?
Regards, Dietmar
Yes but previously it was hard-wired into the DLL and so did not need an interface. For the moment at least you will need an interface like...
C_EXTERNAL GET_WKEY1@ '__get_wkey1'():INTEGER*4
Thanks Paul,
this helped for GET_WKEY1@. Now I faced the same problem for subroutine FLUSH_WKEYBOARD@.
Regards, Dietmar
C_EXTERNAL FLUSH_WKEYBOARD@ '__flush_wkeyboard'()
This is what I would have expected to work. But unfortunately it does not seem to work.
IMPLICIT NONE
C_EXTERNAL GET_WKEY1@ '__get_wkey1'():INTEGER*4
C_EXTERNAL FLUSH_WKEYBOARD@ '__flush_wkeyboard'()
integer*4 jret
jret=GET_WKEY1@()
write(*,*) 'jret=',jret
call FLUSH_WKEYBOARD@()
write(*,*) 'called FLUSH_WKEYBOARD@'
stop
end
has been compiled by means of command
ftn95 /64 sample4.for /link
which results in
[SLINK64 v1.6, Copyright (c) Silverfrost Ltd. 2015-2016] Loading c:\ds\samples\salford_8.00_beta.14\lgotemp@.obj Creating executable file sample4.EXE The following symbols were not defined:
__flush_wkeyboard
Executable sample4.exe ist created, however, when starting it it creates a runtime error (missing routine __flush_wkeyboard).
Regards, Dietmar
My apologies. It turns out that this function was not in the export list for the 64 bit DLL. I have added it now for the next release.
Paul,
in a 32 bit application we make use of subroutine
GET_GRAPHICS_MODES@
which for the corresponding 64 bit application results in runtime error: call to missing routine GET_GRAPHICS_MODES@ .
Is this routine available for 64 bit, and, if so, what is the interface?
Regards, Dietmar
Paul,
the same as for subroutine GET_GRAPHICS_MODES@ (of my last entry) seems to be true for SET_PALETTE@ .
Regards, Dietmar
Both of these are missing from the export table. I have added them now.
C_EXTERNAL GET_GRAPHICS_MODES@ '__win_get_graphics_modes'(REF,REF,REF,REF,REF)
C_EXTERNAL SET_PALETTE@ '__win_set_palette'(REF,REF)
In what state currently is the debugger and /check and /undef in 64bit mode? I still did not touch the current version. Reason is simple - this would kill me if i move beyond 32bits, i will not be able to find tons of such errors like these I make every day in my few large codes I use (mine and thirdparty) without exact pointing at the offending line
The current release (v8.0) does not have /check nor options that imply /check such as /undef. It does have /debug and comes with a beta release of the 64 bit debugger SDBG64.exe.
For the moment users are advised do their development in '32 bit' mode (using /check etc.) and then to switch to 64 bits in the final stages. In some projects this may require using memory parameters (e.g. array sizes) that must be scaled down during testing and development.
This is a temporary restriction and work on 64 bit /check has a high priority.
Did you complete any timing test regarding the execution times of the 32-bit vs. the 64-bit compiled code? Thanks.
What dpecifically /debug is doing, what errors it catches? I thought /debug is catches most of /check errors besides array size limit violations.
What plans are regarding Simpleplot in the Clearwin+? Little by little but over all these decades I bacame a heavy user of this handy %pl Clearwin option in addition to my own ones and OpenGL. Probably 50 subroutines now use %pl. Is it working? If not, can I still use older 32bit Clearwin+ with 64bit Fortran? I will probably live ok with the 32 bit size arrays for visualization when passing them to %pl function
What the funny situation I am in... I need 64 bit Fortran like a sunlight but afraid even to try it because this will wreck a major havos in my code
tbell: At the current state of development, the 64-bit timings are generally on a par or somewhat better than the corresponding 32-bit timings. /optimise is currently not available but is planned for the next full release and the benefits of using /optimise will increase as more optimising features are added.
In some special contexts (e.g. the use of DOT_PRODUCT) 64-bit FTN95 will make use of SSE(2) or AVX instructions, potentially giving significantly improved times. These instructions will also be made available for users who are willing to write assembly code via CODE/EDOC.
In short, it is probably too early to switch to 64-bit FTN95 if improved timing is the only motivation.
DanRRight: Primarily, /debug plants code for the debugger (SDBG/SDBG64) to use when stepping through the code etc.. It also gives a better trace-back on run-time failure. /check provides run-time checking (without or without using the debugger); for example, array bounds checking and checking that arguments passed to a subroutine are those that the subroutine expects to receive. However for convenience, /check implies /debug because you would normally want /debug when using /check. Both are designed as tools for testing and development and because of their overheads are not intended for use with the end result.
It would be nice if we could implement 64-bit %pl but this will depend on us either having access to the source code or the authors doing the port for us. I don't have any further information on this at the moment.