I just did a quick-and-dirty comparison based on some SecureDigital/FAT12 code I've been developing under Keil. I did my best to adapt it to SDCC (I downloaded the nightly snapshot from Nov. 10th, 2005).

It was a little work since SDCC didn't directly support the MCU I was using (Dallas DS89C450) so I had to create a header file. Keil included it.

I also found that although I don't normally use scanf in any environment, much less MCS-51, I was using it in my current development for testing purposes. SDCC doesn't seem to include that in the stdio library. So since I was just in a hurry to compare a few apples, I simply removed my single reference to scanf in both Keil and SDCC.

Keil compiles my three source files on a 450MHz Windows XP machine in less than a second. SDCC took just over 6 on a 1.6GHz Linux machine.

I configured both Keil and SDCC to optimize for code size. The resulting code size was 9,895 bytes for Keil and 12,415 bytes for SDCC. That's almost exactly 25% larger for SDCC. And, as-is, I know my application won't work because SDCC doesn't seem to have scanf.

Now I'm not knocking SDCC. I used it for my last C-based project and it worked out fine, with a little hammering (I had to declare numerous functions as reentrant so it would use the stack and not run out of variable storage space). And I won't say that this quick test is definitive or perfect, but a quick test shows that:

1. I had to create my own header file because the headers SDCC includes isn't very comprehensive. That took time.

2. I had to remove scanf from my application to make it compile under SDCC, so obviously the "benchmark" isn't even functional right now. Had I wanted to make it work, I would've had to write a scanf function.

3. As far as I can tell, SDCC made me write a putchar function so that printf could call it. While it is perfectly necessary to allow a developer to write his or her own putchar routine, it does seem logical that a "default" putchar that uses SBUF and TI ought to be included. Keil includes a default putchar whereas I had to write one for SDCC.

4. Keil compiles at least 6 times faster on a slower machine than SDCC does on a faster machine. I'm personally not too concerned about this since the size of a given 8051 project is not usually so lage that this is a major issue, but it is worth noting.

5. With code-size optimization on both systems, SDCC produced code 25% larger.

So while I had no problems using SDCC in my last development, I don't think I'd go as far as saying that there's "no need" for commercial compilers. A 25% difference in code size is still pretty significant, especially on a platform that is generally limited to 64k code size.

Regards,
Craig Steiner