program calling with BS2SX, BS2E and BS2P

Archiver

Hi Tracy,

I am not planning any recursive function, I merely wanted to make clear that
a multilevel
stack offers such a possibility, which is nice.

Now regarding the local variable definitions.
I tend to agree with you. Your scheme allows for precise definitions while
the
compiler does the checking. There are however also other considerations.
When I program, variables appear and disappear as the program develops and
code changes.
For local variables, that I will only use inside a gosub, I want their
declarations also
to appear inside the gosub. Because for local variables ALWAYS the last
bytes of variable
ram are used (in the presented scheme) I believe it is wise to have them
fixed to those
locations. Your remark not having nibbles or bits does not hold. I use the
same technique
you use for your definitions (using modifiers). For example

somegosub:
gosub PushLocal
x var B25
y var B24
flag var x.bit7 'local bit variable
loop var y.lownib 'local nibble variable
'code here
goto PopLocal

Because the local variables are fixed, any inserted new global variable or
redefinition of
variables has no repercussions for a subroutine that uses local variables.
Especially when I haven't been concerned with some program for months, I
don't recall
the use of possible aliases. Local variables might help reduce maintenance
time.

I do however agree with your scheme first to define words, and then define
bytes as parts
of those words, define nibbles etc.
This helps to define a clear border between global variable space and local
variable space.
If you were to define lets say the last 5 words to be local5 (W9) to local1
(W13) then
the above variables x and y could be defined using local1. Then our schemes
become the same.

Finally, a word on the reduced pushlocal and poplocal subroutines.
Well done, those routines occupy just 60 bytes as where my routines occupied
141 bytes
(without using variables though).

PushLocal:
for X=0 to 9
put stackpointer-X,B16(X) ' implied array
next
stackPointer=StackPointer-10
return

PopLocal:
for X=1 to 10
get stackpointer+X,B16(10-X) ' implied array
next
stackPointer=stackPointer+10
return

I wondered how much extra code would be generated if I added a request
variable.

Request var byte

request=10 before each gosub PushLocal (gives 3 bytes overhead)
request=10 before each gosub PopLocal (gives 3 bytes overhead)

PushLocal:
for X=0 to request-1
put stackpointer-X,B0(25-X) ' implied array
next 'put B25 first, B16 last (for request=10)
stackPointer=StackPointer-request
return

PopLocal:
for X=1 to request
get stackpointer+X,B0(25-request+X) ' implied array
next 'get B16 first, B25 last (for request=10)
stackPointer=stackPointer+request
return

These routines occupy 68 bytes and allow me to request as little local
variable space
as I need, leaving as much stackspace as possible, which is a BIG plus. Well
worth the
extra 8 bytes I think. The variables request and x have to defined outside
the maximum
local variable space for PopLocal to function (if not, either or both may be
overwritten
by poplocal).

My suggestion:

system1 var word
system2 var word
TargetID var system1.highbyte
StackPointer var system1.lowbyte
LocalRequest var system2.highbyte 'for request in the above routines
LocalCount var system2.lowbyte 'for x in the above routines

The above variables have to be defined first in a program that uses the
stack.
Be aware that the variables LocalRequest and LocalCount might change during
a program
call or calling a gosub from a gosub. For the LocalCount this does not
matter as it is
used by a for-next loop. For the LocalRequest this could mean that the stack
could get
corrupted when calling PopLocal upon return. It is therefore advisable to
put a
LocalRequest= statement before each gosub PushLocal AND before each gosub
PopLocal statement
to avoid unexpected errors.

This creates 6 bytes of overhead per gosub that uses local variables. Given
the space
difference between my former routines (141 bytes) and these new ones (68
bytes) I have
(141-68)/6=12 subroutines with local variables (per program) before these
new routines
create more overhead than my former routines that did not use variables. I
don't think
I will get to that amount often.


Let me know what you think of those last adaptations.

Greetings, peter
Any more suggestions are welcome.