similar to: [LLVMdev] New 8bit micro controller back-end

Our 8-bit port for PIC16 has taken roughly about 18 months to get to where we are now. Our instruction set is not orthogonal, data memory is banked, program memory is paged, there is only one accumulator and two pointer registers, and the use of indirect memory access is really expensive. So we had to implement some non conventional approaches to get the model working. For the most part, LLVM

Hello Guillaume, > - Is there estimation (from your experiences) of the work required to > implement a backend for a simple 8bits micro controller architecture (1 > men-month, 10 or 100 ?) What is the instruction set of your microcontroller? How rich it is? What is the architecture? Is it RISC-y? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint

Hello, It is a RISC with around 60 instructions like a 80c51 instruction set (without mul/div) and with Direct or indirect memory acces. There is a protected / user mode but the processor keep small and simple. 2009/11/23 Anton Korobeynikov <anton at korobeynikov.info> > Hello Guillaume, > > > - Is there estimation (from your experiences) of the work required to > >

Hello > It is a RISC with around 60 instructions like a 80c51 instruction set > (without mul/div) and with Direct or indirect memory acces. My estimate is something like a man-week for a person, who knows what to do :) I guess the instruction set is pretty similar to msp430's for which we already have a backend. In such situation you might just grab this backend, remove all 16-bit

I won't work at full time on this project and I fear the first week is used to read documentations :) The better way to have an idea is to start backend developement. I'll try to work on this backend for a month and will see if I'm on the right way. 2009/11/24 Evan Cheng <evan.cheng at apple.com> > > On Nov 24, 2009, at 8:30 AM, David Greene wrote: > > > On

Ok great news but as currently I don't have the "know what to do", it would probably take longer... I suppose your estimate only include backend update. Can I have more detail about the Simulator/Debugger part(at an assembler level?) ? I'm not sure if LLVM is able to provide such functionalities. 2009/11/23 Anton Korobeynikov <anton at korobeynikov.info> > Hello >

> > So I think it should be at the discretion of port to enable or disable > > such optimizations as needed. > > While that it a valid approach in general, it is completely at odds > with the approach that the LLVM codebase has taken. The general LLVM > philosophy is that all optimizations should be as aggressive as > possible at whatever they do, and it is then the

I am interested in working on a little architecture project that involves modifying an ISA in some non-trivial ways and seeing what impact it has on instruction frequencies (and other such metrics). Clearly I'll need to hack on a compiler backend, and I thought that LLVM might be a good choice since among mature compiler infrastructures it's fairly young and presumably

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

Benjamin Ylvisaker <benjaminy at alumni.cmu.edu> writes: > I am interested in working on a little architecture project that > involves modifying an ISA in some non-trivial ways and seeing what > impact it has on instruction frequencies (and other such metrics). > Clearly I'll need to hack on a compiler backend, and I thought that > LLVM might be a good choice

On Jun 9, 2011, at 8:09 PM, David A. Greene wrote: > Note that things like instruction frequencies are highly ISA- > dependent. If possible, it is best to evaluate your ideas on more > than one target, just to see what the effects are. What other sorts > of things do you want to study? > > If, long-term, you are planning to do serious studies of performance >

Hello, David > That's pretty optimistic, even for someone who knows what to do. It depends on the target. If it is pretty straightforward, than you can do almost all the stuff automatically. The estimate I provided was the real time for first working version for msp430 backend. If it is just 'normal' RISCy architecture and one should not care about ABI weirdness (this is usually

On Tuesday 24 November 2009 10:57, Anton Korobeynikov wrote: > If it is just 'normal' RISCy architecture and one should not care > about ABI weirdness (this is usually true for MCUs), then the estimate > is correct. You just provide patterns for all the operations, expand > everything unsupported. After that you need to write bunch of libcalls > and first version is ready

Hello, David > Which is straightforward once you know what you're doing.  Before that > point, however, it's very non-trivial.  Basically I'm saying our documentation > needs a lot of work.  :) Yeah. I'm even trying to fix the situation somehow... ;) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Aug 4, 2009, at 9:51 AM, Alireza.Moshtaghi at microchip.com wrote: > >>> So I think it should be at the discretion of port to enable or > disable >>> such optimizations as needed. >> >> While that it a valid approach in general, it is completely at odds >> with the approach that the LLVM codebase has taken. The general LLVM >> philosophy is that

On Nov 24, 2009, at 8:30 AM, David Greene wrote: > On Monday 23 November 2009 09:01, Anton Korobeynikov wrote: >> Hello >> >>> It is a RISC with around 60 instructions like a 80c51 instruction set >>> (without mul/div) and with Direct or indirect memory acces. >> >> My estimate is something like a man-week for a person, who knows what to do >>

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

On Monday 23 November 2009 09:01, Anton Korobeynikov wrote: > Hello > > > It is a RISC with around 60 instructions like a 80c51 instruction set > > (without mul/div) and with Direct or indirect memory acces. > > My estimate is something like a man-week for a person, who knows what to do > :) That's pretty optimistic, even for someone who knows what to do. The

On Sep 21, 2011, at 4:51 PM, Matthew Hilt wrote: > 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