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. 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel