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.
imho add-with-carry-in-cr-fields should just disallow Rc=1, simplifying it substantially.
(In reply to Jacob Lifshay from comment #1)
> imho add-with-carry-in-cr-fields should just disallow Rc=1, simplifying it
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