/LARGEADDRESSAWARE:YES

[Rescator]

That option is available in Pelles linker but defaults to no.
http://www.purebasic.fr/english/viewtop ... dressaware

Quickly explained (to those that do not know) this allows a PB program to use up to 3GB on systems that has the 3GB user mem boot switch used.

And on Vista 64bit a 32bit PB app can use up to 4GB mem (instead of 2GB).

As far as I know PB treats a pointer fully as a pointer, in other words it fully retain the signed bit and does not mess with it. (right Fred?)

More details: http://msdn.microsoft.com/en-us/library/bb147385.aspx

[Rings]

take a look in the help(compile/linker options),
there is chance to set linker switches via textfile.

[Mistrel]

I considered making a post just like this but when I checked the output of a pointer is appeared to be signed just like integers and longs:

Code: Select all

*Pointer=2147483648
Integer.i=2147483648
Long.l=2147483648

Debug *Pointer
Debug Integer
Debug Long

[Rescator]

You are right Mistrel.
This (like the NX bit) must be selectable in the IDE prefs.

Reason is that either pointers must be treated as unsigned,
or converted to quads, if not then: *ptr=2147483647+1
will fail as it wraps to negative right?

Then again, if that aware bit is set, I guess the compiler could just treat pointers as unsigned automatically.

*scratches head* Not an easy one this...

You only have this issue if you add or subtract from a pointer (like when stepping though memory),
directly using the pointer, or using hex values avoids any issue. (it's still stored as a signed value but as it's a absolute value it behaves as expected)

Sadly the following seem to fail:

Code: Select all

EnableExplicit

Define *x

For *x=$7FFFFFF0 To $80000002
 Debug *x
Next

With the large address bit, this has to work, without the bit we're limited to 2GB anyway and won't "tip" over the sign bit, at least not normally.

[Fred]

Well, you can still specify it in the linker flags. It should work, but you couldn't manipulate pointers above 2GB easily. That said, AllocateMemory() could return >2GB without problem, and you can use StrU() to display the value as unsigned. Simple arithmetic like +/- should work but test (with If/EndIf) will fails as long (including pointers) are signed in PB.

Code: Select all

*Pointer = 3000000000
Debug StrU(*Pointer, #PB_Long)

*Pointer + 10
Debug StrU(*Pointer, #PB_Long)

Note: on vista 64, better uses a 64 bits program as it will remove any memory limit. IMHO, the 3GB trick for XP isn't that useful because if your program needs more the 2GB memory, chances are high than 3GB won't suffice.

[pdwyer]

I came across this flag on the MS web site and searched for it on the forums and found this thread.

If you were not using allocate memory but rather dimensioning an array and wanted to use up to 4gb on a 32bit process then this would be useful wouldn't it? It's a shame about not having an unsigned dword data type but there is more to this than just raw memory access isn't there?

This would allow a 32bit process running on a 64bit system with say 8gb ram to use 4 full gig I would think.

[Trond]

If you were not using allocate memory but rather dimensioning an array

The array is allocated with a similar function, so it'd be the same.

and wanted to use up to 4gb on a 32bit process then

You can only use up to 3gb even on a 64-bit system, I think. Else there would be nowhere for the OS libraries and kernel entry points to be.

[pdwyer]

http://download.microsoft.com/download/ ... oyment.doc

Page 6

And http://blogs.msdn.com/oldnewthing/archi ... 23817.aspx

For the Array, do you know that, is it worth testing? (I'm not able to read the ASM output etc)

[Fred]

Actually i'm on the Trond side, where are the kernel libraries addressed in 32 bits mode then ? A 32 bits process can't possibly use the full 4 GB spaces (or there is a processor trick ?).

[pdwyer]

(This is not my area of specialty but ..) Libraries are always running in the process VM space arent they? In this case they will be shareing that 4gb the same way that they would be shareing 3gb on the a normal windows server running the /3gb switch. The 1gb left for the kernel itself though to manage page pool and everything else is separate from the process space. That extra gig wouldn't be needed on a 64bit system as it has the rest of the memory and there are no 32bit drivers running even under wow64.

The wow64 could give a process the full 4gb then for itself and all it's libraries rather than just three in a /3gb environment or two gig in a normal environment.

Or atleast thats how I understand it.

Fred, since you are on this thread, could you confirm if Trond is correct about the array memory? could you allocate a 3.5gb sized array in PB if the OS let you?

[freak]

Kernel libraries are loaded into the lower 2Gb as well in a 32bit program. Else the program couldn't call them. The higher 2Gb are totally unaccessible by the program. Kernel handles are not pointers, so a 32bit program can well access a kernel object stored in a higher location if the kernel supports that.

So yes, on a 64bit system using the flag you get full 4 Gb (see pdwyer's second link), but those 4 Gb will contain all loaded Dlls as well as any system data that the process can directly reference by pointer. (as it is with the 2Gb on a normal 32bit program)

> Fred, since you are on this thread, could you confirm if Trond is correct about the array memory? could you allocate a 3.5gb sized array in PB if the OS let you?

Array allocation is a simple HeapAlloc(). What else would it be ?
I doubt though that you could get a 3.5gb array in a 32bit program because of things like memory fragmentation and the loaded dll's needing space too etc. Also i am not sure if PB could properly access such an array as it was not designed specifically to handle such memory locations. It could work if you are lucky, but we never checked.

Anyway, since PB now supports 64bit i don't see why you would want to use this flag anyway. If you really have need for large amounts of memory then just go 64bit, there you get 8 Terrabytes of virtual process space.

[pdwyer]

If you really have need for large amounts of memory then just go 64bit

Spoil Sport

there you get 8 Terrabytes of virtual process space.

Do you get up to 8tb in vista? for win2k3 64bit you get 32gb for standard and 1tb for the others.

[freak]

> Do you get up to 8tb in vista? for win2k3 64bit you get 32gb for standard and 1tb for the others.

That is the limit for physical memory in the system. The 8TB are virtual memory per process. (its 7TB for Itanium systems)
On Vista64 the physical limit is 128 GB btw (not for basic and home premium)

See here:
http://msdn.microsoft.com/en-us/library/aa366778.aspx

[Trond]

For the Array, do you know that, is it worth testing? (I'm not able to read the ASM output etc)

We know that arrays are allocated dynamically, so it's gotta be a similar function, right?
All dynamic memory allocations on Windows ultimately end up in VirtualAlloc() sooner or later.

[pdwyer]

But I don't know if fasm has the same 31 bit limit as PB with signed ints perhaps it has dwords ...