romell
Posts: 25
Joined: Mon Jul 23, 2012 6:57 pm

Re: FB doublebuffering

Tue Aug 07, 2012 9:18 pm

Cycl0ne wrote:...do a barrier = flush caches...
Are you sure about this part?

The thing that confuses me the most is that there are a lot of slightly different instructions and I'm not really sure with to use where and why...

There are at least 4 different (but similar) instructions dealing with this stuff:
* Invalidate cache
* Clean cache
* Data Memory Barrier
* Data Synchronization Barrier

User avatar
Cycl0ne
Posts: 102
Joined: Mon Jun 25, 2012 8:03 am

Re: FB doublebuffering

Tue Aug 07, 2012 10:16 pm

yup that whats confuses me too.

afaik this is why you have a DSB() and a WSB() (?) where the first clears the pipes that all commands are written and the second clears cache so that you can read correct values from memory. but in linux source both are the same?!?:-P

tufty
Posts: 1456
Joined: Sun Sep 11, 2011 2:32 pm

Re: FB doublebuffering

Wed Aug 08, 2012 6:47 am

It's pretty easy, really.

DMB - blocks all subsequent memory accesses until preceding memory accesses have finished. Non memory accessing instructions may continue.
DSB - blocks /all/ instructions until preceding memory accesses have finished.
ISB - flushes instruction caches (you need this one if you're doing self-modifying code)
Cache flush - flushes data cache.

So you use dmb when you want to be sure preceding memory accesses have finished, but continue doing other stuff (for example, setting a semaphore), dsb when you need everything to be finished before doing anything else (signalling other processes), isb when you've been messing with instructions, and cache flushing when memory is changing under the processor's feet.

http://infocenter.arm.com/help/topic/co ... ok_A08.pdf is a reasonable read, although aimed at cortex-a processors the concepts remain correct.

Simon

Return to “Bare metal, Assembly language”