tokafondo wrote:
Thanks. No trace of WDC's compiler there... I think that the fact that it hasn't been got to work leaves it out of the comparison.
I read something about floating point
here.
For some reason I want the people to be able to run this WDC C compiler. The comparison leaves CC65 as the one to be chosen because it's the one that
works, having speed and code size against it.
I would not recommend basing decisions on this pretty biased article. Someone pointed me to this comparison some time ago, because it seemed to mention a bug in my compiler (vbcc). Trying to verify this was made somewhat tedious, because the author of this comparison uses his own simulator and, in the case of vbcc, his own linker scripts and configuration files. After having a short look I found that the test that did not work with vbcc uses the pages 0x300 and 0x400 to write the results in a simulated frame-buffer or something like that. However his vbcc linker files contains:
Code:
MEMORY
{
...
ram: org=0x0300, len=0x0500
}
SECTIONS
{
...
data: {*(data)} >ram AT>out
...
bss (NOLOAD): {*(bss)} >ram
...
}
I did not investigate further, but putting the data and bss section in the frame buffer does seem suspicious to me. As I did not want to waste much time with the tinkered configs, I slightly adapted the code to the C64 screen buffer and the result compiled with vbcc for C64 looked very similar to the one compiled with cc65. Strangely however, the player "sprite" only showed with cc65. Further investigation showed that the test code used an uninitialized variable for the y-coordinate of the player. After fixing this bug in the test, the result of vbcc exactly matched that of cc65.
When I tried to add a timer variable to measure run-time on the C64, the code did not compile anymore on cc65, because it exceeded the 256 byte limitation of cc65. Apparently the test was exactly tailored to cc65's limitations whereas the vbcc result was basically sabotaged. It is obviously not an unbiased comparison but rather the author started with code for cc65 and did no further investigations when the code did not work with a compiler he personally dislikes (whereas for gcc which apparently generated actually broken code he even went out of his way to fix the assembly code by hand). Using this approach your daily-use compiler will of course tend to look more stable. That does not really say much.
As I wrote above, I am the author of the compiler that the author of this comparison hates, so obviously I am not unbiased as well. When I checked his article, I did not write anything and I did not really want to get involved (and write lengthy posts like this one). However, if people point to this blog, I have to say that after what I have checked so far, it is my firm (and as my findings hopefully show mostly fact-based) opinion that this comparison is much too flawed to base a compiler decision on.
I did not spend much time with this article (mainly wanted to check if there was a bug in my compiler) and only limited time with other 6502 compilers. So I will not comment on the stability of the different compilers. I just can say do not use this article to base your decisions on. It is in no way a fair comparison.