forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

FTN95 64-bit beta test
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Oct 13, 2015 5:51 pm    Post subject: Reply with quote

The current 64 bit development program does not include .NET.
In theory it might but in reality it doesn't.
Back to top
View user's profile Send private message AIM Address
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Fri Oct 23, 2015 6:54 am    Post subject: Reply with quote

As long as SDBG and /CHECKMATE are still supported in 32 bit mode then it will be possible to debug codes. Often small test data sets are sufficient to complete all debugging.
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
Emanuele



Joined: 21 Oct 2009
Posts: 77
Location: Bologna (Italy)

PostPosted: Sun Oct 25, 2015 6:04 pm    Post subject: Re: Reply with quote

mecej4 wrote:

does the CLR virtual machine/interpreter translate .NET code to x86 instructions or x64 instructions? Are all support DLLS available?


It seems to me that the answer is x86 and the linker refers to the 32 bit version of .NET dlls. In this sense the question of x64 .NET may be meaningful.

PaulLaidler wrote:
The current 64 bit development program does not include .NET.


I can understand that in this first phase of the development the .NET 64 is not the priority, however I hope that it will be included in the program soon after the release of win64.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Oct 26, 2015 8:00 am    Post subject: Reply with quote

Emanuele

I am sorry to disappoint you but there are currently no plans to extend .NET to x64.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Oct 29, 2015 10:37 am    Post subject: Problems with /mklib option Reply with quote

Hello,

I am trying to build a 64 bit library from file hello_fort1.for using option /mklib. File hello_fort1.for consists of the following code
Code:

subroutine myprint(C10)
     
      CHARACTER*1 C10
     
      write(2,'(A)') C10
      return
      end

and I tried to create the library by executing command
ftn95 hello_fort1.for /64 /mklib
. However, this resulted in an access violation producing the following text
Code:

Access Violation
The instruction at address 10011b53 attempted to read from location 00000000

 10011b37 strcat [+001c]
 00516d04 nt_link(void) [+077f]
 005165a2 finish(void) [+0507]
 00401000 main [+0598]

eax=00589e00   ebx=00000000   ecx=ffffffde
edx=0008e3c8   esi=00000000   edi=00589e78
ebp=03d9d544   esp=03d9d528   IOPL=0
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00210206 [NC EP NZ SN DN NV]

 10011b53  lodsb
 10011b54  stosb
 10011b55  cmpb     al,0x0

. No library is generated, however, file hello_fort1.obj is created.
Executing command
hello_fort1.for /mklib
works as expected and produces file hello_fort1.lib and not file hello_fort1.obj.
I am using the new beta-2 release (Version: 8.00 beta.14
Built: Thu Oct 8 17:44:44 2015).

Comments are welcome.
Regards,
Dietmar
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Thu Oct 29, 2015 10:53 am    Post subject: Problems with /mklib option Reply with quote

Hello again,

sorry, there was an incorrectness in my previous post. The second command mentioned in the post was meant to produce a 32 bit library using option /mklib and this worked. The command should read
ftn95 hello_fort1.for /mklib
, I forgot the ftn95 command name in the post.

Regards,
Dietmar
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Oct 29, 2015 1:52 pm    Post subject: Reply with quote

Dietmar

At the moment, FTN95 should not accept /MKLIB with /64 and I have now fixed FTN95 so that it gives an error report for this combination.

/MKLIB causes FTN95 to spawn to SLIM (the 32 bit static library manager) and SLIM has not yet been extended to 64 bit object files.

Also, at the moment, SLINK64 can not create static libraries.

Let me know if the use of static libraries is import for you. In theory one should be able to simply concatentate .obj files together in order to produce a .lib file and there is a DOS command to do this.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Oct 30, 2015 12:15 am    Post subject: Reply with quote

Paul,

For 32 bit, I make extensive use of static libraries, made using slink. I use basic commands, example below.
It would be good if this functionality was also available with slink64, at some stage.
(I have never found a compelling need to change to a .dll approach.)

