OR
rjo__
Posts: 2,114
in Propeller 2
I'm not arguing for any further expansion of the instruction set... I'm just trying to figure out how to do this with the current instruction set.
let's say that I have two different cogs interested in testing and then writing to two different bits of the same byte in hub memory...
at nearly the same time... they are contending cogs. If each cog operates on its bit of interest and then writes the result back... one of the cog's bits is going to be overwritten.
It would be handy if a Cog could issue a directive to OR a hub byte rather than simply writing to it... but we can't and we don't want Chip to add the logic for reasons that we all know and Ken can easily explain:)
So... can the first cog that has access to a hub byte... lock it for reading and writing until it is done... after which the other Cog can access it? How?
let's say that I have two different cogs interested in testing and then writing to two different bits of the same byte in hub memory...
at nearly the same time... they are contending cogs. If each cog operates on its bit of interest and then writes the result back... one of the cog's bits is going to be overwritten.
It would be handy if a Cog could issue a directive to OR a hub byte rather than simply writing to it... but we can't and we don't want Chip to add the logic for reasons that we all know and Ken can easily explain:)
So... can the first cog that has access to a hub byte... lock it for reading and writing until it is done... after which the other Cog can access it? How?
Comments
It may be quicker and easier to keep your bits in separate bytes so they are individually updated atomically and OR them to together when you want to use them.
The lock/semaphore bit statuses and transitions are also monitored by each COG as events, so you can POLL AND WAIT on them like the other events and also register an ISR to handle an interrupt caused by a lock transition.
BOTH cogs have to agree on lock number, checking/setting and releasing the lock for each access.
the point is that a normal read or write is atomic. But if you read, modify and write back you need 3 instructions and are not atomic anymore.
Therefore the locks. They basically provide you with one bit changed and the old value in one instruction to assure no other cog can do it at the same time.
But using locks is cooperative, so nothing hinders any cog to write over that memory location(s) you want to share.
Enjoy!
Mike
Well... there is more than one way to do it. I'll just do it another way:)
In the past, I know that at one step in the process, limiting the domain caused noise in intermediate results... which translated to less density in the final result. Previously, I experimented with isolated domains simply to speed up the process... to give the processor exponentially less to think about. Trading time for fidelity.
This is all about differential analysis. So, when you blindly isolate domains, you have no concept what you are doing to the differentials at the borders of your domain.
I am going to be testing some new general approaches to dealing with both the differentials and the noise. So, I really can't anticipate the final impact. That is the really fun and exciting stuff to me... we are all a little different. This kind of stuff I really like.
Will be looking forward to your adventures.