You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I first started programming TRSE I failed to understand why my code would sometimes not compile due to variables already being declared. It was always variables inside functions or procedures - and often my counters or "temp" / "counter" variables. As a main "back then" i386 programmer, i failed to understand the problem, until it was explained. But nevertheless, the problem fr me remains even to this day, and I have come to name my variables with their function/procedure names as prefixed.
To remedy this problem i propose implementing three levels of local variables.
Level 1: (default level for new projects)
Variables can only be declared in global space - perhaps even only one place (one var keyword). This codesamples will therefore result in a compiler-error:
procedure MyFunc(param1: byte);
var
x: byte;
begin
...
Whereas this will work just fine:
var x: byte;
procedure MyFunc(param1:byte)
begin
..
Parameters are counted as "local variables" in this instance, which means that this code, in Level 1, should fail:
var x: byte;
procedure MyFunc(x:byte)
begin
..
Level 2 (seems to be default for current projects)
Local variables are on compile-time prefixed with their function/procedure name and then included into the global space. This will cause local variables to use the same variables over and over, thus overwriting its own memory - only a problen on recursive function calling.
This procedure will therefore not yield the expected result, in Level2:
procedure WhatIsMyNumber(number:byte)
var
the_number : byte; // apriori as non-6502 coder, one would think this is unique to each call of this function.
begin
if (number = 0) then
begin
end else
begin
the_number := number;
WhatsIsMyNumber(number-1);
if (the_number <> number then) // this will be true
begin
// should not happen with "regular stack" - but it does with TRSE Level 2
end
end
end
WhatIsMyNumber(10);
..
Parameters are also prefixed which means this code in Level 2 will not fail:
var x: byte;
procedure MyFunc(x:byte)
begin
..
Level 3
Will by default work as level2, except it introduces the option to
procedure WhatsIsMyNumber(number:byte) stack
var
the_number:byte;
begin
if (number = 0 then)
begin
// done
end
else
begin
the_number := number;
WhatsIsMyNumber(number-1);
if (the_number <> number then) // this will be false
begin
// this will not happen
end
end
end
WhatIsMyNumber(10);
...
What will really happen here, is a userdefined stack will be utilized where each function/procedure contains a "chunk" of data - I will try to pseudo-code something here that might make sense:
@UserStack = $2000
@UserStackPointer = $2000
// compiler-time records
WhatIsMyNumber_record = record
number:byte;
the_number:byte;
end;
// variable which only exists for the purpose of illustration - it should probably "just" be UserStackPointer
var
CurrentRecordCall : WhatIsMyNumber = ^UserStackPointer;
// the function-call
UserStackPointer += sizeof(WhatIsMyNumber_record);
JSR WhatIsMyNumber
UserStackPointer -= sizeof(WhatIsMyNumber_record);
// the function itself
procedure WhatIsMyNumber()
var
number, the_number:byte;
begin
// here we unpack
number := CurrentRecordCall.number;
the_number := CurrentRecordCall.the_number;
optional: include a @UserStackMaxsize which guards against overflow, maybe even with a callback address, like so:
Where each stack-"push" will check if it overflows, and if that happens it will JSR to #MyFunc
The idea is just that of classes, chunks of data, pushed to the current userdefined stackpointer, then the pointer is moved forward, the procedure is called and the memory unrolled into local variables "as regular".
Level 3 will bes low and take a bunch of memory, but it will be entirely voluntarily.
Another option is to merge Level 2 and Level 3, but the explained Level 3 features here, only works when the keyword "stack" is appended to the function call, like this:
procedure WhatIsMyNumber() stack
var
number, the_number:byte;
begin
// will be stacked
The text was updated successfully, but these errors were encountered:
When I first started programming TRSE I failed to understand why my code would sometimes not compile due to variables already being declared. It was always variables inside functions or procedures - and often my counters or "temp" / "counter" variables. As a main "back then" i386 programmer, i failed to understand the problem, until it was explained. But nevertheless, the problem fr me remains even to this day, and I have come to name my variables with their function/procedure names as prefixed.
To remedy this problem i propose implementing three levels of local variables.
Level 1: (default level for new projects)
Variables can only be declared in global space - perhaps even only one place (one
var
keyword). This codesamples will therefore result in a compiler-error:Whereas this will work just fine:
Parameters are counted as "local variables" in this instance, which means that this code, in Level 1, should fail:
Level 2 (seems to be default for current projects)
Local variables are on compile-time prefixed with their function/procedure name and then included into the global space. This will cause local variables to use the same variables over and over, thus overwriting its own memory - only a problen on recursive function calling.
This procedure will therefore not yield the expected result, in Level2:
Parameters are also prefixed which means this code in Level 2 will not fail:
Level 3
Will by default work as level2, except it introduces the option to
What will really happen here, is a userdefined stack will be utilized where each function/procedure contains a "chunk" of data - I will try to pseudo-code something here that might make sense:
optional: include a
@UserStackMaxsize
which guards against overflow, maybe even with a callback address, like so:Where each stack-"push" will check if it overflows, and if that happens it will JSR to #MyFunc
The idea is just that of classes, chunks of data, pushed to the current userdefined stackpointer, then the pointer is moved forward, the procedure is called and the memory unrolled into local variables "as regular".
Level 3 will bes low and take a bunch of memory, but it will be entirely voluntarily.
Another option is to merge Level 2 and Level 3, but the explained Level 3 features here, only works when the keyword "stack" is appended to the function call, like this:
The text was updated successfully, but these errors were encountered: