riscv-isac
riscv-isac copied to clipboard
riscv-software-src
updates for crypto scalar instructions
In the Bitmanip or crypto scalar spec, zext.h is not mentioned as pseudo instruction. Only zext.w is mentioned as pseudo instruction for add.uw, zext.w is not included in the spec. zext.h is only in zbb spec. pack and packw are only in zbkb. In the instruction decoder we can use the isa string to differentiate between zext.h and packw or pack with rs2 as x0.
In the Bitmanip or crypto scalar spec, zext.h is not mentioned as pseudo instruction. Only zext.w is mentioned as pseudo instruction for add.uw, zext.w is not included in the spec. zext.h is only in zbb spec. pack and packw are only in zbkb. In the instruction decoder we can use the isa string to differentiate between zext.h and packw or pack with rs2 as x0.
This causes the same problem as before. What if both the nodes are present in the cgf? Then the decoder will always give out the instruction as zext.h.
Hi,
Even if both the instructions are in the same cgf, the config part of the instructions are different. zext will have zbb and pack, packw will have zbkb. Since zext and pack will be in different isa spec, ISA strings mentioned in the config can be used to differentiate.
Also, so far for each spec we have a separate signature file. I am not sure if we will have zbb and zbkb in the same cgf.
Thanks & Regards, Anand
On Tue, Apr 12, 2022 at 11:15 AM S Pawan Kumar @.***> wrote:
In the Bitmanip or crypto scalar spec, zext.h is not mentioned as pseudo instruction. Only zext.w is mentioned as pseudo instruction for add.uw, zext.w is not included in the spec. zext.h is only in zbb spec. pack and packw are only in zbkb. In the instruction decoder we can use the isa string to differentiate between zext.h and packw or pack with rs2 as x0.
This causes the same problem as before. What if both the nodes are present in the cgf? Then the decoder will always give out the instruction as zext.h.
— Reply to this email directly, view it on GitHub https://github.com/riscv-software-src/riscv-isac/pull/34#issuecomment-1096100185, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECK3Y2ATGWYNK24EGJI6S3VEUEWXANCNFSM5R2YZ6PA . You are receiving this because you authored the thread.Message ID: @.***>
This might work out for the current use case. But it is not a complete solution. Even though the config nodes are different, if both are present in the same cgf, the problem persists. I am not inclined to go down this route as it is a hack for a single scenario. For example this will be extremely problematic to implement for the other decoder (for example the one based on rvopcodes). We need to follow the same philosophy as followed in the rvopcodes. The instructions are always decoded/expressed in terms of the base instruction only.
Updated cgf to use base_op and p_op_cond for pseudo instructions. Removed the condition to check for labels.