[Gc] Re[4]: libatomic_ops aarch64 support

Ivan Maidanski ivmai at mail.ru
Fri Feb 15 00:34:24 PST 2013


 Hi Yvan,

Thursday, 14 Feb 2013, 21:27 +01:00 Yvan Roux <yvan.roux at linaro.org>:
>Hi,
>
>> To my understanding, AO_nop_write should be defined as "dmb st". May be, I'm
>> wrong. Help of the community is really appreciated!
>
>I thought the same at the beginning, but after going back in the docs,
>the release semantics is store-before-store and load-before-store,
>whereas dmb st is just store-before-store.
As defined in generalize-small.template:
AO_store_release = AO_nop_full (dmb) + AO_store
AO_store_write = AO_nop_write + AO_store

According to our definition of AO_store_write (and that dmb st is just store-before-store), it seems to me that AO_nop_write should be "dmb st", right?
Is there any __atomic_thread_fence(__ATOMIC_x) giving "dmb st"?

>
>
>
>>
>>
>> AO_nop_full:
>>         dmb ish
>>         ret
>>
>>
>> Is this the same (or stronger) as for __sync_synchronize?
>
>they are the same.
Is "dmb ish" same as "dmb"?

Thanks.

Regards,
Ivan

>
>
>Thanks,
>Yvan
>
>>>>
>>>>
>>>>
>>>>
>>>>> Please rewrite CAS primitives (for AO_t and AO_double_t, relaxed and
>>>>> acquire/release/full variants) using __atomic_compare_exchange_n.
>>>>
>>>> ok fine, I will do it.
>>>>
>>>>> Q: Which compiler version do you use?
>>>>
>>>> I use for the cross compiler the
>>>> gcc-linaro-aarch64-linux-gnu-4.7-2013.01, I use my own build, but you
>>>> can find the binary release on the Linaro engineering armv8 page in
>>>> the download section (link below), and a 2012.12 native release (the
>>>> one shipped with the vexpress64-openembedded_sdk image) and with this
>>>> one the add-aarch64-support branch build failed during the compilation
>>>> of atomic_ops.c with the error:
>>>>
>>>> atomic_ops.c:96:1: error: unknown type name 'AO_TS_t'
>>>>
>>>>
>>>> Strange. This should be defined as AO_t in test_and_set_t_is_ao_t.h (please
>>>> check preprocessed code).
>>>>
>>>>
>>>>
>>>>  http://www.linaro.org/engineering/armv8
>>>>
>>>>
>>>>> In case you have more free time (and wish to check some other targets), it
>>>>> would be good to check whether it is ok to use gcc/generic.h (starting
>>>>> from
>>>>> some GCC version) instead of asm-based primitives in gcc/*.h (by
>>>>> eye-inspection of asm code generated for the target comparing it to the
>>>>> instructions written in gcc/*.h files).
>>>>
>>>> I don't guarantee that I will check all the targets, but will give a look ;)
>>>>
>>>>
>>>> Thank you. I think it would be better to understand/fix the problems with
>>>> AArch64 first.
>>>>
>>>> Regards,
>>>> Ivan
>>>>
>>>>
>>>>
>>>>> Thank you. Sorry for a delay with the answer.
>>>>
>>>> No problem, many thanks
>>>>
>>>> Cheers,
>>>> Yvan
>>>>
>>>>> Regards,
>>>>> Ivan
>>>>>
>>>>> Fri, 8 Feb 2013, 16:53 +01:00 from Yvan Roux < yvan.roux at linaro.org >:
>>>>>
>>>>> Hi Ivan,
>>>>>
>>>>> Do you need more inputs regarding the aarch64 support, I didn't had
>>>>> time to work on this topic during the past weeks, but as I have a slot
>>>>> dedicated to that during the coming one, it would be great if you tell
>>>>> me what I can do.
>>>>>
>>>>> Cheers,
>>>>> Yvan
>>>>>
>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20130215/540fc1ce/attachment.htm


More information about the Gc mailing list