This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: disabling libm



"J. Johnston" wrote:
> 
> Joel Sherrill wrote:
> >
> > "J. Johnston" wrote:
> >
> >>Joel Sherrill wrote:
> >>
> >>>Hi,
> >>>
> >>>I am trying to update my tic4x toolset.  The tic4x does not
> >>>use IEEE FP.  The last time I looked into this, the newlib libm
> >>>was very IEEE FP format dependent.  It would be easier to not
> >>>have newlib's libm for now.  Is it possible to completely disable
> >>>it for a target?
> >>>
> >>
> >>It is definitely "possible" via configuration; the question is whether
> >>it is warranted.  Does the build fail or do any of the libm files
> >>placed in libc cause problems?  I assume you are already just linking
> >>in your own libm stuff anyway.
> >
> >
> > I have managed to get a build to complete at this point with libm.
> > Speaking without doing an up to date analysis, this libm is heavily
> > dependent on IEEE floating point format.  The tic4x target is not
> > IEEE so very little if anything works even if it compiles.
> >
> > I have a hacked together libm substitute that is far from optimal
> > but tries to be portable.  But really I would like to see newlib
> > work better with non-IEEE FPUs.  Any ideas?
> >
> 
> Well, the mathfp stuff uses a number of floating-point algorithms
> that should work for the platform.  So, for starters. try
> --enable-newlib-hw-fp to configure.  There are still some IEEE-isms
> found there, but a lot of basics are provided (e.g. sin/cos) in
> float algorithms.

OK.  I have a set of assembly routines that go to the FPU for
core routines so this could be a logical progression.

> You will need to replace a number of the routines in libm/common.
> For this, there is the libm/machine directory.  Add a tic4x directory
> and start adding stuff in there.  With the stuff in common replaced,
> you should have a good basic math set.  Finally, you can replace any
> other remaining routines in mathfp that are IEEE dependent.

OK.  I wish the simulator worked.  I don't feel bad about merging 
existing patches or updating old patches but adding LOTS of new code
is always questionable without a good way to test. :(

> -- Jeff J.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]