archive crtlib.lib
addobj border.obj
...
addobj quitest.obj
file

Based on your post above, is the DOS equivalent simply "copy *.obj crtlib.lib" then use "le crtlib.lib" in slink64 ?

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Oct 30, 2015 9:48 am    Post subject: Reply with quote

John

Further work on SLINK64 and/or SLIM is planned in order to accommodate 64 bit static libraries but I was looking for a quick short term fix.

I was hoping that a DOS command like COPY would do the trick but I have tried COPY and it does not work for me. The alignment of the runtime machine instructions goes wrong. It might be quicker to fix SLINK64 or SLIM so I will see if we can move this up the priority order. I will also try to recover what we used to do before SLINK/SLIM was finished.
Back to top
View user's profile Send private message AIM Address
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri Oct 30, 2015 2:48 pm    Post subject: Reply with quote

Hello,

I am also using static libraries very extensively. For porting short applications and for the time being, I link 64 bit object files directly. I would appreciate very much if you would support some functionality to build and link against 64 static libraries.

In this context I wonder if I can create 64 bit objects, libraries or executables from C/C++ code using scc.exe. We make use of 64 bit object files built from C source code, as well.

Regards,
Dietmar
Back to top
View user's profile Send private message
DietmarSiepmann



Joined: 03 Jun 2013
Posts: 279

PostPosted: Fri Oct 30, 2015 3:20 pm    Post subject: Problem with substrings Reply with quote

Hello,

I am trying to port a Fortran 32 bit application to 64 bit which makes use of substrings. The position indices used are of type INTEGER*2.

Both the 32 bit and the 64 bit application may be successfully created using the beta 2 version of ftn95 (Version: 8.00 beta.14). However, while the 32 bit executable works as expected, the 64 bit executable produces an access violation.

Here is the source code referred to as sample1.for for the following.
Code:

      IMPLICIT NONE
     
      INTEGER*2 LPTTCMD
      PARAMETER(LPTTCMD=256)
      CHARACTER MYCMDLINE*(LPTTCMD)

#if BAD
      INTEGER*2 ITA, ITE
      ITA=1_2
      ITE=2_2
      write(*,*) 'INTEGER*2 case'
#else
      INTEGER*4 ITA, ITE
      ITA=1_4
      ITE=2_4
      write(*,*) 'INTEGER*4 case'
#endif
           
      CALL COMMAND_LINE(MYCMDLINE)
      write(*,*) 'ITA=',ITA
      write(*,*) 'ITE=',ITE
      write(*,*) 'MYCMDLINE(ITA:ITE)=',MYCMDLINE(ITA:ITE)
      if (MYCMDLINE(ITA:ITE) .eq. '/?') then
        !+ Help-Text ausgeben
        stop
      else
        write(*,*) 'Didi1 ', 'ITA=',ITA

        if (MYCMDLINE(ITA:ITA) .eq. '-') then
          write(*,*) 'Fehler: Unbekannte Option' // MYCMDLINE(ITA:ITE)
        else
          write(*,*) 'Didi2'
        endif
      endif
     
      stop
      end


The 64 bit exexcutable is created via comands
ftn95 sample1 /ALL_WARNINGS/NON_STANDARD/SINGLE_THREADED/OLD_ARRAYS/ALT_KINDS/PERSIST/ZEROISE/UNLIMITED_ERRORS/FIXED_FORMAT/SAVE/NO_WARN73/WIDE_SOURCE /CFPP /BINARY_folder SALFORD64 /64 /DEFINE BAD 1

and

slink64 SALFORD64\sample1.obj /file:SALFORD64\sample1.exe

. The definition of C preprocessor flag BAD forces the type of variables ITA and ITE to be INTEGER*2 . The call

SALFORD64\sample1.exe dd

