forums.silverfrost.com

[Farhadpour]

Plato3/FTN95 Personal on AMD 64 bit machine! can anyone help please?

I use a Dual boot Quadcore AMD machine with Windows XP professional installed on drive C and Windows XP Professional x64 installed on drive D.

FTN95/Plato install well and run fine under the 32bit Windows OS. I cannot get FTN95/Plato to work under the 64bit windows OS. The software installs fine on Progrm Files (x86) and Pluto runs. Problems start when I read in a Fortran file and attempt to compile it. Irrespective of the fortran program used, I always get the following Access_violation messagesand the compilation fails!!!

I have tried running with the *.exe files under windows xp compatibility mode, but the same error occurs. I also get the same error when I use FTN95 under Visual Studio. Has anyone had this kind of problem before? Is it to do with the different pointer lengths in 32 and 64 bit operating systems? can anyone suggest a workaround? I have 8 Gigabyte of RAM and would very much like to see and use it all, which is not possible with the 32bit OS.
I will be grateful for any helpful suggestions.


Farhad Farhadpour



Compiling file: FreeFormat1.f95
Access violation:
The instruction at address 00538571 attempted to write to location 7fff0000
00538445 generate_default_pattern(<ptr>char,<ptr>structￄtype_definition) [+012c]

0050d050 allocate_static_object(<ptr>structￄscoped_entity) [+02b6]

004c172b allocate_a_variable(<ptr>structￄscoped_entity,<ptr>structￄscope)#42 [+02d2]

004c1e06 allocate_all_the_vars(<ptr>structￄscoped_entity,<ptr>structￄscope)#42 [+004d]

004c2228 allocate_var_space(<ptr>structￄscope) [+1b38]

004169c5 end_function(int) [+0565]

004187b4 parse_end_statement(<ptr>char,int,<ref>int) [+0b89]

0041205b handle_token(<ptr>char,int,int,int,int,<ref>int) [+0e6b]

eax=00000000 ebx=00000000 ecx=00000004
edx=00000000 esi=005c1bb0 edi=7fff0000
ebp=0384ed78 esp=0384ed28 IOPL=0
ds=002b es=002b fs=0053
gs=002b cs=0023 ss=002b
flgs=00210202 [NC OP NZ SN DN NV]
0360/6020 TSTK=4 [ ]
00538571 rep

00538572 stosb

[JohnHorspool]

Farhadpour,

I use FTN95 on an AMD Quadcore Phenom under XP64. It compiles and runs perfectly. The 32bit exe's produced run fine on any windows 32bit and 64 bit systems .

I do not use Plato or any IDE , I compile and link from a DOS window using batch files. I create applications using clearwin, GDI and OpenGL graphics. Not once have I had a problem using a 64bit OS with 32bit software. I even got the 32 bit applications to run under Linux 64bit Ubuntu using "wine" !

As FTN95 produces 32bit applications they will not be able to access your 8GB of ram.

[LitusSaxonicum]

Farhadpour,

Have you tried compiling when your machine is in 32-bit mode, and running the code (later) when it is in 64-bit mode? It should run. If it does, I would put your problem down to the installation of FTN95 under XP64 (e.g. the PATH settings aren't correct).

Since you won't get access to the full 8Gb even under XP64 - because FTN95 is 32-bit - then you could buy one of the "RAM Disk" packages. This will make your spare RAM look like a superfast hard drive when using XP32.

Eddie

[JohnCampbell]

Farhadpour,

Address "location 7fff0000" is not a valid address for win32. You are being overly optimistic in trying to address more than about 1.7 gb of memory with FTN95-32. We will all have to wait for FTN95-64 !!

Eddie,

I have looked into ways of transferring more than 2gb of information to other memory, to avoid the slow disk I/O rates. My review of ramdisk concluded it is not a good solution for faster addressing of more than 2gb of memory. (I have not actually bought and tested ramdisk) I have 2 questions about the ramdisk approach.
1) I have seen no documentation that you can use more than 4gb of physical memory with ramdisk, to indicate that this approach is suitable for emulating more than 2gb of fast disk accessing. Has anyone experience of a ramdisk with say 8gb of memory in a win32 environment?
2) All the testing I have seen shows disk I/O rates for ram-disk (or similar) that are very disappointing. Also my testing of solid-state disks appears to provide very ordinary transfer rates, especially for writing large blocks. I am assuming that the transfer rates are limited to the transfer rate limits of the disk I/O bandwidth. Does anyone know what these limits are?

My conclusion is the only worthwhile solution is a 64-bit OS. If anyone has experience of ramdisk or similar solutions for handling disk I/O of more than 2gb I would appreciate your advice.

John