search for: mcus

It is really cool that LLVM has a backend for PIC now. I wonder if someone could comment on the suitability of LLVM for 8-bit and 16-bit MCUs? Is there significant impedance mismatch or is it relatively easy to get good object code for these platforms? (I.e. roughly comparable to gcc4?) I ask since gcc is causing significant pain for one of my students. He could switch over to LLVM but only after writing a backend for AVR (8-bit...

...s thread explains some of the challenges that we are facing on PIC16 Ali. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of John Regehr Sent: Monday, May 19, 2008 9:45 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] LLVM on small MCUs? It is really cool that LLVM has a backend for PIC now. I wonder if someone could comment on the suitability of LLVM for 8-bit and 16-bit MCUs? Is there significant impedance mismatch or is it relatively easy to get good object code for these platforms? (I.e. roughly comparable to gcc4?) I...

John Regehr wrote: > I ask since gcc is causing significant pain for one of my students. He > could switch over to LLVM but only after writing a backend for AVR (8-bit > RISC). An AVR backend would be very cool. AVR is way more compiler friendly than PIC, so it should not be all that difficult either. The only hitch is that in the MCU world people expect to be able to write interrupt

On Mon, 2008-05-19 at 20:40 +0300, Pertti Kellomäki wrote: > The only hitch is that in the MCU world people expect to be > able to write interrupt handlers and the like in C... Most of the support that I have seen for this in other compilers amounts to custom calling conventions and preambles. Are you thinking of more than this?

Anyone else interested in an AVR backend? If so, for what members of the AVR family? If we do a port, likely it'll support only the ATmegas. John

I have a client who might well make use of an AVR32 port, but I suspect that machine is very different than the one you are currently examining. shap On Mon, 2008-05-19 at 12:38 -0600, John Regehr wrote: > Anyone else interested in an AVR backend? > > If so, for what members of the AVR family? If we do a port, likely it'll > support only the ATmegas. > > John >

> I have a client who might well make use of an AVR32 port, but I suspect > that machine is very different than the one you are currently examining. I have not looked at AVR32 closely but my understanding is that it is a new architecture that shares a substring with AVR for marketing reasons. John

GCC for AVR is awesome but, as far as I know, until very little time ago, compiler support for PIC was close to none. 2008/5/19 Jonathan S. Shapiro <shap at eros-os.com>: > I have a client who might well make use of an AVR32 port, but I suspect > that machine is very different than the one you are currently examining. > > > shap > On Mon, 2008-05-19 at 12:38 -0600, John

> [llvm-commits] PATCH for PIC16 target. Do you have a link? Google isn't turning this up. I'd be interested in hearing more about this experience... Thanks, John

> Do you have a link? Google isn't turning this up. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080512/062319.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL:

>> Do you have a link? Google isn't turning this up. >http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080512/062319.html Wow, PIC looks like a brutal port. AVR would be easy in comparison: stack-based architecture with plenty of registers. However, these architectures share: - 8-bit loads, stores, and arithmetic ops. - Harvard architecture What sizes and

hello R-world, according to the strucchange package .pdf, "all procedures in this package are concerned with testing or assessing deviations from stability in the classical linear regression model." i'd like to test/assess deviations from stability in the Poisson model. is there a way to modify the strucchange package to suit my purposes, or should i use be using another

I am interested in developing a backend for the PIC microcontrollers. Specifically, I plan to write for the 8-bit MCUs, but would hopefully also support the 16 and 32 bit models (eventually). It is my understanding that a backend for PIC16 was previously a part of the project but was dropped in version 2.9. Is there any development on this front currently? Is there any interest in developing this for the current bu...

...rget. 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 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 :) Surely, optimization stuff & supporting of some "nice" features will require much more time....

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 :) Which is straightforward once you know what you're doing. Before that point, however, 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

David, I started a discussion yesterday on lld / chunks for ELF as we need relocations to be read when reading the inputs especially for handling comdat. The other way thus can be done is doing symbol resolution while reading which makes the linker less suitable for concurrent operations. Let me know what you think? Shankar Easwaran > On Jun 5, 2015, at 23:35, Davide Italiano <davide

Hello, I'm interested in LLVM as an opportunity to support C++ programming for legacy MCUs (8051, PIC1x, etc.). Recently, I tried to use C Backend as means to achieve this. As C Backend was removed in recent LLVM versions, I started with LLVM 3.0 which was last version to include it. For starters, I played with MSP430 target, which is supported by LLVM, so allows roundtrip experiments (...

...s >>are being worked on, how likely they are to continue to be invested in, etc - versus accepting that companies have their own >>priorities, some private objectives, etc). No worries I’m very happy to provide any information necessary. I really want the port to accepted upstream. RL78 MCUs are part of the Renesas Product Longevity program https://www.renesas.com/eu/en/support/products-common/product-longevity-program-plp.html. The majority of current RL78 devices have the termination date set as “December 2033”, and a few “March 2026”. Also RL78 is under active development: new devic...

Well, it's an ARM7TDMI core, so basically one register operation per clock, with memory accesses taking longer. Having the memory on-chip should make memory access much less of an impact. I was afraid that you would answer the way you did: I thought about my question after I sent it, and the "LP" in CELP is what makes it a sequential process; it can't do linear prediction on a