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
