[LLVMdev] MOS6502 target

[Edwin Amsler]

I was doing some thinking and discussing, and another interesting problem is that the MOS6502 really doesn't have much in the way of general purpose registers.

Some add/move/etc can use reg X or Y in immediate mode, but I think the expectation is that it operates on the zero page directly.

Has anyone managed to do that effectively? Instructions that take as input a memory location to read values from?

Ex: "ADD A, #00FF" where "#00FF" is the final byte in the zero page. 

> On Jul 3, 2014, at 1:21 PM, John Criswell <jtcriswel at gmail.com> wrote:
> 
>> On 7/2/14, 9:44 PM, Bruce Hoult wrote:
>> 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.
> 
> One interesting problem with doing that is determining which zero page locations are free for use on the target machine.  The Apple II ROM, for example, reserves many of these locations for its own use. Other machines may reserve different locations within the zero page.
> 
>> 
>> 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.
> 
> A typical callgraph analysis run within libLTO can be used (along with Tarjan's algorithm) to find SCCs in the callgraph.  The default callgraph implementation within LLVM is extremely conservative with function pointers and external code, so for some programs, the results may not be good.
> 
> Alternatively, one could use the DSA analysis within the poolalloc project to get a better callgraph.  There's even code within SAFECode to find SCCs, although I don't recall off-hand which pass it is and whether it's active in the default compilation.
> 
> Regards,
> 
> John Criswell (who fondly remembers assembly programming on his Apple //c)
>