Related articles |
---|
What does it take to create a GCC machine description for a new proces jgeer@agere.com (Joris van der Geer) (2001-03-22) |
Re: What does it take to create a GCC machine description for a new sunni@speakeasy.net (Shankar Unni) (2001-03-26) |
From: | Shankar Unni <sunni@speakeasy.net> |
Newsgroups: | comp.compilers |
Date: | 26 Mar 2001 13:51:44 -0500 |
Organization: | Posted via Supernews, http://www.supernews.com |
References: | 01-03-101 |
Keywords: | GCC, practice |
Posted-Date: | 26 Mar 2001 13:51:43 EST |
Joris van der Geer wrote:
> I am assessing what it would take (time) to create a machine
> description for GCC for a new processor. It should deliver reasonably
> efficient code.
> [Depends on how similar it is to an existing description. -John]
Indeed. It all depends on:
* Your familiarity with code-generation concepts as a whole,
table-driven code-generation more specifically, and GCC code generation
most specifically.
* The similarity of your architecture to some existing architecture that
GCC supports.
In my case, I was doing a GCC port for a chip we were working on at a
previous employer of mine, that was based on a MIPS core, with several
DSP extensions.
I was familiar with MIPS code generation, and generally familiar with
table-driven code generation, and only slightly familiar with GCC's
backend.
The initial port took me a week (mostly getting familiar with the GCC
backend - just had to add some instruction templates for the new
instructions), and it generated just plain old MIPS-2 code unless I
used inline assembly to access those new ops.
Generating code from standard C constructs that took advantage of the
new DSP instructions in a fully optimizable fashion took a *LOT* more
time (I was still hacking away 6 months later, trying to, e.g., inline
strcmp using some of those 8-bytes-in-a-longword ops, when I left the
company). In addition, I had to change the BFD backend around to
generate a new object file format loosely based on COFF
(Win32+extensions), and *that* took time, too..
If you're just doing a "generic RISC processor" backend, for an
architecture which is reasonably orthogonal and looks much like the
common RISC processors of today, but is not based on any of them, I'd
give it a ball-park estimate of 1 month of work before it's polished
enough to generate code for a simple C test suite. And several months
before the code is efficient enough for your liking (depends on your
threshold of pain and pickiness..)
--
Shankar Unni sunni@speakeasy.net
Return to the
comp.compilers page.
Search the
comp.compilers archives again.