Re: Does gcc works as a cross compiler to 8031 micro controllers?

[Dave Hudson <dave at cyclicode dot net>]

Hi Jim,

Jim Wilson wrote:
> I am not familiar with the AVR, 68hc11, and IP2022.  The H8 family is a mixed
> 8/16 bit part.  It has 8 16-bit registers, and thus isn't too bad as a gcc
> target.  Looking at the 68hc11 port, I see that it has some 16-bit registers,
> so it doesn't look like an 8-bit microcontroller to me, it looks like a
> mixed 8/16 bit part.  Maybe we need a definition of what exactly an 8-bit
> microcontroller is?
I'd argue that an 8-bit micro is one for which the normal register width 
is 8 bits.  The AVR has a few 16-bit registers (pointers) but each of 
these is actually two 8-bit registers combined together (much like H & 
L, B & C or D & E were on things like 8080s) - almost all of the AVRs 
instructions perform 8-bit operations.  A lot of people write AVR code 
using avr-gcc because it's pretty much as good as many of the commercial 
compilers (I wrote a pretty complete RTOS and TCP/IP stack using it a 
few years ago).

The IP2022 has a single 8-bit accumulator (W) an 8-bit multiplier 
overflow register and three 16-bit pointer registers (there's an 
external address register too but that's largely irrelevant as far as 
gcc's concerned) with everything else being either a direct or indirect 
memory reference (each insn only taking one clock cycle though). 
ip2k-gcc (our in-house version derived from the original Red Hat port 
and then folded back into the Red Hat tree last year) is our main system 
compiler and we have a lot of users (hundreds if not thousands of 
programmers) writing code with it - I've not seen any complaints about 
the code generation yet (perhaps their expectations are low though 
because so many other 8-bit compilers aren't so hot :-))

FWIW getting good code out of gcc has taken a few rather unconventional 
tricks but gcc has been a very good framework to build with and we now 
have some quite large and complex files where I can look at code 
sequences and know that I couldn't write things any better by hand 
(there are other places where I could take out 20% of the opcodes but 
they're getting fewer by the day).  FWIW when I look at i386 code from 
gcc-3.2 I often find similar places where I could improve things by 
hand.  Considering that the generally perceived wisdom is that gcc 
doesn't do 8-bit targets well and certainly not accumulator-based 
architectures we get pretty surprising results.

> While it is certainly possible to emit code for some 8-bit microcontrollers,
> I'd argue that it isn't worth the trouble.  The quality of code you get is
> so bad that you would be better off writing in assembly language.  Also, you
> have to take so many liberties with the C standard that you really aren't
> writing C code anymore.
Actually we've got to the stage now where we're actually going the other 
way - hand crafted assembler routines have been discarded because 
ip2k-gcc actually does a better job overall using C code (it never tires 
of spotting common subexpressions that even really good assembler 
programmers often miss and it tends to spot reuse opportunities at 
greater distances).

FWIW I don't see many liberties being taken in our codebase and we have 
customers building things like 802.11b, Bluetooth and HomePlug access 
points as well as an awful lot of embedded device apps - most of the OS, 
the entire IP stack, switching code, configuration interfaces, etc, are 
all written in C - typically 90%+ of the code (by lines of code - 
probably about 95% by object code size).  I randomly pick C files out of 
our codebase every few weeks and build them  for an i386, an ARM or an 
Alpha - this tends to keep things pretty honest :-)

gcc does have some weaknesses for supporting 8-bit targets.  One of the 
more notable is that it has a fondness for performing some very 
irritating integer promotions and then not having the decency to notice 
that it's not using the upper 8 bits of the 16 it's just created, but 
most of these can be eliminated via constant propagation.  It's also a 
little irritating with the way it wants to use more registers than it 
needs to but then that's generic and effects all of the ports AFAIK.


Regards,
Dave