Unused macro: CPU_ISR_PASSES_FRAME_POINTER

[Joel Sherrill]

You don't protect or1k specific code with this. It is only supposed to be used in generic code. I suspect the generic clock framework has a cast to cover this up 

On August 9, 2014 3:04:09 AM CDT, Hesham Moustafa <heshamelmatary at gmail.com> wrote:
>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
>>