[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200415163015.GG11469@brightrain.aerifal.cx>
Date: Wed, 15 Apr 2020 12:30:15 -0400
From: Rich Felker <dalias@...c.org>
To: sidneym@...eaurora.org
Cc: musl@...ts.openwall.com
Subject: Re: Hexagon DSP support
On Wed, Apr 15, 2020 at 08:19:29AM -0500, sidneym@...eaurora.org wrote:
> Recently work has been done with clang/llvm/lld to extend support for
> Qualcomm's Hexagon DSP to a Linux target. At this point the publicly
> available LLVM tools are able to build and run Hexagon programs via QEMU.
> I've attached a patch that add the Hexagon bits to musl. The optimized
> routines have been purposely omitted to keep the size and complexity to a
> minimum.
>
> The changes are being mirrored here:
> https://github.com/quic/musl/tree/hexagon
> The QEMU mirror is here: https://github.com/quic/qemu
> A description of the assembly language is here:
> https://developer.qualcomm.com/download/hexagon/hexagon-v5x-programmers-refe
> rence-manual.pdf?referrer=node/6116
>
> The objective is to have enough freely available tools and libraries that
> any user could develop code for the DSP. The C-library is an important part
> of that stack and this patch is intended to start a discussion of what would
> need to happen in order for Hexagon to be added to the musl sources.
Thanks for reaching out upstream and sharing this. I did a quick
glance over the port (mostly just arch/hexagon dir, not source dirs in
any detail) and what I've read so far looks good.
One question I have: alltypes.h.in defines _REDIR_TIME64. Is this
because there's an existing unofficial ABI in deployments that you
don't want to break? If so that's probably okay, but if not it's not
necessary or wanted for new 32-bit archs to define this; if it's not
defined, the unadorned symbol names will just be 64-bit versions, just
like on 64-bit archs.
> I've tested this using libc-test (git://repo.or.cz/libc-test) and 56 errors
> are reported. The support for Hexagon in QEMU is on-going and while some of
> the errors (math) may be attributed to QEMU most also happen on hardware. A
> good chunk fail due to floating point exception status or precision.
Can you send the output report to the list or post it somewhere
publicly accessible? I can probably give you a quick rundown on
whether any of the failures are unexpected (on qemu or real hardware)
and it will suggest which parts of the source I (and others in the
community) should focus on reviewing.
Rich
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.
