Wow this is actually more than just a C compiler... it supports numerous 6502 systems like NES, has a number of useful libraries and examples like disk i/o and many ample programs including sprite multiplexing. There are also extensive pragmas to help optimize.
The only other compiler for 6502 I've ever used (and had to modify) is the old cc65. The original author stop developing it (10+ years ago):
https://cc65.github.io/
I experimented with cc65 and wrote a simple game that ran on my actual C64 hardware. It was a lot of direct memory access, unrolling loops, and avoiding stack usage. A fun time overall, and it ultimately ran smoothly, but I see do why people who attempt anything serious on a C64 tend to focus on using ASM.
Neat. When I owned 8-bit machines back in the 1980's, I never bothered to learn assembly; just BASIC. I'd love to tinker with retro computers again including things like the Commander X16, but to be honest I'm too old and impatient to code in assembly even though I'm comfy with it now. If I could use a C compiler that inflicted a non-heinous size/performance penalty, I'd be happy. Especially if I could link in asm libs for performance-critical or low-level functions.
Idea ... If you want to stick to a (late) 1980s platform AND you want to code in C without penalty, consider the Sega Genesis.
68000 CPU. There's a mature and helpful homebrew scene. Documentation is good. The SGDK devkit/framework is nice and gives you a no fuss pipeline from C through GCC to a ROM file output that you can run on any emulator, or actual Genesis console (flash cart), or an FPGA like the MiSTer project. 68K assembly is pleasant IMO, if you want to sprinkle in some of that with your C. And, to satisfy an 8-bit itch, the Genesis also has a Z80 CPU on board, typically used for audio programming. Which, by the way, gives you authentic 1980s arcade/console FM synthesis.
IMO the Genesis' architecture of sprites, tilemaps, and palettes is very sane and easy to grok (compared to, say, the Super Nintendo of the era). Also, flat memory model. Yay.
That's awesome. 40 years ago people would have killed for such (I myself included, if it were for Z80 instead of 6502).
But why? I know better then to ask for such projects, but here I do, because the project's readme provides a 'history & motivation' section, albeit which doesn't really tells much of the latter.
"The original idea for the oscar64 compiler was to translate the C source to an intermediate 16 bit byte code". That's (afair) the approach taken by the (out-of-tree) GCC port to the Parallax P8X32A (itself not an easy target for C: registers, if one wants to call the local memory location used as such that are wide, but the architecture is memory starved and there's no hardware stack). Is there some overlap?
> After extensive optimizations it turns out, that the interpreted code is not significantly smaller than the native code in most scenarios (although there are cases where the difference is significant).
Does that mean that the whole thing was ultimately a failed experiment, or that the native code optimizations have become so good that the interpreted mode is made obsolete in most situations?
It turned out that for most cases, there is no gain by using an interpreter. Most code that does make any sense on a C64/6502 is compiled into a smaller and faster native version. For some code e.g. heavy floating point or many pointer indirection the interpreter wins on the memory size - but this is not a good use of a C64.
This was my assumption as well, when I started this compiler. It just did not play out this way with most code that I have written for it. The native code optimizer is able to reduce 16bit arithmetic to 8bit in many cases, where it can prove that the value range is small, and also avoid many pointer/stack operations by global call chain analysis. Both benefit the native code path
So I recently took at broad look at some of the old C compilers and wrote an article about it. One interesting thing of note is a lot of compilers in the mid 70s compilers like the Small-C compiler actually only compiled a subset of the C programming language. This was because the 8-bit systems were much more resource constrained the then PDP-11s that C was developed on, and C was difficult to compile. It's hard to believe computers once struggled to run C code, and that definitely contributes to why you see more Pascal, Assembly, and Basic during that time period
I don't think the Small-C compiler was all that popular with professionals (or even hobbyists). It was incomplete, slow and produced (on the Z80) poor code.
C was indeed not ideal for 8 bitter (hence the astonishment around this topic). CP/M istself was written in PL/0 (I suppose with a sprinkle of assembler). Macro assemblers were popular then for shrink-wrap software. Custom software was often done in BASIC.
Professionals used cross compilers (or cross assemblers) when they had a chance. Microsoft BASIC e.g. was developed on a PDP-10.
Also: these old compilers ran on the target system. If all features are supported, the compiler might not fit into memory, and need many passes to work.
The compiler will most likely not support a current C++ standard in the near future, but several C++ features are already implemented. The compiler can be switched into C++ mode with the command line option -pp or by providing a source file with a .cpp extension.”
Cool stuff, seems to be competing with cc65 (not very performant, includes a stdlib), sdcc (very new port), vbcc (not open-source, best performance), and kickc (not standard c)
Not much of a point since Apple ][ has the SWEET16 interpreter already as part of its BASIC ROM. But yes, it would be nice if the LLVM-MOS6502 folks put some effort towards feature parity with this toolchain. LLVM almost certainly has better auto-optimization than a new bespoke compiler.
According to Wikipedia the SWEET16 Interpreter is significantly slower than native assembly (Wiki says 1/10th the speed). A C compiler that targets 6502 would make sense if I want to code something to run on the Apple ][ that's relatively performant
