similar to: [LLVMdev] LLVM and Interrupt Service Routines.

We've used the used attribute to ensure they are not deleted and had no problem. Andrew On Tue, Jul 21, 2009 at 10:07 AM, <Sanjiv.Gupta at microchip.com> wrote: > Hi, > Apparently, there is no explicit support for ISRs in the llvm framework.  I > could not find a matching attribute that can be used to mark a function as > an ISR, which codegen and optimizer can use

Hi Sanjiv, Assuming that that support for Ada in LLVM is complete, I would look to see if there is something that is done there. Ada provides two pragmas (Interrupt_Handler & Attach_Handler) which allow you to both statically and dynamically attach interrupts to procedures. Alex Karahalios On Jul 21, 2009, at 8:07 AM, <Sanjiv.Gupta at microchip.com> <Sanjiv.Gupta at

On 24/07/2009, at 19.41, <Alireza.Moshtaghi at microchip.com> wrote: > As you know PIC16 does not have stack; so generating code for ISR and > all functions that it calls (including all stdlib and basic math > intrinsics used for mult/div/etc) requires special code generation > techniques. But we don't have this information until after llvm-ld has > merged all compilation

Anton recently added support for __attribute__((naked)) in r76198 and r76201. I'd imagine that the GCC "interrupt" and "isr" synonyms would go in similarly. How each target handles the code generation differences will be the interesting part. deep On Tue, Jul 21, 2009 at 3:07 PM, <Sanjiv.Gupta at microchip.com> wrote: > Hi, > Apparently, there is no explicit

> If you have to generate two copies of the function with different > entrypoints, the *front-end* should handle the duplication. This is > just like C++ constructors. > > One really old patch that apple guys experimented in the past was a > "slow and fast call" attribute, which you could stick on function > declarations. If you added it to a function, the

On Jul 26, 2009, at 3:42 AM, Sanjiv Gupta wrote: >> >> What happens with functions that are called both inside and outside >> ISR context? Do you have to codegen two copies of those? >> >> > Yes. That's precisely what we are trying to achieve in llvm-ld. > But the problems don't end there, as llvm-ld doesn't have any idea of > libcalls

Jakob Stoklund Olesen wrote: > On 24/07/2009, at 19.41, <Alireza.Moshtaghi at microchip.com> wrote: > > >> As you know PIC16 does not have stack; so generating code for ISR and >> all functions that it calls (including all stdlib and basic math >> intrinsics used for mult/div/etc) requires special code generation >> techniques. But we don't have this

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

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. >>> >>>

Please read below: > > - Save /all/ registers, including those that are normally caller > > saved. > > - Use a special return instruction (RETI). > > - Step over the "red zone" on the stack. > > - Set up a safe stack frame before calling normal functions. > > > > I usually write the first level interrupt handler in assembler, and > > then

On Jul 24, 2009, at 8:47 AM, Jakob Stoklund Olesen wrote: > Duncan Sands <baldrick at free.fr> writes: > >> the interrupt handler itself is a parameterless procedure that does >> not >> return a value. As such, I guess calling conventions and so forth >> are >> not very relevant for it :) In any case llvm-gcc and gcc mainline >> seem

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

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 standards, I would like to get the blessing of llvm community, and in particular, Chris who at some point

On Wed, 2009-07-15 at 10:37 -0700, Devang Patel wrote: > On Wed, Jul 15, 2009 at 9:32 AM, sanjiv gupta<sanjiv.gupta at microchip.com> wrote: > > Consider the example command line below > > > > $ llvm-ld -disable-opt hello.bc -l std -o hello.out > > > > Why does -disable-opt links in all the bitcode from the libstd.so into > > hello.out? > > ...

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/18 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> Hi Mikhail, >> Thanks for your wonderful help so far. I have few more questions to ask: >> >> How do I modify the driver to pick tools from where the driver itself >> resides, rather than from the PATH? >> Do I need to write some C++ code

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

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

Consider the example command line below $ llvm-ld -disable-opt hello.bc -l std -o hello.out Why does -disable-opt links in all the bitcode from the libstd.so into hello.out? - Sanjiv

On Mon, 2008-08-18 at 08:50 -0700, Eli Friedman wrote: > On Mon, Aug 18, 2008 at 6:31 AM, <Sachin.Punyani at microchip.com> wrote: > > assert(Res.getValueType() == N->getValueType(0) && N->getNumValues() == 1 && > > "Invalid operand expansion"); > > > > LOAD node has two values but the assertion checks N->getNumValues() == 1 >

On Mon, 2009-10-05 at 16:54 -0700, Eli Friedman wrote: > On Mon, Oct 5, 2009 at 11:11 AM, Sanjiv Gupta > <sanjiv.gupta at microchip.com> wrote: > > Sanjiv Gupta wrote: > >> Sanjiv Gupta wrote: > >> > >>> Duncan Sands wrote: > >>> > >>> > >>>> Hi Sanjiv, I think a lot of the softening code assumes you are