flat assembler
Message board for the users of flat assembler.
Index
> Windows > Memory allocation problem |
Author |
|
revolution 06 Aug 2012, 01:24
32-bit Windows loads the system DLLs at the high end of the lower 2GB addresses (i.e. <0x80000000) and reserves the addresses above 0x80000000 for the kernel. Even if you boot in 3GB mode you still won't find a contiguous 2GB range of available address space. You have two options:
|
|||
06 Aug 2012, 01:24 |
|
magicSqr 06 Aug 2012, 01:28
Thx revolution for rapid reply
I'm running Win7 64-bit so what do I need to do\use ? (haven't done any programming for 64-bit) |
|||
06 Aug 2012, 01:28 |
|
revolution 06 Aug 2012, 01:33
Also the pagefile cannot act as a memory substitute, only as a backing store for swapped process memory. So even though you are using 64-bit you can't pretend that you have 10GB physical memory by increasing the size of the pagefile, you will still have a maximum per-process memory of 3GB less the memory used by the kernel and drivers.
|
|||
06 Aug 2012, 01:33 |
|
magicSqr 06 Aug 2012, 02:30
OK, thanks for clearing up my misunderstanding of the pagefile.
I'll have to do some research on x64 programming then. I currently only have a copy of the old win32.hlp file. Is there a 64-bit version? |
|||
06 Aug 2012, 02:30 |
|
baldr 06 Aug 2012, 15:22
|
|||
06 Aug 2012, 15:22 |
|
magicSqr 06 Aug 2012, 17:28
lol
What can I say, still using win32.hlp, w32dasm, etc. Just an old-fashioned kind o' guy. Looks like x64 is gonna drag me kicking and screaming into the 18th century :O) btw, had a look at winDbg(x64) (@_@), shocking, why didn't someone make w64dasm, ggrrrrrr |
|||
06 Aug 2012, 17:28 |
|
magicSqr 06 Aug 2012, 20:26
Okley Dokley,
found out about rax, rbx etc. 16 registers, loving it I can print unsigned 64-bit integers with printf using %llu Could someone point me to a 64-bit version of the win32 API ref and the same for C (C++) functions Many thanks |
|||
06 Aug 2012, 20:26 |
|
AsmGuru62 07 Aug 2012, 14:17
What is shocking about WinDbg64?
|
|||
07 Aug 2012, 14:17 |
|
magicSqr 07 Aug 2012, 14:23
AsmGuru62 wrote: What is shocking about WinDbg64? Nothing really, just a case of old dogs and new tricks |
|||
07 Aug 2012, 14:23 |
|
baldr 09 Aug 2012, 03:25
magicSqr wrote: Could someone point me to a 64-bit version of the win32 API ref and the same for C (C++) functions |
|||
09 Aug 2012, 03:25 |
|
magicSqr 09 Aug 2012, 22:23
Thanks baldr, I'm trawling my way through it now
|
|||
09 Aug 2012, 22:23 |
|
f0dder 10 Aug 2012, 11:24
Remember to flag the application as "large address space aware" - that'll give you quite a bit of address space, even for a 32bit application, if you're running under 64bit Windows.
You might want to check Mark Russinovich's "Pushing the Limits of Windows" blog series, especially the part on virtual memory. Also, stay away from Global/LocalAlloc unless you have to use them (clipboard API, AllocateStreamOnHGlobal). HeapAlloc is better for general allocations, and VirtualAlloc is your friend if you deal with huge blocks. |
|||
10 Aug 2012, 11:24 |
|
magicSqr 10 Aug 2012, 22:07
Thanks f0dder, i'll take a look.
Now I'm onto 64-bit I can allocate 2 chunks of 2GB and a chunk ~ 0.75GB which will keep me going. If I don't find the info I seek within this space, the files I'll be checking get larger and larger so eventually I'd end up in the position of having to use a temporary file anyway to save the 2GB and read more. As for the local vs global vs virtual, anything I've ever tried never rendered any extra mem, so I normally use global for ease of typing |
|||
10 Aug 2012, 22:07 |
|
f0dder 10 Aug 2012, 22:37
Are you allocating these large amounts of memory to read full file contents into, then do in-memory searches? If so, you might want to play around a bit with memory-mapped files instead. While you lose some control of exactly how data is read, it can be quite advantageous in some situations - working on (read-only) data directly out of the filesystem cache buffers without copying to your own buffers can be pretty nice in some situations. And especially if your application is 64bit things get easy because you can be lazy and map huge files directly, instead of mapping/unmapping views of the file.
It's not the end-all-be-all of file access that some people seem to believe, but it can definitely be nice for some access patterns |
|||
10 Aug 2012, 22:37 |
|
magicSqr 12 Aug 2012, 10:47
Many thanks f0dder, file-mapping was exactly what I needed
|
|||
12 Aug 2012, 10:47 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.