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 <heshamelmat...@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.sherr...@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.sherr...@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.sherr...@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@rtems.org >>>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>>>> -- >>>>>> Joel Sherrill, Ph.D. Director of Research & >Development >>>>>> joel.sherr...@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@rtems.org >>>>>> http://lists.rtems.org/mailman/listinfo/devel >>>> -- >>>> Joel Sherrill, Ph.D. Director of Research & Development >>>> joel.sherr...@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.sherr...@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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
