SK-AM64B: PRU: Deprecation of SUC and RSC

Hello Dimitar,

Baseline - what we know so far

The carry bit works as expected with ADD, ADC, SUB, RSB.

As far as I can tell from looking at the SUC source code (and in alignment with Michel's tests here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1244359/sk-am64b-am64x-pru-assembler-how-works-this-bloody-carry/4754696#4754696 ), SUC uses the carry bit improperly: if there IS a carry bit, no carry math happens, and if there is NOT a carry bit, then 1 is subtracted from the result.

From Michel's test code:

LDI32 r4, 0xfffffffe
ADD r5, r4, 1 ; no carry expected
SUC r5, r5, 0 ; so should not change the result, 0xffffffff expected

R4: 0xFFFFFFFE
R5: 0xFFFFFFFE

LDI32 r6, 0xffffffff
ADD r7, r6, 1 ; carry expected
SUC r7, r7, 0 ; so should subtract 1 and return to 0xffffffff

R6: 0xFFFFFFFF
R7: 0x00000000

RSC is coded the same way as SUC, so it should have the same issues.

Multi-word arithmetic 

Do you have specific multi-word arithmetic pairs with SUC and RSC that you have validated provide correct outputs? If so, please let us know so we can take that information into account!

So far, I have only looked at the most basic 64 bit subtracts, which should give the wrong outputs:

sub64(reg64 dst, reg64 src1, reg64 src2)
expands out to
{ sub32(dst.bits00_31, src1.bits00_31, src2.bits00_31);
suc32(dst.bits32_63, src1.bits32_63, src2.bits32_63); }

and

rsb64(reg64 dst, reg64 src1, reg64 src2)
expands out to
rsb32(dst.bits00_31, src1.bits00_31, src2.bits00_31);
rsc32(dst.bits32_63, src1.bits32_63, src2.bits32_63);

Regards,

Nick

I tested the following function written in assembly. It returns value 0 in r14. So to me it looks like carry works correctly if used in SUB/SUC pairs to implement multi-word arithmetic.

        .text
        .global test
test:

        ldi     r14, 0                  # Return result. 0 on success.

        # Test carry
        ldi     r0, 0x0100
        ldi     r1, 0x0001

        sub     r20.b0, r0.b0, r1.b0    # Multi-word arithmetic
        suc     r20.b1, r0.b1, r1.b1
        sub     r21.w0, r0.w0, r1.w0    # Single-word arithmetic
        xor     r20, r20.w0, r21.w0
        max     r14, r14, r20           # Catch non-zero result in r20.


        # Test no carry
        ldi     r0, 0x0102
        ldi     r1, 0x0001

        sub     r20.b0, r0.b0, r1.b0    # Multi-word arithmetic
        suc     r20.b1, r0.b1, r1.b1
        sub     r21.w0, r0.w0, r1.w0    # Single-word arithmetic
        xor     r20, r20.w0, r21.w0
        max     r14, r14, r20           # Catch non-zero result in r20.

        ret

Hello Dimitar,

I will try to replicate your tests on my side tomorrow.

Regards,

Nick

Hello Dimitar,

First off, thank you for creating this post.

I have not had time to run tests on hardware yet, but spent some time chatting with other folks about this issue. I think you might be correct with your statement that SUC and RSC were only designed to be used with specific instructions.

There is only a single carry bit that can be used. And the same carry bit is used for both ADC and SUC. However, the nature of the carry bit is different for 64 bit adds than it is for subtracts (where the carry output of ADD is a positive 1, and the carry output of SUB should be a negative one). So I can see why a designer might not consider passing the output of ADD into SUC during the design process, if SUC is expecting a negative carry instead of a positive carry.

If these carry bits are treated differently under the hood, maybe that could lead to the observed behavior (e.g., if ADD outputting a positive carry means carry_bit=1, while SUB outputting a negative carry means carry_bit=0). I am following up with some teammates to try to dig a bit deeper into the low-level behavior.

Feel free to ping the thread if I have not provided an update towards the middle or end of the week.

Regards,

Nick