gcc support of mips32 release 2

gcc support of mips32 release 2

[Long Li]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 638 bytes --]

Hi, Guys,

I have a question about gcc support for mips32 release
2. I noticed that in gnu as(assembler) 2.14, there is
an option for it, but does newest gcc version support
mips32 release 2? I did not find it in the mips.c or
configure file. 

Seems to me, this mips32 release 2 is an extension of
mips32, added some new instructions, eg. EHB, etc. So
would it be necessary that gcc be updated, like what
gnu as has done, in the future to reflect this
extension?

Thanks a lot! I really appreciate it.


Long


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: gcc support of mips32 release 2

[Eric Christopher]

> Seems to me, this mips32 release 2 is an extension of
> mips32, added some new instructions, eg. EHB, etc. So
> would it be necessary that gcc be updated, like what
> gnu as has done, in the future to reflect this
> extension?

It will be in the soon to be released 3.4. Contributed by Chris
Demetriou of Broadcom.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc support of mips32 release 2

[Dominic Sweetman]

> > Seems to me, this mips32 release 2 is an extension of
> > mips32, added some new instructions, eg. EHB, etc. So
> > would it be necessary that gcc be updated, like what
> > gnu as has done, in the future to reflect this
> > extension?
> 
> It will be in the soon to be released 3.4. Contributed by Chris
> Demetriou of Broadcom.

We added patterns to let our (old) GCC use the new rotates and
bit-insert/extracts, at least in simple cases.  I'm not sure whether
we've put those in our 3.4 evolution tree yet, but if we have we
should push those out.

--
Dominic Sweetman
MIPS Technologies.

Re: gcc support of mips32 release 2

[Dominic Sweetman]

> > Seems to me, this mips32 release 2 is an extension of
> > mips32, added some new instructions, eg. EHB, etc. So
> > would it be necessary that gcc be updated, like what
> > gnu as has done, in the future to reflect this
> > extension?
> 
> It will be in the soon to be released 3.4. Contributed by Chris
> Demetriou of Broadcom.

We added patterns to let our (old) GCC use the new rotates and
bit-insert/extracts, at least in simple cases.  I'm not sure whether
we've put those in our 3.4 evolution tree yet, but if we have we
should push those out.

--
Dominic Sweetman
MIPS Technologies.

Re: gcc support of mips32 release 2

[Long Li]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 914 bytes --]

Thanks for the email. Could you give me a link to your
3.4 evolution tree?

Thanks,


Long

--- Dominic Sweetman <dom@mips.com> wrote:
> 
> > > Seems to me, this mips32 release 2 is an
> extension of
> > > mips32, added some new instructions, eg. EHB,
> etc. So
> > > would it be necessary that gcc be updated, like
> what
> > > gnu as has done, in the future to reflect this
> > > extension?
> > 
> > It will be in the soon to be released 3.4.
> Contributed by Chris
> > Demetriou of Broadcom.
> 
> We added patterns to let our (old) GCC use the new
> rotates and
> bit-insert/extracts, at least in simple cases.  I'm
> not sure whether
> we've put those in our 3.4 evolution tree yet, but
> if we have we
> should push those out.
> 
> --
> Dominic Sweetman
> MIPS Technologies.
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: gcc support of mips32 release 2

[Dominic Sweetman]

I wrote:

> > We added patterns to let our (old) GCC use the new rotates and
> > bit-insert/extracts, at least in simple cases.  I'm not sure whether
> > we've put those in our 3.4 evolution tree yet, but if we have we
> > should push those out.

Long Li (long21st@yahoo.com) replied:

> Thanks for the email. Could you give me a link to your
> 3.4 evolution tree?

Interesting.  It's not as simple as I'd like: our 3.4 work is not yet
published, and I'm pretty sure it includes support for hardware etc we
haven't generally released details of yet.

Nigel (our main gcc expert) is on vacation this week.  In his absence,
David: do you know whether the rotate/insert stuff is in 3.4 yet?

--
Dominic

Re: gcc support of mips32 release 2

[David Ung]

On Mon, 2004-03-08 at 11:11, Dominic Sweetman wrote:
> I wrote:
> 
> > > We added patterns to let our (old) GCC use the new rotates and
> > > bit-insert/extracts, at least in simple cases.  I'm not sure whether
> > > we've put those in our 3.4 evolution tree yet, but if we have we
> > > should push those out.
> 
> Long Li (long21st@yahoo.com) replied:
> 
> > Thanks for the email. Could you give me a link to your
> > 3.4 evolution tree?
> 
> Interesting.  It's not as simple as I'd like: our 3.4 work is not yet
> published, and I'm pretty sure it includes support for hardware etc we
> haven't generally released details of yet.
> 
> Nigel (our main gcc expert) is on vacation this week.  In his absence,
> David: do you know whether the rotate/insert stuff is in 3.4 yet?
> 

