largeadware question and gigabytes of memory

[daydreamer]

Hi
this is 64bit .exe
got error when trying to make array in static,that it was max 07fffffffffh something,its too big
is this and dynamic alloc need largadware,despite its 64bit mode?
also wonder if I need different alloc/free in 64bit mode than previous
some method of check maxmemory and if I get 64gb, subtract that with x gb(maybe 2-5gb) before I alloc memory ,so windows doesnt get unstable or crash?
whats typical memory hz in your 64bit cpu compared to clock freqency?if working with a memoryintensive program,I am only guaranteed memoryspeed?

[hutch--]

magnus,

With MASM (ml64) you use the /LARGEADDRESSAWARE option to ensure you only use fully compatible 64 bit code. When you get an error that says you cannot use that option, it will be a code construction that cannot be used in win64. It is usually things like trying to load a large "immediate" value into a memory variable, if you have the problem, load the value into a register first then move the register into the 64 bit variable.

As long as you keep the app fully compatible with 64 bit Windows, you can access very large amounts of memory, if you go the other route you limit the app to 32 bit address range for no real gain, you may as well write in 32 bit.

[aw27]

07fffffffffh = ‭549,755,813,887‬ bytes = 512 GB
Quite a lot, it will not work in most systems.

[daydreamer]

As long as you keep the app fully compatible with 64 bit Windows, you can access very large amounts of memory, if you go the other route you limit the app to 32 bit address range for no real gain, you may as well write in 32 bit.

I wish that you and other who has highend 64bit with loads of RAM can test it on 64gig RAM systems,with a 64bit version of a numbercrunching 32program,inspired by 64bit Cg apps that take advantage of all aviable RAM,so it can have lots of photorealistic textures while numbercrunching with algos with the right math to render photorealistic

[hutch--]

magnus,

You are missing something here, if you code in 32 bit Windows code, you have a 2 gig limit and about another gig if you use the /LARGEADDRESSAWARE flag. If you write 64 bit Windows code that uses the /LARGEADDRESSAWARE flag, you can use up to 192 gigabytes of memory if you have that much installed and make truly massive amounts of data.

Since you live in a northern hemisphere cold country, I hope you have a great white Christmas.

[jj2007]

In 32-bit code, adding the negative addresses with /LARGEADDRESSAWARE is an interesting adventure, because all code that relies on addresses being positive will produce nice surprises.

I wonder, though, why 64-bit code would need /LARGEADDRESSAWARE? 2^63 is 9.223e18...

[hutch--]

> I wonder, though, why 64-bit code would need /LARGEADDRESSAWARE? 2^63 is 9.223e18...

So it does not get restricted to 2 gig. Without it, its one of those half arsed options for code that contains 32 bit constructions that are not valid in 64 bit mode. Its win32 on steroids as far as extra registers but knackered win64. 

[jj2007]

Right, that builds and runs indeed fine but is somehow against the 64-bit spirit:

Code Select Expand

include \Masm32\MasmBasic\Res\JBasic.inc ; ## console demo, builds in 32- or 64-bit mode with UAsm, ML, AsmC ##
Init
  mov eax, Chr$("Hello World")
  PrintLine rax
  MsgBox 0, "Wow, that works indeed!!!!", "Hi", MB_OK
EndOfCode

OPT_64 1 ; put 0 for 32 bit, 1 for 64 bit assembly
OPT_DebugL /LARGEADDRESSAWARE:NO

[TimoVJL]

The /LARGEADDRESSAWARE option tells the linker that the application can handle addresses larger than 2 gigabytes. In the 64-bit compilers, this option is enabled by default. In the 32-bit compilers, /LARGEADDRESSAWARE:NO is enabled if /LARGEADDRESSAWARE is not otherwise specified on the linker line.

[daydreamer]

You are missing something here, if you code in 32 bit Windows code, you have a 2 gig limit and about another gig if you use the /LARGEADDRESSAWARE flag. If you write 64 bit Windows code that uses the /LARGEADDRESSAWARE flag, you can use up to 192 gigabytes of memory if you have that much installed and make truly massive amounts of data.

Since you live in a northern hemisphere cold country, I hope you have a great white Christmas.

thanks,not so often white christmas here close to Copenhagen,hope you also have a great Christmas
only have 20gb and C code so far that use 2gb and also x64 testing dynamic alloc

@JJ
the coolest looking pointer bug I did many years ago in ddraw software renderer,sea and atmosphere textures blended,accidently part of sphere used sea texture for outer atmosphere,looked like cool transparent wrinkled plastic wrapped part of sphere

[hutch--]

He he, we had an almost sunny day today (Christmas Day) as it lightly rained last night and the wind blew the smoke away. For all of the heatwave predictions, we have not had very hot conditions here in Sydney, some evenings have been a bit cold. It would really help if we had a couple of days of really heavy rain but it does not look like its going to happen any time soon.

[aw27]

A 32-bit application on a 64-bit OS can use the /LARGEADDRESSAWARE linker switch to address 4GB.
This is what Raymond Chen says.
https://devblogs.microsoft.com/oldnewthing/20050601-24/?p=35483

"Use" does not mean allocate, I have never been able to allocate more than 2GB on a 32-bit application running on a 64-bit OS when using /LARGEADDRESSAWARE, either with HeapAlloc or VirtualAlloc. When using /LARGEADDRESSAWARE I can allocate a bit more than without /LARGEADDRESSAWARE, but never more than 2GB. We can address but we can not allocate, the system DLLs continue to be placed above the 2GB address as before.

Now, about 64-bit applications:
Some people use /LARGEADDRESSAWARE switch when linking a 64 bit application. This is not necessary because the default for 64-bit applications is /LARGEADDRESSAWARE. What I have seen some people doing (here) is use /LARGEADDRESSAWARE:NO on a 64-bit application.
Although legal, when used blindly, as tends to be, causes problems.

[hutch--]

With a 32 bit app with the /LARGEADDRESSAWARE flag set, you can allocate almost 2gig in one allocation but you can allocate another block depending on the extra size you get from using the flag after some of the high address space is used by some hardware.

[aw27]

With a 32 bit app with the /LARGEADDRESSAWARE flag set, you can allocate almost 2gig in one allocation but you can allocate another block depending on the extra size you get from using the flag after some of the high address space is used by some hardware.

Yes, it is true. 

[aw27]

Testing how far we can go with /LARGEADDRESSAWARE in 32-bit by top down allocation in chunks 10000 pages.