News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Console app and memory availability

Started by CCurl, October 28, 2015, 04:39:44 AM

Previous topic - Next topic

CCurl

I am writing a console app using the flat memory model. It is a Forth compiler, and I would like it to have access to at least 4 MB of memory.

Being a newbie, it is not clear what memory I have access to without needing to ask the system for more.  So, how much of the computer's memory does that have access to out of the box, without needing to call something like HeapAlloc?

If I do something like this, then the resulting EXE is huge, so I am trying to stay away from that approach:

BYTE        theMemory        FourMB      DUP (?)

Currently my app uses HeapAlloc, which works, but switching from unallocated to allocated memory requires an address converison, which I would prefer not to have to do.

What if I do this?

.stack 480000h ; 4 1/2 MB

That should make 4 1/2 MB available from the start without needing to allocate any, shouldn't it?  And since the stack starts at the top and grows towards the bottom, then in theory, I should be able to use the almost 4 1/2 MB of memory from the bottom up to where the stack pointer is, right? And if i set EBP = (ESP - 4MB), then I suppose one could think of it as a HUGE local variable.

I realize this idea is probably unconventional ... but you as you guys are quickly learning, I am one of those people who likes to test the limits. So ... will it work?

jj2007

We've all gone through this, see e.g. StackBuffer(). However, you need a really excellent reason to avoid HeapAlloc & friends. Under Windows, you can allocate half a GigaByte without any problems - why bother with the stack, or write a manual that instructs the user to be cautious with the stack etc etc...?

The bloat thing can be avoided if you put the buffer into .data?, not .data - but caution, MASM has a nasty bug. If you come up with that excellent reason to avoid HeapAlloc, we may give you a workaround :icon_mrgreen:

nidud

#2
deleted

CCurl

Quote from: nidud on October 28, 2015, 06:49:50 AM

LINK /STACK:reserve[,commit] ...

Sweet ... it works. Thanks. Assuming that each "word" uses 50 bytes on average, with an 8MB stack, my Forth system now has room for about 175,000 words, with no need to allocate any memory. And the EXE is only 17k.

Should I run into problems, I will allocate the memory by hand instead of letting the linker build it in for me.

dedndave

there is also VirtualAlloc   :biggrin:

i prefer the heap functions, and the stack
but, i try to avoid programs that require a special assembly/link command line

you can "probe" the stack down to get larger commit values, as well
you can use the forum search tool, as the word "probe" is rarely used elsewhere   :P

KeepingRealBusy

I agree with Dave, use VirtualAlloc.

Dave.

jj2007

Dave,

You don't agree with Dave, because Dave prefers the heap :P

Jokes apart: No real need to use two functions, because the OS uses VA under the hood if HeapAlloc requests more than about half a megabyte. But again, it's a matter of taste, too ;-)