[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150326051129.GF23507@brightrain.aerifal.cx>
Date: Thu, 26 Mar 2015 01:11:30 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: GSoC 2015. Porting musl libc to RISC-V project. Proposal
help and feedback.
On Thu, Mar 26, 2015 at 01:12:03PM +1000, Roman Titov wrote:
> Hello, musl.
>
> At the moment I'm working on pre-final form of my proposal and I
> need some help here.
> I defined 3 milestones for the project:
>
> * Milestone #1 (MANDATORY):
> Complete musl-libc port for riscv-linux, targeting RV32G and
> RV64G ISAs.
Can you clarify the G suffix?
> * Milestone #2 (MANDATORY):
> *Analysis* and/or testing of potential optimization candidates.
> What, why and how could be further optimized and which perfomance
> increase expected.
>
> * Milestone #3 (OPTIONAL):
> Implementation (partial or full) of *found* optimizations with
> constant functional and regression *testing*.
>
> I need help with exact criterion definitions for milestone #1.
> "Complete musl-libc port..." is nothing. We can't rate level of
> success or failure here, as no obligations given and so, this is not
> a good proposal milestone.
Roughly it should mean a working, non-stub version of each mandatory
arch-specific file musl needs, where working can be demonstrated in
some way. For functionality not already covered by one of the tests in
libc-test, it may be nice to add tests to libc-test as a means of
demonstrating that there are no obvious failures.
> ***
> So, here are my suggestions:
>
> Functional criterion:
> riscv-musl (lets call it so) should pass all libc-test
> [http://wiki.musl-libc.org/wiki/Libc-Test] tests, except tests for:
> * optional features that are not implemented in musl yet (e.g.
> posix/XSI, mentioned at libc-test musl-wiki page above)
At his point I don't think there are any optional features tested that
aren't implemented. There are a few mandatory macros that aren't
defined in musl's headers due to lack of an established value they
should have but these failures are obvious. The rest of the current
failures on "working" archs are minor math issues and known bugs with
pending fixes. Aside perhaps from math issues where the C code is less
accurate than existing x86 asm, a new "working" arch should not have
failures that don't also show up on x86.
> * features, that could not be implemented, because of ISA limitations
This should not include anything except fenv on soft-float archs. I'm
not clear on whether the proposed port is soft-float, hard-float, or
both, and whether there would be separate ABIs for both or just one
ABI.
> * features, that could not be implemented, because of riscv-toolkit
> limitations (e.g. unimplemented riscv-gcc or riscv-linux feature/API
> or unstable riscv-gcc or riscv-linux API/ABI)
I don't believe anything like that will exist. Do you have examples in
mind?
> Of course reasoned explanation of "why particular feature was not
> implemented" should (and would) be granted.
Yes, if there's a reason something can't be done then it would be
reasonable to document that. But I don't anticipate hitting such
issues anyway.
> Perfomance criterion:
> riscv-musl should be tested with libc-bench [http://www.etalabs.net/libc-bench.html][http://git.musl-libc.org/cgit/libc-bench/]
> benchmark and should not show any significant regression compared to
> existing riscv-musl benchmarking results
> [http://www.etalabs.net/compare_libcs.html] for other platforms.
It might make sense to do some new timing tests, especially as part of
an evaluation of where further work is needed.
> (Right now I still have no better perfomance criterion and no better
> definition of "significant regression" than "intuitive" one.
> Generally, my idea is to compare riscv-musl libc-bench results with
> existing musl implementations and with existing riscv-glibc.
> riscv-musl and musl results should correlate, if any riscv-glibc
> results is 2 times better - investigate.)
> ***
Do you know if testing on real hardware will be possible, or if the
emulator can simulate "real hardware" timing.
> Any feedback is highly appreciated.
> Is this milestones *ok* and *enough for the job*? Do you *agree*
> with them? (probably not so significant to musl, as for lowRISC,
> which is actual project "owner")
> Are my criterions *ok*? Do you *agree* with them?
> *Any* additions, deletions, corrections, advices, etc.
>
> "Full" version of proposal would be in a few hours.
As I mentioned on IRC I'm still travelling from ELC right now so I
haven't had a chance to review and comment to the extent I'd like.
I'll try to give more feedback tomorrow.
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.
