This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc for any microcontroller?
- From: <tm_gccmail at mail dot kloo dot net>
- To: Petr Danecek <danecek at ucl dot cas dot cz>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 21 Mar 2003 17:48:35 -0800 (PST)
- Subject: 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