[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/7] target/riscv: Generate nanboxed results from fp helpe
Re: [PATCH v2 1/7] target/riscv: Generate nanboxed results from fp helpers
Thu, 6 Aug 2020 18:02:27 +0800
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
On 2020/8/6 16:42, Chih-Min Chao wrote:
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
>>> Make sure that all results from
single-precision scalar helpers
>>> are properly nan-boxed to 64-bits.
>>> Signed-off-by: Richard Henderson <firstname.lastname@example.org>
>>> target/riscv/internals.h | 5
>>> target/riscv/fpu_helper.c | 42
>>> 2 files changed, 28 insertions(+),
>>> 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
>>> + return f | MAKE_64BIT_MASK(32,
>> If define it here, we can also define a
more general function with flen.
>> +static inline uint64_t nanbox_s(float32
f, uint32_t flen)
>> + return f | MAKE_64BIT_MASK(flen, 64
>> 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
> 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 and
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
I have an implementation based on this draft and will
send it as RFC patch next week.
Thanks for your information.
As Krste said once, as we don't have RV16, FP16 separated won't
make sense. Obviously, it has changed.:-P
I also have implemented a version of FP16 ,“obvious set including existing FP
instructions with format field set to "half" (fmt=10)“
If you want to send the patch, I will not send it again.:-)