updates for crypto scalar instructions #34
Conversation
…in rs2 value for zext.h rs2 is always 0, if pack instruction is used with x0 as rs2 then cannot distinguish from each other, hence using cover label to differentiate. 2) updated coverage.py for xperm4, xperm8, zip, unzip instructions
|
In the Bitmanip or crypto scalar spec, zext.h is not mentioned as pseudo instruction. |
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 |
|
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
<#34 (comment)>,
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. |
Added conditions to extract bs and rnum fields in rvopcodesdecoder.py Removed zext.h from internaldecoder.py
|
Updated cgf to use base_op and p_op_cond for pseudo instructions. Removed the condition to check for labels. |
riscv_isac/plugins/specification.py
Outdated
| @@ -5,7 +5,7 @@ | |||
|
|
|||
| class DecoderSpec(object): | |||
| @decoderHookSpec | |||
| def setup(self,arch): | |||
| def setup(self,arch,isa): | |||
There was a problem hiding this comment.
The setup function of the plugins does not need the isa anymore and all of the changes related need to be reverted back.
There was a problem hiding this comment.
Removed isa from the plugin setup function
|
Dear @anku-anand The CTG and ISAC Repo had been moved to riscv-arch-test via PR If you think this PR is important, and need to me merged on to risc-v CTG or ISAC, please re-submit your PR against riscv-arch-test This repository shall be archived in about one week time . |
No description provided.