[llvm-dev] Experimental 6502 backend; memory operand folding problem

[via llvm-dev]

I never thought I’d see the day when someone proposed treating the 6502 like a GPU…

—escha

> On Feb 12, 2016, at 6:30 AM, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I think it would be sufficient to pick 8 or 16 pairs of zero page locations as the "registers". Who needs 128 registers, unless you're also doing inter-procedural register allocation? True, that would be a good idea, so non-recursive functions can be allocated a fixed set of registers (based on the maximum call depth they are used from?) and never need to save/restore anything. That would be useful for other CPUs too. but LLVM doesn't support this.
> 
> As for treating 1-2 as a register as well as 0-1 and 2-3? Theoretically possible, of course, but needless complexity.
> 
> On Fri, Feb 12, 2016 at 4:54 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> On 2/12/2016 7:23 AM, Bruce Hoult via llvm-dev wrote:
> I haven't seen what you are doing, but if I was writing a back end for
> the 6502, I'd lie to LLVM and describe RAM page 0 as being the real
> registers, and A, X and Y as being special purpose registers used for
> temporaries.
> 
> How did you get the "(z), x" and "(z, y)" addressing modes to work with this scheme?  The "z" is two adjacent zero-page bytes---did you model 16-bit registers as all possible pairs of adjacent 0p addresses?
> 
> -Krzysztof
> 
> -- 
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160212/9175df7e/attachment-0001.html>