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

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>

Not having looked at GPU architectures or programming, what aspect are you
referring to? Static assignment of local variables? Of course that was
standard in FORTRAN and COBOL days.

On Fri, Feb 12, 2016 at 6:05 PM, <escha at apple.com> wrote:
> 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> 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
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and is
> believed to be clean.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160212/377d3a7f/attachment.html>

Treating the 0 page as a big register file (and A, X, Y as special registers)
makes it quite GPU-like, in that it makes for a fairly large
arbitrarily-addressed register file (rather than distinct, disjoint registers
like a CPU). There’s also a number of GPUs that have special registers that are
“cheaper” or required to actually do ops on, so again, it seems familiar, at
least in that sense!

—escha
> On Feb 12, 2016, at 9:34 AM, Bruce Hoult <bruce at hoult.org> wrote:
> 
> Not having looked at GPU architectures or programming, what aspect are you
referring to? Static assignment of local variables? Of course that was standard
in FORTRAN and COBOL days.
> 
> On Fri, Feb 12, 2016 at 6:05 PM,  <escha at apple.com <mailto:escha
at apple.com>> wrote:
> 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 <mailto: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 <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>
> 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner <http://www.mailscanner.info/>, and
is
> believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160213/743d9cc1/attachment.html>