New GCC ports?

New GCC ports?

[Michael P. Hayes]

In my spare time I have ported GCC (binutils and GDB) to the Texas
Instruments TMS320C3x and TMS320C4x Digital Signal Processors.
Currently my port patches against GCC-2.7.2.2 and is starting to
produce excellent code within the limitations of GCC.  I would like to
have my efforts included into the general GCC release but am unsure
which of the GCC development trees is the most suitable for new ports,
egcs or gcc2?


FYI, the C[34]x architecture has the following salient features:

--the minimum addressable unit is 32-bits so sizeof(char) = sizeof(short) =
  sizeof(int) = sizeof(long) = sizeof(float) = 1.
--three stage instruction pipeline
--delayed branches have three delay slots
--parallel instructions for simultaneous multiply/add, arithmetic/load/store
  operations
--bit reversed and modulo N addressing
--suuport for zero overhead looping
--pre/post increment/decrement addressing modes using an index register for
  the increment/decrement.

The 32-bit bytes required a litle bit of hackery to the GCC modes.
This was more of a problem with the binutils.  Other architectures,
such as the AMD 21xx, require 16-bit bytes so there is room for generalisation.

Having three delay slots exposed many bugs in the 2.7.2.2 version of reorg.c.
Does the new version solve many of the existing problems?

One of the areas of difficulty I found was the handling of the CC.  I
did not want to use cc0 since I wanted insns scheduled between setting
and testing of the CC.  However, the C[34]x sets the CC with many
instructions unlike the other RISC processors that don't use cc0.
Thus many of the C[34]x patterns require clobbers of the CC within a
parallel construct---this has exposed some subtle bugs in the GCC
core.  The setting of the CC is also complicated by the fact that it
is register dependent.  Thus a large number of patterns are required
for each instruction to handle clobbering of the CC.

Another problem area was handling shift instructions.  The C[34]x has
two shift instructions: ASH and LSH.  With a positive shift count they
shift to the left; with a negative shift count they shift to the
right.  This does not map well on to the GCC operators, ashift,
lshiftrt, and ashiftrt.  The best way I found to handle this problem
was to introduce an additional operator lshiftlft.  However, I'm not
fully happy with this approach and wouldn't mind some suggestions how
to handle this.

Extensions to GCC I would like to see would be support for scheduling
parallel instructions (this would require an unroll of loops so that
the operands were available), support for repeating blocks of code (I
had to bolt this on, praying that some of the GCC optimization passes
wouldn't move things around too much---I believe the port for the AMD
SHARC does something similar.  Something like UNSPEC_FIXED would be
useful here to say that the insn is not to be moved around, like
UNSPEC_VOLATILE but without the volatile connotations.), and support
for pre/post inc/decrement addressing with a register increment, rather
than the size of the mode.

Michael.

Re: Results for haifa-disabled egcs-970828 g++ testsuite on sparc-sun-solaris2.5

[Alexandre Oliva]

Joern Rennecke writes:

>> Very odd.  Alexandre is not getting any unexpected failures.
>> My setup, built from the top with just "make", using the
>> 970825 snapshot to build gcc and then that gcc to build cc1plus,
>> does get failures for the g++ tests on sparc-sun-solaris2.5.

> One thing to double-check when you are getting no failures is that the
> tests are actually run.  I've seen sometimes configuration errors that
> would result in the tests to be only compiled, so no execute failures
> could be detected.

The tests that have failed are compile-time ones, and I can assure
that my configuration does run tests.

Another possible difference is that I have built gcc with `make
bootstrap' (stage1 was compiled with gcc 2.7.2.2), then built the rest
of the package (including libg++) with make all at the top-level.
Then I installed the whole package with `make install' and tested it
manually, by running runtest (from dejagnu-970707) with a command line
such as:

runtest --tool g++ --srcdir=$egcsroot/gcc/testsuite \
GXX_UNDER_TEST=$egcsinstall/bin/gcc CXXFLAGS="-g -O"

I don't remember having got any of those errors with egcs-970825 (when
I finally set things up to produce a decent report, egcs-970828 was
released :-)

My site.exp file contained just:

