[LLVMdev] Instructions on a target with no general purpose registers

[Owen Anderson]

On Jul 5, 2014, at 11:47 AM, Bruce Hoult <bruce at hoult.org> wrote:

> Although I'm new to LLVM, I don't think that can really be true. Sure, LLVM has the assumption of a machine with "lots" of registers, but it works with the x86, which doesn't have many registers, and has instructions that work only with fixed input or output registers.

Actually, LLVM is *also* poorly suited to machines with lots of registers.  A lot of the register allocation infrastructure is built around small-ish register files with relatively sparse aliasing relationships.  From experience, modeling a machine with 256 GPRs and extensive use of register sequences results in a lot of pain in various parts of the code generator.

> To a first approximation, you can treat the 6502 as a machine with 256 8 bit registers, and register to register (and register to memory) pseudo-instructions that are expanded at a late stage to short sequences using A, X, Y as temps. That will certainly *work*. Not optimally for 8 bit values, but it's pretty much the best you can do anyway if you're dealing with 16 or 32 bit values.

This will definitely work, but you’re not really compiling for 6502 at that point.  You’re compiling for a bytecode VM that has 256 GPRs, where each bytecode opcode is implemented as a sequence of 6502 instructions.  If your goal is just to get something to run on a 6502, this will definitely work, but it’s not actually solving the problem of making LLVM work as a proper 6502 compiler.

Fundamentally, you have to ask what you’re looking to get out of this.  If it’s just for fun, or if you just want to get (say) C++11 to run on your 6502 without caring about the low-level performance, that’s definitely doable.  But if you’re trying to actually build a production-grade 6502 compiler, you’ll find that you’re unlikely to benefit from most of the facilities that LLVM provides in the SelectionDAG and Machine layers.  They’re simply built for machines that work very, very differently.  I’m not claiming it’s impossible to bend them to your will, but I am questioning the value in doing so.  I think you’d get a better result with less work if you translated out of LLVM IR into a code generation pipeline more specialized for the needs of a 6502.

—Owen

> On Sun, Jul 6, 2014 at 5:55 AM, Owen Anderson <resistor at mac.com> wrote:
> Hi Edwin
> 
> I’ve refrained from raining on your other thread, but LLVM’s instruction selection model, and in fact a large portion of its code generation model, is not well-fitted to modeling the 6502.  I don’t think you’re going to get significant benefit from trying to bend it to work for the 6502, and you’ll spend a lot of time working around baked in assumptions that aren’t true for your target.
> 
> —Owen
> 
> 
> On Jul 5, 2014, at 6:59 AM, Edwin Amsler <edwinguy at gmail.com> wrote:
> 
> > I've mentioned my sneaky plans to target the MOS6502 here before.
> >
> > The big issue I think is that a lot of instructions don't really have a choice for output register. It all just goes into the accumulator, X index, or Y index based on the specific instruction.
> >
> > So, my question is, when I'm defining my ins, outs and registers for these instructions, is it going to be a problem that different instructions outputs are defined by the function that is called? And I guess, how do I tell LLVM it can't pick any old register for a given instruction?
> >
> > Thanks,
> >
> > Edwin
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140705/a43c02ae/attachment.html>