Hi
clovepower!
clovepower wrote: ↑Thu Jul 11, 2024 6:38 am
Unfortunately, I think the fix introduced another issue
For that matter I fear he has introduced more than one. But I think that, in the end, this is a good thing: because it allowed me to see that there was one basic thing that wasn't right.
In order to better explain the complexity of the fix I must introduce a brief explanation, that is, how
ugBASIC manages calculations without using the stack. In a nutshell: the compiler translates every calculation that can be understood as dynamic into a static calculation, as much as possible. A dynamic calculation is a calculation in which, at the time of compilation, the result is not known. A static calculation is just the opposite. The advantage of static calculations is that it is not necessary to have a stack (i.e. a "dynamic" structure) and, furthermore, that all instructions are inherent to the calculation itself. There are, so to speak, no "service" instructions. Another advantage, in the end, is that it is possible to optimize the generated code, removing useless instructions (even if sometimes a little too much, as happened with one of the latest bugs).
Now, given an instruction:
The
bottom,
top and
step variables must be calculated dynamically and valued when compared with the
var variable. To do this you would need to have a stack, where you can manipulate the value of those variables. This in 8-bit processors is very slow, and it would force us not to allow entering the middle of a
FOR or exiting it, which standard BASIC allows.
To avoid this, I fixed
ugBASIC so that it statically generates the code that calculates these variables and which will therefore be recalled (recalculated) at every cycle. Previously this was not done and the value was calculated at the input of
FOR...NEXT was therefore used. Hence the further bug. Obviously I had to implement this mechanism also for a possible
FOR within a
PARALLEL PROCEDURE, with the
bottom,
top and
step variables are declined independently for each thread.
In this evening's COLDFIX the problem has been fixed, and the program you wrote works correctly, both with
OPTION TYPE NARROW and without.
