Question about the TAS instruction.

[Thorham]

Hi,

The 680x0 guide file I have, says this about the TAS instruction:

This instruction uses read-modify-write cycle, which is not dividable and allows synchronisation of several processors. But this instruction is NOT ALLOWED ON AMIGA!

I've tried this instruction, but nothing out of the ordinary seems to happen Is this statement correct, or is TAS safe to use?

Any pointers are appreciated

[Galahad/FLT]

TAS isn't safe to use on Zorro II systems, as certain conditions are expected and never happen.

TAS is also not a good idea on Amiga as the instruction can cause a bus lock during an interrupt, with that certain part of memory thats been Tested and Set, is now not available to other processors, which will cause problems.

From what I can remember, a TAS will cause a bus lock at any time, not at the end of of a interrupt cycle.

[Toni Wilen]

It isn't safe.

One issue is TAS to chip RAM + Agnus DMA accesses at the same time = incorrectly working TAS.

Problem is TAS's special cycle (read-modify-write cycle which is unsupported on Amiga) When TAS read cycle has finished, it can't be stopped anymore, write cycle will start and in worst case Agnus is also using this cycle for DMA (because it thought TAS read cycle was normal single read cycle)

I haven't seen any bus lockups, only wrong TAS results (but I have only been testing it on chip RAM)

[Thorham]

Thanks guys

Pity, but luckily there's still BSET, so no problem. As long as testing and setting can't be interrupted, I'm happy

[hitchhikr]

Does this rule apply to a "tas dx" like form ?
I seems to remember that what it does just set the bit 7 of the specified data register.

[Kalms]

What is the purpose of the atomicity?

There is no atomic read+write operation against memory in the Amigas. (Unless CAS/CAS2 are supported, which I don't think they are.) So there is no way to perform an atomic read-modify-write operation, which is guaranteed not to be intercepted by another DMA capable device in the system.

However if you seek atomicity with regards to interrupts within the same CPU, the situation is easier; the CPU will only check for external interrupts between the processing of two instructions. So, if you know that the instruction itself will not generate an exception (perhaps because you're attempting to read/write a page which has been marked as unavailable by the MMU) then you can implement semi-atomic operations by using ordinary logic operations where you can deduce the old value from the new. For instance a semaphore:

acquireSemaphore:
		addq.b	#1,semaphore			; attempt to acquire semaphore
		beq.s	.done				; if current value = 0, you acquired it
		subq.b	#1,semaphore
		; wait for some time (or for an event) before re-trying
		bra.s	acquireSemaphore

.done:		rts

releaseSemaphore:
		subq.b	#1,semaphore
		rts

semaphore:	dc.b	255

But again - the question is, what is the purpose of the atomicity?

[Thorham]

Originally Posted by Kalms

What is the purpose of the atomicity?

I need this for insuring that a task exception won't do certain things, such as killing the task, while the task is inside a critical section. I wanted to use TAS for this, but BSET works as well, because I don't need the read-write cycle, I just need a test and a write to be done in one go (using two instructions means the exception can happen after the test, and before the write and this is bad in my code).

[Wepl]

the question arises if tas/cas would be save on real fast mem? but afaik there can be dma too (for example scsi/ata/ethernet)