C02 - An 8-bit optimized C syntax compiler for the 6502

[CurtisP]

I just realized that the 65C02's PLX instruction gives me a way to easily allow an expression to be use as an array index on the left side of the assignment.

[CurtisP]

I created a branch that targets the 65C02. but couldn't get the code to compile in dasm.

[DerTrueForce]

CurtisP wrote:

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.

That makes perfect sense. It means the compiler can be simpler, and you don't have to worry about including something that could potentially be sub-optimal.

CurtisP wrote:

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...

Funnily enough, I was wondering if this would translate well to the z80...
The CO₂ pun idea was actually fairly good, I think. I don't know about the whole cc thing, though.

[CurtisP]

DerTrueForce wrote:

I still think I'd like to use C02 in my project, especially if it runs on the 'C02 as well.

What platforms will you be writing 6502 code for and on?

[White Flame]

By the way, comparing to cc65 isn't going to be that meaningful. CC65's goal is to bring actual proper standard C to 6502 platforms, so it's going to be bigger and have greater mismatch with the CPU platform assumptions. If C02's goal is to have a 6502-friendly "C-like language", then yeah you're going to generate smaller more 6502-idiosyncratic instructions, but it's still a custom language to learn if you want to attract a userbase instead of just building your own tools.

[BigEd]

Sounds good to me though - a c-like language with a good fit to the machine.

(I'd call it CC02 though, to make search easier.)

[CurtisP]

White Flame wrote:

CC65's goal is to bring actual proper standard C to 6502 platforms, so it's going to be bigger and have greater mismatch with the CPU platform assumptions.

Then C02 fills a different niche, which is what I was going for.

[DerTrueForce]

CurtisP wrote:

DerTrueForce wrote:

I still think I'd like to use C02 in my project, especially if it runs on the 'C02 as well.

What platforms will you be writing 6502 code for and on?

The project I'm referring to is going to be a handheld device(project thread here). One of my goals for it is to have it be able to build and overwrite it's own firmware and OS. I was originally going to do this by writing an assembler to run on it, and write the OS in assembly. If I can do that in something a little bit nicer, that'll make it much easier.
Basically, I'd want to use it on and for my own platform. This means I'd need to write my own libraries for it or adapt existing ones, but I think I can do that.

[CurtisP]

I added a command line option -h to specify a header file to be inserted at the beginning of the code.

The purpose is to allow a single program to be easily compiled against different target machines.

I plan to add another option to specify the include file directory and restructure the sample/test code directories to better demostrate how this can be used.

[unclouded]

White Flame wrote:

By the way, comparing to cc65 isn't going to be that meaningful. CC65's goal is to bring actual proper standard C to 6502 platforms, so it's going to be bigger and have greater mismatch with the CPU platform assumptions. If C02's goal is to have a 6502-friendly "C-like language", then yeah you're going to generate smaller more 6502-idiosyncratic instructions, but it's still a custom language to learn if you want to attract a userbase instead of just building your own tools.

I agree, the comparison isn't fair since cc65 can compile C never intended for the 6502. Perhaps a comparison with https://github.com/dschmenk/PLASMA, since it was designed for the 6502.

Having more high-level language compilers for the 6502 is a win though. I didn't use cc65 because it's C, I used it because I found it quicker for testing ideas than assembler. I'd be prepared to learn a new syntax for that purpose (and I'm jealous because I wanted to write a high level language closely bound to the 6502).

[CurtisP]

unclouded wrote:

White Flame wrote:

I'd be prepared to learn a new syntax for that purpose (and I'm jealous because I wanted to write a high level language closely bound to the 6502).

This has been stewing in my head for over a decade, and it wasn't until the last year that I really started implementing it.

I'm still working out the details so any and all suggestions are appreciated.

[CurtisP]

Another update to the code: up to three variables on the left side of the assignment, for function calls that return values in the X and/or Y registers as well as the Accumulator.

[CurtisP]

Another update:

I deprecated the #define directive in favor of the const keyword, although the syntax differs from standard C.

I had previously implemented an #enum directive. This has been replaced by the num keyword with a syntax similar to standard C.

All constant references in C02 are prefixed with a # symbol.

[CurtisP]

Update: Added the struct keyword. C02 implements most of the functionality of structs in C.

Structs make the compiler a bit larger, but I feel they are too useful to leave out. For example, the variable and constant lookup tables are structured as arrjects (a separate array for each member). The struct lookup tables are implemented using structs and the as a result the code is much easier to read. I plan to go back and refactor the variable and constant tables to use structs as well.

C02 does not support arrays of structs, and the lack of native pointer support precludes a trivial implementation of linked lists. However, the block and pointer functions in the standard library were written to replicate both of these functionalities. The repository currently contains a test directory. I think I will add an examples directory as well.

Edit: I added @ as the size-of operator.

[CurtisP]

Bug Fix: Chained IF/ELSE statements weren't compiling correctly. Finally figured out how to make them work.