----- 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
