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..?
Tucker032
That they different targeted families (R for real-time), I wasnt' doubting. My original question was specifically why longer pipeline on R: because you should start processing an ISR faster with a shorter pipline (I would think ..?).
Tucker032 said:Performance Monitor Unit, Yes, No Performance Monitor Unit: This is the module which makes Cortex-R to be used for Real Time Applications.
This I didn't understand, what do you mean, and how the PMU relates to the pipline ..
Also, from its description:
https://developer.arm.com/documentation/100026/0101/performance-monitor-unit/about-the-pmu?lang=en
"..These provide useful information about the behavior of the processor that you can use when debugging or profiling code.."
This does not make or explain how R architecture is real-time. This is for monitoring its performance.
EDIT:
Interestingly this article on link here: https://www.design-reuse.com/articles/26106/cortex-r-versus-cortex-m.html . Also says "PMU is really what makes Cortex R be used for real-time apps: helps in profiling". Ok, so I need to profile the code on core, after selecting it .. which I should select based on knowing its real-time should allow me to meet my real-time to begin with... hmmm.
Also, that same link interestingly says: latency is higher for R then M.. Whaaaaat. And not even for pipline reasons, as suggested there.