View previous topic :: View next topic |
Author |
Message |
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Fri Jul 22, 2016 9:15 am Post subject: 64-bit and .NET |
|
|
Hi,
does the new 64-bit compiler produces .NET assemblies as well or is it limited to standard executables? Or in other words: can I produce a 64-bit .NET 4.0 assembly with FTN95?
Regards,
Goran |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Jul 22, 2016 7:00 pm Post subject: |
|
|
FTN95 has not been adapted to produce 64 bit .NET assemblies.
The work on porting to standard 64 bit Windows is still ongoing and there are other pressing issues that probably need to be addressed after that. |
|
Back to top |
|
|
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Mon Aug 26, 2019 3:53 pm Post subject: |
|
|
Any update on 64-bit .NET assemblies? |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Mon Aug 26, 2019 4:11 pm Post subject: |
|
|
There are currently no plans to extend FTN95 in order to provide for 64 bit .NET assemblies. |
|
Back to top |
|
|
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Thu Sep 05, 2019 2:31 pm Post subject: |
|
|
What exactly is not supported? We managed to get our .Net dll work in 64-bit by removing the "32-bit Machine" file flag after the compilation. The results of the calculation performed with the 64-bit version are the same as with 32-bit.
I only found out the the TRY-CATCH block causes crashes in 64-bit. |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Thu Sep 05, 2019 9:25 pm Post subject: |
|
|
Did you do file I/O? |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2820 Location: South Pole, Antarctica
|
Posted: Fri Sep 06, 2019 1:27 am Post subject: Re: |
|
|
gperiskic wrote: | What exactly is not supported? We managed to get our .Net dll work in 64-bit | hahaha...hacks!
We also for two decades were running parallel simulations using FTN77 /95 with LIB libraries created in other companies Fortran compilers despite the LIB formally were not supported....also hacks! Something was worked something not but that was enough. Only recently 100% compatible solution was found by using DLL, thanks to mecej4 for the implementation. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Sep 06, 2019 8:13 am Post subject: |
|
|
gperiskic
I am surprised that you have .NET FTN95 working for 64 bits.
One limitation of 32 bit .NET FTN95 is that applications normally call into salflibc.dll and this won't work for 64 bits. So your application must be unusual in this respect at least.
After that, your experience implies that the assembly code produced by FTN95 and DBK_LINKx works equally well for 64 bits. This, in one sense, is as it ought to be but never-the-less is quite remarkable. |
|
Back to top |
|
|
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Fri Sep 06, 2019 8:21 am Post subject: |
|
|
Well, we didn't really hack anything, just removed the flag as mentioned above.
We use classes from C# to define the input/output interface and pass them directly to the fortran assembly, without any i/o disk operations. The fortran assembly is performing various mathematical analysis, without any graphical work.
So it makes me wonder that you claim that 64-bit is not supported in NET at all.
Exactly the same is valid for my question regarding .NET Core support - even here we managed to get it work, just had to compile without salflibc...
@Paul: we compile with /NO_SALFLIBC switch and subsequently remove the 32-bit flag - this works both for 64-bit and NET Core. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7928 Location: Salford, UK
|
Posted: Fri Sep 06, 2019 8:35 am Post subject: |
|
|
gperiskic
That is encouraging. Can you provide details of how to remove the 32 bit flag. |
|
Back to top |
|
|
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Fri Sep 06, 2019 8:41 am Post subject: |
|
|
Sure...
Either use "dnSpy" (go to FileHeader and unklick "32-Bit Machine") or use Microsoft CorFlags.exe (call 'corflags myAssembly.dll /32BIT-' from command prompt). |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
Posted: Fri Sep 06, 2019 8:42 am Post subject: |
|
|
dbk_link explicitly puts that flag on to force the assembly to 32-bit. If it didn't then .NET could load it in 64-bit mode and any calls to salflibc would break the system. As I recall one of reasons we chose not to go down the 64-bit .Net route was that it didn't support arrays larger than 32-bits. |
|
Back to top |
|
|
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Fri Sep 06, 2019 8:46 am Post subject: |
|
|
Robert - you mean that if a single array needs more then 4 GB memory then it doesn't work.? |
|
Back to top |
|
|
Robert
Joined: 29 Nov 2006 Posts: 445 Location: Manchester
|
|
Back to top |
|
|
gperiskic
Joined: 18 Dec 2009 Posts: 34 Location: Stuttgart, Germany
|
Posted: Fri Sep 06, 2019 9:29 am Post subject: |
|
|
Ok, thanks Robert, this is good to know. We don't have such large arrays, but I'll keep this in mind.
Anything else? As mentioned before, a try-catch block (for exceptions catching) works fine with 32-bit but crashes with 64-bit. |
|
Back to top |
|
|
|