Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify description of Zvkt #380

Open
Mingku-Chang opened this issue Jan 24, 2024 · 4 comments
Open

Clarify description of Zvkt #380

Mingku-Chang opened this issue Jan 24, 2024 · 4 comments

Comments

@Mingku-Chang
Copy link

I am confused with the Zvkt (Vector Data-Independent Execution Latency) definition.
It said, "All floating-point operations" are not affected by Zvkt.
But the vfslide1up.vf and vfslide1down.vf operations are listed in the affected range.
I think these 2 operations are in floating-point format, even though they were categorized as Vector Slide Instructions.
For the same reason, I believe vfmv* (Floating-Point Scalar Move) operations are also unaffected by Zvkt.
Could you clarify this part?

@nibrunieAtSi5
Copy link
Contributor

@kdockser for your consideration. (we could/should clarify since vfmv.v.f is indeed listed in RVV 1.0 Section 13 but vfslide1* are listed in Section 16).

@mjosaarinen
Copy link
Collaborator

My recollection is that the use case for the slide instructions in vector crypto was to help with AES key scheduling (to hold subkeys) -- and this is obviously unrelated to floating point. So it seems that the inclusion of this instruction is indeed an error.

@kdockser
Copy link
Collaborator

kdockser commented Feb 1, 2024

I agree with Markku that floating-point is unrelated to subkeys, however, the vfslide1*.vf instructions just move bits (not necessarily floating point values) from the floating-point scalar registers. From this point of view, they are just as useful as their integer-register counterparts for bringing in keys. In fact, they provide a user with 32 64-bit registers for holding keys (or other useful values for cryptography). As I recall, this is why we included them.

On the other hand, this does not fit with our blanket non-normative statement about floating-point operations. It is also somewhat inconsistent with our not specifying vfmerge or vfmv as being covered under Zvkt. However, the slide instruction is more useful to cryptography than merge or move.

My preference is to update the spec by modifying the non-normative "All floating-point operations" statement to say "All floating-point operations except vfslide1[up|down].vf". This way we are not modifying the normative part of the spec (which is best to avoid) and we are supporting the advantages of using vfslide* for crypto.

@mjosaarinen and @nibrunieAtSi5 Does this sound reasonable to you?

@nibrunieAtSi5
Copy link
Contributor

nibrunieAtSi5 commented Feb 2, 2024

I found the use of floating-point registers as extra storage a bit of an anti-pattern but I am quite sure it will happen.

I found your argument about not making any normative change if we can avoid it spot on. The spec being ratified, the bar to make such change should be pretty high and I do not think this qualify.

So overall this sounds very reasonable to me.

We could maintain a list of known inconsistencies that we may eventually revise in a future revision of the vector crypto spec. And in general gathering community feedback on usage would be interesting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants