[Coco] Basic09 local variable storage

[Wayne Campbell]

----- Original Message ----- 
From: "CoCo Mongrel" <cocomongrel at googlemail.com>
To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
Sent: Tuesday, January 26, 2010 9:22 AM
Subject: [Coco] Basic09 local variable storage


> Hey everybody!
>
> So variables are local to procedures in Basic09, right?  Does that mean 
> that
> the storage is allocated dynamically?  If I have a couple procedures that
> are called at different times with their own local variables, could 
> Basic09
> reuse the same memory for local variables?
>

Variables are local to procedures, but they are not allocated dynamically. A 
procedure exists within memory until it's link count becomes 0. It's data 
allocation exists as long as the procedure is executing. The system 
determines what memory is baing allocated, so it's more of a blind draw as 
to whether the exact same memory will be used for either procedure.

> procedure main
> dim zigfoo:integer
>
> zigfoo:=0
> run dothing1(zigfoo)
> run dothing2(zigfoo)
> end
>
> procedure dothing1
> param zigfoo:integer
>
> for x = 1 to 100
> zigfoo:=zigfoo+x
> next x
> end
>
> procedure dothing2
> param zigfoo:integer
>
> for x:= 1 to 100
> print zigfoo
> next x
> end
>
> The undeclared 'x' variables in each procedure are 'automatic' INTEGERs, 
> is
> that right?  Should I worry about the storage for them?  Would it use less
> memory to declare an 'x' in the main procedure and pass it to the
> subprocedures by reference, or does Basic09 allocate the memory 
> dynamically
> for each procedure call?  I'm not asking whether passing 'x' as a 
> parameter
> is the right thing to do from the perspective of structured programming,
> just trying to understand how Basic09 allocates memory for variables.
>

No. There are only 2 data types that can be declared by use, REAL and 
STRING. Reals are any variable name NOT declared in a DIM statement that 
DOES NOT HAVE a $ as the last character of the name. Strings are any 
variable NOT declared in a DIM statement that HAS a $ as the last character 
of the name. These string variables have a length of 32 characters, the 
default length of strings.

Using undimmed variables in FOR/NEXT loops has consequences. FOR/NEXT loops 
occur in 2 types, INTEGER and REAL. In both cases, the variable used in the 
FOR statement, has an additional allocation of the same size as the variable 
used in the FOR. This allocation is pointed to by the TO keyword. The field 
following TO can be a variable or a value. The value, or the value of the 
variable, is stored at the address pointed to by TO. In data memory, this 
looks like this (assuming x occurs at data memory offset 003D, and is a 
INTEGER):

FOR x:=1 TO 10

13 81 003D 8D 01 46 003F 8D 0A

13 is the FOR token
81 says x is a INTEGER
003D is the address of x
8D says value is a BYTE
01 is the value
46 it the TO token
003F is where TO points to
8D says value is a BYTE
0A is the value

In the data allocation:

003D 01
003F 0A

The INTEGER version of FOR/NEXT is much faster than the REAL version. You 
should use it unless you must use the REAL version.

Passing parameters is something entirely different. If you pass x as a 
parameter, the called procedures still retains the memory allocation. The 
called procedure does not allocate memory for the parameter. However, if a 
parameter is passed by value, then extra memory allocation occurs. The value 
passed is placed in temorary memory in the calling procedure until the 
called procedure ends.

Wayne

> CoCoMongrel
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco