Bug 914 - setvl should not set SO
Summary: setvl should not set SO
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL:
Depends on:
Blocks: 587 952 1089
  Show dependency treegraph
 
Reported: 2022-08-26 20:24 BST by Jacob Lifshay
Modified: 2023-05-29 23:19 BST (History)
2 users (show)

See Also:
NLnet milestone: ---
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2022-08-26 20:24:04 BST
this is mostly a reminder for lkcl

https://libre-soc.org/irclog/%23libre-soc.2022-08-26.log.html#t2022-08-26T19:52:58
Comment 1 Luke Kenneth Casson Leighton 2022-08-29 12:35:43 BST
it's more that "setvl." should not *read* XER.so... ahh but...
in power_decoder2.py DecodeOE unconditionally reads the dec.OE
flag which should *not* be happening, just as it should not
be happening for e.g. mulh* rldic* etc.

really there are enough exceptions in DecodeOE to justify adding
a separate "OE" field - or, better, an RC.RC_NO_OE option.
but that is... quite intrusive at the moment as it means
dmitry has to update binutils, and the rest of the code which
currently checks (and expects) RC.RC would need to check
RC.RC_NO_OE.  hmmm a separate CSV column would be better
Comment 2 Jacob Lifshay 2022-08-29 12:39:40 BST
(In reply to Luke Kenneth Casson Leighton from comment #1)
> it's more that "setvl." should not *read* XER.so... ahh but...
> in power_decoder2.py DecodeOE unconditionally reads the dec.OE
> flag which should *not* be happening, just as it should not
> be happening for e.g. mulh* rldic* etc.

imho the issue is that setvl. should not *write* SO or OV[32]. reading them is fine, since they can be assumed to be rarely modified.

this is like how add. will read SO and write that to CR0, but it won't modify SO or OV.
Comment 3 Dmitry Selyutin 2023-05-29 20:26:18 BST
If we introduce OE into binutils, this will take the only bit left in svp64_record structure. We either need to find a clever way to compress the information we have there, or avoid introducing OE as Jacob suggests, or expand svp64_record structure, or introduce OE and never introduce anything else. Choose one. :-)