[LLVMdev] MOS6502 target

Edwin Amsler edwinguy at gmail.com
Thu Jul 3 17:02:39 PDT 2014


Well, the stack pointer be a single byte, so pushing things on there doesn't work terribly well.

Assuming I pass by reference, that's 128 values absolutely total before it wraps around and silently clobbers itself. It means single byte values will be incredibly inefficient... Tricky stuff. 

I'm lucky on the C64 since it's rare to exit back to the kernel with machine language apps (never did it when I was a kid at least), so if I destroy the Kernel's stack, no one will ever know! Mwahaha!

With regard to code layout, ideally everything would get inlined since I have gobs of memory compared to everything else. I wouldn't need to worry as much about the stack as long as real values don't get stored there.

> On Jul 2, 2014, at 9:44 PM, Bruce Hoult <bruce at hoult.org> 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.
> 
> 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.
> 
> If you have the call DAG, you can turn that into a total ordering such that if A transitively calls B then the locations of A's locals will always be at higher addresses than B's locals. (or vice versa).
> 
> This will probably be a bit bigger than the maximum dynamic depth of a stack implementation, but I think usually not a lot. And it lets you use absolute addressing instead of slow (zp),y, and also let you avoid saving and restoring simulated callee-save registers.
> 
> 
> 
> 
>> On Thu, Jul 3, 2014 at 1:23 PM, Edwin Amsler <edwinguy at gmail.com> wrote:
>> Hey there!
>> 
>> I've started to embark on a path to try and create a backend for a 39 year old CPU with only an accumulator, two index registers, and a 256 byte stack. It does have a bank of 256 bytes before the stack that are pretty quick though.
>> 
>> Really, if I can get an assembler out of `llc`, that'll be success enough for me. Clang would be better, but I think that might be crazy talk.
>> 
>> I've been doing lots of research so far, but from the experts, how feasible does this sound?
>> 
>> I've also been banging my head against the wall trying to figure out what all the classes for different instruction types do. Is there a nicely documented index? Is it in source somewhere, or should I start one?
>> 
>> Thanks,
>> 
>> Edwin
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140703/0c76f122/attachment.html>


More information about the llvm-dev mailing list