From b32c1f7a1d37f696783eb3e23a48dafcc3557b39 Mon Sep 17 00:00:00 2001 From: Bill Schmidt Date: Thu, 27 Jun 2019 13:40:35 -0500 Subject: [PATCH] More work in chapter 2. --- Intrinsics_Reference/ch_biendian.xml | 289 ++++++++++++++++++++++++++- 1 file changed, 281 insertions(+), 8 deletions(-) diff --git a/Intrinsics_Reference/ch_biendian.xml b/Intrinsics_Reference/ch_biendian.xml index 12079d0..24597e6 100644 --- a/Intrinsics_Reference/ch_biendian.xml +++ b/Intrinsics_Reference/ch_biendian.xml @@ -78,13 +78,17 @@ xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="VIPR.biendian"> languages), these data types may be accessed based on the type names listed in when Power ISA SIMD language extensions are enabled using either the - vector or __vector keywords. NOTE - THAT THIS IS THE FIRST TIME WE'VE MENTIONED THESE LANGUAGE - EXTENSIONS, NEED TO FIX THAT. + vector or __vector keywords. [FIXME: + We haven't talked about these at all. Need to borrow some + description from the AltiVec PIM about the usage of vector, + bool, and pixel, and supplement with the problems this causes + with strict-ANSI C++. Maybe a separate section on "Language + Elements" should precede this one.] - For the Fortran language, OH YET ANOTHER STINKING TABLE gives a - correspondence between Fortran and C/C++ language types. + For the Fortran language, [FIXME: link to table in later + section] gives a correspondence between Fortran and C/C++ + language types. The assignment operator always performs a byte-by-byte data copy @@ -413,9 +417,11 @@ register vector double vd = vec_splats(*double_ptr); Vector Operators In addition to the dereference and assignment operators, the - Power SIMD Vector Programming API (REALLY?) provides the usual - operators that are valid on pointers; these operators are also - valid for pointers to vector types. + Power SIMD Vector Programming API [FIXME: If we're going to use + a term like this, let's use it consistently; also, SIMD and + Vector are redundant] provides the usual operators that are + valid on pointers; these operators are also valid for pointers + to vector types. The traditional C/C++ operators are defined on vector types @@ -452,6 +458,273 @@ register vector double vd = vec_splats(*double_ptr);
Vector Layout and Element Numbering + + Vector data types consist of a homogeneous sequence of elements + of the base data type specified in the vector data + type. Individual elements of a vector can be addressed by a + vector element number. Element numbers can be established either + by counting from the “left” of a register and assigning the + left-most element the element number 0, or from the “right” of + the register and assigning the right-most element the element + number 0. + + + In big-endian environments, establishing element counts from the + left makes the element stored at the lowest memory address the + lowest-numbered element. Thus, when vectors and arrays of a + given base data type are overlaid, vector element 0 corresponds + to array element 0, vector element 1 corresponds to array + element 1, and so forth. + + + In little-endian environments, establishing element counts from + the right makes the element stored at the lowest memory address + the lowest-numbered element. Thus, when vectors and arrays of a + given base data type are overlaid, vector element 0 will + correspond to array element 0, vector element 1 will correspond + to array element 1, and so forth. + + + Consequently, the vector numbering schemes can be described as + big-endian and little-endian vector layouts and vector element + numberings. + + + For internal consistency, in the ELF V2 ABI, the default vector + layout and vector element ordering in big-endian environments + shall be big endian, and the default vector layout and vector + element ordering in little-endian environments shall be little + endian. [FIXME: Here's a purported ABI requirement; should this + somehow remain part of the ABI document?] + + + This element numbering shall also be used by the [] + accessor method to vector elements provided as an extension of + the C/C++ languages by some compilers, as well as for other + language extensions or library constructs that directly or + indirectly refer to elements by their element number. + + + Application programs may query the vector element ordering in + use by testing the __VEC_ELEMENT_REG_ORDER__ macro. This macro + has two possible values: + + + + + + + + + __ORDER_LITTLE_ENDIAN__ + + + Vector elements use little-endian element ordering. + + + + + __ORDER_BIG_ENDIAN__ + + + Vector elements use big-endian element ordering. + + + + + +
+ +
+ Vector Built-In Functions + + Some of the POWER SIMD hardware instructions refer, implicitly + or explicitly, to vector element numbers. For example, the + vspltb instruction has as one of its inputs an + index into a vector. The element at that index position is to + be replicated in every element of the output vector. For + another example, vmuleuh instruction operates on + the even-numbered elements of its input vectors. The hardware + instructions define these element numbers using big-endian + element order, even when the machine is running in little-endian + mode. Thus, a built-in function that maps directly to the + underlying hardware instruction, regardless of the target + endianness, has the potential to confuse programmers on + little-endian platforms. + + + It is more useful to define built-in functions that map to these + instructions to use natural element order. That is, the + explicit or implicit element numbers specified by such built-in + functions should be interpreted using big-endian element order + on a big-endian platform, and using little-endian element order + on a little-endian platform. + + + The descriptions of the built-in functions in contain notes on endian issues that + apply to each built-in function. Furthermore, a built-in + function requiring a different compiler implementation for + big-endian than it uses for little-endian has a sample + compiler implementation for both BE and LE. These sample + implementations are only intended as examples; designers of a + compiler are free to use other methods to implement the + specified semantics as they see fit. + +
+ Extended Data Movement Functions + + The built-in functions in map to Altivec/VMX load and + store instructions and provide access to the “auto-aligning” + memory instructions of the VMX ISA where low-order address + bits are discarded before performing a memory access. These + instructions access load and store data in accordance with the + program's current endian mode, and do not need to be adapted + by the compiler to reflect little-endian operating during code + generation. + + + VMX Memory Access Built-In Functions + + + + + + + + + Built-in Function + + + + + Corresponding POWER + Instructions + + + + + Implementation Notes + + + + + + + + vec_ld + + + lvx + + + Hardware works as a function of endian mode. + + + + + vec_lde + + + lvebx, lvehx, lvewx + + + Hardware works as a function of endian mode. + + + + + vec_ldl + + + lvxl + + + Hardware works as a function of endian mode. + + + + + vec_st + + + stvx + + + Hardware works as a function of endian mode. + + + + + vec_ste + + + stvebx, stvehx, stvewx + + + Hardware works as a function of endian mode. + + + + + vec_stl + + + stvxl + + + Hardware works as a function of endian mode. + + + + +
+ + Previous versions of the VMX built-in functions defined + intrinsics to access the VMX instructions lvsl + and lvsr, which could be used in conjunction with + vec_vperm 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 + built-in pseudo sequences published in previous VMX documents + continue to work with little-endian data layout and the + little-endian vector layout described in this + document. However, the use of these sequences in new code is + discouraged and usually results in worse performance. It is + recommended (but not required) that compilers issue a warning + when these functions are used in little-endian + environments. It is recommended that programmers use the + vec_xl and vec_xst vector built-in + functions to access unaligned data streams. See the + descriptions of these instructions in for further description and + implementation details. + +
+
+ Big-Endian Vector Layout in Little-Endian Environments + (Deprecated) + + Versions 1.0 through 1.4 of the 64-Bit ELFv2 ABI Specification + for POWER provided for optional compiler support for using + big-endian element ordering in little-endian environments. + This was initially deemed useful for porting certain libraries + that assumed big-endian element ordering regardless of the + endianness of their input streams. In practice, this + introduced serious compiler complexity without much utility. + Thus this support (previously controlled by switches + -maltivec=be and/or -qaltivec=be) is + now deprecated. Current versions of the gcc and clang + open-source compilers do not implement this support. + +
+
+ +
+ Language-Specific Vector Support for Other + Languages filler