search for: pic16s

llvm no build? llvm/llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘bool llvm::PIC16AsmPrinter::printMachineInstruction(const llvm::MachineInstr*)’: llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp:80: error: ‘CurBank’ was not declared in this scope llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘virtual bool llvm::PIC16AsmPrinter::runOnMachineFunction

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

On Sep 20, 2011, at 10:59 PM, Matthew Hilt wrote: > I've been looking closely at LLVM as a means to developing a new toolchain for an MCU core of very similar architecture. To that end, the once included PIC16 backend might be a valuable reference. I found a message in April of this year that indicated it had been dropped from new releases however, and that were it to be resumed "it

I've been looking closely at LLVM as a means to developing a new toolchain for an MCU core of very similar architecture. To that end, the once included PIC16 backend might be a valuable reference. I found a message in April of this year that indicated it had been dropped from new releases however, and that were it to be resumed "it will be largely a rewrite". I'm wondering if

On Sep 21, 2011, at 2:53 PM, Dan Gohman wrote: > On Sep 20, 2011, at 10:59 PM, Matthew Hilt wrote: > >> I've been looking closely at LLVM as a means to developing a new toolchain for an MCU core of very similar architecture. To that end, the once included PIC16 backend might be a valuable reference. I found a message in April of this year that indicated it had been dropped from

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

Mike Stump wrote: > llvm no build? > > llvm/llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function > ‘bool llvm::PIC16AsmPrinter::printMachineInstruction(const > llvm::MachineInstr*)’: > llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp:80: error: ‘CurBank’ was not > declared in this scope > llvm/lib/Target/PIC16/PIC16AsmPrinter.cpp: In member function ‘virtual >

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

There is a ~/llvm-2.8/lib/Target/PIC16/ backend in llvm-2.8. It doesn't appear to be present in llvm-2.9. Has that backend been dropped? Graham

The target in this case is 8-bit, accumulator based, however it is Von Neumann; so - good to know it's not *quite* the "Trifecta of Doom". LLVM offers some very attractive features for our usage, and it would be disappointing to abandon it as an option all together. Faced with the alternative being to write the compiler from scratch, is the consensus that doing so will be a better

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

Chris, I will try to get it done before 2.6. (8/21). - Sanjiv -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu on behalf of Chris Lattner Sent: Wed 8/12/2009 10:08 PM To: LLVM Developers Mailing List Subject: [LLVMdev] XCore & PIC16 AsmPrinters Hi XCore and PIC16 maintainers, I'd appreciate it if you guys could move your AsmPrinter implementation to be in a

Chris Lattner wrote: > 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). > Hi Chris, I'll try to get this done either this weekend or early next week. -- Richard Osborne | XMOS

> Chris Lattner wrote: > >> 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). >> I've moved the XCore AsmPrinter in r79094:

Chris Lattner wrote: > 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

On Fri, Apr 8, 2011 at 10:26 PM, Graham Reitz <grahamreitz at me.com> wrote: > There is a ~/llvm-2.8/lib/Target/PIC16/ backend in llvm-2.8.  It doesn't appear to be present in llvm-2.9. > > Has that backend been dropped? Yes; commit message for r116190: "Per discussion with Sanjiv, remove the PIC16 target from mainline. When/if it comes back, it will be largely a rewrite,

I found out the problem. Looks like I can not rely on argv[0] to contain the full path of the executable always. Can I rely on: static Path GetMainExecutable(const char *argv0, void *MainAddr); is it Cross-platform? What to pass for second parameter here. C++ forbids taking address of "main", and the "Main" of CompilerDriver is in a shared object here. - Sanjiv Sanjiv

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

Hi Sanjiv, > 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