forums.silverfrost.com

[DrTip]

we have created one on an XP 64 bit operating system

not vista though.

though we had lots (100+)arrays of the order 10MB+ not one single huge array

Carl

[JohnCampbell]

Carl,

Thanks for the response. Did you use ftn95 and slink to produce the executable ? What was the 64bit O/S ?
I'm using two arrays of 1.3gb. When I use SLINK, it groups all arrays in the same section, either in virtual common or in .bss.
I wasn't aware that you could use a win/32 compiler and linker to use the larger memory available on a 64bit O/S

John

[JohnCampbell]

Hi All,

I'm disappointed that no one has responded with any experience of the /3gb switch.

Although I am yet to understand how to increase my data area above 2gb, using slink, I have ordered a new pc with 4gb of memory and when it comes will try again, this time without the need to use virtual memory disk transfers as often. (Using the /3gb switch on a pc with 1gb of physical memory did not work well !)

If anyone has tried this before, please let me know

regards

John Campbell

[DrTip]

Sorry John I missed you second question

We used

Windows XP Professional x64 Edition Version 2003 service pack 2

there is a file boot.ini that has to have the /3GB line added to it

we were using an old FTN95 code which used to be a FTN77 code which was written to the fortran 66 standard

it was buildt using a set of batch file calling FTN95 and then SLINK also using /3GB so we could debug when required

to create the executable. It has all worked as one would expect though some of the debug information is ocassionally a bit erratic and we have to spit numbers to debug files to ensure the debugger is correct/wrong.

having said that it is old (tested) code that takes 18 hours to run so we don't debug very often.

in terms of the code probably no individual array are likely to be as big as say a 1GB but there are lots of arrays.

All arrays are old style static common blocks the stack size is about 10MB I think.

with regard to win32 on 64 bit ops. there are some hoops (normally to do with drivers for hardware) but 32bit apps work simply because there are so many of them that the vendors have had to come up with a technology to handle them. The visible sign of this is that on XP x64 is that the are two program files folders (a bit 32 one and a 64 bit one)

I don't know the details but I believe there is a conversion process that happens at the operating systemn level to convert from 32 bit to 64 bit

technology is called windows on windows WOW or something like on intel chips.

we were very lucky actually we just tried the x64 thing to see if it would help and then saw some threads here talking about 3GB and tried it out, and it really saved our bacon, since the code needed to double in size unexpectedly and we didn't really have a plan B!

Carl

[JohnCampbell]

Carl,

Thanks for the response.
Paul, in a previous post said that the memory addressing range is 4gb, using the full unsigned 32bit integer. The /3gb gives the user process 3gb and the system 1gb, rather than the default of 2gb each.

I would be very interested to see the .map for the program you have got to work. The problem I appear to be having is that if the ".bss" data area exceeds 2gb then windows XP does not recognise the .exe as a valid executable. The following is taken from the map summary for my test program.

Executable section map:

Section Base Length Flags

.text 00401000 000013f6 60000020
.bss 00403000 9d5b344c c0000080
.comment 9d9b7000 000000ba 00000a00
.data 9d9b8000 00000450 c0000040
.idata 9d9b9000 000005a1 c0000040
.CRT 9d9ba000 0000000c c0000040
.salfmap 9d9bb000 0000059b 40000040
.salfsys 9d9bc000 00000018 c0000040
.salfvc 9d9bd000 0000002c c0000040
.reloc 9d9be000 00000000 42000040

I can't get slink to produce a valid .exe file which has more than 2gb in the large arrays. With the mixture of large arrays I am using, all are going into the same memory "section". Unfortunately my test program is compact, so I can't test if the combination of all sections can exceed 2gb.
I have looked at some other programs, where arrays in common are located in the ".bss" and ".data" sections, but I'm yet to understand why or if this could solve my problem.

Again, thanks for the response.

John

[nickb]

I still have problems when running a large program on VISTA but have tracked them down to trying to bring up the file open dialog. If I remove this code, the program works perfectly, but this is not ideal.
Has anyone else come across this problem?