fpu/softfloat: a question on BFloat 16 support on QEMU

fpu/softfloat: a question on BFloat 16 support on QEMU

[LIU Zhiwei]

Hi Richard,

I am doing bfloat16 support on QEMU.

Once I tried to reuse float32 interface, but I couldn't properly process 
rounding in some insns like fadd.

What's your opinion about it? Should I expand the fpu/softfloat?

Best Regards,
Zhiwei

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[Alex Bennée]

LIU Zhiwei <zhiwei_liu@c-sky.com> writes:

> Hi Richard,
>
> I am doing bfloat16 support on QEMU.
>
> Once I tried to reuse float32 interface, but I couldn't properly process 
> rounding in some insns like fadd.

What do you mean by re-use the float32 interface? Isn't bfloat16 going
to be pretty much the same as float16 but with some slightly different
float parameters for the different encoding?

Like the float16 code it won't have to deal with any of the hardfloat
wrappers so it should look pretty similar.

>
> What's your opinion about it? Should I expand the fpu/softfloat?

bfloat16 is certainly going to become more common that we should have
common softfloat code to handle it. It would be nice is TestFloat could
exercise it as well.

>
> Best Regards,
> Zhiwei


-- 
Alex Bennée

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[Richard Henderson]

On 6/8/20 5:53 AM, LIU Zhiwei wrote:
> Hi Richard,
> 
> I am doing bfloat16 support on QEMU.
> 
> Once I tried to reuse float32 interface, but I couldn't properly process
> rounding in some insns like fadd.
> 
> What's your opinion about it? Should I expand the fpu/softfloat?

Yes, we need to expand fpu/softfloat.

You'll want something like

static const FloatFmt bfloat16_params = {
    FLOAT_PARAMS(8, 7)
};

(This would be the Arm and x86 definition, anyway; hopefully risc-v is the same.)

And then add all of the other interface functions that you need to use that
parameter.

FWIW, it appears that Arm only requires:

  float32_to_bfloat16
  bfloat16_mul
  bfloat16_add

and I could even get away with only float32_to_bfloat16, since technically
Arm's BFAdd and BFMul psuedo-code are implemented in terms of single-precision
arithmetic, followed by a round-to-odd into BFloat16.


r~

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[LIU Zhiwei]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]



On 2020/6/8 23:50, Alex Bennée wrote:
> LIU Zhiwei <zhiwei_liu@c-sky.com> writes:
>
>> Hi Richard,
>>
>> I am doing bfloat16 support on QEMU.
>>
>> Once I tried to reuse float32 interface, but I couldn't properly process
>> rounding in some insns like fadd.
> What do you mean by re-use the float32 interface?
Once I think bfloat16 can been converted to float32  by

deposit32(0, 16, 16, bf16)

Then do a bfloat16 op by float32 op.

At last, get the bfloat16 result by right shift the float32 result 16 bits.
> Isn't bfloat16 going
> to be pretty much the same as float16 but with some slightly different
> float parameters for the different encoding?
Agree.
> Like the float16 code it won't have to deal with any of the hardfloat
> wrappers so it should look pretty similar.
Good idea. I will list the float16 interfaces,  and try to emulate the 
bfloat16 one by one.

I list float16 interfaces in softfloat.c alone. It counts 67 interfaces.
>> What's your opinion about it? Should I expand the fpu/softfloat?
> bfloat16 is certainly going to become more common that we should have
> common softfloat code to handle it. It would be nice is TestFloat could
> exercise it as well.
Thanks. I will try to use make check-softfloat to test bfloat16 interfaces.

Best Regards,
Zhiwei
>> Best Regards,
>> Zhiwei
>


