On Wed, Dec 21, 2016 at 08:08:24PM -0500, Ethan Dicks wrote: >In the case of BASIC, there are no objects and no calls to malloc(). >What is recovered is formerly-used string space. If you say A$="foo" >and later say A$="bar", the string storage just grows downward, leaving >both 'foo' and 'bar' in memory, but only one live pointer. Sorry for nitpicking, but I was under the impression that when strings are assigned to literals in the BASIC code, the pointers would point directly to the BASIC program area: 10 A$="FOO":A$="BAR" RUN I expect this to not allocate any other storage than the descriptor for A$, which would first point to the "FOO" and then to the "BAR" in the BASIC program memory. This could be one of the reasons why NEW or entering a line number clears all variables. The string length would be set so that the trailing closing quote is not included. Strings clearly are not NUL-terminated in BASIC, because otherwise stuff like A$=CHR$(0) would not work. I guess that in direct mode (entering the above without the line number), storage for both strings should be allocated. Unfortunately I was unable to test this, because x64 crashes in my Debian GNU/Linux unstable system on startup, in XQueryExtension() that was called by XRRQueryExtension(). I think that I had chosen Wayland in the GNOME Session Manager. For some reason, keyboard input did not work with other choices when I installed the system a few weeks ago. >In Commodore BASIC, integers and floats are never given back once >defined, so the only way to free that memory is CLR or RUN which resets >all the pointers to the top of RAM, giving back all that space at once >(and that only takes a handful of cycles). On a somewhat related note, I wonder if anyone else has run into the following: 1. Hit the STOP key to interrupt the execution of a BASIC program. 2. The BASIC interpreter reports the line number where it was interrupted. 3. Input some invalid statement (for example, trigger a syntax error) 4. CONT (will be refused with an error, due to step 3) 5. GOTO (The line number in step 2) The execution appears to continue just fine with the GOTO statement, with all variables intact. Why was the CONT refused? What would the GOTO do differently from the CONT if we assume that the line consists of a single statement? Another fun phenomenon is the LOAD statement. When used in a program, it seems to preserve the variables, but it will apparently cause the equivalent of GOTO to the first program line, even when the LOADed program did not replace the currently executing one. You all probably have seen a loader written in BASIC that uses a status variable like this: 10 IF A=0 THEN A=1:LOAD "PART1.PRG",8,1 20 IF A=1 THEN A=2:LOAD "PART2.PRG",8,1 30 IF A=2 THEN SYS49152 I wonder what would happen if you did some string manipulation and then loaded a program that would overwrite some of the string storage. In the best case, upon completing the LOAD statement, the BASIC interpreter would report ?OUT OF MEMORY ERROR because the end of the BASIC program area would now exceed the start of the string space. Best regards, Marko Message was sent through the cbm-hackers mailing listReceived on 2016-12-22 08:00:02
Archive generated by hypermail 2.2.0.