🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.atari.st
Article #37295

Re: GFA BASIC Bug (or feature?)

#37295
From: Kevin Clendenien
Date: Wed, 22 Mar 1989 05:38
49 lines
3529 bytes
In article <1217@ns.UUCP> logajan@ns.UUCP (John Logajan) writes:
>Thanks entirely to Hans-Ch. Eckert of Berlin, West Germany for solving
>this "problem" I had with GFA Basic!
>
>To wit: GFA BASIC apparently moves valid strings around when it does
>garbage collection.  Thus if you poke, or otherwise put, a machine
>language routine in a string, it will from time to time, be moved
>around.  Eckert's fix is to get the new VARPTR(X$) value *EVERY* time
>the machine language routine is called.
>
>My accidental fix (because I didn't understand the problem) was to move
>the machine language routine into an integer array. (Gee, I hope they
>don't do garbage collections on arrays????)
>
[stuff deleted]
>- John M. Logajan @ Network Systems; 7600 Boone Ave; Brooklyn Park, MN 55428  -
>- ...rutgers!umn-cs!ns!logajan / logajan@ns.network.com / john@logajan.mn.org -
This is definately not a bug.  That is the very nature of garbage collection.
Strings are not like other variable types by the fact that they can be
variable length.  Integer, and floating point variables are always the same
size, so if you replace the variable I% with a new value, the new value
is guaranteed to fit in the same space that the old value fit.  But what
happens if S$ = "Hello there", and then you replace S$ with "1234567890123"?
Well, the new value is too large to fit where the old value was, so BASIC
puts it somewhere else in memory, effectively losing the memory that used
to hold "Hello there".  All of this old space is recovered during
Garbage Collection.  BASIC moves all of the strings around, so that it
will end up with an area of memory that has contiguous addresses, thereby
guaranteeing that a new large string will be able to fit.  I'm not completely
familiar with how GFA BASIC handles strings, but if your know the length
of your assembly language program, and you place a statement like this:
S$ = SPACE$(123)
as the first line in your program, where 123 is replaced with the length
of your assembly language program, then it is possible that S$ will 
never be moved during Garbage Collection, since it was the first string
to be defined.  Most BASICs build their variable tables on the basis
of the order that the variables are defined.  Thus, since S$ was defined
before any other strings, it will have space reserved for it first, and
also, when Garbage Collection comes around, S$ will be checked first to
see if its space should be released, and since it will still be marked
as being used, it shouldn't be moved.  The building of variable tables
on a first defined, first reserved basis is also the reason that you
should define the variables that are accessed most in your program, first.
This means that when BASIC has to look up the value of a variable, it
will find the most used ones the quickest, since they'll be in the 
beginning of the table.
-------------------------------------------------------------------------
sl161011@silver.UUCP                                     Kevin Clendenien
-------------------------------------------------------------------------
Technical Details
Message-ID: <3497@silver.bacs.indiana.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watmath!iuvax!silver!sl161011
References: <1217@ns.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watmath!iuvax!silver!sl161011
From: sl161011@silver.bacs.indiana.edu (Kevin Clendenien)
Newsgroups: comp.sys.atari.st
Subject: Re: GFA BASIC Bug (or feature?)
Message-ID: <3497@silver.bacs.indiana.edu>
Date: 22 Mar 89 05:38:54 GMT
References: <1217@ns.UUCP>
Reply-To: sl161011@silver.UUCP (Kevin Clendenien)
Organization: Indiana University BACS, Bloomington
Lines: 49