similar to: [LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]

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

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

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

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

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

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

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

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

> 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

Mikhail Glushenkov wrote: > Hi Sanjiv, > > 2009/6/29 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > >> I want to retrieve the value of argv[0] (which was passed to main function >> of the driver) in PrependCustomizedPath. >> > > I've added a way to access argv[0] in hooks: > http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/50789 >

Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a subdirectory like the rest of the other targets (e.g. make it live in lib/Target/PIC16/AsmPrinter). Anton is planning to move MSP430 to use the same approach. Having all the targets use the same design simplifies the build system and keeps the target architecture more

The driver behaves differently when I run it by specifying absolute path than when I run it with relative path. See example Relative: i00202 at ubuntu:/tmp$ mcc16 --save-temps -dry-run hello.c./clang-cc -I ./include -triple=pic16- -emit-llvm-bc hello.c -o hello.bc-pqDR1Y llvm-ld -link-as-library hello.bc-pqDR1Y -o tmp.bc-M1Rwip llc -march=pic16 -f tmp.bc-M1Rwip -o tmp.s-DcVczP gpasm -I ./inc

Hi Sanjiv, 2009/6/30 Sanjiv Gupta <sanjiv.gupta at microchip.com>: > One more thing: > How to make --save-temps always on, so that users won't have to specify it > every time they invoke the driver? Either always run the driver via an alias, or edit lib/CompilerDriver/BuiltinOptions.cpp: cl::opt<SaveTempsEnum::Values> SaveTemps ("save-temps",

In my ongoing work on refactoring the asmprinters, I've found that PIC16 doesn't put ':' after labels in some cases. Specifically, it looks like basic block labels are emitted without a ':': movwf @__floatunsidf.frame. + 2 movlp .BB1_2 goto .BB1_2 .BB1_2 ; %bb7 movlw 0 banksel @__floatunsidf.frame. but that

On Aug 12, 2009, at 9:48 PM, Sanjiv.Gupta at microchip.com wrote: > Chris, > I will try to get it done before 2.6. (8/21). > Thanks Sanjiv! One other nice cleanup (but which is not time critical at all) would be to merge the contents of "PIC16Section" into the new "MCSectionPIC16" class. Unlike the previous design, you're now allowed to store arbitrary

Hi Duncan, We are targetting a reasonably functional PIC16 backend for llvm 2.5. The only problem in our way is a local patch in ExpandIntegerOperand, which couldn't make its way to trunk so far. The discussion is contained in the following link: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081103/069593.html I now have time to take it up again and do whatever rework is