What registers are safe ?

I’ve checked the docs for this, but I can’t find an answer.

On an arm target, what registers can be used for the interrupt
“snippets” that are user provided. Are all registers
saved/restored (with the exception of the documented
parameters/returns) around where the “snippet” is pasted
in ? If not, which registers are safe to use ?

Specifically I am interested in the mask/unmask snippets.

Rennie

Brian Stecher wrote:


For the oddball routines, even though the code isn’t being “called” and
the arguments and return value are in strange places, you should follow
the register save/restore rules for a normal function call.

Yes, these are what I am interested in (I had incorrectly understood that
unmask/mask were “snippets” also - I am clear on that now).

Are you saying that in the “oddball” routines I should save/restore all
registers ? This seems to defeat the purpose of making them “snippets”
to begin with. The sample code I am using (ARM integrator) doesn’t save
all registers on entry/restore all on exit for eoi or id.

Rennie

Rennie Allen <rallen@csical.com> wrote:

I’ve checked the docs for this, but I can’t find an answer.

On an arm target, what registers can be used for the interrupt
“snippets” that are user provided. Are all registers
saved/restored (with the exception of the documented
parameters/returns) around where the “snippet” is pasted
in ? If not, which registers are safe to use ?

Specifically I am interested in the mask/unmask snippets.

In the Building Embedded Systems book, where it talks about writing
your own callout, it notes that they’re invoked with the normal
function calling conventions (aside from the interrupt_id/_eoi oddballs).
Follow whatever the rules are for a normal ARM function (I don’t know
off-hand what they are for that architecture).

For the oddball routines, even though the code isn’t being “called” and
the arguments and return value are in strange places, you should follow
the register save/restore rules for a normal function call.


Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

Rennie Allen <rallen@csical.com> wrote:

Brian Stecher wrote:

For the oddball routines, even though the code isn’t being “called” and
the arguments and return value are in strange places, you should follow
the register save/restore rules for a normal function call.

Yes, these are what I am interested in (I had incorrectly understood that
unmask/mask were “snippets” also - I am clear on that now).

Are you saying that in the “oddball” routines I should save/restore all
registers ? This seems to defeat the purpose of making them “snippets”
to begin with. The sample code I am using (ARM integrator) doesn’t save
all registers on entry/restore all on exit for eoi or id.

No, as I said above, you treat the “snippets” as normal function calls
for the purposes of determining which registers you need to save and
which you can just trash. The only differences are which registers
the “arguments” come in from, where the “return” value is placed
and the fact that you fall off the bottom of the code rather than
using a “return from subroutine” instruction.

\

Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

Rennie Allen wrote:

Brian Stecher wrote:


For the oddball routines, even though the code isn’t being “called”
and the arguments and return value are in strange places, you should
follow the register save/restore rules for a normal function call.

Yes, these are what I am interested in (I had incorrectly understood that
unmask/mask were “snippets” also - I am clear on that now).

Are you saying that in the “oddball” routines I should save/restore all
registers ? This seems to defeat the purpose of making them “snippets”
to begin with. The sample code I am using (ARM integrator) doesn’t save
all registers on entry/restore all on exit for eoi or id.

You can safely use r0-r3 and ip within the id/eoi code.

r4 is expected to contain the (controller relative) interrupt vector.
r5-r8 can hold values put there by the kernel code that invokes the
startup fragments. These are described in the comments at the top of
the callout_interrupt_integrator.S file.

If you use any other registers you will need to preserve them in your
callout code.

Sunil.