Using C and reading CPU Register (Carry-Flag) via assembler

For the sake of completeness -

STMDB   R13!, {R1}

and

LDMDB   R13!, {R1}

above can be discarded.

you are interested in CRSR -> you are interested in CPSR

Hey Tamir,
thanks for your fast reply.

I am working on an ARM Cortex-M3. CPSR was unknown to the compiler, but APSR wasn't :)
Anyways, I placed your code (with CPSR changed to APSR) in a new .c file and it compiled without grumping :]

For evaluation I tried that:

int
main(void)
{
        unsigned long dummy;
        unsigned long a=1000;
        unsigned long b=10000;

        dummy = a - b;  //Carry-bit should be set
        UARTprintf("\n: %d \n", processor_in_user_mode);
        dummy = b - a;//Carry-bit shouldn't be set
        UARTprintf("\n: %d \n", processor_in_user_mode);

but both times it prints out '489' which is:

111101001

so nothing changed. But register 17 bit 31 is according to the datasheet the carry bit, which should have changed here...
I also tried PSR instead of APSR: no change

By the way: CPSR is printed bold in code, PSR or APSR isn't.

Hi Susan

Couple of options:

Use this standardized CMSIS function portable between popular toolchains

__get_APSR(void)

Or use MDK/RVCT specific named register variables

uint32_t apsr __asm("APSR");

if (apsr & APSR_C)
   // do this
else
   // do that

Hope this helps
Marcus

Note that you can manage quite well without ever knowing the content of the carry bit.

if (b >= a) {
    b -= a;
    // no borrow
} else {
    b -= a;
    // handle borrow
}

unsigned a,b,c;
c = a+b;
if (c < a || c < b) {
    // addition overflow
}

Point taken - didn't know that C works that way (owning the carry bit).
Would it work, if the prior calculation was in assembler, too? 'Cause I thought that the codepart written in assembler will be transcoded to machinecode in a coherent way...won't it?

I wanted to avoid the method Per suggested, because I was just curious if it is possible to avoid it. That was my single goal: Curiosity :-) . Stupid, I guess.

Now I will just do it the standard way without using assembler.

Thanks a lot for your help!

Marcus, I tried yours, too.

__get_APSR(void)

Do I need a special header or include file for this?
Cause µVision tells me:

undefined symbol __get_APSR();

identifier "APSR_C" is undefined, respectively (when trying the other one)

__get_APSR() is defined in CMSIS, so yes, you do need to include a header file, namely core_cmFunc.h.

The identifier APSR_C was just a made up example, perhaps defined as macro, to demonstrate that you need to compare with a numeric value. BTW, CMSIS also defines a structure APSR_Type so that you could perhaps write something like:

if ((APSR_Type)apsr.b.C)
  // do this
else
  // do that

But as others have said already: For your purposes, this is completely unnecessary.

Best regards
Marcus

The ARM compiler is "smart" enough that it merges the assembler instructions with the instructions generated from the C code. Then it performs a number of optimization steps.

So inlined assembler need not survive unmodified to the finaly binary.

If you want to implement a large-number library while using the carry flag, then you should implement the evaluations fully in assembler.

Note that a comparison "if (a >= b)" is very fast on the ARM processor, and the optimizer will recognize that it's the same variables in the comparison as in the actual subtraction. So no extra memory accesses. Just a comparison. And the optimizer might even note that the comparison and the subtraction are basically the same thing, and the code is still interested in a subtraction.

When programming in C - do stay with C. Do not try to fool the optimizer by taking short cuts. When you are not happy with C, because of special needs: write full functions in assembler.

That's the whole point of any high-level language (HLL) - you delegate responsibility for the low-level detail to the compiler.

Thanks a lot guys,
I will stay with C :-]