No, it is not part of the our 3.4 extension yet, but it is part of SDE.
I think the support for rotates already exists in the 3.4 mainline.

David.

Re: gcc support of mips32 release 2

[Eric Christopher]

> 
> No, it is not part of the our 3.4 extension yet, but it is part of SDE.
> I think the support for rotates already exists in the 3.4 mainline.

Yes. It was part of Chris's work.

-eric

-- 
Eric Christopher <echristo@redhat.com>

Re: gcc support of mips32 release 2

[Maciej W. Rozycki]

On Fri, 5 Mar 2004, Dominic Sweetman wrote:

> We added patterns to let our (old) GCC use the new rotates and
> bit-insert/extracts, at least in simple cases.  I'm not sure whether
> we've put those in our 3.4 evolution tree yet, but if we have we
> should push those out.

 As a side note, it makes me wonder where the borderline of the RISC
actually is.  Even Intel abandoned support for bit insert/extract
instructions after an initial attempt for the i386.  They figured out the
implementation was too complicated. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc support of mips32 release 2

[Dominic Sweetman]

Maciej W. Rozycki (macro@ds2.pg.gda.pl) writes:
> 
> > We added patterns to let our (old) GCC use the new rotates and
> > bit-insert/extracts, at least in simple cases.  I'm not sure whether
> > we've put those in our 3.4 evolution tree yet, but if we have we
> > should push those out.
> 
>  As a side note, it makes me wonder where the borderline of the RISC
> actually is.  Even Intel abandoned support for bit insert/extract
> instructions after an initial attempt for the i386.  They figured out the
> implementation was too complicated. ;-)

It probably was... but MIPS uses register-to-register ALU operations
and no condition codes.  The interface to the ALU is typically rather
simple.  So adding some peculiar new 2- or 3-operand computation is
relatively easy.

If the instruction is too complicated, of course, it might eventually
become a critical path and make the whole CPU slower.  But
insert/extract - while elaborate to describe - involve only fairly
shallow logic.

Remember: the point of RISC was never to have less instructions
(that's just a cute acronym) - the point was and is to define an
instruction set which is easy to implement as an efficient pipeline.

Of course, instructions still have to be *useful* to be added.
Insert/extract make a reasonable case for themselves, but actually
arrived in MIPS32 release 2 as part of a bunch of other bit-shuffle
instructions (also includes rotates and various byte-swaps) which -
together - help quite a bit to manipulate sub-word data in registers.

--
Dominic Sweetman
MIPS Technologies

Re: gcc support of mips32 release 2

[Michael Uhler]

Dominic already gave the long explanation.

When we added field insert and extract, we were very sensitive to the
implementability of the instructions.  If you look at the semantic
definition, independent of the somewhat complex explanation, you'll
find that both insert and extract can be implemented with a
left or right shift, followed by a mux-per-bit which selects between
the shifted operand or the unshifted operand.  That can be done
very efficiently in hardware.

/gmu

On Thu, 2004-03-18 at 05:18, Maciej W. Rozycki wrote:
> On Fri, 5 Mar 2004, Dominic Sweetman wrote:
> 
> > We added patterns to let our (old) GCC use the new rotates and
> > bit-insert/extracts, at least in simple cases.  I'm not sure whether
> > we've put those in our 3.4 evolution tree yet, but if we have we
> > should push those out.
> 
>  As a side note, it makes me wonder where the borderline of the RISC
> actually is.  Even Intel abandoned support for bit insert/extract
> instructions after an initial attempt for the i386.  They figured out the
> implementation was too complicated. ;-)
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 
-- 
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.  Email: uhler@mips.com
1225 Charleston Road     Voice:  (650)567-5025  FAX:   (650)567-5225
Mountain View, CA 94043  Mobile: (650)868-6870  Admin: (650)567-5085

Re: gcc support of mips32 release 2

[Ralf Baechle]

On Thu, Mar 18, 2004 at 02:10:35PM +0000, Dominic Sweetman wrote:

> Of course, instructions still have to be *useful* to be added.
> Insert/extract make a reasonable case for themselves, but actually
> arrived in MIPS32 release 2 as part of a bunch of other bit-shuffle
> instructions (also includes rotates and various byte-swaps) which -
> together - help quite a bit to manipulate sub-word data in registers.

