Is volatile always verboten for FSL QE structures?
Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?
I'm asking because I really want to know ;)
Signature · 2 lines
Michael Barkowski 905-482-4577
Quoted 1 line · Michael Barkowski
Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?
'volatile' just doesn't really do what you think it should do. The PowerPC architecture is too complicated w.r.t. ordering of reads and writes. In other words, you can't trust it.
No one should be using 'volatile' to access I/O registers.
Signature · 2 lines
Timur Tabi Linux kernel developer at Freescale
Quoted 6 lines · Timur Tabi
Quoted 1 line · Michael Barkowski
Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?
'volatile' just doesn't really do what you think it should do. The PowerPC architecture is too complicated w.r.t. ordering of reads and writes. In other words, you can't trust it.
No one should be using 'volatile' to access I/O registers.
See Documentation/volatile-considered-harmful.txt
- k
Quoted 8 lines · Kumar Gala
Quoted 5 lines · Timur Tabi
Quoted 3 lines · Michael Barkowski
Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?
Quoted 8 lines
Quoted 5 lines
'volatile' just doesn't really do what you think it should do. The PowerPC architecture is too complicated w.r.t. ordering of reads and writes. In other words, you can't trust it.
No one should be using 'volatile' to access I/O registers.
See
Documentation/volatile-considered-harmful.txt
I'm happy to adopt your interpretation of it, and I appreciate the explanation.
from Documentation/volatile-considered-harmful.txt:
Quoted 4 lines
- The above-mentioned accessor functions might use volatile on architectures where direct I/O memory access does work. Essentially, each accessor call becomes a little critical section on its own and ensures that the access happens as expected by the programmer.
Part of it was that I wondered if this was one of those architectures. I guess not.
Signature · 2 lines
Michael Barkowski 905-482-4577
Quoted 20 lines · Michael Barkowski
Quoted 8 lines · Kumar Gala
Quoted 5 lines · Timur Tabi
Quoted 3 lines · Michael Barkowski
Just wondering - is there a case where using volatile for UCC parameter RAM for example will not work, or is the use of I/O accessors everywhere an attempt to be portable to other architectures?
Quoted 8 lines
Quoted 5 lines
'volatile' just doesn't really do what you think it should do. The PowerPC architecture is too complicated w.r.t. ordering of reads and writes. In other words, you can't trust it.
No one should be using 'volatile' to access I/O registers.
See
Documentation/volatile-considered-harmful.txtI'm happy to adopt your interpretation of it, and I appreciate the explanation.
Quoted 7 lines
from
Documentation/volatile-considered-harmful.txt:Quoted 4 lines
- The above-mentioned accessor functions might use volatile on architectures where direct I/O memory access does work. Essentially, each accessor call becomes a little critical section on its own and ensures that the access happens as expected by the programmer.
Part of it was that I wondered if this was one of those architectures. I guess not.
I guess this could only work on architectures having a totally ordered memory model. Definitely not the case for Power.
Hi,
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
'volatile' just doesn't really do what you think it should do. The PowerPC architecture is too complicated w.r.t. ordering of reads and writes. In other words, you can't trust it.
It's not sufficient on PowerPC.
It might be necessary, depending on the compiler's mood for moving stuff out of loops.
Consider:
| unsigned int *foo = (unsigned int *)0x12345678; | void bar(void) { while(*foo != 0) asm("eieio"); }
gcc 4.3.4 with -O3 compiles this to
00000000 <bar>:
0: 3d 20 00 00 lis r9,0
2: R_PPC_ADDR16_HA foo
4: 81 69 00 00 lwz r11,0(r9)
6: R_PPC_ADDR16_LO foo
8: 80 0b 00 00 lwz r0,0(r11)
c: 2f 80 00 00 cmpwi cr7,r0,0
10: 4d 9e 00 20 beqlr cr7
14: 7c 00 06 ac eieio
18: 7c 00 06 ac eieio
1c: 4b ff ff f8 b 14 <bar+0x14>Making the target of foo volatile properly rechecks the condition on each iteration.
OTOH my PPC box runs fine, so I'm probably missing something obvious.
Simon
Quoted 5 lines
Making the target of foo volatile properly rechecks the condition on each iteration.
OTOH my PPC box runs fine, so I'm probably missing something obvious.
Probably because the IO accessors do -both- volatile casts and add the barriers :-)
Ben.