[Gc] Re: Re[4]: libatomic_ops aarch64 support

Yvan Roux yvan.roux at linaro.org
Fri Feb 15 01:55:06 PST 2013


Hi Ivan,

> 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?

Yes you're right, with the _write semantics we should use a dmb st.

> Is there any __atomic_thread_fence(__ATOMIC_x) giving "dmb st"?

No, we have to deal with asm statements in that case.

> Is "dmb ish" same as "dmb"?

The difference here is in the shareability domain, where "dmb" is a
barrier applied to the system domain, "dmb ish" is applied to the
inner shareable domain, from what I have understood a system can have
several inner shareable domains, and a barrier applied to one of them
doesn't affect the others, but frankly speaking shareablity domains is
not a crystal clear topic for me !

Cheers,
Yvan

> 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
>>>>>
>>>>>
>
>


More information about the Gc mailing list