forums.silverfrost.com

[JohnCampbell]

John,

If I wrote the program as I intended, then your results show you are also addressing 3.6gb of memory.
We now need to understand how to use the 2 or 3 large memory packets.
If we could move the bits that SLINK spread around and also be able to reference a single array bigger than 2gb then there would be potentially nearly 4gb of addressable memory for FTN95 in WOW64.
It is interesting that the largest array "A1" sucessfully crosses the 2gb memory point, although it is less than 2gb in size.
I have tried to use ALLOCATE for arrays larger than 2gb. It gives STAT=0 on XP-32, but I think that is an error. As a result, I'm not sure it is possible to allocate arrays larger than 2gb on XP-64 / WOW64.
This certainly shows potential for some problem size extension using FTN95.

John

[JohnCampbell]

Paul,
The results from these examples appear very promising for FTN95 and Win-64. It would be good if FTN95 and SLINK could be tuned to better utilise the extra available memory space.
There is potential for FTN95 to address near 4gb of memory in a WOW64 environment. What the previous example shows is an array can span the 2gb memory address. I have changed the previous example slightly to demonstrate that I can also allocate an array starting above 3gb.
There are a few problems I am still anticipating:-
1) ALLOCATE can manage to address available memory throughout the 4gb of addressible space, I assume by using a 32-bit unsigned integer.
2) If ALLOCATE is used for an array >2gb, it returns STAT=0, even in Win-32, indicating that ALLOCATE may not be able to handle arrays larger than 2gb.
3) LOC returns a -ve value if the address is > 2gb, although the array appears to be accessed corectly, even if it spans the 2gb address.
4) There is still the problem of SLINK not leaving a large contiguous memory, but placing a large number of memory uses throughout memory, especially above 1.7gb. I assume this, from my previous example of searching for the largest available contiguous space, to the nearest 4 bytes. Now that addressing large amounts of memory is more practical, could the way SLINK uses memory be reviewed. Also (my interpretation of) placing VC at 1gb could be reviewed.
5) Could ALLOCATE and FTN95 support a single array up to 4gb, by using unsigned 32-bit addressing, certainly > 2gb ?
All my examples are for small codes that have negligable use of the stack. I will change the memory search to a subroutine and place it in the middle of a large program to see if it still works.
Please give this some consideration as it might easily provide FTN95 a significant capacity extension in a Win-64 environment.
John

[PaulLaidler]

John

This is all very promising and helpful. I would like to work on this but there are a number of immediate problems that need to be sorted out first.

Please prompt me again in 4 weeks if there are no signs of action.

Paul

[JohnCampbell]

Paul,

I can assure you I will not forget to contact you.
The gap analysis, which shows memory locations that are excluded from being available to ALLOCATE is interesting. I think my routine "get_free_memory_size" sizes them to the nearest 4 bytes. I have increased the DO loop to 30 and these excluded areas keep on coming. It is not what I would have expected from SLINK, or maybe I've got this a bit wrong ? Is there any documention of what these may be ?

The program to test memory to 4gb looks to be working, as Windows Task Manager is now showing 3,711,008k virtual memory in use when I run it for 5 arrays.

It certainly appears very promising. I look forward to your updates.

John

[Sebastian]