Retargeting a C Compiler to 6502 — 8bitworkshop documentation

[giscus[bot]]

Retargeting a C Compiler to 6502 — 8bitworkshop documentation

I’ve written before about cc65 and some of its optimization challenges. It’s a stable compiler with a robust toolchain, but its code generator doesn’t full advantage of the 6502 when performing 8-b...

https://8bitworkshop.com/docs/posts/2020/retargeting-a-c-compiler-to-6502.html

[HenrikSandell]

I have written a C compiler specifically for 6502. It is of course still a work in progress but I do have support for most of C.
Let me start with the things I do NOT have:

• Bit fields
• Floats
• 32bit int

And the list the things I do have:

• struct/union
  union header { /* block header */
  struct {
  union header ptr; / next block if on free list /
  unsigned size; / size of this block */
  } s;
  Align x;
  }

• Pointers to functions with decl arg, e.g. int (*f)(int *a,int *b) = swap;

• Support for recursive calls; i.e. a variable stack

• Init of complex vars, e.g. auto int days[]= { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31}

• Support for signed and unsigned multiplication (division and mod is in progress)

• A preprocessor for #if, #include, etc (although I do not support #define with arguments)

• Basically almost all of K&R

The compiler is written in C#.

Optimisation could of course be better (it always can). Stuff that the optimiser does:

• Evaluate and propagate constants, e.g. int a=2, b=3; return a+b; ``?`get translated intoreturn 5 ```
• Try to avoid temp vars when evaluating expressions
• Optimise implementation of operation, e.g. a*4 becomes a << 2
• Peephole to avoid long jumps, unnecessary register assignments, and uncecessary CMP, e.g. LDA $A0; CMP #0; BEQ L1becomes LDA $A0; BEQ L1

In case this is of interest to anyone I would be happy to write a short article about it. Obviously I'm not doing this for commercial purposes and I would be happy to share this source sourcecode.

[sehugg]

Sounds like a fun project! I'm sure someone would find it informative, and it's an interesting design space to explore. I've found that getting a test suite to run and pass is the hardest part ;)

One idea I've been kicking around is a hybrid model, where you have 8/16 bit native 6502 code mixed in with 16-bit VM code (I think PLASMA attempts this). The more I play with small systems, the more I realize how much can be done with metaprogramming and mixing execution models, like Infocom's Z-Machine.

I also hope that 8bitworkshop can use C# code someday. Maybe Blazor can translate to JS? I haven't looked into it much.

[FlightControl-User]

You should look at kickc ...

[HenrikSandell]

I have looked at it...
Of course I cannot resist noting what my compiler has and KickC lack... (Then there are tons of nice features in KickC that I lack; e.g. #asm)

Floating point types: float, double
I do not have it

Full support for *, / and %. Constants that are 2^n is optimised to shift/and; e.g. a % 4 => a & 0x3; a / 256 => (kickC) >a

Full support for union. (But that is easy if you have struct)

Full support for arrays of arrays.

Full support for function pointers with parameters and return values.

Full support for Recursive functions: char fib(byte n) { return fib(n-1) + fib(n-2); }
This is something that I believe is important; but also something that was quite tricky to implement. I use a stack on ZP with ZP 0x20 used as SP.

Limited support for bitfields. They can be at most 7bit long and cannot span bytes.

Alignof operator: char s = alignof(word);
I don't have it… Don't see why you need align on 6502 since there are very few problems using any adress (bare some page boundaries that can take an extra cycle)

Support for Variadic functions: sum(int i1, ...) including printf.

Possible to allocate arrays on stack. (But given the limited size of the stack it is a bad idea.)