Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Hesham Moustafa]

I can use this in my port from my assembly code part of _ISR_Handler
just before calling the user C Handler. Something like putting
#if CPU_ISR_PASSES_FRAME_POINTER
 l.add r4, sp, r0
#endif

where r3 and r4 are the first and second arguments respectively.

RTEMS Clock_isr() (which I use for tick timer interrupt) and maybe
other RTEMS C Handlers may not make use of it as some of them are
defined with void arguments.

As Gedare suggested, I provided a default _OR1K_Exception_default that
receives vector number and exception frame pointer.

On Fri, Aug 8, 2014 at 5:13 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>
> On 8/8/2014 10:11 AM, Gedare Bloom wrote:
>> On Fri, Aug 8, 2014 at 10:52 AM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> On 8/8/2014 9:38 AM, Hesham Moustafa wrote:
>>>> On Fri, Aug 8, 2014 at 4:02 PM, Joel Sherrill <joel.sherrill at oarcorp.com> wrote:
>>>>> On 8/8/2014 8:54 AM, Gedare Bloom wrote:
>>>>>> Hi,
>>>>>> The macro CPU_ISR_PASSES_FRAME_POINTER is part of a cpu port defined
>>>>>> in cpu.h, but this macro seems to be unused. I don't know what the
>>>>>> purpose of it was intended. Anyway, it appears to be wrong for some
>>>>>> architectures (ARM and sparc64 at least, maybe others). Should we
>>>>>> remove the macro, or find a use for it and make sure it is correctly
>>>>>> defined for each arch?
>>>>> The intent is that for simple vectored, some architectures passed a vector
>>>>> number and some passed a vector number and a pointer to the interrupt
>>>>> stack frame. This predates the addition of the PIC model.
>>>>>
>>>>> In general terms, I don't know if all simple vectored architectures
>>>>> pass one or two parameters.
>>>>>
>>>>> Is this used anywhere in the tree? Sometimes drivers would use it to
>>>>> adjust the ISR handler prototype to avoid warnings.
>>>> It's used only at isr.h:62
>>>>
>>>> 62 #if (CPU_ISR_PASSES_FRAME_POINTER == 1)
>>>>  63 typedef ISR_Handler ( *ISR_Handler_entry )(
>>>>  64                  ISR_Vector_number,
>>>>  65                  CPU_Interrupt_frame *
>>>>  66              );
>>>>  67 #else
>>>>  68 typedef ISR_Handler ( *ISR_Handler_entry )(
>>>>  69                  ISR_Vector_number
>>>>  70              );
>>>>  71 #endif
>>> But that has rippling implications.  I don't think we want to
>>> change that at the moment. But we could turn it to 1 for
>>> every architecture and see the impact.  But most architectures
>>> have it as single arg. I know the MIPS passes it in so it can
>>> handle FPU exceptions in an RTEMS ISR. To get IEEE FP
>>> on some MIPS, you need the exception handler.
>>>
>>> All other ports set this to FALSE/0.
>>>
>> Well, so far I've seen that arm, sparc, and sparc64 pass the frame
>> pointer. i386 does not.
> The setting doesn't seem right for those. I only saw 1/true for MIPS.
>
> It could be wrong for those.
>> -Gedare
>>> So percpu.h needs to be fixed.
>>>>>> Gedare
>>>>>> _______________________________________________
>>>>>> devel mailing list
>>>>>> devel at rtems.org
>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>> --
>>>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>>>> Support Available                (256) 722-9985
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> --
>>> Joel Sherrill, Ph.D.             Director of Research & Development
>>> joel.sherrill at OARcorp.com        On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>>> Support Available                (256) 722-9985
>>>
>
> --
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
> Support Available                (256) 722-9985
>