On Thu, Mar 20, 2014 at 12:38:49PM +0200, Riku Voipio <riku.voi...@linaro.org>
wrote:
> First part of the patch adds memory fence for aarch64. Strictly, this isn't
> necessary, as the fallback to __atomic_thread_fence (__ATOMIC_SEQ_CST)
> would output the same dmb ish instruction.
Thanks!
We indeed plan to move the test for __atomic_thread_fence to earlier in
the file, so it would become the default (are there any gcc versions that
support aarch64 but not __atomic_thread_fence? I guess not).
However, if aarch64 has some efficient load and store barriers, using them
could be advantegous, i.e., if you have efficient implementations for the
_ACQUIRE and _RELEASE variants, these could be quite useful.
> Second part makes sure the ancient arm float format doesn't get used.
As a historical sidenote, the ancient arm float fornmat is precisely the
reason behind this, btw. :)
However, we do have working code for both cases, and correctness beats
speed, especially for these not-so-often used functions.
I would prefer a massive #if statement for every useufl architeture out
there and updating that over a negated one that breaks when double happens
to be decimal ieee or somesuch bullshit that, in 20 years, might not be
bullshit but the sane default.
It's not as if new arm architectures will be introduced that often.
> Alternative would be to drop all ancient arm float support - anyone still
> using the abi wouldn't be upgrading to new libev.
Well, I am sure old arm isn't the only platform with nonstandard fp (and I
suspect future platforms might switch as well), so I would prefer a change
that simply adds aarch64 to the list of "sane" architectures.
Look at it that way: we also thought we had picked up all noteworthy
architectures with our fences, but we regularly get patches :)
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
