Quote:
Then you'd have a modern 65xx compiler where you get a lot of things for free in terms of e.g. code optimization.
My god, this sounds like a dream !!
You are right that SDCC seems somewhat unfinished. The documentation states that the compiler is highly optimized but in reality it looks like it's not the case. Maybe the feature they talk about in the documentation are "to be added" ?
But that is true with CC65 too, for what I tried to do with it, it's
extremely suboptimal and slow.
Quote:
Of course this would be quite a big task. The LLVM codebase is pretty large, and going through it and the documentation until you understand it well enough to implement your own target is not something you do in an afternoon. But neither is writing your own compiler from scratch.
Sure, if only I could find a trick so that it becomes a student project or something in the like, it would be great that way it would become my work, and it'd be way more convenient than doing it during my free time.
Problem is that, I'm a student in Electrical Engineering and not computer science, doing a CS-related project would be strange, and the biggest problem : Nobody uses the 65xxx processors anymore, making it hard to justify such a project in a researsh point of view.
EDIT :
It looks like clang is made with 32-bit or 64-bit processors in mind, just like GCC. This means it will ANYWAYS be terrible for the 6502, as code like this :
Code:
char a,b;
a = b+4;
Will promote b to int, add 4 to it, then cast it to char again, which is NOT what you'd want to do !
EDIT 2 :
A great quick benchmark for compilers is the following C code :
Code:
static char* source;
char* dest;
void test() {
unsigned char i;
for(i=0; i<8 ; i++) {
char k=1;
dest[2*i] = source[i];
dest[2*i+k] = 0;
}
}
it will test the following optimisations :
- k is loop invariant, should be affected before the for loop
- k is constant, it can be removed completely
- i<8 is always true after the initialisation, therefore the for loop can be optimized in a do/while loop, with the test only at the end
- 2*i should be optimized using another variable, which is incremented twice on each iteration
- the loop should be reversed to test i against 0 (I guess...)