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
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/b1a712eb/attachment.html>
Hi, I found the tutorial presented at last LLVM conference very helpful when starting on my own backend. Especially with the GitHub repository containing a template backend that was quite easy to rename and extend. Here's the slides with a pointer to the repository: http://llvm.org/devmtg/2014-04/PDFs/Talks/Building%20an%20LLVM%20backend.pdf Cheers, Roel On 03/07/14 03:23, Edwin Amsler 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 >
I'd not seen that tutorial, but it looks very nice. One other piece of advice I'd give: Get the assembler working first. Go through your instruction reference, define each instruction's encoding, add the relevant bits to the AsmParser (typically not much, unless you have some weird encodings), and test the assembler with llvm-mc and its show-encodings feature before you try to connect up code generation. And write lots of tests while you're doing this! It makes it easy to see if you've got sensible patterns, when every instruction is in the .td files and you can easily find the ones that aren't used (is it because there's a more sensible way of expressing what they can do, because they do something that isn't easily expressed in LLVM IR, or because you made a mistake?). It's a lot easier to track down bugs in instruction encodings when you've got a decent set of assembly tests for them than when you're staring at compiler output. Common errors include not realising immediates are sign / zero extended or shifted. David On 3 Jul 2014, at 09:57, Roel Jordans <r.jordans at tue.nl> wrote:> Hi, > > I found the tutorial presented at last LLVM conference very helpful when starting on my own backend. Especially with the GitHub repository containing a template backend that was quite easy to rename and extend. > > Here's the slides with a pointer to the repository: > > http://llvm.org/devmtg/2014-04/PDFs/Talks/Building%20an%20LLVM%20backend.pdf > > Cheers, > Roel > > On 03/07/14 03:23, Edwin Amsler 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 >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Thanks! I feel the offline documentation could be improved or re-done with some of these. The current backend doc has lots of definition without explanation. It makes it fairly frustrating when it says "look at the spark target" when it doesn't define any of the classes or define what the options were for or the motivations for their use. Once I've figured this stuff out, I'll likely be contributing to that.> On Jul 3, 2014, at 3:57 AM, Roel Jordans <r.jordans at tue.nl> wrote: > > Hi, > > I found the tutorial presented at last LLVM conference very helpful when starting on my own backend. Especially with the GitHub repository containing a template backend that was quite easy to rename and extend. > > Here's the slides with a pointer to the repository: > > http://llvm.org/devmtg/2014-04/PDFs/Talks/Building%20an%20LLVM%20backend.pdf > > Cheers, > Roel > >> On 03/07/14 03:23, Edwin Amsler 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I've read about half-way. Holy crap is this helpful. This needs to be referenced in the backend docs or the talk needs to be transcribed to become the new backend docs.> On Jul 3, 2014, at 3:57 AM, Roel Jordans <r.jordans at tue.nl> wrote: > > Hi, > > I found the tutorial presented at last LLVM conference very helpful when starting on my own backend. Especially with the GitHub repository containing a template backend that was quite easy to rename and extend. > > Here's the slides with a pointer to the repository: > > http://llvm.org/devmtg/2014-04/PDFs/Talks/Building%20an%20LLVM%20backend.pdf > > Cheers, > Roel > >> On 03/07/14 03:23, Edwin Amsler 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 > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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)
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>
On 7/2/2014 8:23 PM, Edwin Amsler wrote:> > 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?The set of programs that you will be able to compile will be severly limited. There is no OS to speak of, so the only mode you will be able to use is the "base metal". This means no file I/O. If you ever plan to run the output on a real hardware, add an option to reserve memory addresses for memory mapped registers. There is a 16-bit derivative of 6502, maybe you could target that instead? In any case, good luck. Sounds really cool! -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Oh yeah, I'm not expecting to port some major app. I have pretty intimate knowledge of what my c64 can and can't do. It barely has a kernel (pretty much just in-memory routines for disk, screen, and tape access). This isn't a practical project (good C compilers exist already), this is an excuse to play with LLVM.> On Jul 9, 2014, at 4:25 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > >> On 7/2/2014 8:23 PM, Edwin Amsler wrote: >> >> 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? > > The set of programs that you will be able to compile will be severly limited. There is no OS to speak of, so the only mode you will be able to use is the "base metal". This means no file I/O. > > If you ever plan to run the output on a real hardware, add an option to reserve memory addresses for memory mapped registers. > > There is a 16-bit derivative of 6502, maybe you could target that instead? > > In any case, good luck. Sounds really cool! > > -Krzysztof > > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev