Skip to content
This repository has been archived by the owner on Mar 20, 2024. It is now read-only.

provide a note that emphasizes that implementations are free to trap on vsetvl{i} #578

Closed
David-Horner opened this issue Oct 2, 2020 · 3 comments

Comments

@David-Horner
Copy link
Contributor

David-Horner commented Oct 2, 2020

I'm OK with vill set if vtail is unsupported. However, I believe we should provide a note that emphasizes that implementations are free to trap on vsetvl{i}

  • on any specific combination of vtype values
  • to trap conditionally (typically with a CSR configuration setting)
  • recommend to not trap on implementation supported vtype settings

Highlight the benefit of immediate trapping (either explicitly itemizing and explaining or referencing another document). [ some of those being: definitive identification of instruction, allowing precise determination of arguments, which in turn allows setting an equivalent vtype (in a typical case substitute tailun for tailag)]

see:
#367 (comment)
this was initially raised in the context of the agnostic tail debate

@kasanovic
Copy link
Collaborator

In general, implementations are free to trap on any instruction or any value in general. Adding a special note here would cause readers to question if trapping is allowed for every other instruction where a note is not present.

@David-Horner
Copy link
Contributor Author

@kasanovic Adding a special note here would cause readers to question if trapping is allowed for every other instruction where a note is not present.

I suspect most readers will not be so confused. It is hardware engineers and EE devlopers that care about such things.

By not adding the note many more will be unaware of the consequences of not trapping.
What does a hardware engineer care about EE and user code challenges?
It is the classic rhetorical question.

@kasanovic
Copy link
Collaborator

OK - we can add a note that if writes of illegal vtype values are not trapped, alternative vector designs can not be emulated as the use of vill is too late to take action.

I will say that the community of hardware engineers are very much the ones that worry when things are not consistent between different instruction descriptions. I think the important difference here is the defined setting of illegal bit versus undefined reserved behavior on an illegal value.

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

No branches or pull requests

2 participants