<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Well, the stack pointer be a single byte, so pushing things on there doesn't work terribly well.</div><div><br></div><div>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. </div><div><br></div><div>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!</div><div><br></div><div>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.</div><div><br>On Jul 2, 2014, at 9:44 PM, Bruce Hoult <<a href="mailto:bruce@hoult.org">bruce@hoult.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I've considered doing this as well :-) As an exercise to learn the LLVM back end as much as anything.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jul 3, 2014 at 1:23 PM, Edwin Amsler <span dir="ltr"><<a href="mailto:edwinguy@gmail.com" target="_blank">edwinguy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey there!<br>
<br>
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.<br>
<br>
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.<br>
<br>
I've been doing lots of research so far, but from the experts, how feasible does this sound?<br>
<br>
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?<br>
<br>
Thanks,<br>
<br>
Edwin<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>
</div></blockquote></body></html>