[LLVMdev] MOS6502 target

[Bruce Hoult]

How does it fit the thread? Previous poster Jeremy Lakeman's blog says he
has implemented a 6502 in an FPGA, running at about 30x original speed.

Seems relevant to me, especially if anyone is interested in running code on
actual hardware rather than a software simulator.


On Sat, Jul 5, 2014 at 1:17 AM, Edwin Amsler <edwinguy at gmail.com> wrote:

> You can buy one for under $50, reprogram thousands of times and the dev
> tools last I checked confused me.
>
> That's the last I'll say about it until you either start a new thread or
> justify how it fits in this one.
>
> Not a fan of hijacking.
>
> On Jul 3, 2014, at 10:29 PM, Bruce Hoult <bruce at hoult.org> wrote:
>
> 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?
>
>
> On Fri, Jul 4, 2014 at 3:01 PM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com>
> wrote:
>
>> I suppose that once you've got a 6502 working, adding support for a 4510
>> shouldn't be too difficult....
>>
>> (http://c65gs.blogspot.com.au/)
>>
>>
>> On Fri, Jul 4, 2014 at 10:38 AM, Bruce Hoult <bruce at hoult.org> wrote:
>>
>>> On Fri, Jul 4, 2014 at 12:02 PM, Edwin Amsler <edwinguy at gmail.com>
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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...)
>>>
>>>
>>> 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.
>>>>
>>>
>>>  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.
>>>
>>> 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.
>>>
>>> http://www.6502.org/source/interpreters/sweet16.htm
>>>
>>> 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.
>>>
>>> Some of which are still in active use today, and so even commercially
>>> important e.g. 8051, AVR, and PIC.
>>>
>>> Erm .. are we boring the rest of llvmdev yet?
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140705/8ac5b8b0/attachment.html>