search for: softcores

Displaying 15 results from an estimated 15 matches for "softcores".

Did you mean: softcore
2010 May 24
1
[LLVMdev] LatticeMico32 (LM32) backend
Hello Sébastien, Making backends to LLVM is a significant amount of work. If you want somebody to do it for you, either offer some payment or do your own coding. Keep in mind that the bread-and-butter support for LLVM comes from Apple computer so unless the next iPad will start using softcores, be prepared to pursue the other courses of action I laid out. I may be having to write a backend to the N68050 softcore soon but am busy writing my own LLVM-based compiler at the moment so don't expect me to jump up and down with excitement just because there is a new softcore that doesn'...
2010 May 24
0
[LLVMdev] LatticeMico32 (LM32) backend
On Monday 24 May 2010 14:32:19 Eli Friedman wrote: > Resending the email isn't really productive; for the given question, > the lack of a reply should answer your question. Was there something > else you wanted to ask? I find this message unhelpful at best, if not purely arrogant. You are making an open source compiler, I am making an open source processor: we are fighting for the
2010 May 24
3
[LLVMdev] LatticeMico32 (LM32) backend
On Mon, May 24, 2010 at 2:11 AM, Sébastien Bourdeauducq <sebastien.bourdeauducq at lekernel.net> wrote: > Just bringing that up as I did not get any reply so far. Resending the email isn't really productive; for the given question, the lack of a reply should answer your question. Was there something else you wanted to ask? -Eli > Thanks, > Sébastien > > > On Tuesday
2010 Aug 18
2
C Prog
Hi, does anyone have small programms in C, one to encode and one to decode with celt, that I could use for a fpga chip softcore? greets yon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20100819/7cd96a41/attachment-0002.htm
2016 Aug 18
8
[RFC] AAP Backend
Hi all, We wish to submit our latest AAP implementation as an experimental backend into LLVM. We need community feedback and reviewers for patches which we will submit soon. AAP was designed in early 2015 and aims to advance compiler development for small deeply embedded Harvard architectures, which are widely used commercially. AAP is freely available as an open source softcore for use in FPGA
2016 Nov 16
2
[RFC] AAP Backend
Hi all, I have just updated most of the patches to roll them forwards to LLVM top-of-tree, and incorporated various suggested changes. We're still looking for reviewers, if anyone is interested. Thank you, Edward Jones On 15/09/16 17:12, Ed Jones wrote: > I have now posted the final two patches for the backend to add > Disassembler support, ISel and CodeGen. The full list of patches
2016 Aug 25
2
[RFC] AAP Backend
As it stands, the active customers for this target are the out-of-tree backends which we are working on which can't be submitted for inclusion into LLVM. The general aim of the backend though is to include features from architectures which are not well represented in LLVM, for example non-power of two register sizes, non-octet chars, or very constrained register sets, and to this end we hope
2013 Dec 21
3
[LLVMdev] running clang format on the Mips target
Hi David, What kind of "a lot of out-of-tree changes"? You should push changes incrementally as you do work. Holding onto changes means that many things, not just reformatting, can make them need to be redone. We frequently clean up and rewrite code to make it cleaner and easier to maintain. We are moving to a more strict internal review and pushing of changes and post commit
2007 Dec 22
0
[LLVMdev] Status of Elsa->LLVM
On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > Does Elsa provide an advantage over g++? For me, understanding it is a > big plus. ;-) In addition, Elsa has a Berkeley-like license which I > prefer. Ok. If you're not planning on extending the front-end, understandability doesn't really matter ;-). I get where you're coming from though! > Since I only
2007 Dec 22
5
[LLVMdev] Status of Elsa->LLVM
Chris Lattner wrote: > On Dec 21, 2007, at 1:08 PM, Richard Pennington wrote: > >> I'm a little further along now. I've started to put together a simple >> driver for Elsa and LLVM that I'm calling "ellsif" (cute name, I think >> it works). >> >> The file being compiled is a "printf" function. Here are timing >> results
2011 Aug 22
1
[LLVMdev] llvm-fpga microblaze target
folks hi, something i just wanted to double-check. is it possible to use, with LLVM, entirely free software tools to build and upload to a xilinx microblaze FPGA target? i take some c code, put it through llvm-fpga, aaand... then what? is there any documentation about this stuff, anywhere? tia, l.
2007 Dec 23
1
[LLVMdev] Status of Elsa->LLVM
Chris Lattner wrote: > On Dec 22, 2007, at 2:40 AM, Richard Pennington wrote: > >> Does Elsa provide an advantage over g++? For me, understanding it is a >> big plus. ;-) In addition, Elsa has a Berkeley-like license which I >> prefer. > > Ok. If you're not planning on extending the front-end, > understandability doesn't really matter ;-). I get
2007 Dec 22
0
[LLVMdev] [Oink-devel] Status of Elsa->LLVM
> I've build gcc many times over the years for different target processors > and was never able to get my head around it internally. It is incredibly > complex. I also didn't like the fact that I had to have N copies of gcc > to support N processors. Scott McPeak is rather familiar with the internals of gcc and edg and says elsa is far simpler. > I became interested in
2007 Dec 23
1
[LLVMdev] [Oink-devel] Status of Elsa->LLVM
Daniel Wilkerson wrote: >> I've build gcc many times over the years for different target processors >> and was never able to get my head around it internally. It is incredibly >> complex. I also didn't like the fact that I had to have N copies of gcc >> to support N processors. > > Scott McPeak is rather familiar with the internals of gcc and edg and >
2013 Dec 24
2
[LLVMdev] running clang format on the Mips target
Hi David, I agree with you that it would be rude to simply clang-format the MIPS backend without coordination with any out-of-tree derivatives. To be honest, it hadn't occurred to me that there would be any such derivatives and the possibility wasn't raised in our internal discussion before we brought the subject up on this list. I'm keen to coordinate with such derivatives to