Re: gcc for any microcontroller?

[Petr Danecek <danecek at ucl dot cas dot cz>]

thank you for your answer, Toshi.
if i understand it correctly, HC08 would be difficult to port, though
not impossible. now, is it worth of it? maybe there is a more suitable c
compiler somewhere. i doubt that writing cc from scratch is a good
choice...?
petr

On Sat, 2003-03-22 at 02:48, tm_gccmail at mail dot kloo dot net wrote:

> Since I'm a processor geek, I'll take a fling at answering this one.
> 
> Yes, probably gcc can be ported for any microcontroller. The real question
> is whether a good port can be done for a microcontroller.
> 
> GCC emits good code for processors which have:
> 
> o Many general-purpose registers
> o Orthogonal and reasonable addresing modes
> o Few or no special-purpose registers
> o Homogenous memory space
> 
> GCC has trouble generating code for processors which have:
> 
> o Few or no general-purpose registers
> 
>   Many microcontrollers use an accumulator-based architecture, which does
>   not work with common register allocation algorithms at all, so you wind
>   up emulating general-purpose registers using strange techniques.
> 
>   Also, stack-based architectures are difficult to accomodate as well.
> 
>   Applies to: 68HC11, 8051, Z80, 6502, PicoJava, x86 FPU, etc.
> 
> o Lack of standard addressing modes
> 
>   Some processors have no or very few bits of displacement on the indirect
>   addressing mode, which causes gcc problems. Unfortunately, some people
>   are publishing papers which say "you don't need displacement addressing
>   modes because they can be easily simulated" (Crispin Cowan, etc) and
>   some processors have actually been built without displacement addressing
>   modes. This problem complicates many optimizations including CSE, loop
>   optimizations, instruction scheduling, etc.
> 
>   Applies to: NIW architecture, IA64, etc.
> 
> o Many special-purpose registers
> 
>   This complicates register allocation and instruction scheduling greatly,
>   and makes code generation very difficult.
> 
>   Applies to: SH, etc
> 
> o Special areas of memory which can only be accessed by special addressing
>   modes and/or banked memory
> 
>   This usually applies to DSPs and DSP-like processors which have internal
>   memory which can be accessed in parallel with the external bus, or to
>   funky processors that have been extended past their normal lifespan by
>   artificially extending the address space.
> 
>   Applies to: 8051, etc
> 
> o Modal instructions
> 
>   Some processors have instructions whose behavior change depending upon
>   the state of the processor status bits. 
> 
>   Applies to: SH, 65816, etc.
> 
> o Literal pools
> 
>   Some procesors can only encode short constants into immediate loads
>   and require a PC-relative reference to load long constants. These
>   long constants are usually stored in small batches called
>   "literal pools".
> 
>   Applies to: SH, S390, etc.
> 
> Having said all that, I suppose the minimal instructions necessary to
> support gcc are:
> 
> o load indirect
> o store indirect
> o load immediate
> o negate
> o add
> o compares
> o boolean ops
> o conditional branches
> o jumps
> o subroutine calls
> 
> I think most other operations can be synthesized from those instructions
> (albeit somewhat inefficiently).
> 
> Toshi
> 
>