This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Context save/restore seems to take too many cycles?

Champs,

I asked this for a key customer.

On F2837x, 

This is the diassembly codes of the customer's critical ISR code by C compiler for context save (top left) and context restore (bottom right).

Based on these codes, it takes more than 30 cycles for context save/restore, is it right?

If we add 15-20 cycles of interrupt latency (from the event trigger to entry of the ISR), then there should be at least 20+30 = 50 cycles used in this ISR for interrupt latency, context save/restore.

Is my understanding right?

This should be limited to the architecture of C28x, right?

Is it possible to significantly reduce the context save/restore cycles without resorting to assembly manually?

(That is, use C compiler only)

Wayne Huang

  • Wayne,

    It looks about right for a nestable interrupt.  If you are not using TI-RTOS, and the ISR in question has the highest priority (i.e. won't be nested), you can make use of the INTERRUPT pragma, like this:

    #pragma INTERRPUT(control_isr_cpu1_pwm8, HPI)

    This forces the compiler to use SAVE & RESTORE instructions for the FPU part of the context save, rather than using MOVL for each register separately.  It should remove about 4 cycles on both the context save and context restore.  See section 6.9.14 of the C compiler guide for more information.  Apart from that I don't think you can do much without going to assembly or somehow making use of the CLA.

    Regards,

    Richard 

  • Richard,

    I see.
    Thank you for your information.

    Wayne