ISR Use of Registers; Privileged Mode?

[gray]

Two questions:

• With an interrupt, only R0 to R3 [1] are pushed onto the stack upon entry of the ISR. Does the compiler automatically account for this limitation when compiling ISRs, or is there anything I need to take care of manually?
• Does all thread mode (ie. not handler) code run privileged? Is there a defined/systematic way to set this (short of some SYSTEM.EMIT sorcery?)

[1] plus R12, LR, PSR and return address, but that is not relevant here.

[cfbsoftware]

When an interrupt handler is invoked any additional registers that need to be saved are automatically saved.

All Astrobe applications run in Privileged mode. There is no built-in support for running in User mode.

[gray]

When an interrupt handler is invoked any additional registers that need to be saved are automatically saved.

Just to be sure: so all exception handlers, not only ISRs (eg. a handler for the SVC call/exception), need to be marked with the square-bracketed integer, like 'PROCEDURE handler[0]', so the compiler is aware of this requirement?

[cfbsoftware]

Yes - that is the function of the square brackets after the procedure (handler) name. It indicates to the compiler that registers have to be saved on entry to the handler and restored on return. Refer to section 4.6 Interrupt Handlers in the Astrobe ARM Cortex-M Oberon programmers Guide for more detail. This document is included in the Astrobe distribution or can be downloaded from the Oberon page on the Astrobe website:

https://www.astrobe.com/Oberon.htm

[gray]

And you don't mark the exception handlers in Traps.mod with square brackets because it does not matter, as you never return to the interrupted code anyway?

Sorry for all the nagging, I would like to understand all this...

In the same vein -- the nagging and trying to understand -- another question about Traps.mod: why do you assign SVCTrap to the vectors 000H and 004H:

Code: Select all

PROCEDURE Init*;
VAR
  i, addr: INTEGER;
BEGIN 
  Assign(DataStart, SVCTrap);
  Assign(ResetVector, SVCTrap);
  ...

[cfbsoftware]

And you don't mark the exception handlers in Traps.mod with square brackets because it does not matter, as you never return to the interrupted code anyway?

Correct.

In the same vein -- the nagging and trying to understand -- another question about Traps.mod: why do you assign SVCTrap to the vectors 000H and 004H:

All unassigned interrupt locations are initialised to 1. Hence if an unassigned interrupt occurs, execution will then proceed at address 0 which will invoke the standard trap handler. 004H is unlikely to be landed on but just in case ...