Since it's very easy to avoid the use of floating point in
the kernel, it has not been a big issue.
Do you need to use floating point in the kernel for some reason?
- Dan
-----Original Message-----
From: Conn Clark
To: May Ling List
Sent: 4/24/2002 9:56 AM
Subject: What problems are there with floating point emulation in the
kernel?
Hello everyone,
I've been told on this list that there are problems fpu
emulation
in the kernel. I was curoius as to what the errors are and the aftermath
(pun intended) that occurs when they are encountered. ( Like are the
values off a little bit or a lot, does it cause a kerel panic, does it
block interupts, does it unleash a terible monster that will destroy the
universe, etc... .)
I'm also very supprised that Motorola and IBM haven't dedicated
some resources to address these problems since their fpu-less chips are
often used in linux designs.
thanks in advance,
Conn
--
*****************************************************************
If you live at home long enough, your parents will move out.
*****************************************************************
Conn Clark
Engineering Stooge clark@esteem.com
Electronic Systems Technology Inc. www.esteem.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Dan Kegel wrote:
Since it's very easy to avoid the use of floating point in
the kernel, it has not been a big issue.
Do you need to use floating point in the kernel for some reason?
- Dan
Its not the use of floating point in the kernel thats the problem.
I would like to "emulate" the fpu in the kernel so I can
compile glibc and everything else with fpu instructions to save
ram. I have been told however that there are "issues" with this
approach, and the only way to go is to emulate the fpu in the
kernel and compile everything with soft float. What I want to
know is what these issues are? (accuracy,segment_fault,etc..)
Conn
--
*****************************************************************
If you live at home long enough, your parents will move out.
*****************************************************************
Conn Clark
Engineering Stooge clark@esteem.com
Electronic Systems Technology Inc. www.esteem.com
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Conn Clark wrote:
Its not the use of floating point in the kernel thats the problem.
I would like to "emulate" the fpu in the kernel so I can
compile glibc and everything else with fpu instructions to save
ram. I have been told however that there are "issues" with this
approach, and the only way to go is to emulate the fpu in the
kernel and compile everything with soft float. What I want to
know is what these issues are? (accuracy,segment_fault,etc..)
Oh. Right. Well, google reports at least one issue with the code;
see http://groups.google.com/groups?selm=fa.h1feiov.9jqg8k%40ifi.uio.no
Mikael Pettersson (mikpe@csd.uu.se)
Subject: Re: Kernel bugs found using inspect tool
Newsgroups: fa.linux.kernel
Date: 2000/02/25
Ricky Beam writes:
> On Tue, 22 Feb 2000, Rupp, Ed J wrote:
> >the AT&T toolchest called 'inspect'. I found 10 near-certain
> >bugs which may or may not be causing any observable problems
> >and 13 probable bugs which I couldn't immediately tell if they ...
> >===== Questionable ====
> >arch/ppc/math-emu/op-4.h: comparison takes precedence over assignment near
> >line 215
> > (x3 += ((x2 += ((x1 += ((x0 += i) < x0)) < x1) < x2)))
This whole expression is broken.
The evaluation order for the "<" operator is unspecified, which means that
subexpressions like "((x0 += i) < x0)" do not have well-defined values.
They also violate the ANSI-C rules about permissible accesses and updates
of variables between sequence points.
- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/