4.3 Bit Encoding for Itanium Instructions
| Numerous type A Itanium instructions can share the same major opcode. They are differentiated from one another by a 2-bit opcode extension field in bits <35:34>. Most also have a second 2-bit opcode extension field in bits <28:27>, a 4-bit opcode extension field in bits <32:29>, and a 1-bit reserved opcode extension field in bit <33>. Table 4-2 illustrates the bit encodings for the Itanium addition and subtraction instructions; nobody need actually memorize binary values for the machine instructions of any modern architecture. Compilers and assemblers convert human-readable mnemonic alphanumeric opcodes into binary machine instructions. Symbolic debuggers interpret binary machine instructions back into mnemonic opcodes.
The total number of bits for an immediate constant can be collected out of the pieces in various available positions across the instruction word. We have used sign, hi, med, and lo to indicate how those pieces need to be collected by the hardware into a two's complement integer of the prescribed width. For almost all instructions, including add and sub, such an integer will be sign-extended to full 64-bit width prior to use. Note that the meanings of values 00 and 01 in bits <28:27> are reversed between the "plus 1" and "minus 1" versions of the Itanium add and sub instructions. While these appear to be arbitrary code designations, their roots lie in the design of the ISA. An illustration of instruction encoding from SQUARESWe now have enough information to interpret some of the machine code for the SQUARES program. Let us specifically deconstruct the fourth instruction bundle, which the little-endian GNU assembler expressed in its listing file (Figure 3-2) as follows: 0030 0BA05428 0020E000 04004800 00000400 In isolation, this output is difficult to interpret. We see four double words (128 bits in all), but are given no indication as to how the bytes are arranged in the bundle. To obtain more information, we can use commands to request that the Linux (little-endian) GNU debugger show the binary code of this fourth instruction bundle. We need to ascertain which quad word forms the low end of the instruction bundle: (gdb) x/xg main+3*16 0x4000000000000550 <main+48>: 0x80e020002854a00b (gdb) x/xg main+3*16+8 0x4000000000000558 <main+56>: 0x00040000004ffff6 This output seems to show us how to interpret the equivalent information from the assembly listing file (Figure 3-2). The second quad word is not fully consistent, however. This is because the debugger is working with final address values, after the linker has modified the relative addresses specified by the assembler. (Note that the same gdb commands in the HP-UX environment would print the bytes of an instruction in big-endian order.) The debugger can deconstruct the fourth instruction bundle from machine code into three Itanium instructions: (gdb) x/3i main+3*16 0x4000000000000550 <main+48>: [MMI] add r20=r21,r20;; 0x4000000000000551 <main+49>: addl r14=-48,r1 0x4000000000000552 <main+50>: nop.i 0x0;; When unpacking the three 41-bit Itanium instructions from the bundle at a virtual address corresponding to the symbol main+48, gdb represents individual instruction addresses as main+48, main+49, etc. For HP-UX, gdb instead adds :0, :1, etc. to the address. Looking back to Figures 4-1 and 4-2, we see that we should slice the 128 bits into three 41-bit instructions and one 5-bit bundle template. We introduce a hybrid {hex} and <binary> notation:
where hex character values 4, 2, and 0 have been expanded into 4-bit binary representations and vertical bars have been inserted at the boundaries suggested by Figure 4-1. Right away we learn that the 5-bit template code is 0x0b, which, along with the debugger's notation [MMI], describes the types of instructions in this bundle. Templates are discussed in detail in Chapter 10. Moving to the left, we have 2 + 9 x 4 + 3 = 41 bits for the "slot 0" instruction that is, the one in this bundle that occurs earliest in our assembly language source. Its four highest order bits at the left are 10002 = 816, representing the opcode. Looking at Table 4-2 above, we see that this could be consistent with an add instruction if bits <36:27> are appropriate. We can shift to a binary perspective and partition each 41-bit slot using Figure 4-2 for guidance and Table 4-2 for interpretation. Since we are not especially interested in the nop instruction that the assembler inserted in slot 2, we will do this only for slots 0 and 1: 0: <1 000|0 0000 0000 0|001 0100|0010 101|0 0101 00|00 0000> 8 add subcode r20 r21 r20 qp = 0 1: <1 001|1|1111 1111 1|11111|01|1010 000|0 0011 10|00 0000> 9 s med hi r1 lo r14 qp = 0 where we inserted spaces to clarify the relationship between the hex characters and their binary expansions. The instruction in slot 0 is seen to have r3=r20, r2=r21, and r1=r20 with the appropriate subcode in bits <36:27> for the specific add instruction in SQUARES. The instruction in slot 1 is seen to have the unique opcode 9 and to have r3=r1 and r1=r14. We also need to pull the sections of the 22-bit immediate operand together: imm22 = s + hi + med + lo = <11 1111 1111 1111 1101 0000> = {3fffd0} ==> {ffff ffff ffff ffd0} = decimal -48 where we have sign-extended the 22-bit immediate value to its full 64-bit width. The instruction in slot 0 is indeed an addl instruction with an immediate constant expressing the offset to be added to the global pointer (r1) at runtime, pointing to storage allocated for sq2. We are confident you will agree with us that this is tedious work! Nevertheless, in keeping with our philosophy of completing most of the stories that we begin, we felt it was important to show this relationship between mnemonic assembly language and machine language in full detail. In practice, of course, we always rely on the tools of the programming environment to deal with such tedious business. |
EAN: N/A
Pages: 223