Aarch64 support for libev

Marc Lehmann schmorp at schmorp.de
Fri Mar 21 17:23:11 CET 2014


On Fri, Mar 21, 2014 at 02:43:58PM +0200, Riku Voipio <riku.voipio at linaro.org> wrote:
> > 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.

Good to hear, the assembly barrier I already applied to ecb.h, simply
because it's useful to have a reference (in case we support other compiler
assembly language for example).

> 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 it's worth the impact.

The more important question is whether these instructions actually work
as load and store barriers - cpus are full of such instructions that by
name are, but in practise are not enough, so in doubt, it's better to stay
safe, too :)

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

Right, as designed - kepe in mind that it isn't the mixed endian variant,
but the safe fallback, i.e. it shuld work on every architecture, even the
ones using ieee format in "expected" endianness.

In fact, endianness is another reason why the fallback exists, as apparently,
some (niche) architetcures have different endianness between floats and ints.

> I think this will surprise many people.

It shouldn't, as the replacements should just work - in theory, with a
ubercompiler, they might even be as fast.

Without doubt, aarch64 should get STDFP, of course. In addition...

> > 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.
>
> 2) adds aarch64 to list of sane archs

... I think we talked a bit past each other. I am not happy with a solution
that singles out "old arm" to use the fallback, I want a specific list of
architectures.

However, I am fine with saying "arm, except old ones, use the optimised
implementation".

I can synthesize this from your first patch, and your second patch (so you
already gave me all the precious information I need). It would be nice if
you could test it when it is finished, though :)

> 3) warns if the old arm method gets used

I don't think ecb.h should warn if the result is supposedly working.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list