diff options
Diffstat (limited to 'src/cmd/internal/obj')
| -rw-r--r-- | src/cmd/internal/obj/arm64/doc.go | 53 | ||||
| -rw-r--r-- | src/cmd/internal/obj/inl.go | 26 | ||||
| -rw-r--r-- | src/cmd/internal/obj/objfile.go | 16 | ||||
| -rw-r--r-- | src/cmd/internal/obj/ppc64/doc.go | 277 | ||||
| -rw-r--r-- | src/cmd/internal/obj/riscv/cpu.go | 8 | ||||
| -rw-r--r-- | src/cmd/internal/obj/riscv/obj.go | 4 |
6 files changed, 192 insertions, 192 deletions
diff --git a/src/cmd/internal/obj/arm64/doc.go b/src/cmd/internal/obj/arm64/doc.go index 1234a3e818..2763cf4139 100644 --- a/src/cmd/internal/obj/arm64/doc.go +++ b/src/cmd/internal/obj/arm64/doc.go @@ -11,7 +11,7 @@ Instructions mnemonics mapping rules 1. Most instructions use width suffixes of instruction names to indicate operand width rather than using different register names. - Examples: +Examples: ADC R24, R14, R12 <=> adc x12, x24 ADDW R26->24, R21, R15 <=> add w15, w21, w26, asr #24 FCMPS F2, F3 <=> fcmp s3, s2 @@ -20,7 +20,7 @@ using different register names. 2. Go uses .P and .W suffixes to indicate post-increment and pre-increment. - Examples: +Examples: MOVD.P -8(R10), R8 <=> ldr x8, [x10],#-8 MOVB.W 16(R16), R10 <=> ldrsb x10, [x16,#16]! MOVBU.W 16(R16), R10 <=> ldrb x10, [x16,#16]! @@ -39,7 +39,7 @@ ldrsh, sturh, strh => MOVH. 5. Go adds a V prefix for most floating-point and SIMD instructions, except cryptographic extension instructions and floating-point(scalar) instructions. - Examples: +Examples: VADD V5.H8, V18.H8, V9.H8 <=> add v9.8h, v18.8h, v5.8h VLD1.P (R6)(R11), [V31.D1] <=> ld1 {v31.1d}, [x6], x11 VFMLA V29.S2, V20.S2, V14.S2 <=> fmla v14.2s, v20.2s, v29.2s @@ -52,7 +52,7 @@ Go asm supports the PCALIGN directive, which indicates that the next instruction to a specified boundary by padding with NOOP instruction. The alignment value supported on arm64 must be a power of 2 and in the range of [8, 2048]. - Examples: +Examples: PCALIGN $16 MOVD $2, R0 // This instruction is aligned with 16 bytes. PCALIGN $1024 @@ -63,7 +63,8 @@ its address will be aligned to the same or coarser boundary, which is the maximu alignment values. In the following example, the function Add is aligned with 128 bytes. - Examples: + +Examples: TEXT ·Add(SB),$40-16 MOVD $2, R0 PCALIGN $32 @@ -79,7 +80,7 @@ have the same alignment as the first hand-written instruction. In the following example, PCALIGN at the entry of the function Add will align its address to 2048 bytes. - Examples: +Examples: TEXT ·Add(SB),NOSPLIT|NOFRAME,$0 PCALIGN $2048 MOVD $1, R0 @@ -91,7 +92,7 @@ In the following example, PCALIGN at the entry of the function Add will align it Go asm uses VMOVQ/VMOVD/VMOVS to move 128-bit, 64-bit and 32-bit constants into vector registers, respectively. And for a 128-bit interger, it take two 64-bit operands, for the low and high parts separately. - Examples: +Examples: VMOVS $0x11223344, V0 VMOVD $0x1122334455667788, V1 VMOVQ $0x1122334455667788, $0x99aabbccddeeff00, V2 // V2=0x99aabbccddeeff001122334455667788 @@ -104,7 +105,7 @@ is the 16-bit unsigned immediate, in the range 0 to 65535; For the 32-bit varian The current Go assembler does not accept zero shifts, such as "op $0, Rd" and "op $(0<<(16|32|48)), Rd" instructions. - Examples: +Examples: MOVK $(10<<32), R20 <=> movk x20, #10, lsl #32 MOVZW $(20<<16), R8 <=> movz w8, #20, lsl #16 MOVK $(0<<16), R10 will be reported as an error by the assembler. @@ -121,7 +122,7 @@ Special Cases. related to real ARM64 instruction. NOOP serves for the hardware nop instruction. NOOP is an alias of HINT $0. - Examples: +Examples: VMOV V13.B[1], R20 <=> mov x20, v13.b[1] VMOV V13.H[1], R20 <=> mov w20, v13.h[1] JMP (R3) <=> br x3 @@ -146,7 +147,7 @@ Argument mapping rules Go reverses the arguments of most instructions. - Examples: +Examples: ADD R11.SXTB<<1, RSP, R25 <=> add x25, sp, w11, sxtb #1 VADD V16, V19, V14 <=> add d14, d19, d16 @@ -155,32 +156,32 @@ Special Cases. (1) Argument order is the same as in the GNU ARM64 syntax: cbz, cbnz and some store instructions, such as str, stur, strb, sturb, strh, sturh stlr, stlrb. stlrh, st1. - Examples: +Examples: MOVD R29, 384(R19) <=> str x29, [x19,#384] MOVB.P R30, 30(R4) <=> strb w30, [x4],#30 STLRH R21, (R19) <=> stlrh w21, [x19] (2) MADD, MADDW, MSUB, MSUBW, SMADDL, SMSUBL, UMADDL, UMSUBL <Rm>, <Ra>, <Rn>, <Rd> - Examples: +Examples: MADD R2, R30, R22, R6 <=> madd x6, x22, x2, x30 SMSUBL R10, R3, R17, R27 <=> smsubl x27, w17, w10, x3 (3) FMADDD, FMADDS, FMSUBD, FMSUBS, FNMADDD, FNMADDS, FNMSUBD, FNMSUBS <Fm>, <Fa>, <Fn>, <Fd> - Examples: +Examples: FMADDD F30, F20, F3, F29 <=> fmadd d29, d3, d30, d20 FNMSUBS F7, F25, F7, F22 <=> fnmsub s22, s7, s7, s25 (4) BFI, BFXIL, SBFIZ, SBFX, UBFIZ, UBFX $<lsb>, <Rn>, $<width>, <Rd> - Examples: +Examples: BFIW $16, R20, $6, R0 <=> bfi w0, w20, #16, #6 UBFIZ $34, R26, $5, R20 <=> ubfiz x20, x26, #34, #5 (5) FCCMPD, FCCMPS, FCCMPED, FCCMPES <cond>, Fm. Fn, $<nzcv> - Examples: +Examples: FCCMPD AL, F8, F26, $0 <=> fccmp d26, d8, #0x0, al FCCMPS VS, F29, F4, $4 <=> fccmp s4, s29, #0x4, vs FCCMPED LE, F20, F5, $13 <=> fccmpe d5, d20, #0xd, le @@ -188,20 +189,20 @@ such as str, stur, strb, sturb, strh, sturh stlr, stlrb. stlrh, st1. (6) CCMN, CCMNW, CCMP, CCMPW <cond>, <Rn>, $<imm>, $<nzcv> - Examples: +Examples: CCMP MI, R22, $12, $13 <=> ccmp x22, #0xc, #0xd, mi CCMNW AL, R1, $11, $8 <=> ccmn w1, #0xb, #0x8, al (7) CCMN, CCMNW, CCMP, CCMPW <cond>, <Rn>, <Rm>, $<nzcv> - Examples: +Examples: CCMN VS, R13, R22, $10 <=> ccmn x13, x22, #0xa, vs CCMPW HS, R19, R14, $11 <=> ccmp w19, w14, #0xb, cs (9) CSEL, CSELW, CSNEG, CSNEGW, CSINC, CSINCW <cond>, <Rn>, <Rm>, <Rd> ; FCSELD, FCSELS <cond>, <Fn>, <Fm>, <Fd> - Examples: +Examples: CSEL GT, R0, R19, R1 <=> csel x1, x0, x19, gt CSNEGW GT, R7, R17, R8 <=> csneg w8, w7, w17, gt FCSELD EQ, F15, F18, F16 <=> fcsel d16, d15, d18, eq @@ -211,13 +212,13 @@ FCSELD, FCSELS <cond>, <Fn>, <Fm>, <Fd> (11) STLXR, STLXRW, STXR, STXRW, STLXRB, STLXRH, STXRB, STXRH <Rf>, (<Rn|RSP>), <Rs> - Examples: +Examples: STLXR ZR, (R15), R16 <=> stlxr w16, xzr, [x15] STXRB R9, (R21), R19 <=> stxrb w19, w9, [x21] (12) STLXP, STLXPW, STXP, STXPW (<Rf1>, <Rf2>), (<Rn|RSP>), <Rs> - Examples: +Examples: STLXP (R17, R19), (R4), R5 <=> stlxp w5, x17, x19, [x4] STXPW (R30, R25), (R22), R13 <=> stxp w13, w30, w25, [x22] @@ -227,28 +228,28 @@ FCSELD, FCSELS <cond>, <Fn>, <Fm>, <Fd> Optionally-shifted immediate. - Examples: +Examples: ADD $(3151<<12), R14, R20 <=> add x20, x14, #0xc4f, lsl #12 ADDW $1864, R25, R6 <=> add w6, w25, #0x748 Optionally-shifted registers are written as <Rm>{<shift><amount>}. The <shift> can be <<(lsl), >>(lsr), ->(asr), @>(ror). - Examples: +Examples: ADD R19>>30, R10, R24 <=> add x24, x10, x19, lsr #30 ADDW R26->24, R21, R15 <=> add w15, w21, w26, asr #24 Extended registers are written as <Rm>{.<extend>{<<<amount>}}. <extend> can be UXTB, UXTH, UXTW, UXTX, SXTB, SXTH, SXTW or SXTX. - Examples: +Examples: ADDS R19.UXTB<<4, R9, R26 <=> adds x26, x9, w19, uxtb #4 ADDSW R14.SXTX, R14, R6 <=> adds w6, w14, w14, sxtx Memory references: [<Xn|SP>{,#0}] is written as (Rn|RSP), a base register and an immediate offset is written as imm(Rn|RSP), a base register and an offset register is written as (Rn|RSP)(Rm). - Examples: +Examples: LDAR (R22), R9 <=> ldar x9, [x22] LDP 28(R17), (R15, R23) <=> ldp x15, x23, [x17,#28] MOVWU (R4)(R12<<2), R8 <=> ldr w8, [x4, x12, lsl #2] @@ -257,12 +258,12 @@ offset is written as imm(Rn|RSP), a base register and an offset register is writ Register pairs are written as (Rt1, Rt2). - Examples: +Examples: LDP.P -240(R11), (R12, R26) <=> ldp x12, x26, [x11],#-240 Register with arrangement and register with arrangement and index. - Examples: +Examples: VADD V5.H8, V18.H8, V9.H8 <=> add v9.8h, v18.8h, v5.8h VLD1 (R2), [V21.B16] <=> ld1 {v21.16b}, [x2] VST1.P V9.S[1], (R16)(R21) <=> st1 {v9.s}[1], [x16], x28 diff --git a/src/cmd/internal/obj/inl.go b/src/cmd/internal/obj/inl.go index 1b1d13a679..d65a7357a6 100644 --- a/src/cmd/internal/obj/inl.go +++ b/src/cmd/internal/obj/inl.go @@ -13,19 +13,19 @@ import "cmd/internal/src" // every time a function is inlined. For example, suppose f() calls g() // and g has two calls to h(), and that f, g, and h are inlineable: // -// 1 func main() { -// 2 f() -// 3 } -// 4 func f() { -// 5 g() -// 6 } -// 7 func g() { -// 8 h() -// 9 h() -// 10 } -// 11 func h() { -// 12 println("H") -// 13 } +// 1 func main() { +// 2 f() +// 3 } +// 4 func f() { +// 5 g() +// 6 } +// 7 func g() { +// 8 h() +// 9 h() +// 10 } +// 11 func h() { +// 12 println("H") +// 13 } // // Assuming the global tree starts empty, inlining will produce the // following tree: diff --git a/src/cmd/internal/obj/objfile.go b/src/cmd/internal/obj/objfile.go index 7bae31f343..e9302ee642 100644 --- a/src/cmd/internal/obj/objfile.go +++ b/src/cmd/internal/obj/objfile.go @@ -448,14 +448,14 @@ func contentHash64(s *LSym) goobj.Hash64Type { // Depending on the category of the referenced symbol, we choose // different hash algorithms such that the hash is globally // consistent. -// - For referenced content-addressable symbol, its content hash -// is globally consistent. -// - For package symbol and builtin symbol, its local index is -// globally consistent. -// - For non-package symbol, its fully-expanded name is globally -// consistent. For now, we require we know the current package -// path so we can always expand symbol names. (Otherwise, -// symbols with relocations are not considered hashable.) +// - For referenced content-addressable symbol, its content hash +// is globally consistent. +// - For package symbol and builtin symbol, its local index is +// globally consistent. +// - For non-package symbol, its fully-expanded name is globally +// consistent. For now, we require we know the current package +// path so we can always expand symbol names. (Otherwise, +// symbols with relocations are not considered hashable.) // // For now, we assume there is no circular dependencies among // hashed symbols. diff --git a/src/cmd/internal/obj/ppc64/doc.go b/src/cmd/internal/obj/ppc64/doc.go index a9d89c93b4..bdaeaf69e1 100644 --- a/src/cmd/internal/obj/ppc64/doc.go +++ b/src/cmd/internal/obj/ppc64/doc.go @@ -23,207 +23,212 @@ In the examples below, the Go assembly is on the left, PPC64 assembly on the rig 1. Operand ordering - In Go asm, the last operand (right) is the target operand, but with PPC64 asm, - the first operand (left) is the target. The order of the remaining operands is - not consistent: in general opcodes with 3 operands that perform math or logical - operations have their operands in reverse order. Opcodes for vector instructions - and those with more than 3 operands usually have operands in the same order except - for the target operand, which is first in PPC64 asm and last in Go asm. +In Go asm, the last operand (right) is the target operand, but with PPC64 asm, +the first operand (left) is the target. The order of the remaining operands is +not consistent: in general opcodes with 3 operands that perform math or logical +operations have their operands in reverse order. Opcodes for vector instructions +and those with more than 3 operands usually have operands in the same order except +for the target operand, which is first in PPC64 asm and last in Go asm. - Example: - ADD R3, R4, R5 <=> add r5, r4, r3 +Example: + + ADD R3, R4, R5 <=> add r5, r4, r3 2. Constant operands - In Go asm, an operand that starts with '$' indicates a constant value. If the - instruction using the constant has an immediate version of the opcode, then an - immediate value is used with the opcode if possible. +In Go asm, an operand that starts with '$' indicates a constant value. If the +instruction using the constant has an immediate version of the opcode, then an +immediate value is used with the opcode if possible. + +Example: - Example: - ADD $1, R3, R4 <=> addi r4, r3, 1 + ADD $1, R3, R4 <=> addi r4, r3, 1 3. Opcodes setting condition codes - In PPC64 asm, some instructions other than compares have variations that can set - the condition code where meaningful. This is indicated by adding '.' to the end - of the PPC64 instruction. In Go asm, these instructions have 'CC' at the end of - the opcode. The possible settings of the condition code depend on the instruction. - CR0 is the default for fixed-point instructions; CR1 for floating point; CR6 for - vector instructions. +In PPC64 asm, some instructions other than compares have variations that can set +the condition code where meaningful. This is indicated by adding '.' to the end +of the PPC64 instruction. In Go asm, these instructions have 'CC' at the end of +the opcode. The possible settings of the condition code depend on the instruction. +CR0 is the default for fixed-point instructions; CR1 for floating point; CR6 for +vector instructions. + +Example: - Example: - ANDCC R3, R4, R5 <=> and. r5, r3, r4 (set CR0) + ANDCC R3, R4, R5 <=> and. r5, r3, r4 (set CR0) 4. Loads and stores from memory - In Go asm, opcodes starting with 'MOV' indicate a load or store. When the target - is a memory reference, then it is a store; when the target is a register and the - source is a memory reference, then it is a load. +In Go asm, opcodes starting with 'MOV' indicate a load or store. When the target +is a memory reference, then it is a store; when the target is a register and the +source is a memory reference, then it is a load. - MOV{B,H,W,D} variations identify the size as byte, halfword, word, doubleword. +MOV{B,H,W,D} variations identify the size as byte, halfword, word, doubleword. - Adding 'Z' to the opcode for a load indicates zero extend; if omitted it is sign extend. - Adding 'U' to a load or store indicates an update of the base register with the offset. - Adding 'BR' to an opcode indicates byte-reversed load or store, or the order opposite - of the expected endian order. If 'BR' is used then zero extend is assumed. +Adding 'Z' to the opcode for a load indicates zero extend; if omitted it is sign extend. +Adding 'U' to a load or store indicates an update of the base register with the offset. +Adding 'BR' to an opcode indicates byte-reversed load or store, or the order opposite +of the expected endian order. If 'BR' is used then zero extend is assumed. - Memory references n(Ra) indicate the address in Ra + n. When used with an update form - of an opcode, the value in Ra is incremented by n. +Memory references n(Ra) indicate the address in Ra + n. When used with an update form +of an opcode, the value in Ra is incremented by n. - Memory references (Ra+Rb) or (Ra)(Rb) indicate the address Ra + Rb, used by indexed - loads or stores. Both forms are accepted. When used with an update then the base register - is updated by the value in the index register. +Memory references (Ra+Rb) or (Ra)(Rb) indicate the address Ra + Rb, used by indexed +loads or stores. Both forms are accepted. When used with an update then the base register +is updated by the value in the index register. - Examples: - MOVD (R3), R4 <=> ld r4,0(r3) - MOVW (R3), R4 <=> lwa r4,0(r3) - MOVWZU 4(R3), R4 <=> lwzu r4,4(r3) - MOVWZ (R3+R5), R4 <=> lwzx r4,r3,r5 - MOVHZ (R3), R4 <=> lhz r4,0(r3) - MOVHU 2(R3), R4 <=> lhau r4,2(r3) - MOVBZ (R3), R4 <=> lbz r4,0(r3) +Examples: - MOVD R4,(R3) <=> std r4,0(r3) - MOVW R4,(R3) <=> stw r4,0(r3) - MOVW R4,(R3+R5) <=> stwx r4,r3,r5 - MOVWU R4,4(R3) <=> stwu r4,4(r3) - MOVH R4,2(R3) <=> sth r4,2(r3) - MOVBU R4,(R3)(R5) <=> stbux r4,r3,r5 + MOVD (R3), R4 <=> ld r4,0(r3) + MOVW (R3), R4 <=> lwa r4,0(r3) + MOVWZU 4(R3), R4 <=> lwzu r4,4(r3) + MOVWZ (R3+R5), R4 <=> lwzx r4,r3,r5 + MOVHZ (R3), R4 <=> lhz r4,0(r3) + MOVHU 2(R3), R4 <=> lhau r4,2(r3) + MOVBZ (R3), R4 <=> lbz r4,0(r3) + + MOVD R4,(R3) <=> std r4,0(r3) + MOVW R4,(R3) <=> stw r4,0(r3) + MOVW R4,(R3+R5) <=> stwx r4,r3,r5 + MOVWU R4,4(R3) <=> stwu r4,4(r3) + MOVH R4,2(R3) <=> sth r4,2(r3) + MOVBU R4,(R3)(R5) <=> stbux r4,r3,r5 4. Compares - When an instruction does a compare or other operation that might - result in a condition code, then the resulting condition is set - in a field of the condition register. The condition register consists - of 8 4-bit fields named CR0 - CR7. When a compare instruction - identifies a CR then the resulting condition is set in that field - to be read by a later branch or isel instruction. Within these fields, - bits are set to indicate less than, greater than, or equal conditions. +When an instruction does a compare or other operation that might +result in a condition code, then the resulting condition is set +in a field of the condition register. The condition register consists +of 8 4-bit fields named CR0 - CR7. When a compare instruction +identifies a CR then the resulting condition is set in that field +to be read by a later branch or isel instruction. Within these fields, +bits are set to indicate less than, greater than, or equal conditions. + +Once an instruction sets a condition, then a subsequent branch, isel or +other instruction can read the condition field and operate based on the +bit settings. - Once an instruction sets a condition, then a subsequent branch, isel or - other instruction can read the condition field and operate based on the - bit settings. +Examples: - Examples: - CMP R3, R4 <=> cmp r3, r4 (CR0 assumed) - CMP R3, R4, CR1 <=> cmp cr1, r3, r4 + CMP R3, R4 <=> cmp r3, r4 (CR0 assumed) + CMP R3, R4, CR1 <=> cmp cr1, r3, r4 - Note that the condition register is the target operand of compare opcodes, so - the remaining operands are in the same order for Go asm and PPC64 asm. - When CR0 is used then it is implicit and does not need to be specified. +Note that the condition register is the target operand of compare opcodes, so +the remaining operands are in the same order for Go asm and PPC64 asm. +When CR0 is used then it is implicit and does not need to be specified. 5. Branches - Many branches are represented as a form of the BC instruction. There are - other extended opcodes to make it easier to see what type of branch is being - used. +Many branches are represented as a form of the BC instruction. There are +other extended opcodes to make it easier to see what type of branch is being +used. - The following is a brief description of the BC instruction and its commonly - used operands. +The following is a brief description of the BC instruction and its commonly +used operands. - BC op1, op2, op3 +BC op1, op2, op3 - op1: type of branch - 16 -> bctr (branch on ctr) - 12 -> bcr (branch if cr bit is set) - 8 -> bcr+bctr (branch on ctr and cr values) + op1: type of branch + 16 -> bctr (branch on ctr) + 12 -> bcr (branch if cr bit is set) + 8 -> bcr+bctr (branch on ctr and cr values) 4 -> bcr != 0 (branch if specified cr bit is not set) There are more combinations but these are the most common. - op2: condition register field and condition bit + op2: condition register field and condition bit This contains an immediate value indicating which condition field to read and what bits to test. Each field is 4 bits long with CR0 - at bit 0, CR1 at bit 4, etc. The value is computed as 4*CR+condition - with these condition values: + at bit 0, CR1 at bit 4, etc. The value is computed as 4*CR+condition + with these condition values: - 0 -> LT - 1 -> GT - 2 -> EQ - 3 -> OVG + 0 -> LT + 1 -> GT + 2 -> EQ + 3 -> OVG Thus 0 means test CR0 for LT, 5 means CR1 for GT, 30 means CR7 for EQ. - op3: branch target + op3: branch target - Examples: +Examples: - BC 12, 0, target <=> blt cr0, target - BC 12, 2, target <=> beq cr0, target - BC 12, 5, target <=> bgt cr1, target - BC 12, 30, target <=> beq cr7, target - BC 4, 6, target <=> bne cr1, target - BC 4, 1, target <=> ble cr1, target + BC 12, 0, target <=> blt cr0, target + BC 12, 2, target <=> beq cr0, target + BC 12, 5, target <=> bgt cr1, target + BC 12, 30, target <=> beq cr7, target + BC 4, 6, target <=> bne cr1, target + BC 4, 1, target <=> ble cr1, target - The following extended opcodes are available for ease of use and readability: + The following extended opcodes are available for ease of use and readability: - BNE CR2, target <=> bne cr2, target - BEQ CR4, target <=> beq cr4, target - BLT target <=> blt target (cr0 default) - BGE CR7, target <=> bge cr7, target + BNE CR2, target <=> bne cr2, target + BEQ CR4, target <=> beq cr4, target + BLT target <=> blt target (cr0 default) + BGE CR7, target <=> bge cr7, target - Refer to the ISA for more information on additional values for the BC instruction, - how to handle OVG information, and much more. +Refer to the ISA for more information on additional values for the BC instruction, +how to handle OVG information, and much more. 5. Align directive - Starting with Go 1.12, Go asm supports the PCALIGN directive, which indicates - that the next instruction should be aligned to the specified value. Currently - 8 and 16 are the only supported values, and a maximum of 2 NOPs will be added - to align the code. That means in the case where the code is aligned to 4 but - PCALIGN $16 is at that location, the code will only be aligned to 8 to avoid - adding 3 NOPs. +Starting with Go 1.12, Go asm supports the PCALIGN directive, which indicates +that the next instruction should be aligned to the specified value. Currently +8 and 16 are the only supported values, and a maximum of 2 NOPs will be added +to align the code. That means in the case where the code is aligned to 4 but +PCALIGN $16 is at that location, the code will only be aligned to 8 to avoid +adding 3 NOPs. - The purpose of this directive is to improve performance for cases like loops - where better alignment (8 or 16 instead of 4) might be helpful. This directive - exists in PPC64 assembler and is frequently used by PPC64 assembler writers. +The purpose of this directive is to improve performance for cases like loops +where better alignment (8 or 16 instead of 4) might be helpful. This directive +exists in PPC64 assembler and is frequently used by PPC64 assembler writers. - PCALIGN $16 - PCALIGN $8 +PCALIGN $16 +PCALIGN $8 - Functions in Go are aligned to 16 bytes, as is the case in all other compilers - for PPC64. +Functions in Go are aligned to 16 bytes, as is the case in all other compilers +for PPC64. 6. Shift instructions - The simple scalar shifts on PPC64 expect a shift count that fits in 5 bits for - 32-bit values or 6 bit for 64-bit values. If the shift count is a constant value - greater than the max then the assembler sets it to the max for that size (31 for - 32 bit values, 63 for 64 bit values). If the shift count is in a register, then - only the low 5 or 6 bits of the register will be used as the shift count. The - Go compiler will add appropriate code to compare the shift value to achieve the - the correct result, and the assembler does not add extra checking. +The simple scalar shifts on PPC64 expect a shift count that fits in 5 bits for +32-bit values or 6 bit for 64-bit values. If the shift count is a constant value +greater than the max then the assembler sets it to the max for that size (31 for +32 bit values, 63 for 64 bit values). If the shift count is in a register, then +only the low 5 or 6 bits of the register will be used as the shift count. The +Go compiler will add appropriate code to compare the shift value to achieve the +the correct result, and the assembler does not add extra checking. - Examples: +Examples: - SRAD $8,R3,R4 => sradi r4,r3,8 - SRD $8,R3,R4 => rldicl r4,r3,56,8 - SLD $8,R3,R4 => rldicr r4,r3,8,55 - SRAW $16,R4,R5 => srawi r5,r4,16 - SRW $40,R4,R5 => rlwinm r5,r4,0,0,31 - SLW $12,R4,R5 => rlwinm r5,r4,12,0,19 + SRAD $8,R3,R4 => sradi r4,r3,8 + SRD $8,R3,R4 => rldicl r4,r3,56,8 + SLD $8,R3,R4 => rldicr r4,r3,8,55 + SRAW $16,R4,R5 => srawi r5,r4,16 + SRW $40,R4,R5 => rlwinm r5,r4,0,0,31 + SLW $12,R4,R5 => rlwinm r5,r4,12,0,19 - Some non-simple shifts have operands in the Go assembly which don't map directly - onto operands in the PPC64 assembly. When an operand in a shift instruction in the - Go assembly is a bit mask, that mask is represented as a start and end bit in the - PPC64 assembly instead of a mask. See the ISA for more detail on these types of shifts. - Here are a few examples: +Some non-simple shifts have operands in the Go assembly which don't map directly +onto operands in the PPC64 assembly. When an operand in a shift instruction in the +Go assembly is a bit mask, that mask is represented as a start and end bit in the +PPC64 assembly instead of a mask. See the ISA for more detail on these types of shifts. +Here are a few examples: - RLWMI $7,R3,$65535,R6 => rlwimi r6,r3,7,16,31 - RLDMI $0,R4,$7,R6 => rldimi r6,r4,0,61 + RLWMI $7,R3,$65535,R6 => rlwimi r6,r3,7,16,31 + RLDMI $0,R4,$7,R6 => rldimi r6,r4,0,61 - More recently, Go opcodes were added which map directly onto the PPC64 opcodes. It is - recommended to use the newer opcodes to avoid confusion. +More recently, Go opcodes were added which map directly onto the PPC64 opcodes. It is +recommended to use the newer opcodes to avoid confusion. - RLDICL $0,R4,$15,R6 => rldicl r6,r4,0,15 - RLDICR $0,R4,$15,R6 => rldicr r6.r4,0,15 + RLDICL $0,R4,$15,R6 => rldicl r6,r4,0,15 + RLDICR $0,R4,$15,R6 => rldicr r6.r4,0,15 Register naming 1. Special register usage in Go asm - The following registers should not be modified by user Go assembler code. +The following registers should not be modified by user Go assembler code. R0: Go code expects this register to contain the value 0. R1: Stack pointer @@ -231,7 +236,7 @@ Register naming R13: TLS pointer R30: g (goroutine) - Register names: +Register names: Rn is used for general purpose registers. (0-31) Fn is used for floating point registers. (0-31) diff --git a/src/cmd/internal/obj/riscv/cpu.go b/src/cmd/internal/obj/riscv/cpu.go index 8c2daf6e5b..594f8ea3fc 100644 --- a/src/cmd/internal/obj/riscv/cpu.go +++ b/src/cmd/internal/obj/riscv/cpu.go @@ -276,15 +276,11 @@ const ( ) // RISC-V mnemonics, as defined in the "opcodes" and "opcodes-pseudo" files -// from: -// -// https://github.com/riscv/riscv-opcodes +// at https://github.com/riscv/riscv-opcodes. // // As well as some pseudo-mnemonics (e.g. MOV) used only in the assembler. // -// See also "The RISC-V Instruction Set Manual" at: -// -// https://riscv.org/specifications/ +// See also "The RISC-V Instruction Set Manual" at https://riscv.org/specifications/. // // If you modify this table, you MUST run 'go generate' to regenerate anames.go! const ( diff --git a/src/cmd/internal/obj/riscv/obj.go b/src/cmd/internal/obj/riscv/obj.go index 61044b0531..2c00c87aa2 100644 --- a/src/cmd/internal/obj/riscv/obj.go +++ b/src/cmd/internal/obj/riscv/obj.go @@ -323,9 +323,7 @@ func setPCs(p *obj.Prog, pc int64) int64 { // FixedFrameSize makes other packages aware of the space allocated for RA. // // A nicer version of this diagram can be found on slide 21 of the presentation -// attached to: -// -// https://golang.org/issue/16922#issuecomment-243748180 +// attached to https://golang.org/issue/16922#issuecomment-243748180. // func stackOffset(a *obj.Addr, stacksize int64) { switch a.Name { |