[Coco] 6809 Test and Set instruction?

[William Astle]

James Diffendaffer wrote:
>> If memory serves there was a Busy/*BusAvailable pin on the master 
>> (6809)
>> and a corresponding pin on the slave (6809E) used to arbitrate this, 
>> with
>> read-modify-write instructions locking the bus until they were done
>> (typically 2-3 machine cycles).

You know, it might be possible to accomplish the equivalent of a 
"test-and-set" as used for synching between cpus assuming to 6809s have 
the logic as described above implemented. Suppose the following:

FLAG	FCB $FF	* used for synchronization

LOCK	INC FLAG
	BEQ LOCKED	##
	DEC FLAG	##
	BRA LOCK
LOCKED	* DO STUFF

UNLOCK	DEC FLAG

(As long as INC and DEC lock the memory bus during the read,modify,write 
part of the instruction, the above will work.)

The above is pretty naive. Note that the initial unlocked value is 
critical here - it must be $FF so that INC will bring the value to 0 so 
then if FLAG is 0, we know what the previous state was.

You might think you could unlock the resource by simply storing $FF to 
the location but that is not exactly true. That will work in most cases 
but will fail if the unlock happens while another processor is executing 
the ## instructions above. Using DEC means that when all the lock/unlock 
processes finish, the value of "flag" will be $FF.

Note that the above implements what is known as "busywaiting" and is not 
ideal if you have a single CPU system doing multiprogramming as it will 
then busywait until the entire time slice it is allotted finishes. In a 
multi-processor system, however, odds are the busywaiting won't last 
very long as the other processor will finish and unlock the resource at 
some point.

If one is operating a single cpu system, disabling interrupts during the 
lock test is more efficient. It is even more efficient to simply disable 
interrupts during the entire critical section and dispense with locks 
altogether. This is not always reasonable, however, so if one does 
implement the above on a single CPU system, it is useful to YIELD the 
CPU to another process if one encounters a locked resource. (That 
assumes the OS allows a process to do so.)

One final note: for synchonrization, all one actually needs is an atomic 
instruction that allows one to set a memory location to a value and 
retrieve the previous value of that location. So, for example, if one 
could to the following:

LOAD A with 1
EXCHANGE A with Location 1
TEST A

Only the "EXCHANGE" instruction would have to be atomic. (IIRC, that's 
essentially what Linux uses on the x86 platform.)

-- 
William Astle
finger lost at l-w.ca for further information

Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL++++$ P++ L+++ !E W++ !N w---
!D !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y?