Hello,
I might be too late for that discussion but I think we need to summarize
all discussion
in all patch threads. Otherwise we are going in loop and Ola needs to do
that hard work
again and again.
So I think the summary is:
1. ODP supports C99, not C11 and that is why we can not use C11 built in
atomic operations.
If we think that C99 is bad idea (atomic things can be reason for that)
we can discuss supporting C11.
2. Yes we need odp abstractions for atomic operations. People like to
use use-cases and follow examples.
And to not dependent on gcc/glibc is also great benefit. So you can wait
for changes
in upstream gcc or correct function in your odp arch implementation.
The other case is why linux-generic has to have Octeon (for example)
optimized code if Octeon SoC is not supported in linux-generic.
I would like to see assembly code in linux-octeon then in linux-generic.
And linux-generic should use gcc built in function. Gcc functions
might not be optimal but they are generic. There is only one reason that
other platforms can reuse that code. And probably it's
good idea to provide effective functions (I think there are not match
experts in memory models in atomic operations.)
Abstractions should be very useful for implementations. You just can see
which scope of work you need to redo in other arch.
3. Ola's patch supports 3 memory models which cover all our hw. I think
it's good for now. If somebody has other mode then he is
free to go to add or use gcc built in function like Ola did for x86.
Summarizing 1,2 and 3 I think we have options 1. accept Ola's work. 2.
Switch to C11 and ask Ola to reuse C11 gcc built ins where
it's possible.
Thanks,
Maxim.
On 11/05/2014 11:26 PM, Victor Kamensky 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?
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
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
