flexBASIC use of COG(cpu) P2
Rsadeika
Posts: 3,824
in Propeller 2
I have not used flexBASIC in a while, so I must be messing something up.
In the program below, I am expecting to see a 3 in the terminal, instead I am seeing 0.000. Am I using the cpu function incorrectly, or what. It seems like the called for COG is not working, or not being started.
Thanks
Ray
' solsta4.bas
'
' Oct 8, 2021
'' Comms
'' Variables
dim inBuff as string
dim tempf#
'tempf# = 123
'' Stack
' Stack for sensors COG
dim external_sensors(10)
'' Main
var b = cpu(external_sensors(),@external_sensors(1))
do
print tempf#
pausems 4000
loop
end
'' Subroutines
' external_sensors() COG (cpu)
sub exiernal_sensors()
do
tempf# = 1+2
pausems 1000
''''''''''''''''''''
loop
end sub
"/home/pi/flexprop//bin/flexspin" -2 -l --tabs=2 -D_BAUD=230400 -O1 -I "/home/pi/flexprop/include" "/home/pi/programs/flexprop/flexbasic/solsta4/solsta4.bas" Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2021 Total Spectrum Software Inc. Version 5.9.3-HEAD-v5.9.3 Compiled on: Oct 7 2021 solsta4.bas |-SmartSerial.spin fmt.c ieee32.c solsta4.p2asm Done. Program size is 10152 bytes Finished at Sat Oct 9 07:44:52 2021 /etc/alternatives/x-terminal-emulator -T "Propeller Output -p /dev/ttyUSB0" -e "/home/pi/flexprop//bin/loadp2" -p /dev/ttyUSB0 -b230400 "/home/pi/programs/flexprop/flexbasic/solsta4/solsta4.binary" "-9/home/pi/programs/flexprop/flexbasic/solsta4" -k
Comments
You've got a subroutine called "exiernal_sensors()" (note the third letter is "i" and not "t"), and a global variable "external_sensors()" (presumably meant to be a stack). But in the CPU you're invoking the version with a "t" (which is an array) rather than the version with an "i" (the subroutine).
I'm actually a little surprised that the CPU call didn't produce an error. That may be a bug in flexspin, but I'll have to think about it (it may be that there are times when e.g. you want to produce machine code into an array and execute that, and it could be that the compiler thinks you're trying to do that).
I went ahead and fixed the name of the subroutine and compiled, I got the following: error: Redefining external_sensors as a function
But when I changed 'dim external_sensors(10)' to 'dim external_sens(10)' and changed 'var b = cpu(external_sensors(),@external_sensors(1)) to 'var b = cpu(external_sensors(),@external_sens(1))' then it compiled without errors. What was redefining the subroutine to a function?
Ray
' solsta4.bas ' ' Oct 8, 2021 '' Comms '' Variables dim inBuff as string dim tempf# 'tempf# = 123 '' Stack ' Stack for sensors COG dim external_sensors(10) '' Main var b = cpu(external_sensors(),@external_sensors(1)) do print tempf# pausems 4000 loop end '' Subroutines ' external_sensors() COG (cpu) sub external_sensors() do tempf# = 1+2 pausems 1000 '''''''''''''''''''' loop end subYou had an array named "external_sensors" (created by
dim external_sensors(10)) and then you tried to create a function named "external_sensors" (sub external_sensors()), so you were redefining the symbol "external_sensors".Ray: this line is the redef that the compiler is objecting to:
You cant have a function/sub with the same name as a variable, constant or class.
Since the word 'stack' is not a keyword, to get around the previous confusion, I guess I should start using names like 'dim external_sensors_stack(10)'. So where does the keyword 'function' fit in, if you can change a sub to a function by using the dim designation.
Maybe for defining a stack, the word stack should be a keyword and the you could use something like 'stack external_sensors(10)' without getting into trouble.
Ray
I'm curious about your mindset in needing to give two or more different things the same name?
There's a unique issue with Basic in that the syntax for accessing an array and the syntax for passing a value into a function/subroutine are the same. They both use parenthesis ( ).
But at the same time, what is the value to the programmer to have two things named Bob, and then getting angry at the computer for thinking you're referring to the other Bob?
My thinking is, the use of stack, since I could have seven different stacks going on, I would like to keep them somewhat differentiating, but tied to the relevant COG. So, I guess I will just stick to the dim stack_xxxxx() format to keep things clear, for me. I guess this way I will not get angry at the computer LOL.
Ray
That what I do. Something like this:
dim retval as ulong dim STACK_BlinkLight(64) as ulong retval = CPU(BlinkLight(), @STACK_BlinkLight(1)) print "BlinkLight running on cog: ";retval SUB BlinkLight() do pintoggle(thePin) pauseMs(1000) loop END SUBYou don't change a SUB to a FUNCTION per se.
A SUB does something, then returns to the caller (usually), but does not return a value.
A FUNCTION is just like a SUB except it does return a value(s) to the caller.
I struggled with this a bit too. It helps to recall that the stack is just a chunk of memory reserved (sort of "DIM'd", if you will) for the routine called by CPU. I guess STACK could be an alias for DIM, but that seems redundant. DIM reserves memory just as well, even if semantically it doesn't seem "quite right" at first glance. In my case, DIM grew on me, and now it makes sense to me in that context.
The compiler sometimes uses the word "function" in messages about subroutines. The reason is that a subroutine really is a function, just one that returns no values.
The root problem remains that you were trying to use the same name for two different things (the array stack and the subroutine). That can't work.
Now I get the difference or non difference. I thought that stack was some mysterious function, so stack and dim call for an array, in other words, stack is just an array, to be defined by the dim function. I guess it is 'dim stack_xxxx()' from now on.
Ray
I guess I need an explanation as to how the stack works in reference to flexBASIC.
When you set up an array using 'dim stack_xxx(10)' , this reserves some space, in this case 10 spaces.
b = CPU(BlinkLight(), stack_xxx(1)), what does the 1 get you? Why don't you use the 10, as it was called out? I thought that the stack was something that was built into the system. I guess I need a good explanation as how to best use this stack thing.
Ray
Maybe someone else can correct this if wrong, but here goes my understanding:
The “stack” being defined by DIM STACK_XXXX(10) AS ULONG is a reserved region consisting of ten unsigned longs. There is nothing special about this DIM. The declaration happens at the module level, so any SUB/FUNCTION in the module can “see” this array and read/write to it.
When you start a cog up with CPU(BLINKLIGHT(), STACK_XXXX(1)) , the hidden initialization code that spins up the cog wants to dedicate some stack space for the use of that cog. Where does it get this space? It doesnt want to guess, so it asks you where to supply it. So that “STACK_XXXX(1)” is how you tell it where to set its internal stack pointer when it gets spun-up. This should be a pointer to the first element of the array you DIM’d.
If you passed it “STACK_XXXX(10), then upon spin-up the cogs stack pointer would be at the very end of the region you DIM’d. In other words you would very shortly corrupt whatever was located in memory next to the STACK_XXXX(). You would “fall of the end of the stack” and into somebody elses code or data.
Its probably helpful to remember that all array references in FlexBASIC are not checked for being out of bounds. If you DIM an array of 10 ulongs and accidently write to array element 1000, Flex is perfectly happy to let you do this… and will silently giggle at you when it all comes crashing down.
Hope this helps a bit.
Thanks JRoark, that helps a bit, but I am still not clear as to what the COG(cpu) does with the stack(array). How do you the actual size of the array.
I keep thinking of a Forth stack, FIFO scenario. Not sure if this has muddled my thinking, in regards to flexBASIC.
Ray
Every time you call a function (or subroutine) the compiler has to push the current position, and the values of local variables, on to the stack so they can be restored when the function or subroutine finishes. So basically your stack has to have enough room for all of the local variables, plus compiler scratch space, for each function (or subroutine... please just append "or subroutine" to any more uses of "function" in my post
) that you call (and for the functions that they call, and so on). 10 longs is enough for a simple routine that doesn't call anything else. 256 longs is probably enough for most programs that don't use recursion.
Good news @Rsadeika I see that your experiences here have been noted by ersmith to make his flexbasic compiler a little bit better and its documentation clearer.