C++14 for the Commodore 64 [video]

This was another reason I went the x86->6502 route instead of just a 6502 backend for llvm - it could plausibly work with any code. Let me know what you find.

I don't believe I found those, thank you.

Yes because the code emitted by a compiler is directly proportional to the size of the specification? I fail to see the point.

Static optimization to inlined code that ONLY handles immediate numbers and addresses is fine, and interesting to see the full pipeline working. But that possibility is there really for any language and any asm platform. I remember seeing Forth compile down to 6502 or other asm code, where it compiled down to the asm instructions a human would write for the same task, with basically zero language overhead.

HOWEVER, that was because the code written only did things similar to assembly instructions, similar to this example.

The biggest problem with compiling C family languages to 6502 is the stack. They generally assume something like a local stack frame for variables and parameters, and there's no way to directly express that style of programming at the 6502 instruction level. Note that there were no local variables in these examples, much less any actual function calls. Certainly the ABI used by C would not be machine-code-translatable from x86 to 6502; there would be an ABI written for 6502 and higher level targeting could work.

Instead of generating & trying to translate x86 assembly code, compiling C++14 down to plain C and using a 6502 compiler like cc65 could work significantly better for more idiomatic C++.

While it's an interesting novelty, why write 50+ lines of C++ code when writing 7 lines of commented, well-understood assembly instructions suffice? Add some variables and macros to take care of naming the various bits & locations, or target some codegen directly to 6502 if we're talking about programming "in the large" relatively speaking. Sure, you don't want to touch x64 code for human writing in the general case, but 6502 was designed with hand coding in mind.

Yes. This doesn't strike me as an especially productive line of attack, but maybe I'm missing something (hopefully not obvious), maybe I'm just not imaginative enough, and/or maybe I'm underestimating how much effort people might be willing to put into such an endeavour.

This did get me thinking about the problem a bit this evening though. The 6502 is an awful target for many higher-level languages, but I think you could compile something like C, if you treat zero page as the stack for locals, and index it by X. The programmer would need to be aware of the target's rather tiresome limitations, but you'd get somewhat passable code at least.

(Unlike absolute addressing, you do pay a 1-cycle penalty for indexed zero page accesses, but what can you do? You need to store things in zero page to handle pointers.)

Suppose you had a function with a couple of locals, like this:

    void strip(char *p,char c) {
        unsigned char *dest=p;
        do {
            if(*p!=c) *dest++=*p;
        } while(*p++!=0);
    }

So you'd store c (1 byte), then p (2 bytes), and then once the space for locals is reserved, zero page starting from the address in X would look like this:

    +0, +1 = dest
    +2, +3 = p
    +4     = c

So the ideal generated code would go along these lines:

    DEX:DEX                         ; reserve space for locals
    LDA 2,X:STA 0,X:LDA 3,X:STA 1,X ; dest=p
    .L0
    LDA (2,X)                       ; *p
    CMP 4,X
    BEQ L1                          ; taken when *p==c
    STA (0,X)                       ; *dest=*p
    INC 0,X:BNE L2:INC 1,X:.L2      ; ++dest
    .L1
    LDA (2,X)                       ; *p
    INC 2,X:BNE L3:INC 3,X:.L3      ; ++p
    CMP #0
    BNE L0                          ; taken when *p!=0
    INX:INX
    RTS

I don't think many people would write code like that by hand, but it's not completely insane given the requirements.

This has actually now piqued my interest enough to make me think about actually coding something, so I guess that answers the question about how much effort somebody might be willing to put into such an endeavour.

Other thoughts:

- since ZP,X costs like ABS,Y, maybe have a second stack in main memory for non-pointers and index it with the Y register (the RMW instructions don't have an appropriate addressing mode though)

- you could statically allocate zero page for many programs, which would make it easier to use the (ZP),Y addressing mode

- turning canned snippets (like the INC/BNE/INC) into routines would probably be rarely beneficial, since getting the address into X is rather involved

- I've never used a C compiler for the 6502 so maybe they all do this anyway ;)