Atomic operations between CPU & Blitter

[leonard]

Hi,

I wonder if read/write instruction such as EOR dn,<memory> are "atomic", regarding to blitter for instance?

In other word, imagine CPU is doing EOR #1,$0 and blitter is doing exacly the same at same address. Therorically result will be 0 ( both are doing EOR #1)

but, if operation is not atomic, then it could have a race condition and maybe the result will be 1 instead of 0.

Any idea?

[PeterK]

That sounds a bit strange. My imagination is that only the CPU or a chip can have access to a memory location at a certain time. Only one of them is the owner of the address and data bus for the ChipMem, but never both at the same time. We don't want smoke from the bus drivers.

[NorthWay]

There is a reason why the atomic 680x00 opcodes are "illegal" to use on the Amiga - you can be locked out of the (chip) bus by DMA.
In the same way any RMW instruction - indeed any store at all - will be conflicting with the blitter. Which is why you have the blitter ready bit to test for.

What kind of code do you have if you don't know who is doing what?

[ross]

Atomic operation in amiga architecture is prohibited, hence the reason TAS is unusable in chip mem and can hang the machine.
There is only consecutive operations so in your example result is everytime 0 (the race can be win by CPU or Blitter, it does not matter).

EDIT: hi NorthWay, i lost the race, even if the publication time is the same!

[meynaf]

Originally Posted by leonard

Hi,

I wonder if read/write instruction such as EOR dn,<memory> are "atomic", regarding to blitter for instance?

In other word, imagine CPU is doing EOR #1,$0 and blitter is doing exacly the same at same address. Therorically result will be 0 ( both are doing EOR #1)

but, if operation is not atomic, then it could have a race condition and maybe the result will be 1 instead of 0.

Any idea?

Results can be just anything, depending on which order the read and write operations are performed.
If one of the two has enough time to write before the other reads, then you get 0, else you get 1.

Originally Posted by ross

Atomic operation in amiga architecture is prohibited, hence the reason TAS is unusable in chip mem and can hang the machine.

From the tests I made on my A1200 it can't hang the machine.
It's just that the operation does not get its lock. But it appears to behave fine and despite my efforts i never caught it red handed.

Originally Posted by ross

There is only consecutive operations so in your example result is everytime 0 (the race can be win by CPU or Blitter, it does not matter).

In fact result could be 1. Remember 4 operations are done in reality, not just 2.
First, both have to read the data. If they do it one right after the other, both will read 0.
Then they do the eor and both will write 1...
You get 0 only if one has the time to write its data before the other performs the read.

Of course you may want to run the blitter in nasty mode so cpu does not get any cycle before blitter has ended.
But if the blitter is too slow to start, then the cpu still has time to read the memory before...

[frank_b]

Try TAS from chip RAM on a 500..Buzzing black screen of death and a trip to the power button!

[ross]

Originally Posted by meynaf

From the tests I made on my A1200 it can't hang the machine.
It's just that the operation does not get its lock. But it appears to behave fine and despite my efforts i never caught it red handed.

The official Amiga programming guidelines state that TAS must not be used on an Amiga as it can lock the machine (Agnus can't deal with this special RWM cycle, some DMA access can't take place and results are unpredictable).

EDIT: hmm, seems that is not only a question of DMA "lost" cycles, but a bus contention that drive Agnus to write on the address setup by the CPU or bus lock because of undefined control bus state. Hardware tests are needed

Maybe fixed on Alice?

In fact result could be 1. Remember 4 operations are done in reality, not just 2.
First, both have to read the data. If they do it one right after the other, both will read 0.
Then they do the eor and both will write 1...
You get 0 only if one has the time to write its data before the other performs the read.

You are right!
Cycles can be back-to-back and result is two (consecutive) 1 written in same memory cell!

[Toni Wilen]

In my tests (years ago) TAS never hung but it worked incorrectly (wrong results etc) if DMA conflicted with its second memory cycle (write cycle).

It is also possible it depends on used hardware, accelerator board etc..

[DanScott]

Let me expand slightly what Leonard is attempting, so that the discussion does not go off on a generic tangent about the TAS command

He wants to render some things with the Blitter, and also concurently render some things with the CPU. Both will be rendering with EOR.

