Yes, it's yet another language/compiler for the 6502 of dubious usefulness.

This has been a pet project of mine for quite a few years. I finally doubled down and started seriously developing it last summer, and got the code into a state that is hopefully useable by someone other than myself and put in on GitHub this week.

You can find it at https://github.com/RevCurtisP/C02.

The alpha version of the compiler is written in C, but as the code is currently a hacked together mess, I plan to do a complete rewrite, which I may do in C02, so it can be a native compiler.

I've made a number of design decisions that cause this language to diverge from C in some unusual ways, some of which I am questioning, so I plan to ask for advice and/or opinions.

I plan to post some example code in the next couple days so that you don't have to read through all the documentation.

Thanks for posting. I will take a look.

A self-hosted version of this would be really neat.

This looks like an interesting project. Something like C, and in the spirit of C, but targeted at 8-bit devices instead of 16 or wider.
I agree with Martin_H. Being able to have it self-host could be very useful.

It might be interesting to test the efficiency of its compiled code against another C compiler that targets the 6502. Cc65 is one, I think.

The I will definitely proceed with this as a goal.


I've never actually used cc65. I'm downloading it now to generate some sample source code.

I compiled a Hello World program in both CC65 and C02, targeting the VIC 20.

The C code used with CC65 compiled to 777 bytes total.

The C02 code compiled to 188 bytes.

This was an incredibly trivial example and the generated code was actually very similar.

CC65 .s file

C02 .asm file

so in this case the difference must be in the included library.

Once of the goals of C02 is to be completely system agnostic and independent of any specific system libraries.

For example, I've created a header file that contains just a VIC 20 Basic stub and either hooks or aliases functions to the routines built into the ROM.

This code compiled to a total of 60 bytes.

This is what the generated code looks like.

This sounds really neat! Could you see how compiled code compares when you do loops and calculations? How about something along these lines:

Actually, this is where C02 diverges from regular C. Because C02 is designed to compile directly to 6502 assembly, variables are limited to a single byte and mathematical operators are limited to available machine operations. And, because of the limits of addressing modes, the stack is not used during mathematical operations. Because of this multipluy and divide aren't available as normal operators, and functions may only appear as the first term of an argument, however functions may be nested.

Basically, the parser converts the expression into an LDA or JSR(s) followed by a series of ADC, SBC, AND, ORA, and EOR instructions.

To profile the above code, I will need to make the numbers a bit smaller so that interim results will fit in the range 0-255, and refactor the expression to work within the limits of C02. The parameters to printf are also reversed because of C02's calling convention for functions. In addition, escapes in strings are handled literally, so '\n' will not produce a newline on most 6502 systems. The current solution is to call the system-specific newlin() function.

So this is what the C02 code ends up looking like

and the equivalent C code is now

The resulting assembly will be in the following reply.

For the loops, C02 produces the code

and CC65 produces

For the expression evaluation and subsequent assignment, we get the following:

From C02 (28 bytes)

and from CC65 (40 bytes)

As you can see, C02 translates the code to 6502 operations as closely as possible, while CC65 calls a subroutine for every operation, and it promotes the values to 16-bits then casts them back to 8-bits.

Finally, there is the printing code:

C02 produces


and CC65 produces

I'm no expert, but that looks like C02 is a winner, certainly for code density.
One thing that I noticed is that there are no shift or rotate commands in C02. Is this because there is no way to shift multiple bits in one 6502 instruction?

EDIT: I just checked the docs again, and I see that there are bit-shift instructions. No rotates, but that does make a sense now that I think about it, since the 6502 rotates through the carry bit.
I still think I'd like to use C02 in my project, especially if it runs on the 'C02 as well.

Thinking of which, the name might be a touch awkward, due to the use of 'C02(with the apostrophe) to refer to the 65C02, at least around here). I'm not saying you have to change the name(and I think it's a good one), but might "C-02" work? I think it would differentiate it from the local slang a little more clearly.

The code generated is generic 6502 code with no illegal opcodes, or decimal mode, so it should run on any 6502 derivative. I plan to add a switch to generate 65C02 optimized code (particularly the BRA instruction).

As long as you don't need 16-bit math, it should work pretty well.


The name was intended to be a pun of CO₂ (Carbon Dioxide), and I was also considering a variant for the 8080/Z80 called C80.

At the very least I should rename the compiler cc02, to match cc, gcc, tcc, etc...

There are multiple bit shift instructions in stdlib, which replicate the << and >> operators of C. Functions to do rolling are also possible, depending on what you want to do.

The intention of the language is that the fiddly parts will be written in assembler and called as functions. And the general program flow and overall logic written in C02.