From db465c12666db1c8ab6c0d658b45a04fdb669817 Mon Sep 17 00:00:00 2001 From: "Paul A. Clarke" Date: Thu, 14 May 2020 15:12:06 -0500 Subject: [PATCH] Change references to intrinsics into links Signed-off-by: Paul A. Clarke --- Intrinsics_Reference/ch_biendian.xml | 178 +++++++++++++++------------ 1 file changed, 96 insertions(+), 82 deletions(-) diff --git a/Intrinsics_Reference/ch_biendian.xml b/Intrinsics_Reference/ch_biendian.xml index dd368fc..a8557cf 100644 --- a/Intrinsics_Reference/ch_biendian.xml +++ b/Intrinsics_Reference/ch_biendian.xml @@ -180,8 +180,9 @@ vector unsigned __int128 x = { (((unsigned __int128)0x1020304050607080) << to access the Nth vector element from a vector pointer. The dereference operator * may not be used to access data that is not - aligned at least to a quadword boundary. Built-in functions - such as vec_xl and vec_xst are + aligned at least to a quadword boundary. Built-in functions such as + and + and provided for unaligned data access. Please refer to for an example. @@ -796,238 +797,238 @@ a[3] = c; - vec_bperm + - vec_mergeh + - vec_signedo + - vec_cipher_be + - vec_mergel + - vec_sld + - vec_cipherlast_be + - vec_mergeo + - vec_sldw + - vec_doublee + - vec_mfvscr + - vec_sll + - vec_doubleh + - vec_mule + - vec_slo + - vec_doublel + - vec_mulo + - vec_slv + - vec_doubleo + - vec_ncipher_be + - vec_splat + - vec_extract + - vec_ncipherlast_be + - vec_srl + - vec_extract_fp32_from_shorth + - vec_pack + - vec_sro + - vec_extract_fp32_from_shortl + - vec_pack_to_short_fp32 + - vec_srv + - vec_extract4b + - vec_packpx + - vec_sum2s + - vec_first_match_index + - vec_packs + - vec_sums + - vec_first_match_or_eos_index + - vec_packsu + - vec_unpackh + - vec_first_mismatch_index + - vec_perm + - vec_unpackl + - vec_first_mismatch_or_eos_index + - vec_permxor + - vec_unsigned2 + - vec_float2 + - vec_pmsum_be + - vec_unsignede + - vec_floate + - vec_reve + - vec_unsignedo + - vec_floato + - vec_sbox_be + - vec_xl (ISA 2.07 only) + (ISA 2.07 only) - vec_gb + - vec_shasigma_be + - vec_xl_be + - vec_insert + - vec_signed2 + - vec_xst (ISA 2.07 only) + (ISA 2.07 only) - vec_insert4b + - vec_signede + - vec_xst_be + - vec_mergee + @@ -1056,7 +1057,8 @@ a[3] = c; Before the bi-endian programming model was introduced, the vec_lvsl and vec_lvsr intrinsics were supported. These could be used in conjunction with - vec_perm and VMX load and store instructions for + + and VMX load and store instructions for unaligned access. The vec_lvsl and vec_lvsr interfaces are deprecated in accordance with the interfaces specified here. For compatibility, the @@ -1097,7 +1099,7 @@ a[3] = c; - vec_ld + lvx @@ -1108,7 +1110,7 @@ a[3] = c; - vec_lde + lvebx, lvehx, lvewx @@ -1119,7 +1121,7 @@ a[3] = c; - vec_ldl + lvxl @@ -1130,7 +1132,7 @@ a[3] = c; - vec_st + stvx @@ -1141,7 +1143,7 @@ a[3] = c; - vec_ste + stvebx, stvehx, stvewx @@ -1152,7 +1154,7 @@ a[3] = c; - vec_stl + stvxl @@ -1166,7 +1168,9 @@ a[3] = c; Instead, it is recommended that programmers use the - vec_xl and vec_xst vector built-in + and + + vector built-in functions to access unaligned data streams. See the descriptions of these instructions in for further description and @@ -1479,35 +1483,44 @@ a[3] = c; vec_sld and vec_sro are not bi-endian One oddity in the bi-endian vector programming model is that - vec_sld has big-endian semantics for code + + has big-endian semantics for code compiled for both big-endian and little-endian targets. That - is, any code that uses vec_sld without guarding + is, any code that uses + + without guarding it with a test on endianness is likely to be incorrect. At the time that the bi-endian model was being developed, it was discovered that existing code in several Linux packages - was using vec_sld in order to perform multiplies, + was using + + in order to perform multiplies, or to otherwise shift portions of base elements left. A straightforward little-endian implementation of - vec_sld would concatenate the two input vectors + + would concatenate the two input vectors in reverse order and shift bytes to the right. This would only give compatible results for vector char types. Those using this intrinsic as a cheap multiply, or to shift bytes within larger elements, would see different results on little-endian versus big-endian with such an implementation. Therefore it was decided that - vec_sld would not have a bi-endian + + would not have a bi-endian implementation. - vec_sro is not bi-endian for similar reasons. + + is not bi-endian for similar reasons.
Limitations on bi-endianness of vec_perm - The vec_perm intrinsic is bi-endian, provided + The + intrinsic is bi-endian, provided that it is used to reorder entire elements of the input vectors. @@ -2533,7 +2546,8 @@ a[3] = c; - The lesson here is to only use vec_perm to + The lesson here is to only use + to reorder entire elements of a vector. If you must use vec_perm for another purpose, your code must include a test for endianness and separate algorithms for big- and