Bug 915 - add overflow to av maxu and maxs operations
Summary: add overflow to av maxu and maxs operations
Status: RESOLVED FIXED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: Other Linux
: --- enhancement
Assignee: Luke Kenneth Casson Leighton
URL: https://libre-soc.org/openpower/sv/av...
Depends on:
Blocks: 952 1057
  Show dependency tree / graph
 
Reported: 2022-08-28 18:50 BST by Luke Kenneth Casson Leighton
Modified: 2023-05-07 09:01 BST (History)
2 users (show)

See Also:
NLnet milestone: NLnet.2022-08-051.OPF
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
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2022-08-28 18:50:40 BST 
actually maxu. and maxs. as well as minu. and maxu.
these are needed for potential saturation scenarios

overflow occurs when src2 "wins" over src1.  swapping
the operands allows the opposite detection with no
need for a 2nd operation.

when used in sv with a scalar src2 it can be used to
clamp *and detect* when clamping occurred on an entire
vector src1.
Comment 1 Luke Kenneth Casson Leighton 2022-10-14 15:13:08 BST 
also need Rc=1 variants which merge "cmp" functionality into
the instructions.  has to be done carefully because it's not
exactly the same as normal Rc=1, it is more like "cmp".
Comment 2 Luke Kenneth Casson Leighton 2022-10-23 17:03:57 BST 
combined cmp with max:

* the lt flag is set if RA<RB
* the gt flag if RA>RB

etc.

but XER.SO being set can detect if the entire batch is set.
the dependencies however are hell.  it would be better to have
a CRfield vector "reduction" operation, afterwards.
Comment 3 Luke Kenneth Casson Leighton 2022-10-24 09:41:15 BST 
CR0.GT being set is effectively "src2 wins"
CR0.LT is effectively "src1 wins"
CR0.EQ is effectively "nobody wins"
Comment 4 Jacob Lifshay 2023-04-21 02:08:29 BST 
https://git.libre-soc.org/?p=libreriscv.git;a=commitdiff;h=656bc167fc33f761f33e8ec80b09452d93a9bc8b

commit 656bc167fc33f761f33e8ec80b09452d93a9bc8b
Author: Jacob Lifshay <programmerjake@gmail.com>
Date:   Thu Apr 20 18:06:06 2023 -0700

    change minmax CR0 to be a compared with b, not the result compared with 0

I still need to change the simulator
Comment 5 Luke Kenneth Casson Leighton 2023-04-21 08:48:54 BST 
(In reply to Jacob Lifshay from comment #4)

>     change minmax CR0 to be a compared with b, not the result compared with 0
> 
> I still need to change the simulator

just the csv file RA_OR_ZERO should do it.
Comment 6 Jacob Lifshay 2023-04-21 08:55:24 BST 
(In reply to Luke Kenneth Casson Leighton from comment #5)
> (In reply to Jacob Lifshay from comment #4)
> 
> >     change minmax CR0 to be a compared with b, not the result compared with 0
> > 
> > I still need to change the simulator
> 
> just the csv file RA_OR_ZERO should do it.

no, the simulator needs the whole new pseudocode for minmax and opcode allocation and MM-form and MMM handling, etc. which i'm going to do all together

for a partial list see https://bugs.libre-soc.org/show_bug.cgi?id=1057#c0
Comment 7 Luke Kenneth Casson Leighton 2023-04-21 09:02:42 BST 
(In reply to Jacob Lifshay from comment #6)

> no, the simulator needs the whole new pseudocode for minmax and opcode
> allocation and MM-form and MMM handling, etc. which i'm going to do all
> together

ahh ok. i thought they'd been done already
Comment 8 Jacob Lifshay 2023-05-07 09:01:45 BST 
this has been added to both the pseudocode on the wiki and the simulator...CR0 is set to the result of comparing the inputs when Rc=1