Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 28 Sep 2018 10:28:14 -0400
From: Rich Felker <>
Subject: Re: riscv port for review

On Fri, Sep 28, 2018 at 01:43:24PM +0200, Szabolcs Nagy wrote:
> > diff --git a/src/math/riscv64/fmax.s b/src/math/riscv64/fmax.s
> > new file mode 100644
> > index 0000000..40655d3
> > --- /dev/null
> > +++ b/src/math/riscv64/fmax.s
> > @@ -0,0 +1,5 @@
> > fmax
> > +.type   fmax, %function
> > +fmax:
> > +        fmax.d fa0, fa0, fa1
> > +        ret
> this is ok, but note that
> riscv fmax is ieee-754-2018 maximumNumber(x,y)
> iso c fmax (with ts 18661) is ieee-754-2008 maxNum(x,y)
> (see
> and )
> they only differ in snan handling, current iso c (and musl)
> does not care about signaling nans, but that might change.
> (glibc cares and gcc has flags to make it care.)

Yes, for now I think it doesn't matter.

> musl is moving away from asm to c code with gcc style inline
> asm wherever possible (the drawback is the dependency on gcc
> asm syntax and constraints, the benefit is that pcs and
> prologue/epilogue are handled by the compiler so all sorts of
> instrumentations like debug info, -fstack-protector-all, etc
> just work).
> so i'd prefer to convert all these asm to c code.
> (can be done after the port goes in)

Indeed, I'd rather do this later as a fixup for all archs at once than
try to work it out now as part of the riscv porting. They're logically
separate tasks.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.