View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Wed Jun 13, 2018 6:48 am Post subject: |
|
|
Dietmar
CREATE_POLYGON@, FILL_POLYGON@ and DELETE_POLYGON_DEFINITION@ belong to a set of DBOS routines that have not been implemented for 64 bits. The first two will link but will fail at runtime. These can be replaced by the single routine DRAW_FILLED_POLYGON@.
POLYLINE@ is provided (via DBOS.INS) but this just calls DRAW_POLYLINE@ which is therefore more direct. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Jun 14, 2018 11:02 am Post subject: |
|
|
Paul, Eddie,
thanks for your help and information.
I was a little bit confused because the only symbol out of CREATE_POLYGON@, FILL_POLYGON@ and DELETE_POLYGON_DEFINITION@ that slink64 complained about was DELETE_POLYGON_DEFINITION@.
I wondered why the alternate routine to DELETE_POLYGON_DEFINITION@ was DRAW_FILLED_POLYGON@ and thought maybe DELETE_POLYGON_DEFINITION@ would have some visual effect on the screen (like repainting the area covered by the polygon with the background or similar). And I wondered who would free the handle which I thought was still valid under 64 bit.
That's why I asked how to set the color (parameter 4) of DRAW_FILLED_POLYGON@, and Eddie answered this question. What I really meant was to which value I should set the color (e.g. the backgroud color etc.).
Later I found the semantic of DELETE_POLYGON_DEFINITION@ in the Library reference FTN77.
It turned out that DELETE_POLYGON_DEFINITION@ does not have any visual effect on the screen. Hence I think I should replace
Code: |
CALL CREATE_POLYGON@ (...)
CALL FILL_POLYGON@(...)
CALL POLYLINE@(...)
........
CALL DELETE_POLYGON_DEFINITION@(...)
|
by
Code: |
CALL DRAW_FILLED_POLYGON@(...)
CALL DRAW_POLYLINE@(...)
|
where in call DRAW_FILLED_POLYGON@ and DRAW_POLYLINE@ the same colors are used as in CALL FILL_POLYGON@ and POLYLINE@, respectively.
This means that routines CREATE_POLYGON@ and DELETE_POLYGON_DEFINITION@ are obsolete in the 64 bit ftn95 compile environment. To my opinion this is a slight difference to the information given in the table of alternate routines in the ClearWin+ documentation.
Paul, could you please confirm, if my idea of code replacing mentioned above is correct?
Thanks and regards,
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Thu Jun 14, 2018 11:24 am Post subject: |
|
|
Dietmar
Yes I can confirm that you are correct.
CREATE_POLYGON@ and FILL_POLYGON@ are not implemented for 64 bits. When called they produce a runtime error report. So your tests must have avoided calls to these routines. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri May 29, 2020 3:09 pm Post subject: |
|
|
Paul,
I am currently trying to link an INTEL64 app with clearwin64.lib/clearwin64.dll from ftn95 version 8.62.1 (internal version numer 22.3.15).
The code named mymove.for is
Code: |
character*256 mybuffer_src,mybuffer_target,c,curdir$
integer*2 n
N=5
mybuffer_src='abcdfghijk'
#IF SALFORD
call MOVE@(mybuffer_src, mybuffer_target, n)
#ELSE
call MOVE$(mybuffer_src, mybuffer_target, n)
c=curdir$()
write(*,*) 'Current Directory: ', c
#ENDIF
write(*,*) 'mybuffer_src=',mybuffer_src(1:n)
write(*,*) 'mybuffer_target=',mybuffer_target(1:n)
read(*,*) c
end
|
I tried to compile it via command
Code: |
ifort mymove.for /Zi /debug /fpp /DINTEL64 clearwin64.lib
|
, however, symbol MOVE$ remained unresolved, the corresponding error message was
Code: |
mymove.obj : error LNK2001: unresolved external symbol MOVE$
mymove.exe : fatal error LNK1120: 1 unresolved externals
|
. The same code compiles successfully for SALFORD via command
Code: |
ftn95 mymove.for /debug /link /64 /CFPP /DEFINE SALFORD 1
|
. Moreover if commenting/deactivating the call of MOVE$ for INTEL64 the compile is successful. Now I wonder if symbol MOVE$ might have been forgotten somewhere in the environment needed when building INTEL64 stuff making use of clearwin64.
Regards,
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Fri May 29, 2020 4:27 pm Post subject: |
|
|
Dietmar
MOVE@ is an inline FTN95 routine. It is translated directly into assembler code.
I guess that I could add it to clearwin64.dll and maybe even use the same name.
Note that FTN95 usually allows the $ as an alternative to @ so generally you don't need conditional compilation blocks like that used here. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Tue Jun 02, 2020 11:34 am Post subject: |
|
|
Paul,
it would be nice if I could use MOVE$ from clearwin64.dll, for my current INTEL64 implementation uses INTEL C functionality to implement it. Would it be possible to treat other routines (e.g. LS,RS) in the same way?
Concerning your note I am confused: if I substitute MOVE$ by MOVE@ in line 8, then the ifort command mentioned in my post results in
Code: |
mymove.for(8): error #5078: Unrecognized token '@' skipped
call MOVE@(mybuffer_src, mybuffer_target, n)
----------------^
compilation aborted for mymove.for (code 1)
|
. This is in sync with your document doc\clearwin64.txt (Using 64 bit ClearWin+ with third party compilers) where you stated
Quote: |
First, ClearWin+ routines that end with the @ symbol must be changed so that they end with the $ (dollar) symbol.
|
Compiling mymove.for with ftn95 via command
Code: |
ftn95 mymove.for /CFPP /debug /link
|
results in
Code: |
WARNING the following symbols are missing:
MOVE$ c:\ds\samples\salford_8.62\lgotemp@.obj
|
and executing mymove.exe results in a runtime error (call to missing routine _MOVE$).
Regards
Dietmar |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Tue Jun 02, 2020 12:18 pm Post subject: |
|
|
Dietmar
MOVE$ will not work at the moment but routines like WINIO@ can be written as WINIO$ and this form should work for both FTN95 and INTEL.
I will aim to provide MOVE$ and at least some of the other FTN95 intrinsics. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Jun 13, 2020 2:47 pm Post subject: |
|
|
Dietmar
I have added MOVE$ to clearwin64.dll for the next release of this DLL.
Routines like RS are more tricky because
a) the names are very simple and could easily overlap other usage and
b) the arguments can have various types.
For these routines there are standard Fortran alternatives. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7931 Location: Salford, UK
|
Posted: Sat Jun 13, 2020 6:10 pm Post subject: |
|
|
Code: | i = 8
print*, rs(i,2), ishft(i,-2)
print*, ls(i,2), ishft(i,2)
|
|
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Wed Jul 01, 2020 2:47 pm Post subject: |
|
|
Thanks, Paul.
Your suggestion concerning RS and LS is exactly the way I have implemented when using clearwin64.dll of ftn95 version 7.10 for my INTEL64 build.
For clearwin64.dll of ftn95 version 8.62.1 I thought it would be a good idea to use as as many routines from the dll as possible for my INTEL64 build (rather than using my INTEL64 implementation of the routines).
Regards
Dietmar |
|
Back to top |
|
|
|