This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc for any microcontroller?


On 21 Mar 2003, Petr Danecek wrote:

> Hi,
> i suppose that gcc cannot be ported to compile just for any
> microcontroller. are there any requirements on a microprocessor which it
> must fullfil? 
> thank you,
> petr

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]