[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 Dec 2017 09:44:06 +0800
From: gengdongjiu <gengdongjiu@...wei.com>
To: Dave Martin <Dave.Martin@....com>
CC: Mark Rutland <Mark.Rutland@....com>,
"guohanjun@...wei.com" <guohanjun@...wei.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
Suzuki Poulose <Suzuki.Poulose@....com>,
"Catalin Marinas" <Catalin.Marinas@....com>,
"corbet@....net" <corbet@....net>,
"Will Deacon" <Will.Deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linuxarm@...wei.com" <linuxarm@...wei.com>,
"zhihui.gao@...wei.com" <zhihui.gao@...wei.com>,
"huangshaoyu@...wei.com" <huangshaoyu@...wei.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"arvind.yadav.cs@...il.com" <arvind.yadav.cs@...il.com>,
Robin Murphy <Robin.Murphy@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"zhanghaibin7@...wei.com" <zhanghaibin7@...wei.com>
Subject: Re: [RESEND PATCH] arm64: v8.4: Support for new floating point
multiplication variant
On 2017/12/11 21:29, Dave Martin wrote:
>> Thanks for the point out.
>> In fact, this feature only adds two instructions:
>> FP16 * FP16 + FP32
>> FP16 * FP16 - FP32
>>
>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>> will call "FHM", I think call it "FMLXL" may be better, which can
>> stand for FMLAL/FMLSL instructions.
> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
> to match the ISAR0 field name -- we've tended to follow this policy
> for other extension names unless there's a much better or more obvious
> name available
Agree with you, I also think the "FHM" is better.
>
> For "FMLXL", new instructions might be added in the future that match
> the same pattern, and then "FMLXL" could become ambiguous. So maybe
> this is not the best choice.
Ok.
>
>>> Maybe something like "widening half-precision floating-point multiply
>>> accumulate" is acceptable wording consistent with the existing
>>> architecture, but I just made that up, so it's not official ;)
>> how about something like "performing a multiplication of each FP16
>> element of one vector with the corresponding FP16 element of a second
>> vector, and to add or subtract this without an intermediate rounding
>> to the corresponding FP32 element in a third vector."?
> We could have that, I guess.
Ok, thanks!
>
>>>> instructions set. Let the userspace know about it via a
>>>> HWCAP bit and MRS emulation.
Powered by blists - more mailing lists