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)
C Compiler Assembler and Runtime for C64
11–20 of 34 posts
Re: C Compiler Assembler and Runtime for C64
#12> 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?
Re: C Compiler Assembler and Runtime for C64
#13Would this work on the Apple ][? How does it compare/differ from the LLVM 6502-MOS project?
Yep. Same chip: 6502. I'm guessing the nearest thing to this is probably cc65: https://cc65.github.io/
Re: C Compiler Assembler and Runtime for C64
#14Wow 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.
Yes, this is very cool! And impressive!
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/
But there is some development ongoing: https://cc65.github.io/
Would be interesting to see comparison with the new one.
Re: C Compiler Assembler and Runtime for C64
#15> 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.
Re: C Compiler Assembler and Runtime for C64
#16> 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.
The idea of using an interpreter to save space is sound.
Wozniack used that idea in SWEET16 for the Apple II (also 6502 based).
Re: C Compiler Assembler and Runtime for C64
#17Earlier quoted context omitted.
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.
The idea of using an interpreter to save space is sound. Wozniack used that idea in SWEET16 for the Apple II (also 6502 based). https://en.wikipedia.org/wiki/SWEET16 https://www.youtube.com/watch?v=vGdEN9Z7owg
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
Re: C Compiler Assembler and Runtime for C64
#18So 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
Re: C Compiler Assembler and Runtime for C64
#19So 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 b…
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.
Re: C Compiler Assembler and Runtime for C64
#20Cool 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)
[deleted]