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