openhwgroup / corev-gcc

GNU General Public License v2.0
22 stars 23 forks source link

Fixes to xcvbitmanip and xcvsimd #71

Closed MaryBennett closed 1 year ago

MaryBennett commented 1 year ago

The immediate operand order in instructions cv.bclr and cv.bset was wrong. Tests updated to match.

Tests for instructions cv.extract[u].[h,b] and cv.insert.[h,b] fixed for unsigned immediate sel.

Instructions cv.s[ll,ra,la].sc.[h,b] fixed for unsigned immediate j. Tests updated to match.

Files Changed:

melonedo commented 1 year ago

Note that cv.sll/sra/srl.b/h only uses the lower 3 or 4 bits since each element of the vector is 8 or 16 bits long.

Description for cv.srl[.sc,.sci]{.h,.b} rD, rs1, [rs2, Imm6] rD[i] = rs1[i] >> op2[i] Note: Immediate is zero-extended, shift is logical. Only Imm6[3:0] and rs2[3:0] are used for .h instruction and Imm6[2:0] and rs2[2:0] for .b instruction. Other bits are not used and must be set to 0.

Also, cv.extract/extractu.b/h only uses the lower 1 or 2 bits since the length of the vectors is 2 or 4.

Description for cv.extract.h rD, rs1, Imm6 rD = Sext(rs1[I016+15:I016])

MaryBennett commented 1 year ago

Note that cv.sll/sra/srl.b/h only uses the lower 3 or 4 bits since each element of the vector is 8 or 16 bits long.

The assembler handles this. However, no errors or warnings are generated if the input to the immediate is larger than 4 bits.

Also, cv.extract/extractu.b/h only uses the lower 1 or 2 bits since the length of the vectors is 2 or 4.

Same for cv.extract/extractu.b/h.

jeremybennett commented 1 year ago

This is now consistent with both the official specification and the behavior or LLVM.

jeremybennett commented 1 year ago

Good to merge.