[LLVMdev] MOS6502 target

[Bruce Hoult]

I've considered doing this as well :-) As an exercise to learn the LLVM
back end as much as anything.

It probably makes sense to allocate 8 or 16 pairs of zero page locations as
virtual 16 bit registers and make 32 bit operations available only as
library routines/intrinsics.

What would be *really* helpful would be if LLVM had a way to detect that
certain functions and sets of functions (probably >90% of the program) are
NOT recursive and statically allocate fixed zero page and/or high memory
locations for their local variables.

If you have the call DAG, you can turn that into a total ordering such that
if A transitively calls B then the locations of A's locals will always be
at higher addresses than B's locals. (or vice versa).

This will probably be a bit bigger than the maximum dynamic depth of a
stack implementation, but I think usually not a lot. And it lets you use
absolute addressing instead of slow (zp),y, and also let you avoid saving
and restoring simulated callee-save registers.




On Thu, Jul 3, 2014 at 1:23 PM, Edwin Amsler <edwinguy at gmail.com> wrote:

> Hey there!
>
> I've started to embark on a path to try and create a backend for a 39 year
> old CPU with only an accumulator, two index registers, and a 256 byte
> stack. It does have a bank of 256 bytes before the stack that are pretty
> quick though.
>
> Really, if I can get an assembler out of `llc`, that'll be success enough
> for me. Clang would be better, but I think that might be crazy talk.
>
> I've been doing lots of research so far, but from the experts, how
> feasible does this sound?
>
> I've also been banging my head against the wall trying to figure out what
> all the classes for different instruction types do. Is there a nicely
> documented index? Is it in source somewhere, or should I start one?
>
> Thanks,
>
> Edwin
> _______________________________________________
> 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/20140703/b1a712eb/attachment.html>