Wow guys, thanks a lot for your detailed answers.

SDCC is great and so it's its community. I wish I had more time and knowledge to help this project.

Regards,
Diego


On Tue, Nov 5, 2013 at 2:44 PM, Christer Weinigel <christer@weinigel.se> wrote:
On 2013-11-05 12:55, Diego Herranz wrote:
For AVR microcontrollers there is avr-gcc which takes advantage of the huge amount of work spent in the development of GCC.

Why the micros targeted by SDCC don't have a gcc port? Why there is no pic-gcc port? Or 8051, etc? Is it a technical/architecture problem? Licenses problem?

One reason is that both PIC and i8051 are "weird" and absolutely awful architectures for a C compiler.

Both PIC and i8051 have multiple address spaces.  On PIC there is program memory and RAM.  RAM is accessed in banks of 256 bytes and a special register is used to select a bank.  On i8051 there are three different address spaces, program memory (16 bit addresses), xdata (16 bit addresses) and internal memory (8 bit addresses).  To make things even more interesting the first 32 bytes of internal RAM are 4 banks of 8 bytes each which are aliased with the CPU registers. Even more interesting, the highest 128 bytes of the internal memory are Special Function Registers (SFR), but only if direct addressing is used, when indirect addressing is used it will instead access 128 bytes of RAM which are overlaid on the same addresses as the SFRs. gcc works best with a single flat memory space.

Neither of them have a usable general purpose stack.  On PIC the hardware stack is only a call stack with return addresses, if you want a proper stack so you can pass arguments and have recursive functions you have to simulate the stack in software.  On i8051 there is a stack but the architecture doesn't have any nice instructions for stack relative addressing so it's a bit of a pain to use it.

Both are accumulator architectures with very few registers, gcc works best on architectures with many general registers. Historically gcc didn't have that good support for anything that weren't 32 bits either.

gcc has also gotten a lot better att supporting "weird" architectures in recent years, but 10+ years ago when sdcc was originally written, it was probably easier to write a new compiler such as sdcc than to modify gcc to produce code for them.   AVR is also a Harvard architecture with has separate program and RAM address spaces but AVR is not quite as weird an architecture as PIC or i8051 so gcc works decently on AVR.  Today it might be possible to modify gcc to support PIC and i8051, but since sdcc exists and does a decent job of producing code for those architectures, nobody seems to be too interested in doing that.

If you read the original sdcc paper, "Anatomy of a Compiler" by Sandeep Dutta, it contains more details on why sdcc was written and why it works as it does.

  /Christer