SPARC _ISR_Handler questions
Joel Sherrill
joel.sherrill at oarcorp.com
Fri Mar 17 16:38:02 UTC 2006
Aleix Conchillo Flaqué wrote:
> Hi again,
>
> regarding my second question, I've just read about
> CPU_ISR_PASSES_FRAME_POINTER. If it is defined with a 1 value then
> the ISR_Handler_entry has a second parameter to the interrupt stack
> frame.
>
> In the case of SPARC, it is defined as (in cpukit/score/cpu/sparc/
> rtems/score/cpu.h)
>
> #define CPU_ISR_PASSES_FRAME_POINTER 0
>
> Does this means that the second argument (%o1) in cpu_asm.S could be
> omitted?
>
Yes. There is no particular reason to keep passing it. Especially
since the
ERC32 is slow enough that saving one instruction is critical. :)
--joel
> Thanks in advance... again.
>
> Best regards,
>
> aleix
>
> On 17 Mar 2006, at 14:54, Aleix Conchillo Flaqué wrote:
>
>> Hi,
>>
>> I'm trying to implement my own _ISR_Handler (without threading or
>> context switching) and I'm looking the RTEMS _ISR_Handler
>> (cpu_asm.S) code. There two things I don't understand:
>>
>> 1. At the beginning of the routine, the %l1 (PC) is saved into %l6,
>> but %l6 I think it is not used anymore. Why it needs to be keeped?
>> Or... where it is used?
>>
>> 2. When calling the user's handler (call %g4, 0), one argument must
>> be given in %o0 which is the vector number. This is fine as the
>> ISR_Handler_entry type is defined with this argument. But a second
>> argument (%o1) is passed, more concretelly the code reads: o1 = 2nd
>> arg = address of the ISF WAS LOADED... I don't see how the user's
>> handler know about this argument. I don't understand why is it passed.
>>
>> Thanks in advance.
>>
>> Best regards,
>>
>> aleix
>>
>
More information about the users
mailing list