llvm dev - Feb 2016 - Experimental 6502 backend; memory operand folding problem

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

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>

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>