This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Longer pipelines on Cortex R's vs real-time & performance

On Cortex M's , you have 3 stage pipelines, while Cortex R's starting from R4 up you have 8 stage, and R7 even 11.

I don't understand, isn't worse for real-time interrupt response to have longer pipelines? I did read that Cortex-R can interrupt long stores/loads, and jump straight to the vector address & the irq number passed, that is great, but doesn't the pipeline get flushed every hw interrupt or exception/fault, and needs to be re-filled with instructions? So more cycles spent.?  And, it's not that the pipeline get saved for return from interrupts..? 

Parents
  • Which then I'm back strongly to my question (or almost..) Why is the R4  (or Cortex-R in general) is "Real-Time", when you can get faster reponse from and M4 ??

    I have seen one "explanation": The Cortex-R can accept interrupts during multi-cycle instructions (like STM,LDM and maybe xDIV).

    But honestly: I never understood why the Cortex-M concept of automatic saving registers never made it to Cortex-R.

    The term "real time" is something the application defines, never the CPU.

Reply
  • Which then I'm back strongly to my question (or almost..) Why is the R4  (or Cortex-R in general) is "Real-Time", when you can get faster reponse from and M4 ??

    I have seen one "explanation": The Cortex-R can accept interrupts during multi-cycle instructions (like STM,LDM and maybe xDIV).

    But honestly: I never understood why the Cortex-M concept of automatic saving registers never made it to Cortex-R.

    The term "real time" is something the application defines, never the CPU.

Children