Hi Ramana and Peter,
There is no issue in the first case. You are correct that the dmb’s there
> are to ensure the sequential consistency as you’d want to see with
> __ATOMIC_SEQ_CST in the call to the builtin. However what you must remember
> is that STRs are guaranteed to be single-copy atomic
== Blueprints ==
InitialCurrentActual
initial-aarch64-backport31 Oct 201230 Nov 2012
aarch64-baremetal-testing 31 Oct 201230 Nov 2012
fix-gcc-multiarch-testing 31 Dec 201231 Dec 2012
backport-fma-intrinsic 31
Yvan,
That is correct. The addresses need to be aligned as per the restrictions in
the architecture. Yes we could have an issue but software writers need to deal
with it because IIUC you either have a huge performance penalty (x86 / lock
prefix) or correctness issues (ARM, Powerpc) .
Cheers,
R
* meetings/discussions
+ upcoming architecture & h/w features
+ virtio patchset review/discussion
+ 1-2-1 Matt, Michael
+ arndale board secondary CPU boot
+ naming conventions for v8 qemu
+ v7 KVM blueprint status
+ posture assessment
+ KVM call
* thinking through possible
== Progress ==
* Turn off 64-bits bitops in Neon: initial implementation under
benchmarking.
Currently it modifies the handling of: add, sub, and, or, xor, shifts,
not. In some case the generated code is quite larger, so it will careful
benchmarking.
* Started looking at "disable peeling" blue-p
