On 2020/8/6 14:09, Chih-Min Chao wrote:
On 2020/7/24 11:55, Richard Henderson wrote:
> On 7/23/20 7:35 PM, LIU Zhiwei wrote:
>> On 2020/7/24 8:28, Richard Henderson wrote:
>>> Make sure that all results from
single-precision scalar helpers
>>> are properly nan-boxed to 64-bits.
>>> Signed-off-by: Richard Henderson <email@example.com>
>>> target/riscv/internals.h | 5 +++++
>>> target/riscv/fpu_helper.c | 42
>>> 2 files changed, 28 insertions(+), 19
>>> diff --git a/target/riscv/internals.h
>>> index 37d33820ad..9f4ba7d617 100644
>>> --- a/target/riscv/internals.h
>>> +++ b/target/riscv/internals.h
>>> @@ -38,4 +38,9 @@ target_ulong
>>> #define SEW32 2
>>> #define SEW64 3
>>> +static inline uint64_t nanbox_s(float32 f)
>>> + return f | MAKE_64BIT_MASK(32, 32);
>> If define it here, we can also define a more
general function with flen.
>> +static inline uint64_t nanbox_s(float32 f,
>> + return f | MAKE_64BIT_MASK(flen, 64 - flen);
>> So we can reuse it in fp16 or bf16 scalar
instruction and in vector instructions.
> While we could do that, we will not encounter all
possible lengths. In the
> cover letter, I mentioned defining a second function,
> static inline uint64_t nanbox_h(float16 f)
> return f | MAKE_64BIT_MASK(16, 48);
> Having two separate functions will, I believe, be
easier to use in practice.
Get it. Thanks.
That is what has been implemented in spike. It fills up
the Nan-Box when value is stored back internal structure
unbox the value with difference floating type
Has half-precision been a part of RVV? Or do you know the ISA
abbreviation of half-precision?
Thanks very much.
By the way, I prefer to keeping the suffix to tell
different floating type rather than pass arbitrary