J�rgen Veith wrote:
> Recently I browsed through some Alteras Nios II documents. That CPU seems to
> have own instruction set depending from the size version. Further custom
> instructions are possible to implement. 
> 

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.

> There are hints for all kind of developement toos including debuggers but 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. 
> 

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.

> As long as soft core processors have own instructions sets, that requieres
> own code generators and special code optimizers in any compiler. 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. 
> 

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.

> If there is competition with more than one commercial compiler for one
> architecture, the decision is either project history based or the compiler
> with the better code size : runtime performance prevails. 
> 

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.

> Any experience with soft core compiler performance? Are soft cores a
> chicken-egg problem ?
> 

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.

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--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
HTTP://GCC.GNU.org/install/specific.html 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) (
WWW.Altera.com/products/software/products/nios2/emb-nios2_ide.html#editor_c=
ompiler
)
and the .C/OS-II real-time operating system (
WWW.Altera.com/products/devkits/altera/kit-nios_1S40.html#sw
).

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 <walter@bytecraft.com> 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 ( WWW.Retarget.com ) 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.

--0-1287521523-1138990164=:64161--

"J&#4294967295;rgen Veith" <janvi@t-online.de> wrote in message 
news:43e327fd$0$509$9b4e6d93@newsread4.arcor-online.net...
> Recently I browsed through some Alteras Nios II documents. That CPU seems to
> have own instruction set depending from the size version. Further custom
> instructions are possible to implement.
>
> There are hints for all kind of developement toos including debuggers but 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.


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


> As long as soft core processors have own instructions sets, that requieres
> own code generators and special code optimizers in any compiler. 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.
>
> If there is competition with more than one commercial compiler for one
> architecture, the decision is either project history based or the compiler
> with the better code size : runtime performance prevails.
>
> Any experience with soft core compiler performance? Are soft cores a
> chicken-egg problem ?

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
www.nialstewartdevelopments.co.uk

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:

> As long as soft core processors have own instructions sets, that requieres
> own code generators and special code optimizers in any compiler. 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.
>
> If there is competition with more than one commercial compiler for one
> architecture, the decision is either project history based or the compiler
> with the better code size : runtime performance prevails.
>
> Any experience with soft core compiler performance? Are soft cores a
> chicken-egg problem ?

Recently I browsed through some Alteras Nios II documents. That CPU seems to
have own instruction set depending from the size version. Further custom
instructions are possible to implement. 

There are hints for all kind of developement toos including debuggers but 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. 

As long as soft core processors have own instructions sets, that requieres
own code generators and special code optimizers in any compiler. 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. 

If there is competition with more than one commercial compiler for one
architecture, the decision is either project history based or the compiler
with the better code size : runtime performance prevails. 

Any experience with soft core compiler performance? Are soft cores a
chicken-egg problem ?