forces the access violation. The last string displayed is "Didi1 ITA= 1". Now by not defining preprocessor flag BAD, e.g. by executing command

ftn95 sample1 /ALL_WARNINGS/NON_STANDARD/SINGLE_THREADED/OLD_ARRAYS/ALT_KINDS/PERSIST/ZEROISE/UNLIMITED_ERRORS/FIXED_FORMAT/SAVE/NO_WARN73/WIDE_SOURCE /CFPP /BINARY_folder SALFORD64 /64

and linking as mentione above, the type of ITA and ITE is changed to integer*4. Thus the application created works as expected which may be seen from the string "Didi2" which is displayed after the string starting with "Didi1".

As the corresponding 32 bit application runs successfully in both the integer*2 and the integer*4 case I wonder what has gone wrong in the error case.

Regards,
Dietmar
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Fri Oct 30, 2015 11:48 pm    Post subject: Reply with quote

Dietmar,

To link with slink64 I use the command:
slink64 @saplot_load.txt >> ftn95.tce

I have created "saplot_load.txt" by importing the 32 bit saplot.map into Excel and using a pivot table to generate a list of .obj files that were extracted from my .lib files.
eg: adapting c:\clearwin\clearlib.dev\crtlib.lib (crtcrd.obj/ )

It all worked first try! although it would be more difficult to generate a greenfield link list.

I was also surprised by the compile options you have used with /64.
It would be good to have a list of valid (or unsupported) compile options that work with /64.
I notice you use /ALT_KINDS. Do you find any problems with this option ? as I am contemplating this as my default.
I try to avoid use of /OLD_ARRAYS /ZEROISE or /SAVE as they have significant portability problems.

My experience to date with /64 has been very good. For my %gr graphics program, I have been able to expand the data I retain in memory, using a few ALLOCATE arrays and speed up both run time and development of new (enhanced) analysis options.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Oct 31, 2015 9:18 am    Post subject: Reply with quote

Dietmar

We are developing SCC /64 alongside FTN95 /64. SCC /64 is used to build salflibc64.dll. SCC /64 will be fully developed and tested in due course but is not yet ready for beta release. In the meantime it is possible to use FTN95 /64 with a third party C/C++ compiler particularly (and perhaps only) if the C/C++ part is formed into a standard 64 bit DLL.

I have made a note of the FTN95 /64 coding problem that you have posted and I will get back to you as soon as possible on this issue.

John

Your approach to linking is novel but I wonder if you are mostly just unpacking and then repacking. For an alternative approach, you can have as many subprograms as you like in one file, compile a .obj file from it and then treat the resulting .obj file as a library. Or you can use INCLUDE statements to create a master file from many separate files, compile the master file and treat the master.obj as a library. The only limitation is that (at the moment) SLINK64 will complain if you call the file master.lib rather than master.obj. Also, for the moment, very large files are slow to compile but this is something we are working on and will soon be resolved.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Sun Nov 01, 2015 12:39 pm    Post subject: Reply with quote

Paul,

I didn't think my approach was too novel. I was simply replacing the selective library loads "le \tree\bin.lib" with the list of "lo \tree\file.obj", hopefully until I can generate a /64 bin.lib. You are correct that I could generate a bin.obj file if bin.f90 included all required tree\*.f90 files.

I was trying to emulate the selective load of .obj files from bin.lib, which also contains other .obj files.

I have found that using slink64 @saplot_load.txt is a simple approach, which I use for other compiler/linkers that I have not bothered to learn their slim equivalent.

My laziness extends to not using .dll's as I have not yet found a compelling reason to change. A static load has the benefit of not loosing the .dll when copying the .exe to another pc.

Is there any update on the cou@ problem, or should I scrap it's use.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Nov 02, 2015 8:15 am    Post subject: Reply with quote

Dietmar

The INTEGER*2 problem has now been fixed.

John

The COU@ problem has now been fixed.
Back to top
View user's profile Send private message AIM Address
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 4 of 9

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group