Author Topic: Console app and memory availability  (Read 4080 times)

CCurl

  • Member
  • **
  • Posts: 62
Console app and memory availability
« on: October 28, 2015, 04:39:44 AM »
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:
Code: [Select]
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?
Code: [Select]
.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

  • Member
  • *****
  • Posts: 12485
  • Assembler is fun ;-)
    • MasmBasic
Re: Console app and memory availability
« Reply #1 on: October 28, 2015, 06:28:30 AM »
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

  • Member
  • *****
  • Posts: 2390
    • https://github.com/nidud/asmc
Re: Console app and memory availability
« Reply #2 on: October 28, 2015, 06:49:50 AM »
deleted
« Last Edit: February 25, 2022, 10:58:20 AM by nidud »

CCurl

  • Member
  • **
  • Posts: 62
Re: Console app and memory availability
« Reply #3 on: October 28, 2015, 07:47:47 AM »
Code: [Select]
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

  • Member
  • *****
  • Posts: 8828
  • Still using Abacus 2.0
    • DednDave
Re: Console app and memory availability
« Reply #4 on: October 28, 2015, 08:16:02 AM »
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

  • Member
  • ***
  • Posts: 426
Re: Console app and memory availability
« Reply #5 on: October 28, 2015, 01:40:19 PM »
I agree with Dave, use VirtualAlloc.

Dave.

jj2007

  • Member
  • *****
  • Posts: 12485
  • Assembler is fun ;-)
    • MasmBasic
Re: Console app and memory availability
« Reply #6 on: October 28, 2015, 05:33:12 PM »
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 ;-)