There is a chance that at some point, the CPU and the Blitter will be EORing into the same word at the same time. So depending on the read/write cycles of both the CPU and the Blitter accessing the same word of memory, EORing the same bits into that word (final result *should* be a zero'd bit).. is there a chance that the read/write cycle will cause an incorrect result?

[Toni Wilen]

Originally Posted by DanScott

is there a chance that the read/write cycle will cause an incorrect result?

No. Multiple devices can't access same type of RAM at the same time. (CPU can access real fast ram/rom/z2 io/cia while chipram DMA is accessing chip RAM)

But it probably is quite difficult to "sync" CPU and blitter to get also "software level" correct results.

Perhaps it can be done using unrolled loop (assuming 68000, or code that fully fits in cache if 68020+, to keep accesses identically timed). Blitter will have priority so if CPU only does identically timed accesses, blitter will always stop the CPU when it needs chip ram access = automatic sync

[hooverphonique]

Originally Posted by Toni Wilen

Perhaps it can be done using unrolled loop (assuming 68000, or code that fully fits in cache if 68020+, to keep accesses identically timed). Blitter will have priority so if CPU only does identically timed accesses, blitter will always stop the CPU when it needs chip ram access = automatic sync

But if the blitter operation in question has idle cycles, the cpu could possibly read or write the word, the blitter is currently operating on, right!?

[ross]

Originally Posted by DanScott

He wants to render some things with the Blitter, and also concurently render some things with the CPU. Both will be rendering with EOR.

Something escapes me..
The cpu always knows on which areas of memory the blitter works, so it is not enough just to make a check before starting the operation?
If the work is spanned in irq you can simply take a look in the global queue job.
But whithout detail is impossible to say

There is a chance that at some point, the CPU and the Blitter will be EORing into the same word at the same time. So depending on the read/write cycles of both the CPU and the Blitter accessing the same word of memory, EORing the same bits into that word (final result *should* be a zero'd bit).. is there a chance that the read/write cycle will cause an incorrect result?

Considering what has been written yes, is possible (remotely.. with a [un]fortunate back-to-back access).
You can drastically reduce the possibility using the BLTPRI bit (if enought blitter channels is used).
Actually you can even reduce to null if you deny for the CPU even the first chip access with a custom reg. bus read (like on BlitterWait routine).


EDIT:
Just to be clear.
I realize that the latter is certainly not the best way to use CPU and Blitter competently (is no more a "parallel" task ).
But I would not use them to make simple cuncurrent EORs on chip memory areas.
All different, however, if they are used together for very different operations (logic for the blitter and ALU advanced with the processor).
In that case the performance gain is incredible.

[Kalms]

A more problematic aspect than the blitter intercepting the CPU is the CPU intercepting the blitter.

The blitter will fetch from its source channels, then the data is in transit within the blitter for a couple of cycles, then written out to the D channel. Worst case this is 7 bus cycles (ABCD active, A & D point to the same mem location, latency A -> pipeline -> D) ignoring other DMA. If the CPU modifies the memory location during those 7 bus cycles, the CPU result of the CPU operation will be overwritten by the blitter.

[ross]

Originally Posted by Kalms

A more problematic aspect than the blitter intercepting the CPU is the CPU intercepting the blitter.

The blitter will fetch from its source channels, then the data is in transit within the blitter for a couple of cycles, then written out to the D channel. Worst case this is 7 bus cycles (ABCD active, A & D point to the same mem location, latency A -> pipeline -> D) ignoring other DMA. If the CPU modifies the memory location during those 7 bus cycles, the CPU result of the CPU operation will be overwritten by the blitter.

Absolutely right.
This is a mandatory (and working) case for BLTPRI.

[Toni Wilen]

I only meant there is no hardware side-effects.

It is (or at least should have been) obvious that any RMW cycle can be "interrupted" by higher priority channel or any channel if there are free cycle(s) between read and write.

[Crank]

What is "TAS"?

[Steve]

Originally Posted by Crank

What is "TAS"?

http://68k.hax.com/TAS

[Hannibal]

I think I can guess what you are doing, and have considered the same thing. I concluded the cleanest solution was to add an extra back buffer, so the CPU can draw to buffer x-1 while blitter draws to buffer x.