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