forums.silverfrost.com

PaulLaidler · 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.

DietmarSiepmann · Joined: 03 Jun 2013 Posts: 239

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

PaulLaidler · 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.

DietmarSiepmann · Joined: 03 Jun 2013 Posts: 239

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

PaulLaidler · 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.

DietmarSiepmann · Joined: 03 Jun 2013 Posts: 239

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

PaulLaidler · 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.

PaulLaidler · 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.

PaulLaidler · Posted: Sat Jun 13, 2020 6:10 pm Post subject:

DietmarSiepmann · Joined: 03 Jun 2013 Posts: 239

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