What is the reason Cortex-M3 has the initial stack pointer value located at 0x0, and reset handler located at 0x4? What is the design justification for this?
Why couldn't the ARM guys leave 0x0 to the reset handler like they do for Cortex-A, then initialize SP inside the reset handler?
On
I think this one falls under the "it's not a bug, it's a feature" banner.
The ARM architecture M (microcontroller) profile has a completely different exception model to the A and the R profiles. The A-profile (like the R-profile) retain backwards compatibility with previous ARM processors. The M-profile was permitted to deviate from this, and so was designed to be easier to program completely from C/C++ (without asm).
Thus vector entries containing addresses rather than instructions, and once you've done that, why not set the SP in the same way? It also does automatic state saving on exception entry.
On
Cortex-M and Cortex-A has different approach when it comes to booting and vector tale handling.
Cortex-M: by design the processor should fetch first the Stack pointer from address 0 and reset handler from address 0x4 as part of the boot sequence after reset, then any incoming interrupt its interrupt handler (in cortex-m the interrupts are vectored means any interrupt must has its own interrupt handler) must be fetched from the vector table entry , generally speaking in common case the stack pointer and reset hander are placed on tp of the vector table and rest of interrupts handlers are placed after that in order and here the position of each handler within vector table is very important because this is how the cortex-m which handler correspond to which interrupt signal. The big advantage of such mechanism allowing direct fetching of the address and executing right a way the first instruction of the handler as well as for reset handler is to minimize the boot time as interrupt latency so that many aspect of context switching and booting handled mostly by hardware and this allow of course more deterministic boot time and interrupt latency because we avoid dealing with caches for such thing and this is very suitable for real time application, this is one of the reason why arm wanted to have a dedicated family of processors for real time application and they succeed actually here.
Cortex-A: in the other hand Cortex-A from its use case definition is not aimed for real time applications but for high performance computation as well as running full operating system on top of it, so they kept the standard way on how vector table should looks like and no deviation let's say from the standard exist there, so here the vector table consists of multiples entries like in cortex-m but the difference is that in cortex-a each vector table entry is a jump instruction to corresponding exception mode handler but in cortex-m is the exception handler address itself, one of the reason I think in cortex-A is to allow more freedom and space to handle proper mode switching before jumping to actual handler which is way sophisticated than the case of cortex-m where we have only two modes hander/thread managed fully by hardware.
everything unixsmurf said...
The traditional arm approach was a little strange, the typical approach is a list of addresses, not a table of instructions. So that may have been a factor. But they created a gobzillion interrupts not just the one (the vector table is 128/256 deep not just a handful) and no doubt you dont want to have to wrap every interrupt before calling C so the vector table, the changes in/lack of modes, and preserving registers for you, puts this package all together. You can put the address of the C handler right in the table, including the reset vector, to get the reset vector in there you need to have at a bare minimum set the stack pointer before calling, thus you need a spot for the user to indicate the initial value for the stack pointer.