| Two methods come to mind. Experiment for best fit. Both involve
using the malloc() call.
One: from your application call malloc(4194304) to attempt grabbing
all 4 megabytes of possible memory. This is sure to fail but many
C compilers will return the amount of memory actually available to
you, which happens to be the number of free bytes left.
If you're using Assembler (or a C compiler that supports it) then you
can use the malloc gemdos call with a -1 value to get a report
of free bytes. The sample assembler code from my ST Internals book is:
move.l #-1,-(sp)
move.w #$48,-(sp)
trap #1
addq.l #6,sp Number of free bytes is in D0
Dan
|
| > One: from your application call malloc(4194304) to attempt grabbing
> all 4 megabytes of possible memory. This is sure to fail but many
> C compilers will return the amount of memory actually available to
> you, which happens to be the number of free bytes left.
> If you're using Assembler (or a C compiler that supports it) then you
> can use the malloc gemdos call with a -1 value to get a report
> of free bytes. The sample assembler code from my ST Internals book is:
Will this give you the amount of free memory, or the size of the largest
chunk of free memory?
Jim Patterson
|
| The proper way to determine the free memory in the system is to call the
GEMDOS routine Malloc( -1). Note that in Mark Williams C that "Malloc" is
very different from "malloc". Again, Malloc( -1) might just be the size
of the largest free segment, I would have to double check the
documentation to be sure.
The problem with this is that if you are using Mark Williams malloc and
free routines you don't know how much memory the run-time library has
allocated from the operating system but not yet delivered to your
application. I got around that by writing my own malloc() and free()
pakage which give me much more control over memory and allows me to
generate accurate statsitics. If you look in the "memory usage" form of
the new Whack, you will see what I mean. You get numbers for "free
memory" and "unallocated memory" as separate numbers.
BTW, using 4MB as the upper limit is not good enough. It is common for
TT's to have 8MB, and using Dave Small's latest SST gadget, you can
turn a lowly Mega-2 into a *power user* Mega-12 (with a 40Mhz 68030 for
a CPU as well, and no wait states on the upper 8MB! That computer must
FLY when running software that was meant for a lowly 8Mhz 512K 520ST.)
|
| Here's what Allan Pratt (of Atari) had to say about free memory when the
question came up on Usenet a few years ago, includes a example code.
Ray
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Malloc - what it really does (was: Re: SPUFILE 2.0, C questions)
Date: 23 Oct 89 19:29:10 GMT
Organization: Atari Corp., Sunnyvale CA
klute%trillian.irb@unido.uucp (Rainer Klute) writes:
>From what I have found out Malloc (-1L) returns the *sum* of the
>sizes of *all* free memory chunks.
This is emphatically not the case, and never has been.
The original answer was right: it returns the size of the LARGEST
SINGLE CHUNK of free memory. A common way to find out how much memory
there is in the system is to call Malloc(-1L) many times, each time
allocating a chunk of the size it returns, until it returns zero.
Then you report the answer and Mfree() all the chunks you allocated.
Of course, Malloc(-1) is evil if you're in a multi-tasking environment,
because in the time between the Malloc(-1) and actually allocating the
block of the size it reported, you could be preempted and somebody else
might allocate that block away from you! This is only one of a whole
class of problems which a multitasking TOS would have to address: the
single-thread, global, I-own-the-machine nature of TOS applications.
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Malloc(-1L), free memory...
Date: 30 Oct 89 20:37:35 GMT
Organization: Atari Corp., Sunnyvale CA
Well, in a large-memory machine, there can be a LOT of 4K blocks
around. This makes for a lot of recursion.
Re-think this problem as a loop. Use the first long of each block as a
link to the previous block. Keep Malloc'ing until you run out, then
free up the list. Like this:
long freemem()
{
long size, total;
long *start;
long *prev;
prev = 0L;
total = 0L;
do {
size = Malloc(-1L);
if (size) {
total += size;
start = Malloc(size);
if (size < sizeof(char *)) {
/* end of map: too small to keep track */
Mfree(start);
break;
}
*start = (long)prev;
prev = start;
}
} while (size);
while (prev) {
start = *prev;
Mfree(prev);
prev = start;
}
}
============================================
Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
|