Bug 1063 - consider removing predicate-result from SVP64
Summary: consider removing predicate-result from SVP64
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Specification (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Dmitry Selyutin
URL: https://libre-soc.org/openpower/sv/rf...
Depends on:
Blocks: 1012
  Show dependency treegraph
 
Reported: 2023-04-19 12:24 BST by Luke Kenneth Casson Leighton
Modified: 2023-11-12 18:25 GMT (History)
2 users (show)

See Also:
NLnet milestone: NLnet.2022-08-051.OPF
total budget (EUR) for completion of task and all subtasks: 1500
budget (EUR) for this task, excluding subtasks' budget: 1500
parent task for budget allocation: 1011
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
[ghostmansd] amount=750 submitted=2023-09-14 paid=2023-09-19 [lkcl] amount = 750 submitted = 2023-06-22


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2023-04-19 12:24:56 BST
pred-result hooks Rc=1 bit-testing into the destination predicate mask.
however the question is, the same thing may be achieved with an extra
sv.cmpi or sv.crop but at the cost of needing extra temporary registers
to do it.

evaluate whether it is worth keeping.
Comment 1 Luke Kenneth Casson Leighton 2023-04-19 15:33:36 BST
https://libre-soc.org/openpower/sv/normal/

| 0-1 |  2  |  3   4  |  description              |
| --- | --- |---------|-------------------------- |
| 00  |   0 |  dz  sz | simple mode                      |
| 00  |   1 | 0  RG   | scalar reduce mode (mapreduce) |
| 00  |   1 | 1  /    | reserved     |
| 01  | inv | CR-bit  | Rc=1: ffirst CR sel              |
| 01  | inv | VLi RC1 |  Rc=0: ffirst z/nonz |
| 10  |   N | dz   sz |  sat mode: N=0/1 u/s |
| 11  | inv | CR-bit  |  Rc=1: pred-result CR sel |
| 11  | inv | zz  RC1 |  Rc=0: pred-result z/nonz |


mode 0b11 becomes reserved

actually that's all. it is already not part of the other types
of operations (crops, ldst)
Comment 3 Dmitry Selyutin 2023-04-19 17:44:21 BST
> actually that's all

To me that's not even close to definition of "all". :-) This seemingly simple change needs changes in at least these parts:
1. Remove tables and predicates from insndb, as well as the specifier handling.
2. Remove low-level support (these nice Decoder classes).
3. Remove all associated tests and checks here and there.
4. Update the code which relies on pr (not sure whether there's a lot of it though).
5. Update binutils in the same regard.
Comment 4 Luke Kenneth Casson Leighton 2023-04-19 18:20:36 BST
(In reply to Dmitry Selyutin from comment #3)
> > actually that's all
> 
> To me that's not even close to definition of "all". :-)

(spec-wise)

> This seemingly
> simple change needs changes in at least these parts:
> 1. Remove tables and predicates from insndb, as well as the specifier
> handling.
> 2. Remove low-level support (these nice Decoder classes).
> 3. Remove all associated tests and checks here and there.
> 4. Update the code which relies on pr (not sure whether there's a lot of it
> though).
> 5. Update binutils in the same regard.

i know. i don't like doing this, but it is inevitable/necessary.
Comment 5 Dmitry Selyutin 2023-04-19 18:45:54 BST
Well, good news is that most of this is relatively straightforward, I think I can handle everything except for decoder classes. I think we can split this task in two parts, asm+disasm and simulator. What do you think?
Comment 6 Luke Kenneth Casson Leighton 2023-04-19 19:32:18 BST
(In reply to Dmitry Selyutin from comment #5)
> Well, good news is that most of this is relatively straightforward, I think
> I can handle everything except for decoder classes. I think we can split
> this task in two parts, asm+disasm and simulator. What do you think?

simulator doesn't have pred-result, i never added it.  so there is nothing
to remove.  the only remaining functionality missing from the simulator is
Saturation and VLI mode on Data-Dependent Fail-First.
Comment 7 Dmitry Selyutin 2023-04-25 17:23:51 BST
Is it OK if I take (most of) this task? I can fix these: 1) insndn; 2) python tests; 3) binutils. I can also check and point out the rest.
Comment 8 Luke Kenneth Casson Leighton 2023-04-25 17:55:05 BST
(In reply to Dmitry Selyutin from comment #7)
> Is it OK if I take (most of) this task? I can fix these: 1) insndn; 2)
> python tests; 3) binutils. I can also check and point out the rest.

yes awesome go for it.
Comment 9 Dmitry Selyutin 2023-04-26 18:53:29 BST
Current status:
1. Removed PR from Python code (tests included): openpower-isa:nopr branch.
2. Removed PR from binutils: binutils-gdb:svp64-nopr branch.


Once CI for openpower-isa:nopr is completed and brings no devastation, I'll merge it to master. As for binutils-gdb, I'm checking the code, it'll take a while (we don't have good tests yet, perhaps these are to be added in scope of #1003).
Comment 10 Dmitry Selyutin 2023-04-27 06:22:01 BST
State: CI is completed, no new failures, so changes which remove PR are contributed into master. Binutils are updated too, svp64 branch, as usual. Do we have any other activities here, or this can be closed?
Comment 11 Dmitry Selyutin 2023-04-30 22:32:31 BST
Luke, can I mark it as RESOLVED FIXED?