Aarch64 support for libev

Riku Voipio riku.voipio at linaro.org
Fri Mar 21 13:43:58 CET 2014

On 20 March 2014 22:20, Marc Lehmann <schmorp at schmorp.de> wrote:

> On Thu, Mar 20, 2014 at 12:38:49PM +0200, Riku Voipio <
> riku.voipio at 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).

Gcc 4.8 is pretty much going to be the bottom line for Aarch64, so that
should be fine.

> 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.
There is dmb ishld and dmb ishst which kernel uses for rmb and wmb. I don't
know if it is much faster. Need to wait for production hardware to see if
worth the impact.

> > 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. :)

Doesn't get used *accidentally*, I meant. Currently, if one just compiles
the current
libev on a new architecture, like aarch64, the ifdef will pick up the mixed
endian variant.
I think this will surprise many people.

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

Ok, I've attached a simplified patch that:

1) trusts gcc to give a working atomic_thread_fence
2) adds aarch64 to list of sane archs
3) warns if the old arm method gets used

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20140321/3fda29e5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libev-aarch64.patch
Type: text/x-patch
Size: 410 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20140321/3fda29e5/attachment.bin>

More information about the libev mailing list