Bug 926 - add with carry from CR field
Summary: add with carry from CR field
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
Depends on:
Reported: 2022-09-12 03:08 BST by Luke Kenneth Casson Leighton
Modified: 2023-04-16 16:31 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: 1011
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2022-09-12 03:08:02 BST
a vector add-with-carry is traditionally in-element, not
(as is the case with sv.adde) an alias for biginteger add.

weirdly all the adds in Power ISA do not have a variant
that takes CR Fields as carry-in producing carry-out.
slightly awkward is the fact that this may need to have
an Rc=1 variant as well, producing *two* CR Fields.

a workaround on that would be to leverage the CR.SO field
as both the carry-in and carry-out.
Comment 1 Jacob Lifshay 2022-09-12 03:49:43 BST
imho add-with-carry-in-cr-fields should just disallow Rc=1, simplifying it substantially.
Comment 2 Luke Kenneth Casson Leighton 2022-09-12 11:56:03 BST
(In reply to Jacob Lifshay from comment #1)
> imho add-with-carry-in-cr-fields should just disallow Rc=1, simplifying it
> substantially.

i honestly don't know which would be best, here, whether it is mandatory Rc=1
because you have to write it anyway, or, hum.

but it is definitely needed (as an instruction) - parallel carry-adding
would otherwise need the same awfulness as any other ISA lacking carry

but, also, hum, i am kinda surprised this hasn't been added before, i mean
surely using Rc=1 or cmpi is common to find out if carry should occur, right?

oh one idea i have been mulling over (related here): some bits in SVSTATE
which offset where Rc=1 vector results go.

if this new instruction were to *read* the Rc=1 CR field (to obtain the Carry)
then that offset would be relevant, but most importantly an extra operand
specifying the CRfield src (and dest) for carry-in carry-out would not be

behind the scenes although it does not look like it, this is a 3-in 2-out
operation which are borderline (expensive on Hazard Management).

source: RA RB CRf
dest  : RT    CRf