[riscv-hw] Re: Reg. Re-coded format FPU

[Palmer Dabbelt]

On Sun, 07 Feb 2016 20:33:50 PST (-0800), g.vin...@gmail.com wrote:
> I am a student working on FPU in IIT Madras for a
> microprocessor. I saw the recoded format for efficient handling of
> subnormal numbers but I was not able to make much sense out of the given
> examples. Will it be possible for you to provide me with better
> explanations for your recoded format so we can incorporate it in our unit
> to handle subnormal numbers better?

From my limited understanding of the recoded floating point format we use, the
extra bit just removes the special case to handle subnormal numbers by having
enough state to just store them.

This might be wrong, though, as I don't really know anything about this. The
people who know this stuff read hw-...@lists.riscv.org, which I've added to the
thread.

[Andrew Waterman]

That's right; an extra exponent bit allows storing subnormals in a
normalized form. The exponents are also two's complement rather than
biased, and a few special cases (NaN, Inf, zero) can be checked by
looking only at a few bits, rather than the whole number. For some
examples, see https://github.com/ucb-bar/berkeley-hardfloat/blob/master/README.md

[Madhu (Macaque Labs)]

Makes sense. We just finished most of our pipelined FPU. Once we finish

verification against the IBM test cases, will get Vinod to incorporate this encoding.

Any implications of the encoding apart from it not being IEEE compatible ?

Not that I particularly care, my only concern is the performance !

--

Regards,

Madhu

[Thomas Sohmers]

One of the cool things about how Rocket/hardfloat handles the recoded format is that to the outside world, it is IEEE compatible... The is a recoding stage as part of hardfloat which goes from IEEE 32/64 bit form to the Berkeley recoded format, and then from the recoded format back to IEEE. As Andrew said, handling subnormals is a real pain, and while adding recoding does technically add logic/complexity, it is a lot simpler than handling cases with subnormal numbers.

Thomas Sohmers

(978)-212-9856

CEO, REX Computing

http://rexcomputing.com

[Madhu (Macaque Labs)]

That I figured ! The conversion cost does seem worth it compared to the benefits. This should be highlighted
in the README. And it does not really matter

if the internal format is not IEEE.

--

Regards,

Madhu

[Christopher Celio]

Any implications of the encoding apart from it not being IEEE compatible ?

Not that I particularly care, my only concern is the performance !

I found one nuisance of the 65-bit encoding is that it highlights some undefined behavior in the user-level spec: stack spills of single-precision values from the f-registers write undefined values to memory (for good reason). 

From the manual:

If a floating-point register holds a single-precision value, it is guaranteed that a FSD of that register will place a value into memory that when reloaded with a FLD will recreate the original single-precision value in a register. The data format that is stored in memory is undefined beyond having this property.

"User-level code might not know the current type of data stored in a floating-point register but has to be able to save and restore the register values. A common case is for callee-save registers, but this is also essential to implement varargs and user-level threading libraries." - page 48

In my case, the annoyance is that this makes A/B testing against something like Spike a tad more challenging.  Nothing impossible, mind you, but it's another thing to keep in mind and and handle with some post-processing.

-Chris