Re: Scoping effort needed to support new CPU

[Ian Lance Taylor <iant at google dot com>]

Omar <gcc.omar@gmail.com> writes:

> 1- How long will it take to port GCC to the new CPU. I know this is
> question depend on many aspects, but just want to get a rough
> estimate. Lets assume the CPU is a 16-bit RISC with a limited
> instruction set, and that the person doing the port have experience
> doing so. How will this estimate change with if the person doing the
> port do not have any experience?

I'm sure you can understand that this question is impossible to answer
precisely.  If the CPU has no unusual features--in my reasonably
lengthy experience with doing gcc ports I have yet to see such a
case--then I could do the CPU port in a few weeks.  Generally an
assembler and linker port is required as well, which adds another week
or two.  At Cygnus Solutions we used to estimate three months for a
complete port: gcc, gas, ld, gdb.  That was usually reasonably
accurate in practice, but that was experienced and expert programmers
working in an organization with many experts they could ask about any
question.

If you don't have any experience with gcc then it's really going to
boil down to how good a programmer you are, how fast you are at
absorbing all the gcc documentation, and how well you are able to
distinguish between the ugliness that is gcc and the ugliness that is
your port.  Fortunately there are lots of existing ports to serve as
examples.

I should add that there are several organizations which you can hire
to do the port.  This will cost more money and take less time.  For
example, Specifix and CodeSourcery.


> 2- Are there any specific instructions that will make the port easier,
> and/or help with the code density? We are quite early in the
> development cycle, so we can add support to instructions that will
> make it easier to GCC achieve our goals.

It's hard to give general answers, because there are tradeoffs.  You
can get higher code density with more powerful instructions, but then
you need a higher gate count.  Similarly variable length instruction
encoding can give higher density, but that too requires more hardware.

Some simple things to remember are: 1) make sure you have instructions
to branch to an address in a register and call an address in a
register; 2) think about the stack frame layout and make sure you can
access stack variables efficiently; 3) think about register save and
restore and how to make that efficient; 4) in general, the more
orthogonal the instruction set, the better code you will get from
gcc--resist the urge to have special purpose registers, or
instructions which only work with specific registers; 5) the more
registers you have, the better your code will be, but of course that
affects your instruction density; 6) you can often save silicon by not
having a divide instruction, though of course some programs will run
slower; other than that, you will want an instruction for each basic C
operator; 7) if you have floating point support at all, it's OK to
make the floating point registers and the general registers disjoint
sets; 8) make the register size be the same as the pointer size, or
you are in for world of pain; 9) delayed branches are always tempting
but will make the generated code less dense; 10) if speed matters at
all, you always need a bigger instruction cache--make it as big as
possible.


> 3- Any other issues that you think we should consider?
>  3.1- For example, I am estimating that after the initial port, we
> will need to allocate 1 moth worth of effort each year to maintain
> this port (mainly to up-rev to newer GCC versions). Is this a sensible
> number?

Yes, assuming you track the gcc mailing lists so that you are aware of
the issues which are coming up.

In general you've got a tradeoff of money and time.  Hiring experts
will cost more and take less time.


Finally, sorry to be a downer, but almost all new processor companies
fail.  Why not just use an ARM core?

Ian