Hi Juergen,

I tried some testing of the 8kB Demo, but unfortunately without any success.

Why you use not the already well introduced 8051 specific compiler extensions like "data, idata, pdata, xdata, bdata, bit" ?

E.g. to compile a Keil source with the SDCC was many times easier.

It was really a pain to translate only a single module to your compiler (http://www.specs.de/~danni/ap...1wire.c51).

Especially, that no bit variables supported, make your compiler wastefully working with RAM.

But this was one secret, why the 8051 was so tight with code and RAM usage and also fast: its excellent bit capabilities.

So I must convert all bits into bytes and the code grow to 154% in comparison to the Keil.

Because it was to complicated to convert all modules, I have not tested, how efficient the linker managed the usage of RAM.

Maybe the code for the sieve was tighter, but this was definitively not bread and butter of every micro controller application (none of all my applications contain it).

Additional your assembler was not compatible with the original Intel syntax (like Metalink, Keil and so on).


Some other crazy things I have detected:

A static local variable was placed into the XDATA space, which must crash mostly, since most of my applications have no XDATA available, only the 128 or 256 byte of internal RAM.

And if no xdata segment can be declared, how I can define memory mapped IO ?

An array can not be defined local inside a function. But this was the other secret of using C on micros: local variables should only be defined local. Since only then the linker can overlay the used RAM space with other functions.

The other missing thing was, that no bit variables can be used and no bdata segment exist to access it as bits and bytes at the same time. I use this technique often to declare additional ports (P4, P5, P6 and so on), which are realized with 74HC595 / 74HC165 port expanders.

Your header files are incomplete, since no P0 and P2 port pins defined.


So my personal impression was, that the SDCC was still many times better usable.

But any professional product should have advantages in respect to the SDCC to be successful.

Also, if you are not the first one, which build the compiler, you should support all well introduced machine depending extensions. Since nobody want to rewrite its code completely and to be further incompatible to the rest of the world.


Peter