<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>You can buy one for under $50, reprogram thousands of times and the dev tools last I checked confused me.</div><div><br></div><div>That's the last I'll say about it until you either start a new thread or justify how it fits in this one.</div><div><br></div><div>Not a fan of hijacking. </div><div><br>On Jul 3, 2014, at 10:29 PM, Bruce Hoult <<a href="mailto:bruce@hoult.org">bruce@hoult.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">What's the one-paragraph current state of FPGA programming? What does one cost? What support gear do you need (and how much is it)? Is programming one-shot or can you reuse it?</div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Jul 4, 2014 at 3:01 PM, Jeremy Lakeman <span dir="ltr"><<a href="mailto:Jeremy.Lakeman@gmail.com" target="_blank">Jeremy.Lakeman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I suppose that once you've got a 6502 working, adding support for a 4510 shouldn't be too difficult....<br><br>(<a href="http://c65gs.blogspot.com.au/" target="_blank">http://c65gs.blogspot.com.au/</a>)<br>
</div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div class="h5">On Fri, Jul 4, 2014 at 10:38 AM, Bruce Hoult <span dir="ltr"><<a href="mailto:bruce@hoult.org" target="_blank">bruce@hoult.org</a>></span> wrote:<br></div></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<div dir="ltr"><div>On Fri, Jul 4, 2014 at 12:02 PM, Edwin Amsler <span dir="ltr"><<a href="mailto:edwinguy@gmail.com" target="_blank">edwinguy@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra">
<div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div 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></blockquote><div><br></div></div><div>You absolutely don't want anything on the hardware stack except function return addresses and possibly very temp storage e.g. PHA (push A); do something that destroys A, PLA (pull A). Or you could use a ZP temp for that. STA ZP; LDA ZP is I think cycle or two faster, PHA/PLA is two bytes smaller ... size usually wins.</div>
<div><br></div><div>The "C" local variables stack absolutely needs to be somewhere else, bigger, and using a pair of ZP locations as the stack pointer (SP). You can't index off the hardware stack pointer, for a start.</div>
<div><br></div><div>As mentioned before, if possible you'd want to statically allocate as many local vars as possible, as LDA $nnnn is a byte smaller and twice as fast (4 vs 8) as LDY #nn; LDA (SP),Y. (you'll sometimes be able to use INY or DEY instead of the load .. or just reuse the last value. But still...)</div>
<div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto"><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.<br>
</div></div></blockquote><div><br></div></div><div> I actually think that the ideal 6502 compiler would output actual 6502 code (mostly) only for leaf functions, and everything else should be compiled to some kind of byte code. The 6502 was a very very cheap chip to build hardware wise, but the code is BULKY. Even when operating on 8 bit values it's worse than, say, Thumb2, due to the lack of registers. On 16 or 32 bit values it's diabolical if everything is done inline.</div>
<div><br></div><div>Wozniak's "Sweet 16" is still not a terrible design for this, but I think a bit more thought can come up with something better. The Sweet16 interpreter is pretty small though (under 512 bytes I think?), which is pretty important.</div>
<div><br></div><div><a href="http://www.6502.org/source/interpreters/sweet16.htm" target="_blank">http://www.6502.org/source/interpreters/sweet16.htm</a><br></div><div><br></div><div>The criteria whether to use native or bytecode for a given function is pretty similar to the inlining decision. And a decent compact, small interpreter, byte code solution could be reused on other 8 bit CPUs.</div>
<div><br></div><div>Some of which are still in active use today, and so even commercially important e.g. 8051, AVR, and PIC.</div><div><br></div><div>Erm .. are we boring the rest of llvmdev yet?</div><div><br></div></div>
</div></div>
<br></div></div><div class="">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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>
<br></div></blockquote></div><br></div>
<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>
<br></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>LLVM Developers mailing list</span><br><span><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a></span><br></div></blockquote></body></html>