- I don't think Opt65 has anything to do with CC65, it's something written by a C64 guy many years ago, that's why it's old style C. And yes, if we could get that thing to work (and play nice with auto-modified code, etc...) it would be nice to have, even when coding in assembler.
- Fabrice sent me last year some new code for the LCC code generator, which is supposed to be better, but I did not have time to do anything about that, so if some people feel like giving a shot, I can forward you the changes.
Now, regarding that:
I agree that it's possible to have a BETTER C compiler than what currently exist, but "will never generated good code for a 6502 architecture" is not a belief: It's a fact.I disagree and for many reasons, but first of all I want to state that I am not looking for the perfect optimizing C compiler for the Oric, just one that is moderately good and allows me to test algorithms before I convert them to ASM.Let's face it, guys... a C compiler will never generate good code for a 6502 architecture. Simply C is not designed for so limited 8-bit processors.
The reason is that the C is doing some assumptions on the machine model, things like "memory is linear" and "fields of structures should not be reordered" and "you can dereference an element of an array and from there get the position of the next element".
If you program in clean C, you cannot *by design* have something that will run efficiently on a 6502.
The best example is something as simple as a structure that holds some sprites information, with a X,Y position, a pointer to the bitmap to draw, and some life points. Then you have a bunch of these and put that in an array.
In 6502, you would use instead one array for each 8 bit piece of information: An array for the X, one for the Y, one for the lower part of the pointer, one for the higher part of the pointer, one for the life points.
Obviously you can do that in C as well, but what I mean, is that if you are not going to use arrays of structs, you are not really doing C anymore, and if you somewhat modified the compiler to allow that, it would not be a standard C compiler anymore (but it would run MUCH faster).
So yes, you could write a very fast compiler that runs nicely on the 6502, but that would not be a C compiler anymore.
Regarding GCC, what would be nice is actually to have a C++ compiler instead of just C, that would allow for things like deep inlining and constexpression, which would basically give compile time optimized code generation, and references too.
At the moment, I evaluate the speed difference between LCC65 and pure assembler (both code written by me) to be about a factor of 10 on standard code, and up to x50 on convoluted things involving loops and bit-twidlingEven if the compiler reaches only half of the speed of a human it does not matter for me since that is good enough to evaluate the sanity of my algorithm before I switch to assembly. Even between humans coding in assembly, a difference of half speed is very easy to reach so that would be already good. Hell, even one quarter or one height speed would be fine.
Except if you look a bit lower on the thread, you'll see that somebody pointed out that CC65 was not being called with the optimisation parameters.cc65: 301 ticks (6.02s)
gcc: 97 ticks (1.94s)
Which reminds me that in the OSDK we are running LCC with -O2 instead of -O3, maybe there's something worth checking there.