I think there was talk of an FP emulation library a long time ago
(before I was involved with M5) but we decided not to do something
like
that for some reason. Using regular built in FP support gets us most
of
the way with minimal hassle, but then there are situations like this
where it really causes trouble. I presume the prior discussion might
have been about whether getting most of the way there was good
enough,
and that it's simpler.
Gabe
On 10/27/11 07:43, Radivoje Vasiljevic wrote:
>
> ----- Original Message ----- From: "Gabe Black"
<[email protected]>
> To: <[email protected]>
> Sent: 25. октобар 2011 20:53
> Subject: Re: [gem5-dev] Failed SPARC test
>
>
>> On 10/25/11 07:46, Steve Reinhardt wrote:
>>> On Tue, Oct 25, 2011 at 2:30 AM, Gabe Black
<[email protected]>
>>> wrote:
>
> [snip]
>>
>> Yeah, I think ISAs treat IEEE as a really good suggestion rather
than a
>> standard. ARM isn't strictly conformant, and neither is x86. The
default
>> rounding mode *is* standard, though, and I don't think is
adjusted in
>> SPARC as a result of execution. If it changed somehow (unless I'm
>> forgetting where SPARC does that) it's a fairly significant
problem.
>> Whether instructions generate +/- 0 in various situations may
depend on,
>> for instance, what order gcc decides to put the operands. I'm not
sure
>> that it does, but there are all kinds of weird, subtle behaviors
with
>> FP, and you can't just fix how add works if x86 picked the wrong
thing.
>> Then you have to replace add, or semi-replace it by faking it out
with
>> other FP operations. If we're running real x87 instructions (we
>> shouldn't be in 64 bit mode, but we still could) then those use
80 bit
>> operands internally. Where and when rounding takes place depends
on when
>> those are moved in/out of the FPU, and will be different than
true 64
>> bit operands. SSE based FP uses real 64 bit doubles, so that
should
>> behave better. It should also be the default in 64 bit mode since
the
>> compiler can assume some basic SSE support is present.
>>
>
> What about FP emulation using integers and some kind of multiple
> precision
> arithmetic? Then every detail could be modeled, including x87
"floats"
> and
> "doubles" (in registers exponent field is still 15 bits, not 8/11
and
> makes
> mess of overflow/underflow, or it will go in memory and will be
proper
> float/double). Gcc has some switches regarding that behavior but
that is
> very fragile (more like suggestion to compiler then enforcing
option).
> Double rounding in x87 is special story because double extended
> mantissa is not more than twice longer then one for double so
double
> rounding can give different results compared to single rounding
(this
> situation can't happen
> with float vs double). One solution, for example: splitting
mantissas
> into to halves and performing operation, all bits would be
available
> and then proper any kind of rounding could be enforced (real ieee
or
> "isa style ieee"). Performing those operations is not very slow
and it
> is fairly ILP reach so slowdown is not that great as when pure
number
> of instructions is compared (although to have robust code, cpu and
> compiler independence, specially about "optimizing code" some
tests
> are needed to eradicate subnormals due poor support/trap
emulation).
> Plus if instructions are mixed in right way both int and fpu units
can
> be kept busy. Exponent can be one short and problem solved. Only
> division can be somewhattricky (and slow), but it can be done too.
>
>
>>> Even if the FP rounding error isn't the source of the problem,
it might
>>> be
>>> easiest to fix that and get it out of the way so we can see what
the
>>> actual
>>> problem is.
>>>
>>> If you really want to know *why* the kernel is doing all this
FP, then
>>> yes,
>>> you probably need to look at the source code.
>>>
>>> Steve
>>> _______________________________________________
>>> gem5-dev mailing list
>>> [email protected]
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>> _______________________________________________
>> gem5-dev mailing list
>> [email protected]
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>
>
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
