View previous topic :: View next topic |
Author |
Message |
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Mar 30, 2016 4:00 pm Post subject: FLUSH_WKEYBOARD@ |
|
|
Thanks Paul,
this helped for GET_WKEY1@. Now I faced the same problem for subroutine FLUSH_WKEYBOARD@.
Regards,
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Wed Mar 30, 2016 5:16 pm Post subject: |
|
|
C_EXTERNAL FLUSH_WKEYBOARD@ "__flush_wkeyboard"() |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Mar 31, 2016 11:33 am Post subject: |
|
|
This is what I would have expected to work. But unfortunately it does not seem to work.
Code: | 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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Thu Mar 31, 2016 2:29 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Apr 01, 2016 11:03 am Post subject: GET_GRAPHICS_MODES@ |
|
|
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 |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Apr 01, 2016 11:53 am Post subject: SET_PALETTE@ |
|
|
Paul,
the same as for subroutine GET_GRAPHICS_MODES@ (of my last entry) seems to be true for SET_PALETTE@ .
Regards,
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Fri Apr 01, 2016 2:40 pm Post subject: |
|
|
Both of these are missing from the export table. I have added them now.
Code: | C_EXTERNAL GET_GRAPHICS_MODES@ "__win_get_graphics_modes"(REF,REF,REF,REF,REF)
C_EXTERNAL SET_PALETTE@ "__win_set_palette"(REF,REF)
|
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Sun May 15, 2016 7:54 pm Post subject: |
|
|
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
|
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Mon May 16, 2016 7:07 am Post subject: |
|
|
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. |
|
Back to top |
|
|
tbell
Joined: 06 Apr 2006 Posts: 34
|
Posted: Mon May 16, 2016 3:08 pm Post subject: Speed test: 64-bit vs 32-bit |
|
|
Did you complete any timing test regarding the execution times of the 32-bit vs. the 64-bit compiled code? Thanks. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Mon May 16, 2016 9:43 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue May 17, 2016 7:46 am Post subject: |
|
|
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. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue May 17, 2016 8:01 am Post subject: |
|
|
Paul,
Thanks. For the %pl to work with 64 bit option of the compiler can 32 bit Clearwin+ still be used? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7938 Location: Salford, UK
|
Posted: Tue May 17, 2016 8:31 am Post subject: |
|
|
No. You cannot mix 32-bit and 64-bit code. This is an OS restriction. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2834 Location: South Pole, Antarctica
|
Posted: Tue May 17, 2016 11:55 am Post subject: |
|
|
These Simpleplot devs for 20 years do not providing any feedback, let alone support or fixes. My feeling is that they will never move and Clearwin+ will be missing %pl.
How about OpenGL, does it work?
Last edited by DanRRight on Tue May 17, 2016 10:30 pm; edited 2 times in total |
|
Back to top |
|
|
|