MORE INFORMATION
If you are having trouble using the CLEAR statement to enlarge the
stack or data areas to eliminate "Out of Memory" messages or other
memory problems, you should base the arguments for the CLEAR statement
on the values returned by the FRE(n) function (at run time), instead
of specifying absolute numbers. There should only be one CLEAR
statement per program.
Note that you should not assume that the screen and sound buffers will
be in any specific location, since this may change in future
implementations of the Macintosh hardware or operating system. In
addition, you should not assume that the memory for the buffers is
contiguous with the application space, the stack, and the application
heap. In the future, the stack may move as well.
The following is the revised Macintosh memory map:
******* Overall Macintosh Memory Map *******
OS-dependent--> +----------------------------+
| Screen and Sound Buffers |
+----------------------------+
High Memory --> +-----------------------------+
| ROM Support |
| Segment jump table |
+-----------------------------+
| Quickdraw Globals |
register(a5)--> +-----------------------------+
| Application Globals |
+-----------------------------+
| |
| Stack |
: :
:.............................:
: :
| Heap |
| |
Low Memory---> +-----------------------------+
***** Memory Map for a Macintosh QuickBASIC Compiled Application ****
The stack is stored in high memory, as shown in the memory map below.
The stack in highest memory is set at compile time, and contains main
program variables, variables in SHARED statements, variables in
COMMON, and array descriptors. The remainder of stack is used
dynamically at run time for GOSUB statements and subprogram calls.
The statement CLEAR,,<StackSize> changes StackLimit (StackLimit is
shown in the map below). The stack grows downward in memory. If the
stack pointer goes below StackLimit, an "Out of Memory" error should
be reported; however, the stack overflow can go undetected if you
compile without the "Check Arrays and Overflow" option.
FRE(-2) returns the value of CurrStack minus StackLimit, where
CurrStack is the current value of the dynamic stack at the time
FRE(-2) is invoked. The value returned by FRE(-2) is only an estimate,
since the stack changes from moment to moment.
When dynamic subprograms are active, there is another link frame for
each active invocation of a dynamic subprogram below the one link
frame for the main program. Each additional link frame contains the
local variables for the dynamic subprogram.
High---------> +-------------------------------+ <----+
Memory | Common Variables | |
| | |
+-----> |...............................| Main/SHARED
| | Other main program variables: | program
one link | All simple variable data, | variables
frame | static arrays, string | in fixed
| | descriptors, and array | block in Stack
| | descriptors. | |
| | | |
+-----> +-------------------------------+ <----+
: :
: ---- Dynamic Stack ---- :
: :
CurrStack----> :...............................:
: :
StackLimit --> :...............................:
: :
The heap comes next in memory, as shown below. A number of blocks are
allocated out of the heap. The relative location of one block to
another in the heap is unpredictable since they are allocated by the
Macintosh Memory Manager, but the ordering of the blocks tends to be
as shown:
: :
Top (End) : :
of Heap ---->:...............................:
: :
: ----- Free Heap ----- :
: :
The statement CLEAR ,<Data> changes the size of the compiled program's
Data block (shown below). You get an "Out of Memory" message at run
time if the value for <Data> would deallocate some of the compiled
program's machine code. The area that remains over after Data and
Stack space are allocated is available for heap space.
: :
+-------------------------------+ <--+
| String space & DATA | |
|...............................| | Compiled
| File Buffers & Array Contents | | BASIC
|...............................| |-- Data
| Machine code for | | block
| compiled program | |
+-------------------------------+ <--+
: :
Note that the Static Subprogram Storage and BASIC Run-time Library
Private Storage blocks (shown below) are just one block in the earlier
Microsoft BASIC Compiler Version 1.00. In QuickBASIC compiled
programs, they are split for better memory management during CHAIN and
RUN:
: :
+-------------------------------+
| Static Subprogram Storage |
| block |
+-------------------------------+
: :
+-------------------------------+
| Block for BASIC Run-time |
| library private variables |
+-------------------------------+
: :
The Run-time Library block (shown below) is allocated by a
GetResource(MBRL) call from the program's initialization code during
startup before the program starts executing:
: :
+-------------------------------+
| Run-time Library |
| machine code block |
+-------------------------------+
: :
The Initialization block (below) is loaded when the compiled
application is launched. The code that handles the MBPN (File Not
Found) processing is also in this block:
: :
+-------------------------------+
| Initialization machine code |
| block (CODE resource ID = 1) |
+-------------------------------+
: :
Bottom of ---> +-------------------------------+
(start of)
Application Heap. Low memory.
Libraries, MBPC resources, CODE resources, MBLC resources, and other
Macintosh objects (resources and toolbox data structures) are
allocated as necessary in any portion of the heap that is free. In the
above memory map, free memory could be in any of the areas not marked as
a "block."
FRE(-1) returns the total number of bytes not being used by these
blocks and not used by other Macintosh objects. You CANNOT assume that
there is one big block of size FRE(-1) because the free memory can be
interleaved with locked blocks. FRE(-1) will cause the Memory Manager
to compact the heap as much as possible before returning the total
available memory. See Inside Macintosh for more information about the
Macintosh Memory Manager.
FRE(n), where n is not equal to 0 or 1, returns the number of unused
bytes in the BASIC data block. Of course, the machine-code portion of
the block is never free. FRE(n) accurately reflects the amount of
space available for new strings, dynamic arrays, and file buffers.