On 5 November 2014 14:54, Mike Holmes <mike.hol...@linaro.org> wrote:
>
>
> On 5 November 2014 15:26, Victor Kamensky <victor.kamen...@linaro.org>
> wrote:
>>
>> Hi Ola,
>>
>> Please see below general comment about your approach.
>>
>> > +typedef enum {
>> > + /** Relaxed memory order, no ordering of other accesses enforced
>> > */
>> > + ODP_MEMORDER_RLX,
>> > + /** Acquire memory order, later accesses cannot move before
>> > + * acquire operation */
>> > + ODP_MEMORDER_ACQ,
>> > + /** Release memory order, earlier accesses cannot move after
>> > + * release operation */
>> > + ODP_MEMORDER_RLS
>> > +} odp_memorder_t;
>>
>> Why do you have 3 memory models while C11
>> has 6?
>>
>> Are you aware about gcc __atomic built extenstion?
>> https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html
>> They follow C11 quite closely with few caveats (like run-time
>> vs built time). Why don't you use those, instead of implementing
>> them by yourself?
>
>
> If we plan to be compiler agnostic do we want to add more gcc mechanisms ?
I wrote aboute that below - use tiny wrappers; there will
be similar functionality in another compiler ...
I.e look for "__c11_atomic builtins"
http://clang.llvm.org/docs/LanguageExtensions.html
And current and Ola's code is already doing it with __sync
atomics, those are gcc mechanisms. What is different
if __atomic gcc builtin will be used?
Implementing general purpose C11 atomics in ODP
does not make sense to me. IMHO it does not belong
here. ODP is about h/w accelerators abstraction. Where
are h/w accelerators in "C11" (note in quotes) atomics
implementation?
Thanks,
Victor
>>
>>
>> What is the need to reimplement those in ODP?
>>
>> I am not sure, it seems to me that Petri raised similar point.
>> In ODP we need to provide atomic operations that map to
>> possible h/w accelerations that SOCs come up with, like
>> Octeon atomic and ARM8.1A atomic instructions. If we just
>> need atomic function for general purpose memory, those
>> IMHO should come up from somewhere else (like compiler,
>> C11 implementation, etc).
>>
>> Basically if linux-generic needs
>> some of atomic C11 style primitives it could use __atomic
>> builtins directly or with some tiny wrapup api, that deals
>> with gcc/clang differences, but those should not be exposed
>> as ODP apis. I think that point was raised during discussion.
>>
>> BTW linux-generic atomic implementation (one that implements
>> ODP API) could use __atomic with relaxed option to do required
>> operation, but without barrier, if you are not happy with current
>> implementation that uses old __sync builtins.
>>
>> Thanks,
>> Victor
>>
>> _______________________________________________
>> lng-odp mailing list
>> lng-odp@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/lng-odp
>
>
>
>
> --
> Mike Holmes
> Linaro Sr Technical Manager
> LNG - ODP
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
