Bug 1063

Summary: consider removing predicate-result from SVP64
Product: Libre-SOC's first SoC Reporter: Luke Kenneth Casson Leighton <lkcl>
Component: SpecificationAssignee: Dmitry Selyutin <ghostmansd>
Status: RESOLVED FIXED    
Severity: enhancement CC: ghostmansd, libre-soc-isa
Priority: ---    
Version: unspecified   
Hardware: Other   
OS: Linux   
URL: https://libre-soc.org/openpower/sv/rfc/ls010
See Also: https://bugs.libre-soc.org/show_bug.cgi?id=1083
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
Bug Depends on:    
Bug Blocks: 1012    

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?