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

Bruce Hoult via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 12 06:30:58 PST 2016


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> 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
> 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/3f500c89/attachment.html>


More information about the llvm-dev mailing list