cog exec bootstrap code
Seairth
Posts: 2,474
in Propeller 2
I keep staring that the 3-4 lines of code necessary to set up cog exec mode. And I keep thinking that this looks similar to necessity on the P1 to have a SPIN bootstrap to do something similar. Except, now, you have to do it for every single cog you want to start in cog exec mode, not just the first one.
I know. It's not that much code. But it just doesn't look all that elegant. Especially for something that you'd expect to be able to do more directly (i.e. be able to coginit another cog directly to cog exec mode). But, it seems that there are just too many pieces of information to provide:
* Location of instructions in hub memory
* Number of instructions to copy to cog memory
* Offset in cog memory to start copying at
* Offset in cog memory of first instruction to execute
In the P1, this was easy. The last three of those items were hardwired. In the P2, coginit already takes care of the first item. So, suppose that, like P1, you hardwired the last two parameters to 32 (first long after the special registers). Then, have S format as follows:
%xxcccccc_ccccnnnn_nnnnnnnn_nnnnnnnn
xx : ignore
cccccccccc : number of longs to copy (covers lut memory as well)
nnnnnnnnnnnnnnnnnnnn : init address
* If the C field is non-zero, coginit would copy those longs start at the N address into cog memory (starting at #8), then JMP #32.
* If the C field is zero, then coginit acts exactly like it does now.
To support this in code, you really only need AUGS. However, the assembler could provide a second form for coginit:
coginit D/#, #, #
The third parameter is the count field. The generated code would really just be an AUGS/COGINIT.
One minor improvement would be to use the two remaining bits in S to indicate whether to copy to cog memory or lut memory and whether to start in cog exec mode or lut exec mode.
In the end, this gives a simple P1-style initialization when that's all you want. But at the same time, it leaves coginit exactly as generic and flexible as it currently is so that you can do much more advanced cog initialization you you need it.
Anyhow, just something to think about...
I know. It's not that much code. But it just doesn't look all that elegant. Especially for something that you'd expect to be able to do more directly (i.e. be able to coginit another cog directly to cog exec mode). But, it seems that there are just too many pieces of information to provide:
* Location of instructions in hub memory
* Number of instructions to copy to cog memory
* Offset in cog memory to start copying at
* Offset in cog memory of first instruction to execute
In the P1, this was easy. The last three of those items were hardwired. In the P2, coginit already takes care of the first item. So, suppose that, like P1, you hardwired the last two parameters to 32 (first long after the special registers). Then, have S format as follows:
%xxcccccc_ccccnnnn_nnnnnnnn_nnnnnnnn
xx : ignore
cccccccccc : number of longs to copy (covers lut memory as well)
nnnnnnnnnnnnnnnnnnnn : init address
* If the C field is non-zero, coginit would copy those longs start at the N address into cog memory (starting at #8), then JMP #32.
* If the C field is zero, then coginit acts exactly like it does now.
To support this in code, you really only need AUGS. However, the assembler could provide a second form for coginit:
coginit D/#, #, #
The third parameter is the count field. The generated code would really just be an AUGS/COGINIT.
One minor improvement would be to use the two remaining bits in S to indicate whether to copy to cog memory or lut memory and whether to start in cog exec mode or lut exec mode.
In the end, this gives a simple P1-style initialization when that's all you want. But at the same time, it leaves coginit exactly as generic and flexible as it currently is so that you can do much more advanced cog initialization you you need it.
Anyhow, just something to think about...
Comments
But for now, I am way more interested in getting a P2 FPGA that I can try.
It's true that we could make a callable routine deposited by the ROM, which you just call and it loads the code immediately after your call and then jumps to the cog start address, which would have to be implied as register $008 (address $00020).
Man, this address stuff is wearisome on its own. We have a few big things that need untangling, somehow, to get us on the free-and-easy track.