From: brianm@ims.com (Brian McLaughlin)
Subject: Re: memory questions
 
dnskiesling@telis.org (David Kiesling) wrote:
|>
|> >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?
 
Assembly language allows you to manipulate this behavior.
I am not well-informed about C -- it may allow you to
designate the memory footprint of your program, too.
About other compilers, I don't know. DOS makes allowance
for this option, but I don't think many compilers take
advantage of it.
 
|> >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.
 
Correct. Static arrays only in DGROUP. Dynamic arrays
in the far heap.
 
|> How large is DGROUP? If a static array and the stack together equaled
|> more than 64k, then what? Does it automatically create another
|> segment?
 
There is only one DGROUP segment, and it is limited
to a maximum of 64K. If a static array and the stack
together equalled more than 64K, you should get an error
message. If you don't, turn on ALL error checking in PB.
That should do it.
 
The ONLY advantage of using a static array is that you *may*
get a slight speed increase in accessing the data. Overall,
dynanmic is the way to go. Just pop a $DYNAMIC at the top
of your code and forget about it.
 
|> 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?
 
Yes. Exactly.
 
|> >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?
 
Yes. But, if the amount of free memory is less than the string segment
size, I *think* you get a run time error. Not certain on that one.
 
|> So the rest of the far heap holds everything that string segments and
|> DGROUP will not?
 
That pretty much leaves just dynamic arrays, since DGROUP
and string segments hold everything else.
 
|> 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?
 
Yes. And, if there weren't room in the current string segment,
then a new one would be created to hold "hello world!".
 
|> 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?
 
Yes. As I understand it, PB will move the 5-byte string into
the "first fit" space it finds. If there is a better fit later
in line, PB won't look for it, or use it, since that would slow
things down. If there is more than one string segment, all of
them are searched for the "first fit", in the order they were
created, as I understand it. (The far string engine is not
documented. Some of the details I picked up from Dave Navarro,
who was answering someone else's questions on the CIS forum.)
 
--
Brian McLaughlin, Technical Writer  |"Thanks to the Internet, misinformation
 
Continued with next message...
 
*** QwkNews (tm) v2.1
 * [TN71] Internet Newsgroup: alt.lang.powerbasic
--- GEcho 1.20/Pro
---------------