|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Tue Oct 13, 2015 5:51 pm Post subject: |
|
|
The current 64 bit development program does not include .NET.
In theory it might but in reality it doesn't. |
|
Back to top |
|
|
davidb
Joined: 17 Jul 2009 Posts: 560 Location: UK
|
Posted: Fri Oct 23, 2015 6:54 am Post subject: |
|
|
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 |
|
|
Emanuele
Joined: 21 Oct 2009 Posts: 77 Location: Bologna (Italy)
|
Posted: Sun Oct 25, 2015 6:04 pm Post subject: Re: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Mon Oct 26, 2015 8:00 am Post subject: |
|
|
Emanuele
I am sorry to disappoint you but there are currently no plans to extend .NET to x64. |
|
Back to top |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Oct 29, 2015 10:37 am Post subject: Problems with /mklib option |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Thu Oct 29, 2015 10:53 am Post subject: Problems with /mklib option |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Thu Oct 29, 2015 1:52 pm Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Oct 30, 2015 12:15 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Fri Oct 30, 2015 9:48 am Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Oct 30, 2015 2:48 pm Post subject: |
|
|
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 |
|
|
DietmarSiepmann
Joined: 03 Jun 2013 Posts: 279
|
Posted: Fri Oct 30, 2015 3:20 pm Post subject: Problem with substrings |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Fri Oct 30, 2015 11:48 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sat Oct 31, 2015 9:18 am Post subject: |
|
|
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 |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Nov 01, 2015 12:39 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Mon Nov 02, 2015 8:15 am Post subject: |
|
|
Dietmar
The INTEGER*2 problem has now been fixed.
John
The COU@ problem has now been fixed. |
|
Back to top |
|
|
|
|
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
|