logajan@ns.UUCP (John Logajan) (03/22/89)
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????)
GFA Basic Programming rule #978
1.) Either get the new pointer before each call to a machine-language
"string" or
2.) Place the mach-lang routine in a "fixed" location. (I would have
said in an integer array, but I have just raised doubts in my own
mind whether such arrays can be counted on not to hop around.)
--
- 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 -sl161011@silver.bacs.indiana.edu (Kevin Clendenien) (03/22/89)
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 -------------------------------------------------------------------------