set tmpdir /some/directory

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: New GCC ports?

[Jeffrey A Law]

  In message <199709010515.RAA23357@ongaonga.chch.cri.nz>you write:
  > meissner@cygnus.com writes:
  >  > 
  >  > | --three stage instruction pipeline
  >  > | --delayed branches have three delay slots
  >  > | --parallel instructions for simultaneous multiply/add, arithmetic/load/
  > store
  >  > |   operations
  >  > 
  >  > Might be able to be done via scheduling and peepholes.
  > I have had limited success with peepholes.  Ideally I would like to be
  > able to optimize tight loops for such things such as the dot-product.
  > However, to utilise the C30/C40 parallel multiply and add
  > instructions, the first multiplication has to be precomputed outside
  > the loop so that the result is available for the first loop addition. 
One approach that I've had success with in the past was to use reorg
to combine multiple unrelated insns into a PARALLEL instead of into
a SEQUENCE.

That was _far_ more effective than sched + peepholes.  I can probably
dig some of that code out if you want to beat on it a little.  In theory,
one could completely replace the current peephole mechanism with it.

  > The C30/C40 repeat block instruction needs to be emitted at the top of the
  > loop, but effectively operates at the end of the loop when the
  > PC matches the contents of the loop end register.  The loop cannot
  > have calls or jumps across the loop boundary.  I can't see a clean way
  > of implementing this in the machine description.
This is something we need to implement -- more and more processors
have these kinds of instructions.
Jeff

Re: New GCC ports?

[Michael P. Hayes]

meissner@cygnus.com writes:
 > 
 > | --three stage instruction pipeline
 > | --delayed branches have three delay slots
 > | --parallel instructions for simultaneous multiply/add, arithmetic/load/store
 > |   operations
 > 
 > Might be able to be done via scheduling and peepholes.
I have had limited success with peepholes.  Ideally I would like to be
able to optimize tight loops for such things such as the dot-product.
However, to utilise the C30/C40 parallel multiply and add
instructions, the first multiplication has to be precomputed outside
the loop so that the result is available for the first loop addition. 



 > | --bit reversed and modulo N addressing
 > | --suuport for zero overhead looping
 > 
 > 
 > | Extensions to GCC I would like to see would be support for scheduling
 > | parallel instructions (this would require an unroll of loops so that
 > | the operands were available), support for repeating blocks of code (I
 > | had to bolt this on, praying that some of the GCC optimization passes
 > | wouldn't move things around too much---I believe the port for the AMD
 > | SHARC does something similar.  Something like UNSPEC_FIXED would be
 > | useful here to say that the insn is not to be moved around, like
 > | UNSPEC_VOLATILE but without the volatile connotations.), and support
 > | for pre/post inc/decrement addressing with a register increment, rather
 > | than the size of the mode.
 > | 
 > 
 > In egcs, you need to define an insn decrement_and_branch_on_count and/or
 > decrement_and_branch_until_zero (depending on haifa/non haifa scheduler) and
 > maybe a phony hardware register to keep the count in to get zero trip loops.


The C30/C40 repeat block instruction needs to be emitted at the top of the
loop, but effectively operates at the end of the loop when the
PC matches the contents of the loop end register.  The loop cannot
have calls or jumps across the loop boundary.  I can't see a clean way
of implementing this in the machine description.

Re: New GCC ports?

[Jim Wilson]

	| --the minimum addressable unit is 32-bits so sizeof(char) = sizeof(short) =
	|   sizeof(int) = sizeof(long) = sizeof(float) = 1.

	Ouch.  Though, if you wanted/needed more traditional sizes, you might look at
	the Alpha port (until the newest generation, Alphas could only do 32/64 bit
	memory references).

The alpha however is still byte addressable, and that is a very important
distinction.  On a word addressable machine, having an 8 bit character
means that pointers must be two words, one word to hold an address, and
one word to hold the offset within a word.  This is a much more difficult
problem than simply lacking 8byte load/store problems.  Looking at the
alpha port isn't going to help here.

Jim

Re: New GCC ports?

[meissner]

