Scoping effort needed to support new CPU

Scoping effort needed to support new CPU

[Omar]

Hi,
 My company is looking at the possibility of creating a new CPU core
for an embedded application. The goals for the CPU are (in order of
importance):
  1- High code density
  2- Low power
  3- Small silicon footprint (low gate count)

 We want to have GCC as the compiler, so my main goal here is to have
the GCC community help me to get an idea for the following:
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?
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.
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?

Thanks in advance for your comments!
-Omar

Re: Scoping effort needed to support new CPU

[Ian Lance Taylor]

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

Re: Scoping effort needed to support new CPU

[Omar]

Ian,
 Thanks for for your comments. This is very valuable information.

>  Why not just use an ARM core?
 We have analyzed several cores and have rank them in several categories.
 In our analysis, the ARM scores high in code density, and in
toolchain quality (we call it the the gold standard).
 One of the issues with the ARM core is the gate count is relatively
high (almost 2x that of MSP430 and 4X that of the core we currently
use).

 Currently, we have a in-house-brewed compact CPU architecture that we
have sucessfuly used for a similar application, with the advantage of
very low power, low gate count (1/8 the size of the ARM) and high code
density. The limitation with this CPU is that the instruction set is
limited to the point that is not capable of supporting C. Or plan is
to extend this CPU's instruction set carefully so that the code
output from GCC is highly compact and dense, while keeping in check
the gate count and power dissipation. Execution time is not one of our
top concern for this project, since this CPU core is targetted to run
a highly specialized algorithm.

 Your recommendation of hiring an expert with experience doing GCC
ports is a good idea.  I will like to have an expert come over and
give us a kick-start on how to go about porting GCC, and also our
digital designers will be curious to get a better understanding on
which instructions are more beneficial in terms of code density.

Again, thanks for your valuable comments.

Regards,
-Omar