This is the mail archive of the 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: Does gcc works as a cross compiler to 8031 micro controllers?

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.


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