search for: nonisr_only

...-class platform we can probably consider it to be a design flaw if the programmer doesn't know whether a function pointer will be dereferenced from interrupt context or not. This suggests that for any function whose address is taken, there could be a required annotation such as ISR_ONLY or NONISR_ONLY. The compiler could use this to do the right thing without any heroic static analysis or dynamic binding. John

...der it to be a design > flaw if > the programmer doesn't know whether a function pointer will be > dereferenced from interrupt context or not. This suggests that for > any > function whose address is taken, there could be a required > annotation such > as ISR_ONLY or NONISR_ONLY. The compiler could use this to do the > right > thing without any heroic static analysis or dynamic binding. > That could work as well; however, for the PIC16, I'd still be tempted to go with a descriptor table for function pointers. Otherwise, a function pointer would need to...

Hi Ali, Thanks for bringing this up. You're definitely under very tight design constraints from the hardware. I can certainly sympathize. I think two design elements are being conflated here, and it would be worthwhile splitting them out. For correctness, you need to make sure any routines called from an ISR don't clobber equivalent routines called from mainline code. For

Up front I apologize for the lengthy email. Since our patch was not accepted, Chris asked us to follow up with this issue on llvm-dev. For the sake of completeness, let me give a bit of background and the problems that we are facing. I tried to capture as much as possible here so Please do give us feedback. Don't take your stack for granted.... PIC16 has very poor pointer handling, hence