search for: 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

Chris Lattner wrote: > >> We provide two sets of intrinsic functions in the port >> specific library and appropriate function call will be generated >> depending on whether we are in ISR or mainline code. The right way of >> doing this is to keep all the logic in legalizer - use the existing >> infrastructure and customize the library calls for each non-native

On Aug 27, 2009, at 7:44 PM, Sanjiv Gupta wrote: > Chris Lattner wrote: >> >>> We provide two sets of intrinsic functions in the port >>> specific library and appropriate function call will be generated >>> depending on whether we are in ISR or mainline code. The right way >>> of >>> doing this is to keep all the logic in legalizer - use the

> 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

On Aug 27, 2009, at 2:02 PM, Alireza.Moshtaghi at microchip.com wrote: > Extended thanks to the llvm community for feedback in advance, and > especially thanks to Jim for laying out a solution that captures all > aspects of the problems that we are facing. After some discussions > with > our team, we have decided to do the following, but to avoid further > conflict with llvm

Bringing it up again. - Sanjiv Sanjiv Gupta wrote: > Chris Lattner wrote: > >> We should discuss this on llvmdev, I think it came up before but there >> was no conclusive plan that was proposed. >> > The approach that we thought for PIC16 can be described in a > single line as below. > > "Keep the functions called from ISR and main separate by

...lvm-2.8 Thanks, -Ali > -----Original Message----- > From: Sanjiv Kumar Gupta - I00171 > Sent: Wednesday, August 26, 2009 11:41 AM > To: Jim Grosbach > Cc: Alireza Moshtaghi - C13012; clattner at apple.com; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...] > > Jim Grosbach wrote: > > Hi Ali, > > > > Thanks for bringing this up. You're definitely under very tight design > > constraints from the hardware. I can certainly sympathize. > Jim, > First of all, thank you very much for understanding every detail o...

Chris Lattner wrote: > > On Aug 21, 2009, at 11:13 AM, Alireza.Moshtaghi at microchip.com wrote: > >>>> Add a pass to do call graph analyis to overlay the autos and frame >>>> sections of >>>> leaf functions. This pass will be extended to color other nodes of >>>> the call tree >>>> as well in future. >>> >>>

Jim Grosbach wrote: > Hi Ali, > > Thanks for bringing this up. You're definitely under very tight design > constraints from the hardware. I can certainly sympathize. Jim, First of all, thank you very much for understanding every detail of the problem at our hand and coming up with a solution that addresses every aspect of it. IMO, given the constraints, this is probably the best

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