Compilers for Soft Core Processors (as NIOS II)

Jürgen

This is a very tough problem. Compiler implementation is basically attention to detail and heavily experienced labor intensive. It is also seductive. A 90% solution is

10% of the work involved.

It is a chicken-egg problem in two ways. The obvious problem is no compiler no application, no application development no compiler

The second chicken-egg problem is less obvious. It takes about

200-300 design ins to gain the experience needed to optimize to an new instruction set. This creates a development threshold that is a lot higher than the porting costs to a new architecture.

Having said that there is a lot of work going on in reducing porting costs to get workable initial compilers that can be used to get design in experience.

Wallter Banks Byte Craft

Jürgen Veith wrote:

Jürgen, I'm a hardware engineer so don't really understand the intracies of what's involved with compiler development/optimisation.

With NIOS if the compiler (/core) aren't producing the goods you have the option of implementing cycle intensive operations in hardware.

If you're trying to push your performance to the limits the compiler performance isn't the limiting factor that it previously might have been.

How you identify your bottlenecks is an exercise I can't help you with.

Nial

---------------------------------------------------------- Nial Stewart Developments Ltd Tel: +44 131 561 6291

42/2 Hardengreen Business Park Fax: +44 131 561 6327 Dalkeith, Midlothian EH22 3NU

0-1287521523-1138990164=:64161 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE

J=FCrgen Veith posted:

"[..]

There are hints for all kind of developement toos including debuggers but= =20 I was not able to find a C Compiler. As far as I understand it is intended that designers have to use a free GNU Compiler."

It apparently has a port of GCC (though it is not listed on=20

so it might never have been=20 submitted to the Free Software Foundation, as had also happened with=20 Microchip's PIC files for GCC) ( ompiler ) and the .C/OS-II real-time operating system ( ).

J=FCrgen Veith posted:

"As long as soft core processors have own instructions sets, that=20 requieres own code generators and special code optimizers in any compiler."

Walter Banks posted:

"[..]

The second chicken-egg problem is less obvious. It takes about

200-300 design ins to gain the experience needed to optimize to an new instruction set. This creates a development threshold that is a lot higher than the porting costs to a new architecture. [..]"

Still, good quality code (even if not optimized) can be generated by=20 compilers in phases which are not very dependent on the instruction set.=20 If extensive, instructionset-based optimization is not very important,=20 then products from Target Compiler Technologies (

) may=20 be of interest.

J=FCrgen Veith posted:

"As long as many commercial compilers for off-the-shelf processors produce poor code, one can imagine, that gnu optimization for soft cores will be worster.

[..]"

Yes, and the GNU C compiler reputedly produces acceptable but inferior=20 code for a number of embedded targets.

The instruction set is mostly the same regardless of the version - the differences are mostly in the pipelining implementation of the instructions. However, there are a few instructions that are space-expensive to run quickly (such as multiplication, on FPGAs without multipliers, and barrel shifters) which are omitted on the small versions.

Altera wrote a gcc back-end for the Nios II. This was really the only practical option (Xilinx did exactly the same thing for their Microblaize soft processor), considering Altera's needs. They needed a compiler that they could work with easily while changing the details of the processor - they probably made many modifications to the ISA during implementation and optimisation of the design. This would have made it impractical to work with third-party compiler designers in the traditional manner of processor developers. They wanted to avoid doing

*all* the work - using gcc, they get the front-end and middle parts free, and can base the back-end on something vaguely similar (perhaps ARM?). They also get a compiler that is considered one of the better compilers available (at least since around version 3.1), with a very flexible in-line assembly syntax that would work nicely with user-defined extension instructions.

I don't quite get that. Are you saying that since there are many commercial compilers for standard processors that produce bad code, gcc will therefore inevitably produce worse code and is therefore a poor choice? If so, that's is clearly rubbish. There are many reasons for choosing different compilers (when there is a choice). gcc is sometimes the best choice, sometimes not - but it is seldom (for most targets) a rational decision to exclude gcc solely on the quality of its code.

Commercial compilers are seldom chosen on the basis of their code size and speed, or at least that is seldom the major concern. The differences between the performance levels of good compilers is too small to be a big issue in itself, and squeezing the best out of the compilers is hard work - if you are looking for absolute maximal performance, you will be more concerned with things like the ease of use of the profiling tools than the compiler itself.

That's partly why it makes most sense for the soft core developers to write a gcc back-end rather than trying to get something working with third parties. Once a soft core is mature and popular, it may make sense for third parties to write tools for it, but I'd imagine it's more of a challenge than for traditional tools - soft cores can be a moving target.