Re: BASIC OS for the PC

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 list