/4gb access

Paul,

With Version 6.3, I have been able to access up to 3.7gb of memory, using allocate.

I have now tried to test how much memory I could get in my large graphics program, but I am only getting 2gb. I have recompiled all the code with Ver 6.36, ensuring that /DEBUG is the only checking option I am using, but have not been able to address above 2gb.

Would Clearwin+ restrict memory ? The main winio@ calls are:

      i = winio@ ('%ca@&', caption)
!
      if (full_screen) then
         i = winio@ ('%ww[no_border,maximise]&')
      else
         i = winio@ ('%ww[no_border]&')
      end if
!
      i = winio@ ('%sc&', plot_setup_func)                  ! call saplot setup function
      i = winio@ ('%pv&')
!
      i = winio@ ('%`^gr[grey, user_resize, rgb_colours, full_mouse_input, user_surface]&',  &
                    1024, 768,          &   ! screen dimension when not maximised
                    ptr_RGB_Address,    &   ! screen address for rgb surface ( not sure of the order ? )
                    w_handle,           &   ! ` window handle defined in crtstart
                    mouse_back_func)        ! ^ call back function for mouse and resize
!
      i = winio@ ('%mg&', WM_MOUSEWHEEL, OnMouseWheel)      ! mousewheel response
!
      call Saplot_Menus
!
      i = winio@ ('%hw', hwnd)                              ! return the handle of the current window.

Is there any way to identify what .obj files are switching off /3gb, which has been automatic on Win7_64. This is early in my investigations so I am not sure if this is a regression with Ver6.36. I have tested my memory scanning utility and it does provide 4gb with Ver 6.36, but this is a small program.

I shall re-install 6.30 and see what happens, but if you have any suggestions it would be appreciated.

John

hi John

I thought, probably mistakenly, that ANY debugging switch caused the 2Gb limit. I certainly switched off all /DEBUGs and /CHECKs and 'debug' in my SLK files...

K

FTN95 Version 6.30 was improved to allow /DEBUG to not restrict /3gb from operating. This is a significant improvement, as /DEBUG provides the code line number when an error occurs. Any /CHECK or more will stop /3gb from being the default in SLINK.

I slink without the /3gb switch and get up to 4gb on Windows 7_64 as default with small analysis programs that don't use Clearwin+.

I am now trying to allocate larger arrays for the clearwin+ application to see if I can still use the clearwin graphics memory allocation to work. It is not yet working and I am trying to find out why. There are lots of possibilities but if any salflibc.dll library routines have /check identified they may stop /3gb.

John

I am reasonably confident that nothing has changed within our compilers and DLLs that could cause a regression in this area. But where there is software there is always an element of doubt!

Quoted from JohnCampbell FTN95 Version 6.30 was improved to allow /DEBUG to not restrict /3gb from operating. ...

John

aah, I hadn't realised that, thanks, could be handy!

K

John, You've been a great explorer of 3+ GB area implemented by FTN95 developers and i due to that have got a little of air to breath since last year implementing it. But of course that air is ending fast. Since Clearwin+ is now compiler independent, would be great if you or anyone else try to explore the 64bit terra incognita with Clearwin+other compilers like Intel's Fortran which is fastest today and any others and share the experience.

/* well, may be after asking FTN95 developers last time if they have in mind making this compiler 64bit capable at some point in future.

Paul,

I have again tested my main graphics application, but I am only getting 2gb of addressable memory. I have checked all the libraries, and the only compiler options I am using are: /debug /opt /p6 /windows or no option

I have tested my small memory testing program, with /windows and it still works.

Is there a way of identifying what .obj file is restricting the use of /3gb ? There are about 600 routines in this program.

John

I cannot think of any way to do this. The switch only appears in the header of the final exe file.

Quoted from JohnCampbell Paul,

I have again tested my main graphics application, but I am only getting 2gb of addressable memory. I have checked all the libraries, and the only compiler options I am using are: /debug /opt /p6 /windows or no option

I have tested my small memory testing program, with /windows and it still works.

Is there a way of identifying what .obj file is restricting the use of /3gb ? There are about 600 routines in this program.

John

does your big application use a file browser dialogue? If it does, that may be the issue - see this other thread

http://answers.microsoft.com/en-us/windows/forum/windows_7-files/file-save-dialogue-often-does-nothing-when-i-click/73c3ecc4-dc5e-47e8-861f-486e5342c714?page=2

(scroll down to my post on June 8th 2012)

edit: here's a more explicit version... http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a543ecf0-fe4a-4476-be7e-296989c79acb/memory-allocation-failure-after-using-file-open-browser-under-windows-7#35c30d1d-687b-4c32-9b63-a97ad91d8022

K

Paul,

I am on holidays next week and will see if I can implement your binary coding technique you recommended recently. As Kenny has highlighted, it would not surprise me if there is some API functionality that is causing the problem.

John