Re: [sdcc-devel] Why not gcc port?

[Diego H. <die...@di...>]

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 <chr...@we...>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
>
>