View previous topic :: View next topic |
Author |
Message |
dgurok
Joined: 26 May 2011 Posts: 66
|
Posted: Thu Nov 30, 2023 9:59 am Post subject: Different behavior concerning READF@ |
|
|
Hi all,
I'm trying to port an old Salford code from 32-bit to 64-bit. I encountered a problem with READF@. In the 32-bit version, READF@ also reads ASCII data correctly. In the 64-bit version, however, I get an error code 998.
I know I could change it to READFA@, but I want to understand why the same code works differently.
Currently I'm using FTN95/x64 Ver. 8.90.0 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Nov 30, 2023 10:24 am Post subject: |
|
|
dgurok
Can you post or send me a sample program that illustrates the difference? |
|
Back to top |
|
|
dgurok
Joined: 26 May 2011 Posts: 66
|
Posted: Thu Nov 30, 2023 10:32 am Post subject: |
|
|
Code: | PROGRAM TEST
C
CHARACTER TXTDUM*32000
CHARACTER*256 TXTFIL
INTEGER*2 HWND, IERR
INTEGER*4 NB, NBR
C
NB=80
TXTFIL='MOD.txt'
CALL OPENR@(TXTFIL,HWND,IERR)
WRITE(*,*) 'OPENR, IERR ', IERR
C
CALL READF@(TXTDUM,HWND,NB,NBR,IERR)
WRITE(*,*) 'READF, IERR ', IERR
WRITE(*,*) 'TXTDUM(1:80): ', TXTDUM(1:NB)
C
CALL CLOSEF@(HWND,IERR)
WRITE(*,*) 'CLOSEF, IERR ', IERR
C
END |
Result
Code: | 32-bit
OPENR, IERR 0
READF, IERR 0
TXTDUM(1:80): #001 0.000 0.000 1024.187 1000.000 1000. 0.0 0.0 0.0 Li
CLOSEF, IERR 0
64-bit
OPENR, IERR 0
READF, IERR 998
TXTDUM(1:80):
CLOSEF, IERR 0 |
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Thu Nov 30, 2023 1:31 pm Post subject: |
|
|
I took the line of data from your 32-bit example to generate MOD.txt ( as a text file )
Using PLATO with x64, (/64)
I can reproduce your error with "Release" or "Debug", with error 998.
However with "CheckMate", I get error 0, as for 32-bit.
For Win32, all compile options show no error.
I am not sure what error number 998 refers to ? ( can't find it in FTN95.chm)
The documentation for READF@ does say "This routine should be used on binary data." |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Nov 30, 2023 2:05 pm Post subject: |
|
|
998 translates to "Invalid access to memory location".
The failure can be fixed in our build for clearwin64.dll by downgrading the Microsoft optimisation of the code for the file containing this routine.
I can provide a replacement DLL but it will be post v9.00 of FTN95 so that might be problematic. |
|
Back to top |
|
|
dgurok
Joined: 26 May 2011 Posts: 66
|
Posted: Fri Dec 01, 2023 10:15 am Post subject: |
|
|
Thanks Paul,
That would certainly help us if we push forward with our Salford 64-bit port next year, as there are other internal technical problems that need to be solved too |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Fri Dec 01, 2023 10:31 am Post subject: |
|
|
dgurok
Would you like me to send you new DLLs?
They will probably be compatible with your current FTN95 but you will need to proceed carefully and re-instate these new DLLs after upgrading to FTN95 v9.0. |
|
Back to top |
|
|
dgurok
Joined: 26 May 2011 Posts: 66
|
Posted: Fri Dec 01, 2023 10:43 am Post subject: |
|
|
That sounds great. You can send me the download link via PM if you like.
I will then report how the change affects our port. |
|
Back to top |
|
|
dgurok
Joined: 26 May 2011 Posts: 66
|
Posted: Fri Dec 01, 2023 1:08 pm Post subject: |
|
|
Thanks Paul for the new DLLs.
I did a quick test and so far I'm not having any problems reading and writing files in the way we process our data. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2560 Location: Sydney
|
Posted: Sat Dec 02, 2023 2:25 am Post subject: Re: |
|
|
PaulLaidler wrote: | The failure can be fixed in our build for clearwin64.dll by downgrading the Microsoft optimisation of the code for the file containing this routine. |
Interesting problem ! Is this an error in a Microsoft compiler due to inappropriate optimision ? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Dec 02, 2023 8:40 am Post subject: |
|
|
John
I don't know why changing the level of optimisation fixes the problem. I guess that I could have changed the code line by line in an attempt to localise the fault but it's only one file and a small number of routines so there is unlikely to be a significant change in performance. |
|
Back to top |
|
|
|