[LLVMdev] MOS6502 target

[Bruce Hoult]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140704/b9a121ed/attachment.html>