Technical Rambling: variable allocation & scope

[Dan Cook]

This is mostly a note for my reflection, but concerning variable
allocation & it's affect on scope in more detail:

The current method of variable allocation demands extra space be
provided within a program for variable allocation. The only
efficiency is that local variables share addresses (overlap) with
other local vars which never "coexist." That is, if function-A and
function-B are never called from each other, and because local vars by
nature initially contain garbage values every time their parent
function is invoked, the A-vars and the B-vars can share space in
memory without any harm. Similarly, once a local variable has had its
last use, their space in the program can be recycled for other vars to
use. This intricate system results in the most compact form of STATIC
variable allocation possible ... until code mutation is brought into
account:

Code mutation entails the allocation of a variable WITHIN an
instruction that uses that data. Because no data-tables would be
needed for (byte and word) variables, program size does not increase A
SHRED as more variables are added to the code. In fact, LESS space is
required for the use of variables allocated within the code than for
variables with an assumed allocation (i.e. byte a @ "someAddress").
This is because (generally speaking) an instruction with raw data is
smaller and faster than an instruction with a reference to data in it.

Almost all scoping issues immediately disappear because there is no
need to have variables overlap in memory. In fact, it is MORE
efficient in this scenario NOT to recycle allocation space because
each new variable means another simplified instruction (raw data vs a
reference). Allocation would no longer depend on which function calls
which.

Unfortunately, Arrays (and strings) are to large to fit in a single
instruction and are always used in reference anyway. However, when an
array does not require initial data, an address-space in a "safe RAM"
area outside of the program can be reserved for that array. This
automatically applies to all arrays that are local variables, but also
to global arrays which have no initial data specified. For this to
work though, there must be a way to indicate in the source-code where
any "safe-RAM" areas are; otherwise allocation defaults to additional
storage space within the program.

Concerning recursion:

This new method of allocation still does not preserve each "instance"
of variables within a recursive function. A simple solution involves
a keyword which states that a function is or is not recursive, and/or
that specific variables within a function are / are not / are
otherwise. The compiler then inserts commands to push recursive/
dynamic values onto the stack before a recursive call and pop them
back afterward. But the requirement of such a keyword could be
annoying, since other languages allow recursion automatically; and
Antidisassemblage could do the same. It is not difficult to know
which functions are recursive. The down-side is that every value that
does not need to be preserved would also be preserved, wasting time
and space. Perhaps a combination: allow the keywords, but also have
automatic detection. With this automatic preservation of variables,
the compiler could also omit variables which are not instantiated
before a given recursive-call, or which have their last use before the
call, or which do not "exist" within the scope of the call. This
would require tracing of vars and contexts, but much less than the
compiler currently does anyway. I gather from my own on-the-fly logic
just now that smart automatic recursion would be all that is needed.
The only great inefficiency that I see is when a large array needs to
be preserved; but in my opinion that is a matter of poor coding, as
any efficient array manipulating function should be using references
to outside arrays. This issue is similar to the fact that
Antidisassemblage does NOT copy whole arrays when they are passed to
and from a function or even assigned one to another in code. (On a
side note, should that be changed for convenience & intuitive reasons,
despite how inefficient that is? How does C/C++ handle such things?)