Add SetDestination(), SetSource() to spin2?
Rayman
Posts: 15,793
Dealing with one assembly code that is being used twice in two different cogs.
To do this, need to modify the assembly before launching second cog.
Making it work so far, but wondering if it would be easier if there were a SetDestination() and SetSource() commands in Spin2 that would let one change the assembly in an easier and perhaps more clear manner.
Haven't thought it all through yet though...
Does this make sense?
Comments
Is this for things like sharing of pins between multiple cogs?
It's for modifying some parameters in assembly code to be launched into two different cogs...
@Rayman instead of using immediates you could use variables, and change the values of the variables in the DAT section before launching the code. Something like:
DAT mycode drvnot pinval waitx waitval jmp #mycode pinval long 0 waitval long 1 PUB main() pinval := 56 waitval := 20_000_000 coginit(16, @mycode, 0) waitms(1) pinval := 57 waitval := 5_000_000 coginit(16, @mycode, 0) repeat@ersmith True, but think that adds registers to the assembly, right? The assembly cog is very close to 100% register usage...
Yep, the DAT section acting as a common mailbox ... but only at startup, so then each instance takes it parameters one at a time.
I did a variation for the Fcached SD mode driver where the pasm fast copies (SETQ+RDLONG) the whole set of parameters from hubRAM to cogRAM as the first two instructions. Each one having its own hubRAM parameter set.
COGINIT could do similar by passing the parameters hubRAM address in PTRA.
I often do this in PASM (after active code, before res definitions):
...where 0-0 indicates the value needs to be set before the cog is launched, so I do this in Spin before coginit():
h_src := @inarray h_dst := @outarrayEasy peasy. If you want to launch that code into another cog, just change h_src and h_dst as required for that cog.
Yes, it can take more space if the constants are small (< 512). For bigger constants it doesn't matter.
You could use Spin2's bit manipulation directly on the instructions, like:
DAT mycode pinval drvnot #0 mywait waitx waitval jmp #mycode waitval long 1 PUB main() setdest(@pinval, 56) waitval := 20_000_000 coginit(16, @mycode, 0) waitms(1) setdest(@pinval, 57) waitval := 5_000_000 coginit(16, @mycode, 0) repeat PUB setsource(ptr, val) long[ptr].[8..0] := val PUB setdest(ptr, val) long[ptr].[17..9] := valSpin2 has bitfield access. No need to add an over-specific version of the same thing.
So just
and then
@ersmith Can't that just be part of Spin2 language?
Anything could be made part of the language, but it's a pretty niche use case (and easily written by anyone who knows assembly language, as I demonstrated). Moreover builtin functions take up space in the interpreter, so they should probably be added only when really necessary or when they'd be used in many different situations.
@ersmith ok, that’s a good argument.
This probably is a niche case…