Mickster Posts: 2,392
Trying to understand the mechanics of this thing.
Testing FlexBasic on a P1-Quickstart for the first time (nice )
Running the supplied Blink2.bas which throws one of the blink procedures into a cog and so requires a
dim shared cpustack(8)
Then I added another blink procedure in another cog and I created another stack
dim shared cpustack2(8)
But the only way for this to run:
var x = cpu(blinker(LED1, 500), @cpustack(0))
var y = cpu(blinker(LED3, 125), @cpustack2(1))
I can't use "0" as the start of stack memory for the extra cog.
What is actually happening here?
Still haven't figured out how to list code in this thing so...bitmap.
I’m not near my P2 stuff at the moment, but a couple of things come to mind that might help.
1). Add OPTION EXPLICIT to force formal var declaration.
2). Increase HEAPSIZE to 512 or so.
3). Increase each of the stacks to 32 or so. Elbow room!
You can type 3 backticks on their own line to make the forum start and stop displaying code sections.
Maybe this helps.
Ah-ha...wasn't doing the backticks on their own line thing
Bit puzzled as to why that stuff is necessary(?)
This is a simple P1 program in PropBasic.
You say you "can't" use 1; what are the symptoms? That the other LED doesn't blink? If so the problem is likely that the stack size is too small (which is my fault, I should have had a bigger one in a demo). Try increasing it to 16 or even 32.
As for why the stack declaration is even necessary: FlexBasic has a lot of features (e.g. recursion) that rely on a stack being present. PropBasic is great for what it is, but it's a much more restricted subset of BASIC.
As shown, all 3 LEDs works as intended but if I set @cpustack2(1) to @cpustack2(0), as-is the other stack (@cpustack(0)) then none of the 2 cogs run
Increasing the stack (16) does make it work with @cpustack(0) and @cpustack2(0)
I found two examples of the demo, one in a document (manual?) and the other as a source file. One had a stack of 8 and the other had a stack of 32.
None of this is an issue, per se.
The only time PropBASIC uses a stack is when you generate LMM (Large Memory Model) code.
It uses it for subroutine call return addresses only.
So, yeah, PropBASIC does not support recursion.
Stacks too short. If it works with stack2(1) , try dim cpustack(9)
Yes, actually making it work is not the problem and I understand the purpose of the stack. What is not clear is why there are examples that show "(1)" and others that show "(0)"
Just trying to understand what is physically happening.
There may be some examples that date back to when the default array base was 1 (so the first element of array A was A(1)). Nowadays the default is 0 (so A(0) is the first element), but this is settable with
OPTION BASE 1or by declaring the array with an explicit lower bound like
DIM A(1 to 10) as INTEGER.
I figured it was something like that after reading an old thread about what should be the default base.