Hi all, I'm new to the project and will probably ask quite a few obvious questions, so please, bare with me. I'm trying to get my bearings straight as to the general path forward for producing a backend for a custom DSP processor. Currently, I have a port of binutils and a basic simulator (based on SID). I want to make it easier for software engineers to produce code for this architecture so I'm moving onto the next phase by attempting a C compiler, so here I am. First, I would rather not maintain two different descriptions of the assembly/ISA specification, one in binutils/SID (CGEN) and another in LLVM. I have found some posts about the LLVM MC project, that it can essentially produce an inline or standalone assembler, but is the MC project ready for prime-time? Should I invest my time going this route? It's hard to get a sense of what direction the project is moving in. Second, related to the previous, if I were to only maintain the assembly/ISA description in LLVM, can LLVM produce a simulator to execute target specific machine code binaries? I realize that you can, in theory, translate the ll assembly to the host machines processor architecture as a pseudo-simulation, but this doesn't give you hardware specific information about your real target machine, such as what is stored in register r6 at breakpoint 10. Lastly, the DSP processor is a VLIW/EPIC machine. I assume that this fact is going to produce a few hiccups when creating the LLVM backend, just like it did when I was doing the binutils port. Any words of wisdom would be very welcome on this front. Thanks, -Brian
On Mar 15, 2011, at 7:02 AM, Brian Mokrzycki wrote:> Hi all, > > I'm new to the project and will probably ask quite a few obvious questions, so please, bare with me. > > I'm trying to get my bearings straight as to the general path forward for producing a backend for a custom DSP processor. Currently, I have a port of binutils and a basic simulator (based on SID). I want to make it easier for software engineers to produce code for this architecture so I'm moving onto the next phase by attempting a C compiler, so here I am. > > First, I would rather not maintain two different descriptions of the assembly/ISA specification, one in binutils/SID (CGEN) and another in LLVM. I have found some posts about the LLVM MC project, that it can essentially produce an inline or standalone assembler, but is the MC project ready for prime-time? Should I invest my time going this route? It's hard to get a sense of what direction the project is moving in.Hi Brian, MC is used as the integrated assembler for the X86 backend (enabled by default in clang) and ARM (disabled by default due while asm parsing is finished up for inline assembly). So yes, it's ready for prime-time and well worth investing in, but it's also still relatively young, so don't be too surprised if there's a few growing pains along the way. I've done a lot of work on MC-based things, as have others on this list, so if you have questions about how to organize a target description for MC and/or run into troublesome constructs, post questions here and folks will be glad to help.> Second, related to the previous, if I were to only maintain the assembly/ISA description in LLVM, can LLVM produce a simulator to execute target specific machine code binaries? I realize that you can, in theory, translate the ll assembly to the host machines processor architecture as a pseudo-simulation, but this doesn't give you hardware specific information about your real target machine, such as what is stored in register r6 at breakpoint 10.Not currently, no. That's outside the scope of what LLVM's target description is designed to handle.> Lastly, the DSP processor is a VLIW/EPIC machine. I assume that this fact is going to produce a few hiccups when creating the LLVM backend, just like it did when I was doing the binutils port. Any words of wisdom would be very welcome on this front.This part I'm less familiar with, but I believe some others here have done work on similar things. -Jim
Hey Brian, On 03/15/2011 03:02 PM, Brian Mokrzycki wrote:> Second, related to the previous, if I were to only maintain the assembly/ISA description in LLVM, can LLVM produce a simulator to execute target specific machine code binaries? I realize that you can, in theory, translate the ll assembly to the host machines processor architecture as a pseudo-simulation, but this doesn't give you hardware specific information about your real target machine, such as what is stored in register r6 at breakpoint 10.As already pointed out, LLVM's target description is not sufficient here. You might be interested in generating simulators (and other tools) from structural architecture descriptions [1], which is a research topic of a colleague of mine [2] and also makes use of LLVM.> Lastly, the DSP processor is a VLIW/EPIC machine. I assume that this fact is going to produce a few hiccups when creating the LLVM backend, just like it did when I was doing the binutils port. Any words of wisdom would be very welcome on this front.Getting your initial VLIW backend off the ground should not be too hard. It will be unoptimized and probably only limited to a subset of the ISA, but on the other hand LLVM does a good job compensating for features your architecture does not support. I think a good example is the experimental C64X backend mentioned here [3]. Once you are looking into performance, especially wrt. to scheduling (bundling) issues, things get more complicated. I have found the common target machine and schedulers too restrictive and had to work around the Codegen vs. Target separation in LLVM a bit. Feel free to dig through my git repository [4]. cheers, alex [1] http://www.complang.tuwien.ac.at/cd/brandner/papers/rapido09-brandner.pdf [2] http://perso.ens-lyon.fr/florian.brandner/ [3] http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-August/033821.html [4] http://www.complang.tuwien.ac.at/ajordan/llvm-tic64x.git