We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello experts,
I would like to ask the reason why the exception frame forms on PSP in the Cortex-M architecture.My understanding is that MSP (Main Stack Pointer) is the interrupt stack pointer and PSP (Porcess Stack Pointer) is the normal (user) stack pointer.From my little experiences, the exception frame was formed on the interrupt stack.However, the ARM forms it on the user stack.
Best regards,Yasuhiko Kouoto.
There's a whole section on errors like stack overflow in the manual but it won't stop an interrupt being handled Basically there is a derived interrupt and the information for that goes on the interrupt stack.
Whether the registers are saved on the interrupt stack or the process stack makes very little difference except when switching processes. I believe the real reason is as I said to cut down overheads on switching between different processes.
Hello daith,
I am sorry but I cannot understand what you say.
What is the overhead?
I would like you to explain by pictures as even a monkey can understand.
If you think of the concrete OS, please tell me what it is.
Best regards,
Yasuhiko Koumoto.
The saving is in not copying 16 words on every process switch or possibly more if using floating point.
I had alook on the web and here's a description of what's done
Context Switching on the Cortex-M3
Suppose we are time-slicing between processes.
When the timer interrupts the current process a stack frame is stored on the process stack instead of the interrupt stack. The stack frame will include any registers which are not callee save. That is r0-r3,r12,lr,pc and PSR
The interrupt routine decides which process should get then next timeslice. It sets the PendSV interrupt to do the actual switch when the process stack is about to resume execution. This isn't very relevant but it is a mechanism to ensure the routine doing the switch has very low priority and will return to the process stack and that all the callee save registers are okay. The timer interrupt might be written in C but the PendSV interrupt would be written in assembler to have complete control over what happens with the registers.
The processor will chain to the PendSV interrupt when just about to return to the process.
In this routine what it has to do is store all the callee save registers of the old process and load up all the callee save registers of the new process. These are all the registers except r0..r3 etc. above. These can be saved on the process stacks or into a structure associated with the process. It saves the old process stack pointer into the structure associated with the old process. and loads the new process stack pointer from a structure associated with the new process.
It then returns from the interrupt. This will automatically load all the registers which are callee save and continue execution in the new process.
If the interrupt frame for the initial timer interrupt was stored on the interrupt stack then as well as what is done above that stack frame would have to be moved from the interrupt stack either to a structure associated with the old process or to the old process stack. It would then have to move the interrupt frame for the new process to overwrite where the interrupt frame of the old process was. Thus having the frame on the interrupt stack rather than the process stack means that two interrupt frames worth of data have to be moved for every process switch. Therefore another 16 words at least have to be moved. If the process uses floating point registers a lot more have to be moved.
thank you for your effort.
It is very helpful.
However, it looks to me like a problem chicken and egg.
I think the OS is so designed to utilize fully Cortex-M features.
According to your explanations, the Cortex-A case has a big overhead in the multi-processing or multi-tasking.
Is it correct?
The Cortex-A series don't handle things like interrupt chaining or preemption quite so nicely and efficiently. The big difference is that Cortex-M is designed to be simple to program using C and yet to handle interrupts as quickly as possible when used in the way it is designed for, whereas the Cortex-A series is designed more for flexibility, the programmers are in full charge of every aspect and can put all sorts of operating systems on top. Cortex-A cores are faster and yet are not normally expected to be handling enormous numbers of real time low level interrupts like Cortex-M cores do but to be more concerned with higher level decisions and user programs. There isn't quite the same drive to extract the very last cycle out of interrupt handling. A very simple Cortex-M system though might not even have anything that looks like an operating system on it, just interrupt routines to handle some hardware.
I'm sorry for late reply.
I want not to get a semantic or structural reason, but I'd like to simply know that ARM Cortex-M takes such a scheme.
Regarding the overhead, I cannot still understand without any pictures to explain it.
At the context switch, I think the registers would not get from the stack frame.
Also, I cannot understand your explanation why Cortex-A does not take such a scheme.
The overhead is pretty straightforward. This isn't exactly what happens but it illustrates the main point.
Context switch if interrupt data is stored on MSP
Timer interrupt. Interrupt data stored on MSP
Copy some registers to old process specific area
Copy interrupt data from MSP to old process specifc area
Set PSP for new process
Copy interrupt data for new process to MSP
Copy some registers from new process specific area
exit to continue new process, restore state from MSP
Context switch if interrupt data is stored on PSP
Timer interrupt Interrupt data stored on old process PSP
exit to continue new process, restore state from new process PSP
The way Cortex-M does it is just not what a person used to Linux or some other such operating system would expect. It could be simulated on Cortex-A series but it requires hardware support to work well.