And in some case where MIPS such as certain crypto algorithms where MIPS
and RISCs used to look rather pale the new instructions will help
significantly.

  Ralf

Re: gcc support of mips32 release 2

[Ralf Baechle]

On Thu, Mar 18, 2004 at 02:18:01PM +0100, Maciej W. Rozycki wrote:

>  As a side note, it makes me wonder where the borderline of the RISC
> actually is.  Even Intel abandoned support for bit insert/extract
> instructions after an initial attempt for the i386.  They figured out the
> implementation was too complicated. ;-)

Take a look at the 68020 to see where instruction set madness can lead:

	movel	([42, a0, d0.2*2],123), ([43, a0, d0.2*2], 22)
	bfextu	([42, a0, d0.2*2],123){8:8}, d2

And I haven't even started bitching about CALLM's bloat over jsr on a
system with MMU disabled or the fantastic complexities it offers with
all gadgets enabled.  Probably desigend for MACH but in the end just
useless no known OS used them and Moto removed them again for the 030.

  Ralf

Re: gcc support of mips32 release 2

[Geert Uytterhoeven]

On Thu, 18 Mar 2004, Ralf Baechle wrote:
> On Thu, Mar 18, 2004 at 02:18:01PM +0100, Maciej W. Rozycki wrote:
> >  As a side note, it makes me wonder where the borderline of the RISC
> > actually is.  Even Intel abandoned support for bit insert/extract
> > instructions after an initial attempt for the i386.  They figured out the
> > implementation was too complicated. ;-)
>
> Take a look at the 68020 to see where instruction set madness can lead:
>
> 	movel	([42, a0, d0.2*2],123), ([43, a0, d0.2*2], 22)
> 	bfextu	([42, a0, d0.2*2],123){8:8}, d2

These instructions didn't complete in 1 cycle, while the new RISCies do.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: gcc support of mips32 release 2

[Ralf Baechle]

On Fri, Mar 19, 2004 at 11:42:11AM +0100, Geert Uytterhoeven wrote:

> > Take a look at the 68020 to see where instruction set madness can lead:
> >
> > 	movel	([42, a0, d0.2*2],123), ([43, a0, d0.2*2], 22)
> > 	bfextu	([42, a0, d0.2*2],123){8:8}, d2
> 
> These instructions didn't complete in 1 cycle, while the new RISCies do.

That's the point, they went overboard with their C^2ISC philosophy.  These
instructions were more or less unusable by compilers of the time and the
given the rarity were not the most performant instructions of the
architecture either, so made sense only relativly rarely.  So in the end
the didn't get it right in the beginning which lead to the removal of the
instruction in 060, if I recall right.

  Ralf

Re: gcc support of mips32 release 2

[Maciej W. Rozycki]

On Thu, 18 Mar 2004, Dominic Sweetman wrote:

> >  As a side note, it makes me wonder where the borderline of the RISC
> > actually is.  Even Intel abandoned support for bit insert/extract
> > instructions after an initial attempt for the i386.  They figured out the
> > implementation was too complicated. ;-)
> 
> It probably was... but MIPS uses register-to-register ALU operations
> and no condition codes.  The interface to the ALU is typically rather
> simple.  So adding some peculiar new 2- or 3-operand computation is
> relatively easy.

 Well, I suppose that's not much different for a processor like the i386,
which is already capable to load a source operand or store (or RMW) a
destination one for whatever operation is to be executed by the ALU or
microcoded.  Intel could have taken the baroque (or rococo?) approach as
usual, though, and thus run out of die space. ;-)

