New Port for RISC-V

Andrew Waterman andrew@sifive.com
Thu Jan 12 20:43:00 GMT 2017


Thank you for taking the time to give us feedback.

On Thu, Jan 12, 2017 at 9:30 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> General observation: I see no documentation (no changes to .texi files)
> anywhere in this patch series.  I also don't see updates to config-list.mk
> to add RISC-V targets to the set that builds.  (You should make sure the
> port builds cleanly when built with current mainline GCC and configured
> with --enable-werror-always; config-list.mk uses --enable-werror-always
> and it's a rough way of making sure in a cross build that there aren't
> warnings that would make a native bootstrap fail.  It should build cleanly
> for both 32-bit and 64-bit hosts.)
>
> See sourcebuild.texi, "Back End", for a description of various places that
> may need updating for a new port, including lots of things that need
> documenting if your port has them (not all ports will have all those
> target-specific features).  That includes website updates.

Thanks for the pointer.  We'll write documentation, adjust the build
list, and look at sourcebuild.texi for further guidance before
submitting an updated version of the patch set.

>
> Regarding binutils support: to be clear, does 2.28 branch have all the
> features / fixes known to be required at present and will subsequent fixes
> go on there as needed?

Yes, and we will continue to apply fixes to both the trunk and the 2.28 branch.

>
> Regarding Linux kernel support: how confident are you that the signal
> frame ABI, to the extent that this patch embeds it in linux-unwind.h, will
> remain unchanged?  To what extent has that port been reviewed by Linux
> kernel people familiar with the right way to add new Linux kernel ports?

I will consult with the kernel folks on this matter.

>
> Looking at the architecture specification to resolve some questions about
> the port, I see the statement (section 7.4 Subnormal Arithmetic) "In the
> parlance of the IEEE standard, tininess is detected after rounding---that
> is, the underflow exception is raised only if the rounded result is
> subnormal, even if the unrounded result would have been subnormal.".
> That "that is" is *not* an accurate description of what after-rounding
> tininess detection means.  After-rounding tininess detection means the
> result is tiny if the result *rounded to normal precision but with
> infinite exponent range* has an exponent outside the normal range.  This
> means that some results that round to the least normal value (given the
> actual finite exponent range) count as tiny (the exact range of results
> with that property depends on the rounding mode - in round-to-nearest, for
> example, if s is the greatest subnormal and s+u is the least normal, it's
> the half-open interval [s + u/2, s + 3u/4)).  If your processor behaves as
> described in "that is", that does not conform to IEEE 754-2008 and you
> won't get clean glibc test results, for example.

That is an error in the specification; the intent is that RISC-V
implementations conform to IEEE 754-2008.  The next revision of the
spec will simply remove the "that is" clause.  Thank you for pointing
this out.

>
> I also see the architecture has roundTiesToAway support for your hardware
> binary floating point.  Do you intend to support that rounding mode from C
> code?  (I expect a fair number of glibc changes would be needed to do so,
> although the soft-fp part shouldn't be that big.)

Our expectation was that roundTiesToAway would be primarily used in
hand-written library routines, and that application code wouldn't be
interested in using it because most architectures do not provide it
for binary FP.  Perhaps that is not forward-thinking.  We will consult
with the glibc maintainers about the possibility of a RISC-V-specific
extension to the fenv API.

>
> --
> Joseph S. Myers
> joseph@codesourcery.com



More information about the Gcc-patches mailing list