Bug 926

Summary:	add with carry from CR field
Product:	Libre-SOC's first SoC	Reporter:	Luke Kenneth Casson Leighton <lkcl>
Component:	Specification	Assignee:	Luke Kenneth Casson Leighton <lkcl>
Status:	CONFIRMED ---
Severity:	enhancement	CC:	libre-soc-isa, programmerjake
Priority:	---
Version:	unspecified
Hardware:	Other
OS:	Linux
See Also:	https://bugs.libre-soc.org/show_bug.cgi?id=924 https://bugs.libre-soc.org/show_bug.cgi?id=1009 https://bugs.libre-soc.org/show_bug.cgi?id=1027
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:

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.
hm.

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
flags.

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
needed.

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