ISR Use of Registers; Privileged Mode?

Download pre-release library modules and new examples to use with Astrobe for Cortex-M. Forum members can also upload their own source code examples.
Post Reply
gray
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

ISR Use of Registers; Privileged Mode?

Post by gray » Tue Feb 19, 2019 3:09 am

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
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: ISR Use of Registers; Privileged Mode?

Post by cfbsoftware » Tue Feb 19, 2019 11:20 am

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
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Re: ISR Use of Registers; Privileged Mode?

Post by gray » Tue Feb 19, 2019 1:41 pm

cfbsoftware wrote: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
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: ISR Use of Registers; Privileged Mode?

Post by cfbsoftware » Wed Feb 20, 2019 7:45 am

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
Posts: 109
Joined: Tue Feb 12, 2019 2:59 am
Location: Mauritius

Re: ISR Use of Registers; Privileged Mode?

Post by gray » Wed Feb 20, 2019 9:25 am

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);
  ...
Last edited by gray on Wed Feb 20, 2019 3:13 pm, edited 1 time in total.

cfbsoftware
Site Admin
Posts: 493
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Re: ISR Use of Registers; Privileged Mode?

Post by cfbsoftware » Wed Feb 20, 2019 11:14 am

gray wrote: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.
gray wrote: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 ...

Post Reply