Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180913125130.GT4418@port70.net>
Date: Thu, 13 Sep 2018 14:51:30 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Cortex-M support / single float

* Jon Chesterfield <jonathanchesterfield@...il.com> [2018-09-13 12:30:45 +0100]:
> > note that a large part of the float code in libc is in the
> > math library which expects efficient double arithmetics,
> > i plan to rewrite the most important single precision math
> > functions using double arithmetics, this gives significant
> > benefits on all systems except ones with single precision
> > only hw.
> >
> 
> I'm responsible for libm on an architecture with 32bit float in hardware
> and 64bit float via integer ops. It's derived from musl because I like musl.
> 
> Currently operations written in terms of double are rather slow. Would
> upstream accept functions optimised for a 32bit float+int system? I haven't
> written them yet but it's on the todo list.
> 

the math code already has target specific code because of
different long double formats, but the policy in musl is to
minimize such variation because of maintainability.

currently we dont support hw float + soft double systems,
but i think such code is acceptable if it's for supporting a
specific target (i think what we would really like to avoid
is configurability: if users of a target can choose between
several different options and change behaviour with many
knobs, that would be hard to test/maintain)

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.