On 2017/12/12 2:58, Suzuki K Poulose wrote: > Hi gengdongjiu > > Sorry for the late response. I have a similar patch to add the support for > "FHM", which I was about to post it this week. Suzuki, you are welcome. May be you can not post again to avoid the duplicate review, thanks!
> > On 11/12/17 13:29, Dave Martin wrote: >> On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote: >>> >>> On 2017/12/11 19:59, Dave P Martin wrote: >>>> On Sat, Dec 09, 2017 at 03:28:42PM +0000, Dongjiu Geng wrote: >>>>> ARM v8.4 extensions include support for new floating point >>>>> multiplication variant instructions to the AArch64 SIMD >>>> >>>> Do we have any human-readable description of what the new instructions >>>> do? >>>> >>>> Since the v8.4 spec itself only describes these as "New Floating >>>> Point Multiplication Variant", I wonder what "FHM" actually stands >>>> for. >>> 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. >> >> 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. > > I think the FHM stands for "FP Half precision Multiplication instructions". I > vote for keeping the feature bit in sync with the register bit definition. > i.e, FHM. agree with you > > However, my version of the patch names the HWCAP bit "asimdfml", following > the compiler name for the feature option "fp16fml", which > is not perfect either. I think FHM is the safe option here. yes, "FHM" is safe here. > >> >>>> 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. >> > > I agree, and that matches the feature description. Ok, thanks! > > -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html