llvm dev - Aug 2009 - [LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]

> Function pointers are where things get fun. To do these, we need to
> determine at run time whether we need to call the ISR or the mainline
> version of a function
This sounds convenient but it may well be overkill.

On a PIC-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

On Aug 25, 2009, at 8:59 AM, John Regehr wrote:
>> Function pointers are where things get fun. To do these, we need to
>> determine at run time whether we need to call the ISR or the mainline
>> version of a function
>
> This sounds convenient but it may well be overkill.
>
> On a PIC-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.
>
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 be 32-bits wide (16 for the function  
itself, and 16 for the argument address). At that point, it's a very  
short step to supporting the runtime decision about which version of  
the function to call. Generally speaking, I've found that when  
possible, it's best for the compiler to just do the right thing  
without requiring additional annotations from the user. Every time  
I've strayed from that in a PIC target compiler, I've regretted it.

Regards,
   Jim

Right now, we are saving the address to frame right before the beginning
of function code space; so before calling the function pointer, we have
the frame pointer as well. That saves us two bytes of valuable ram -
compared to rom - per pointer (and with a bit of analysis we can only do
this for functions whose address is taken as to not waste rom space
either). Jim's proposal for adding second pointer for ISR function
pointers is generic and tempting, and with pointer to frame before each
function, we would only need two 16-bit pointers for each fptr; and it
eliminates need for static analysis of code to figure things out. But
still there is ram over usage that may not be favorable by the user of
the compiler. I think the benefits of this approach are enough to make
it fly but I have to look into that a little more.

Thanks,
-Ali
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
On
> Behalf Of Jim Grosbach
> Sent: Tuesday, August 25, 2009 9:30 AM
> To: John Regehr
> Cc: llvmdev at cs.uiuc.edu
> Subject: Re: [LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]
> 
> On Aug 25, 2009, at 8:59 AM, John Regehr wrote:
> 
> >> Function pointers are where things get fun. To do these, we need
to
> >> determine at run time whether we need to call the ISR or the
mainline
> >> version of a function
> >
> > This sounds convenient but it may well be overkill.
> >
> > On a PIC-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.
> >
> 
> 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 be 32-bits wide (16 for the function
> itself, and 16 for the argument address). At that point, it's a very
> short step to supporting the runtime decision about which version of
> the function to call. Generally speaking, I've found that when
> possible, it's best for the compiler to just do the right thing
> without requiring additional annotations from the user. Every time
> I've strayed from that in a PIC target compiler, I've regretted it.
> 
> Regards,
>    Jim
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev