From what I tested so far, it seems that CC65 generates a way better code than RCC16.
I depends on what you mean by "better" code...
Rcc16 generates faster code than cc65, at the expense of bigger code. This is mostly due to the fact cc65 uses JSR calls to load operands whereas rcc16 uses a sequence of instructions to load operands into virtual registers.
Just tried a classical Eratosthene sieve program:
Code: Select all
/* Eratosthenes Sieve benchmark */
#define size 10000
char flags[10000];
extern int printf(char *format,...);
int main()
{
int i, prime, k, count=0;
for(i=0;i<size;i++)
if (!flags[i]) {
prime = i + i + 3;
for (k=i+prime; k<size ; k+=prime) flags[k]=1;
count++;
}
printf("\n%d primes\n", count);
}
cc65 is more than 2 times slower than rcc16 to compute the prime numbers (-O2 optimization level for both compilers)
About memory utilization: despite what I said about cc65 generating smaller code, for small programs cc65 has to include the routines handling the operands (those called by the JSR instructions) so the result might be inversed.
In the case of the sieve program above, the .tap image is 11359 bytes when generated by the OSDK, and 2732 bytes when generated by lc65 plus 10000 bytes of data, ie. 12732 bytes.