> Remember: the point of RISC was never to have less instructions
> (that's just a cute acronym) - the point was and is to define an
> instruction set which is easy to implement as an efficient pipeline.

 Well, the meaning of RISC indeed depends on what you express by "reduced"  
there (i.e. whether it's "small" or "simple").  Historically, the
instruction set used to include about the smallest reasonable set of 
operations needed for efficient programming, with any redundancy offloaded 
to short sequences of simple instructions.  This could have changed, as 
technology evolved, though.

> Of course, instructions still have to be *useful* to be added.

 Well, I suppose so, as long as you set a reasonable threshold on 
usefulness.

> Insert/extract make a reasonable case for themselves, but actually
> arrived in MIPS32 release 2 as part of a bunch of other bit-shuffle
> instructions (also includes rotates and various byte-swaps) which -
> together - help quite a bit to manipulate sub-word data in registers.

 I see.  Actually all of them are a bit redundant, often replaceable with
short sequences of other instructions, but I guess code compacting may
matter more for the embedded environment than for general-purpose
computing.

 And while we are at instruction usefulness -- why are there the "di" and
"ei" instructions, but there is no a complement instruction, say "si" (for
"set interrupts"), that would copy bit #0 from a GPR to cp0.status.ie
compactly and atomically?

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc support of mips32 release 2

[Maciej W. Rozycki]

On Thu, 18 Mar 2004, Ralf Baechle wrote:

> Take a look at the 68020 to see where instruction set madness can lead:
> 
> 	movel	([42, a0, d0.2*2],123), ([43, a0, d0.2*2], 22)
> 	bfextu	([42, a0, d0.2*2],123){8:8}, d2
> 
> And I haven't even started bitching about CALLM's bloat over jsr on a
> system with MMU disabled or the fantastic complexities it offers with
> all gadgets enabled.  Probably desigend for MACH but in the end just
> useless no known OS used them and Moto removed them again for the 030.

 But m68k isn't exactly RISC and high code density was a priority over
microcode simplicty (or absence) for the architecture.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc support of mips32 release 2

[Dominic Sweetman]

Maciej

> > Insert/extract make a reasonable case for themselves, but actually
> > arrived in MIPS32 release 2 as part of a bunch of other bit-shuffle
> > instructions (also includes rotates and various byte-swaps) which -
> > together - help quite a bit to manipulate sub-word data in registers.
> 
>  I see.  Actually all of them are a bit redundant, often replaceable with
> short sequences of other instructions, but I guess code compacting may
> matter more for the embedded environment than for general-purpose
> computing.

When we relied on things like Specmarks for benchmarks, those are
mostly general purpose C programs.  They tend to be intricate
programs, not dominated by repetitive handling of large-scale data
(the floating point benchmarks *are* data-intensive, which is why 
architectural strangeness is much more successful on those).

Moreover, Specmarks have a strong tendency to use 'int' data types;
sub-word data handling is essentially irrelevant to performance on
them.  RISCs are good at the fiddly stuff (at least, well-designed
RISCs are) and happy with the int data types: so the Specmarks are
relatively good and we're happy.

But an important sub-class of embedded workloads are data intensive,
where the data represents some sort of stream.  Basic data items are
often 8- or 16-bits in size.  Existing RISC instruction sets end up
bloating the inner loops of these programs, and it's marginal
performance gains rather than code size which motivates us to make
this work better.

>  And while we are at instruction usefulness -- why are there the "di" and
> "ei" instructions, but there is no a complement instruction, say "si" (for
> "set interrupts"), that would copy bit #0 from a GPR to cp0.status.ie
> compactly and atomically?

The 'di' is there to be atomic.  Such sequences are rare and code
compactness is not an issue.  As you probably heard before, the use of
a potentially-interruptible RMW sequence on the status register to
disable interrupts is potentially troublesome (most common OS' manage
themselves so it isn't an issue, but still...)

The 'ei' comes for free with it.

In encoding terms, di/ei can be seen to be individual members of a
generic instruction whose action is something like "atomically
set/clear bit in a CP0 register".  But CP0 registers are low-level
things, whose bits have real hardware functions; so implementing the
bit-set/bit-clear is not the same in all cases.  So we've defined
this instruction minimally, only or critical bits.

--
Dominic

Re: gcc support of mips32 release 2

[Maciej W. Rozycki]

Dominic,

> But an important sub-class of embedded workloads are data intensive,
> where the data represents some sort of stream.  Basic data items are
> often 8- or 16-bits in size.  Existing RISC instruction sets end up
> bloating the inner loops of these programs, and it's marginal
> performance gains rather than code size which motivates us to make
> this work better.

 I see.  Though the associated code compaction reduces cache footprint
which improves performance as well.

> The 'di' is there to be atomic.  Such sequences are rare and code
> compactness is not an issue.  As you probably heard before, the use of
> a potentially-interruptible RMW sequence on the status register to
> disable interrupts is potentially troublesome (most common OS' manage
> themselves so it isn't an issue, but still...)

 Hmm, is the remaining minority of the OSes, that can't manage the
sequence, important enough to add such an instruction?  The atomicity of
this operation should only matter if interrupt handlers are expected to
leave interrupts disabled upon an exit to the same context -- such a setup
should be pretty rare.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: gcc support of mips32 release 2

[Dominic Sweetman]

Maciej,

> > The 'di' is there to be atomic...
> 
>  Hmm, is the remaining minority of the OSes, that can't manage the
> sequence, important enough to add such an instruction?

Perhaps not.  The case I always suggest is that of a serial port
transmit interrupt handler, which often wants to disable the TxReady
interrupt when it finds there's no more data to send.  There's almost
always a way to do that without changing the SR interrupt mask, of
course... 

--
Dominic

Re: gcc support of mips32 release 2

[Michael Uhler]

The real issue is one of strictly nested interrupts.  The lack of an
atomic di, in particular, works fine as long as all interrupts are
strictly nested in such a way that no interrupt code changes the
state of the IM bits between the read and write of the sequence.
While most operating systems appear to be strictly nested, there
are some very important kernels in embedded markets which are not
strictly nested.

When I added di (and, for symmetry, ei) to Release 2, I did so after
spending considerable time talking with these customers and was
convinced that it was important.

/gmu

On Mon, 2004-03-22 at 03:14, Maciej W. Rozycki wrote:

> > The 'di' is there to be atomic.  Such sequences are rare and code
> > compactness is not an issue.  As you probably heard before, the use of
> > a potentially-interruptible RMW sequence on the status register to
> > disable interrupts is potentially troublesome (most common OS' manage
> > themselves so it isn't an issue, but still...)
> 
>  Hmm, is the remaining minority of the OSes, that can't manage the
> sequence, important enough to add such an instruction?  The atomicity of
> this operation should only matter if interrupt handlers are expected to
> leave interrupts disabled upon an exit to the same context -- such a setup
> should be pretty rare.

-- 
Michael Uhler, Chief Technology Officer
MIPS Technologies, Inc.  Email: uhler@mips.com
1225 Charleston Road     Voice:  (650)567-5025  FAX:   (650)567-5225
Mountain View, CA 94043  Mobile: (650)868-6870  Admin: (650)567-5085

Re: gcc support of mips32 release 2

[Goswin von Brederlow]

Ralf Baechle <ralf@linux-mips.org> writes:

> On Fri, Mar 19, 2004 at 11:42:11AM +0100, Geert Uytterhoeven wrote:
> 
> > > Take a look at the 68020 to see where instruction set madness can lead:
> > >
> > > 	movel	([42, a0, d0.2*2],123), ([43, a0, d0.2*2], 22)
> > > 	bfextu	([42, a0, d0.2*2],123){8:8}, d2
> > 
> > These instructions didn't complete in 1 cycle, while the new RISCies do.
> 
> That's the point, they went overboard with their C^2ISC philosophy.  These
> instructions were more or less unusable by compilers of the time and the
> given the rarity were not the most performant instructions of the
> architecture either, so made sense only relativly rarely.  So in the end
> the didn't get it right in the beginning which lead to the removal of the
> instruction in 060, if I recall right.
> 
>   Ralf

Thats a

 move.l 31530(A0, D0*2), 5675(A0, D0*2)  (that would give a bus error)

before assembly right?

That instruction is great to access array or aligned structure members
with an offset and compilers should be able to generate it for it. But
its only realy usefull if your short on registers, which gcc does not
optimize for.

Don't think they got removed. Could it be you are thinking about
mulu.l d0,d0:d1   (32*32=64 bit mul) and the like?

MfG
        Goswin

Re: gcc support of mips32 release 2

[Ralf Baechle]

On Wed, Mar 24, 2004 at 01:38:27PM +0100, Goswin von Brederlow wrote:

>  move.l 31530(A0, D0*2), 5675(A0, D0*2)  (that would give a bus error)
> 
> before assembly right?
> 
> That instruction is great to access array or aligned structure members
> with an offset and compilers should be able to generate it for it. But
> its only realy usefull if your short on registers, which gcc does not
> optimize for.
> 
> Don't think they got removed. Could it be you are thinking about
> mulu.l d0,d0:d1   (32*32=64 bit mul) and the like?

Maybe - my memories of 68k are getting dusty.  In '92 or '93 I had started
my own Linux/68k port but disgusted by the complexity of some parts of the
68k architecture - such as execution timing tables of several pages just
for the move instruction or even shell scripts in case of the 68851 MMU.
Eventually I got my hands on a MIPS box in '94, again for porting Linux
to MIPS as the very first MIPS project I ever did.  Architectures tend to
get ugly when they age, when new features are added and compatibility
issues arrise but for most part I think MIPS has managed to age very
gracefully which I believe in part is one of the benefits of RISC design
principles, so I'm still happy after 10 years of MIPS stuff and feel
little desire to open those Motorola manuals on my shelf :-)

  Ralf

Re: gcc support of mips32 release 2

[Dominic Sweetman]

> ... I think MIPS has managed to age very
> gracefully which I believe in part is one of the benefits of RISC design
> principles, so I'm still happy after 10 years of MIPS stuff

Thanks Ralf, the cheque will be in the post :-)