[-- Attachment #2: Type: text/html, Size: 2784 bytes --]

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[LIU Zhiwei]

On 2020/6/9 3:34, Richard Henderson wrote:
> On 6/8/20 5:53 AM, LIU Zhiwei wrote:
>> Hi Richard,
>>
>> I am doing bfloat16 support on QEMU.
>>
>> Once I tried to reuse float32 interface, but I couldn't properly process
>> rounding in some insns like fadd.
>>
>> What's your opinion about it? Should I expand the fpu/softfloat?
> Yes, we need to expand fpu/softfloat.
>
> You'll want something like
>
> static const FloatFmt bfloat16_params = {
>      FLOAT_PARAMS(8, 7)
> };
>
> (This would be the Arm and x86 definition, anyway; hopefully risc-v is the same.)
Yes. It's the same for me.
> And then add all of the other interface functions that you need to use that
> parameter.
>
> FWIW, it appears that Arm only requires:
>
>    float32_to_bfloat16
>    bfloat16_mul
>    bfloat16_add
>
> and I could even get away with only float32_to_bfloat16, since technically
> Arm's BFAdd and BFMul psuedo-code are implemented in terms of single-precision
> arithmetic, followed by a round-to-odd into BFloat16.
Some different here.

It's directly implemented in half-precision unit. So I'm afraid I have 
to implement as many as interfaces like float16.

Best Regards,
Zhiwei

>
>
> r~

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[Alex Bennée]

LIU Zhiwei <zhiwei_liu@c-sky.com> writes:

> On 2020/6/8 23:50, Alex Bennée wrote:
>> LIU Zhiwei <zhiwei_liu@c-sky.com> writes:
>>
>>> Hi Richard,
>>>
>>> I am doing bfloat16 support on QEMU.
>>>
>>> Once I tried to reuse float32 interface, but I couldn't properly process
>>> rounding in some insns like fadd.
>> What do you mean by re-use the float32 interface?
> Once I think bfloat16 can been converted to float32  by
>
> deposit32(0, 16, 16, bf16)
>
> Then do a bfloat16 op by float32 op.

No I don't think you want to be munging things like that - best to
decompose it into FloatParts and let the common code deal with the
actual calculation.

We've learnt the hard way that having lots of slightly different
functions each dealing with edge cases and rounding ends up in mistakes
creeping in. The common code path is well tested and a lot easier to
understand.

>
> At last, get the bfloat16 result by right shift the float32 result 16
> bits.

Again the common round and packing code should be agnostic to the
underlying precision.

>> Isn't bfloat16 going
>> to be pretty much the same as float16 but with some slightly different
>> float parameters for the different encoding?
> Agree.
>> Like the float16 code it won't have to deal with any of the hardfloat
>> wrappers so it should look pretty similar.
> Good idea. I will list the float16 interfaces,  and try to emulate the 
> bfloat16 one by one.
>
> I list float16 interfaces in softfloat.c alone. It counts 67 interfaces.
>>> What's your opinion about it? Should I expand the fpu/softfloat?
>> bfloat16 is certainly going to become more common that we should have
>> common softfloat code to handle it. It would be nice is TestFloat could
>> exercise it as well.
> Thanks. I will try to use make check-softfloat to test bfloat16 interfaces.
>
> Best Regards,
> Zhiwei
>>> Best Regards,
>>> Zhiwei
>>


-- 
Alex Bennée

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[LIU Zhiwei]

On 2020/6/9 17:42, Alex Bennée wrote:
> LIU Zhiwei <zhiwei_liu@c-sky.com> writes:
>
>> On 2020/6/8 23:50, Alex Bennée wrote:
>>> LIU Zhiwei <zhiwei_liu@c-sky.com> writes:
>>>
>>>> Hi Richard,
>>>>
>>>> I am doing bfloat16 support on QEMU.
>>>>
>>>> Once I tried to reuse float32 interface, but I couldn't properly process
>>>> rounding in some insns like fadd.
>>> What do you mean by re-use the float32 interface?
>> Once I think bfloat16 can been converted to float32  by
>>
>> deposit32(0, 16, 16, bf16)
>>
>> Then do a bfloat16 op by float32 op.
> No I don't think you want to be munging things like that - best to
> decompose it into FloatParts and let the common code deal with the
> actual calculation.
>
> We've learnt the hard way that having lots of slightly different
> functions each dealing with edge cases and rounding ends up in mistakes
> creeping in. The common code path is well tested and a lot easier to
> understand.
Get it. Thanks.
If I am ready, I will upstream the bfloat16 code.

Best Regards,
Zhiwei
>> At last, get the bfloat16 result by right shift the float32 result 16
>> bits.
> Again the common round and packing code should be agnostic to the
> underlying precision.
>
>>> Isn't bfloat16 going
>>> to be pretty much the same as float16 but with some slightly different
>>> float parameters for the different encoding?
>> Agree.
>>> Like the float16 code it won't have to deal with any of the hardfloat
>>> wrappers so it should look pretty similar.
>> Good idea. I will list the float16 interfaces,  and try to emulate the
>> bfloat16 one by one.
>>
>> I list float16 interfaces in softfloat.c alone. It counts 67 interfaces.
>>>> What's your opinion about it? Should I expand the fpu/softfloat?
>>> bfloat16 is certainly going to become more common that we should have
>>> common softfloat code to handle it. It would be nice is TestFloat could
>>> exercise it as well.
>> Thanks. I will try to use make check-softfloat to test bfloat16 interfaces.
>>
>> Best Regards,
>> Zhiwei
>>>> Best Regards,
>>>> Zhiwei
>

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[LIU Zhiwei]

[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]



On 2020/6/8 23:50, Alex Bennée wrote:
> LIU Zhiwei <zhiwei_liu@c-sky.com> writes:
>
>> Hi Richard,
>>
>> I am doing bfloat16 support on QEMU.
>>
>> Once I tried to reuse float32 interface, but I couldn't properly process
>> rounding in some insns like fadd.
> What do you mean by re-use the float32 interface? Isn't bfloat16 going
> to be pretty much the same as float16 but with some slightly different
> float parameters for the different encoding?
>
> Like the float16 code it won't have to deal with any of the hardfloat
> wrappers so it should look pretty similar.
>
>> What's your opinion about it? Should I expand the fpu/softfloat?
> bfloat16 is certainly going to become more common that we should have
> common softfloat code to handle it. It would be nice is TestFloat could
> exercise it as well.
Hi Alex,

I have add the bfloat16 interfaces in QEMU softfloat.  Now I moved 
forward to test the bfloat16 interfaces.

When I looked into the fp-test.c and the berkeley-testfloat-3, I found 
it's some difficult to add bfloat16 interfaces test cases.

There are no corresponding bfloat16 slow_X interlaces in slowfloat.c. 
Nor there is bfloat16 test_X interfaces in berkeley-testfloat-3.

case F16_MULADD:

  test_abcz_f16(slow_f16_mulAdd, qemu_f16_mulAdd);

  break;


If I want to test bfloat16 interfaces, could you give some advice? 
Should I need to modify berkeley-testfloat-3 to support the bfloat16 test.

Best Regards,
Zhiwei

>> Best Regards,
>> Zhiwei
>


[-- Attachment #2: Type: text/html, Size: 2603 bytes --]

Re: fpu/softfloat: a question on BFloat 16 support on QEMU

[Richard Henderson]

On 6/17/20 12:09 AM, LIU Zhiwei wrote:
> If I want to test bfloat16 interfaces, could you give some advice? Should I
> need to modify berkeley-testfloat-3 to support the bfloat16 test.

I think we'll have to write some new code for this.

Easiest might be:
  (1) shift left to convert bfloat16 to float32,

  (2) if the current rounding mode is directed
      (float_round_{down,up,to_zero}), use that;
      otherwise use float_round_to_odd so that
      we can get the correct bfloat16 rounding later.

  (3) use the float32 arithmetic routine.

  (4) round to bfloat16 as per the current mode.

This should not require too much new code.


r~