TIP: Click on subject to list as thread! ANSI
echo: power_bas
to: ALL
from: DAVID KIESLING
date: 1998-02-03 04:06:00
subject: Re: memory questions

From: dnskiesling@telis.org (David Kiesling)
Subject: Re: memory questions
 
>Part of an EXE file's header contains instructions to the
>operating system about how much memory the program needs.
>All compiled Basic programs follow a convention of asking
>for far more memory than could ever exist. In that case, the
>loader takes all available convenitonal memory and assigns
>it to the program.
 
So I take it programs compiled from some other languages don't do
this?
 
>One segment is set aside as DGROUP. This segment contains
>all the static variables and arrays in your program, the
>stack, and a fair number of other pieces of data.
 
Just static arrays or all arrays? I'll assume just static. That makes
more sense to me.
How large is DGROUP? If a static array and the stack together equaled
more than 64k, then what? Does it automatically create another
segment?
 
>One or more segments are set aside for program code. Any
>memory that is left over is the far heap. This is where
>dynamic arrays and string segments are allocated.
 
Okay, got that much.
 
>It is important to understand that a memory segment can be
>as small as 16 bytes, or as large as 64K, but no larger.
 
So the advantage of making string segments less than 32k is because I
might end up with the final 32k string segment holding only a puny
little 2-byte string, hogging all that 32k of memory?
 
>String segments are dynamically allocated, as they are needed.
 
So a new string segment would take away another 32k (or whatever
$STRING is set to) of free memory from the far heap, or however much
free memory is left if it's less than 32k?
 
>The size of a string segment defaults to 32K, but you can adjust
>it using the $STRING metacommand. String segments only hold
>variable length string data, no numeric data. They are in the
>far heap.
 
So the rest of the far heap holds everything that string segments and
DGROUP will not?
 
>Since a static variable is known at compile time, it's actual
>value is stored in the EXE file at compile time. At run time,
>the value is stored in DGROUP.
 
>Dynamic variables are stored in the far heap. Local
>variables are stored on the stack.
 
Thanks! I understand more now than I did before.
 
What happens when a (hypothetically) s$ contains "hello" and starts at
position 10 in a string segment, then another string variable starts
at position 15, right after "hello", but then s$ changes to "hello
world!"? Would s$ have to move to the "end of the line" of the
variables in that segment to accomodate the larger string? What
happens to that 5-byte (plus overhead?) space it left behind? If
another string variable is created and less than 5 bytes, will it hop
in that empty space instead of jumping on the end of the line of
strings, to conserve space?
 
>Does PB35 allow you to put variable length string data in EMS?
 
No. Quoting PB:
 
"A VIRTUAL array is another extension of the DYNAMIC type. Memory is
allocated at run time, and it may use any amount of available EMS
memory.  You must choose VIRTUAL allocation explicitly with
DIM VIRTUAL.  VIRTUAL arrays support array bounds within the long
integer range.  All data for VIRTUAL arrays is stored in EMS memory.
The FRE(-11) function can be used to determine if enough EMS memory
is available for allocation.
 
Note:  Dynamic strings and Flex strings are not supported in
       VIRTUAL arrays."
 
*** QwkNews (tm) v2.1
 * [TN71] Internet Newsgroup: alt.lang.powerbasic
--- GEcho 1.20/Pro
---------------
* Origin: Toast House Remote (1:100/561)

SOURCE: echomail via exec-pc

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.