| In my spare time I have ported GCC (binutils and GDB) to the Texas
| Instruments TMS320C3x and TMS320C4x Digital Signal Processors.
| Currently my port patches against GCC-2.7.2.2 and is starting to
| produce excellent code within the limitations of GCC.  I would like to
| have my efforts included into the general GCC release but am unsure
| which of the GCC development trees is the most suitable for new ports,
| egcs or gcc2?

Given gcc2 is trying to be stable and make a release right now, probably egcs
would be more to your liking, especially if machine independent changes are
needed.
| 
| FYI, the C[34]x architecture has the following salient features:
| 
| --the minimum addressable unit is 32-bits so sizeof(char) = sizeof(short) =
|   sizeof(int) = sizeof(long) = sizeof(float) = 1.

Ouch.  Though, if you wanted/needed more traditional sizes, you might look at
the Alpha port (until the newest generation, Alphas could only do 32/64 bit
memory references).

| --three stage instruction pipeline
| --delayed branches have three delay slots
| --parallel instructions for simultaneous multiply/add, arithmetic/load/store
|   operations

Might be able to be done via scheduling and peepholes.

| --bit reversed and modulo N addressing
| --suuport for zero overhead looping

The haifa scheduler has improvements in this area.

| --pre/post increment/decrement addressing modes using an index register for
|   the increment/decrement.

Look at the rs6000 machine description, starting with movdi_update1 (in
egcs/gcc2 recent releases).

| The 32-bit bytes required a litle bit of hackery to the GCC modes.
| This was more of a problem with the binutils.  Other architectures,
| such as the AMD 21xx, require 16-bit bytes so there is room for generalisation.
| 
| Having three delay slots exposed many bugs in the 2.7.2.2 version of reorg.c.
| Does the new version solve many of the existing problems?

There haven't been that many changes to reorg.

	...

| Extensions to GCC I would like to see would be support for scheduling
| parallel instructions (this would require an unroll of loops so that
| the operands were available), support for repeating blocks of code (I
| had to bolt this on, praying that some of the GCC optimization passes
| wouldn't move things around too much---I believe the port for the AMD
| SHARC does something similar.  Something like UNSPEC_FIXED would be
| useful here to say that the insn is not to be moved around, like
| UNSPEC_VOLATILE but without the volatile connotations.), and support
| for pre/post inc/decrement addressing with a register increment, rather
| than the size of the mode.
| 

In egcs, you need to define an insn decrement_and_branch_on_count and/or
decrement_and_branch_until_zero (depending on haifa/non haifa scheduler) and
maybe a phony hardware register to keep the count in to get zero trip loops.

Pre/post inc/decrement is already there if you write the patterns the way
combine tries them.

Re: New GCC ports?

[Joern Rennecke]

> In my spare time I have ported GCC (binutils and GDB) to the Texas
> Instruments TMS320C3x and TMS320C4x Digital Signal Processors.
> Currently my port patches against GCC-2.7.2.2 and is starting to
> produce excellent code within the limitations of GCC.  I would like to
> have my efforts included into the general GCC release but am unsure
> which of the GCC development trees is the most suitable for new ports,
> egcs or gcc2?

It is suitable for egcs if it is well written.  To be suitable for gcc2
in the short term, you have to be able to fit it in without possibly
destabilizing changes to the machine-independent files.  Your description
sounds like your current work does not fit the latter requirement.

Either way, you have to present a convincing reason for every change to
machine-independent files.  Convincing means enough to convince the
respective maintainer.
But for gcc2, you might have to wait for the gcc 2.8.x release process to
pass for some kinds of changes to be even considered.

> Another problem area was handling shift instructions.  The C[34]x has
> two shift instructions: ASH and LSH.  With a positive shift count they
> shift to the left; with a negative shift count they shift to the
> right.  This does not map well on to the GCC operators, ashift,
> lshiftrt, and ashiftrt.  The best way I found to handle this problem
> was to introduce an additional operator lshiftlft.  However, I'm not
> fully happy with this approach and wouldn't mind some suggestions how
> to handle this.

The SH3 has a dynamical shift instruction just like this.  Look in sh.md
and sh.c for TARGET_SH3 to have a look how this is handled.  It doesn't
need a new operator to support this.