CLIB COG and how to do a CMPEXCH?

ImageCraft

I was talking to someone about floating point code for the Prop and the thread in the forum about fast sqrt makes me thinking: we can put a bunch of library code in another COG and use a semaphore mechanism to activate it, e.g. that COG would be executing something like

forever
if (state == LIBCOG_START)
{
state = LIBCOG_BUSY
<invoke some function>
state = LIBCOG_FINISH
}

The function will be invoked by some sort of ID, probably a jump table index. "state" and parameters live in HUB RAM of course.

The library function mechanism for these functions then become

if (state == LIBCOG_IDLE)
{
state = LIBCOG_RESERVE
<write parameters and function code>
state = LIBCOG_START
while (state != LIBCOG_FINISH)
;
<get result>
state = LIBCOG_IDLE
}

A problem is implementing the equivalence of CMPEXCH using LOCKs to modify "state." Fro all you Propeller heads, any idea?

***
So at the cost of using another COG, we get full native speed on these functions.


***
As for the actual functions

I can think of
- low level FP primitives, pack, unpack, add, sub, etc.
- strcpy/memcpy etc.
- sqrt

I have yet to look at the sin/cos/trig support in the Propeller ROM, but we will probably put the wrapper functions there too.

Mike Green

The existing floating point library works that way although it doesn't use the LOCK instructions.· The I2C/SPI low level drivers used in FemtoBasic also work that way using a double long parameter in hub memory.· Have a look at them both.

ImageCraft

Thanks, it just occurs to me that the only critical operation is the library call to "reserve" the COG, i.e. then it can be handle by a simple LOCKSET and a LOCKCLR at the end after the COG finishes and the results are copied back.

Mike Green

Most synchronization across cogs does not need to use the LOCKxxx instructions. The reason to avoid them if not needed is that they're a limited resource (only 8 available) and you might need them for something else.

In the case of a library like this that might be used by any of several other cogs, you do need to use LOCKxxx.

ImageCraft

Exactly

Paul Baker

After more than two years of experience with the Propeller I have finally found an application which absolutely needs the locks. Im going to·refrain from going into details of what it is, but I will be releasing it when Im done. It requires multiple cogs accessing the same chip in an asynchronous manner, but because of the wired OR configuration they cannot access the device at the same time. At first I thought of having a device handler cog where all requests must go through, but that is a waste of a cog since it would just be a glorified switch. So locks it is. In the consumer producer model the only time semaphores/locks are needed is when there are multiple producers and/or consumers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.