• State Accepted Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 350 subscribers
  • Views 5680 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Instruction Modification: DCCMVAU and write buffer

a.surati

Hello,

The ARMv8-A-TRM provides the code snipped shown below, under section K9.5.2 within subsection "Ensuring the visibility of updates to instructions for a uniprocessor":

Assume that the memory, to which the instruction is being written, is Normal, Write-Back, Write-Allocate.

Suppose that the STR instruction encountered a cache-miss. The write buffer consumed the write, to allow the CPU to proceed.

The CPU then went on to execute DCCMVAU, with the write still within the buffer. 

How does DCCMVAU affect the pending writes in the write buffer?

Why is an instruction to drain the write buffer not needed between STR and DCCMVAU? (Possibly because DCCMVAU drains the buffer too?)

AArch32
P1
 STR R11, [R1] ; R11 contains a new instruction to be stored in program memory
 DCCMVAU R1 ; clean to PoU makes the new instruction visible to the instruction cache
 DSB
 ICIMVAU R1 ; ensures instruction cache/branch predictor discards stale data
 BPIMVA R1
 DSB ; ensures completion of the invalidation
 ISB ; ensures instruction fetch path sees new instruction cache state
 BX R1

 

Thank you,

Amol

 

Parents
  • 0 in reply to Michael Williams
    Thank you. I think I understand.

    I see how the definitions such as PoU are 'universal', binding, and largely independent of and a driving force behind the implementation.

    There could be a hundred levels of write buffers above the PoU and the DCCMVAU impl. would be responsible for draining them.

    There could be a micro-controller (encryption/decryption of the data going in and out I/DCache/Write-Buffer for e.g.) sitting above the PoU on the path, and DCCMVAU impl. would be responsible for programming it, unless the micro-controller needed be exposed to the programmer, in which case the arch. ref. manual would need to change to provide the appropriate methods to the programmer.

    Unless the definition of the PoU itself were to be changed, DCCMVAU would continue to guarantee the programmer that the write lands where the ICache can see it.
Reply
  • 0 in reply to Michael Williams
    Thank you. I think I understand.

    I see how the definitions such as PoU are 'universal', binding, and largely independent of and a driving force behind the implementation.

    There could be a hundred levels of write buffers above the PoU and the DCCMVAU impl. would be responsible for draining them.

    There could be a micro-controller (encryption/decryption of the data going in and out I/DCache/Write-Buffer for e.g.) sitting above the PoU on the path, and DCCMVAU impl. would be responsible for programming it, unless the micro-controller needed be exposed to the programmer, in which case the arch. ref. manual would need to change to provide the appropriate methods to the programmer.

    Unless the definition of the PoU itself were to be changed, DCCMVAU would continue to guarantee the programmer that the write lands where the ICache can see it.
Children
No data