Re: [Fwd: Current state of MIPS16 support?]

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

On 17th April (yes, I know that's a long time) Johannes wrote:

> I quickly discovered that mips16 support in gcc-2.95 is broken.
> ...
> gcc-3.1 does seem to generate correct code for my tiny
> test programs, but lacks mips16 support routines in
> libgcc.a when configured for target mips-linux.
> ...
> Dominic Sweetman from Algorithmics mentioned in a posting
> to the linux-mips list (http://oss.sgi.com/mips/mail.html)
> that they have numerous patches against an old gcc version.
> Has someone had a look at the Algorithmics gcc, or even
> attempted to incorporate thier patches into gcc-3.x?

I really owe you guys a reply, so I'll go for a cross-post.

Eric replied:

> mips16 support was broken for quite some time. Recently a lot of bug
> fixes have gone into making it quite usable, though fairly unstable...

Sounds fair.

> I have not looked at the Algorithmics code because I don't have
> copyright on it...

We do publish our sources on our web server.  Not only are they GPL
but we have a copyright assignment to the FSF in place (which I know
was sent to Jim Wilson of Cygnus, albeit in 1993...)

We're operating from a baseline which was a Cygnus/RedHat "2.96"
release made to MIPS Technologies in late 2000.  A snapshot from a
contract which had run into some kind of dissension, it had some new
MIPS16 support but it was very buggy (the regular 32-bit MIPS code
generator, too).  It has some nice features, though, like the "Haifa"
scheduler and the DFA extensions to machine descriptions for
superscalar CPUs.

It's true we have not contributed patches lately.  We don't really
have the resouces; our success rate used to be very low, and since
we're not working around the developing 3.x sources the prospects seem
even dimmer.

We're working (with funding from MIPS Technologies) on building a
toolchain which:

o Can build Linux kernel, libraries and applications alike;

o Is substantially more efficient than other GCC versions when
  producing MIPS application ("MIPS/ABI", PIC) code;

o Will produce ugly-but-correct PIC code for MIPS16 functions, so
  MIPS16 can be tested in a standard Linux environment;

o Operates to a known and documented ABI (even the forgotten details,
  like gprof...)

(The modesty of those ambitions should be measured against the reality
of today's Linux/MIPS...)

We should be done in 6 weeks or so.  Our intention is to provide this
port as both source and binary RPMs for free download, and to
encourage its widespread use.

We appreciate it would be great if this work was converged into a
robust 3.x compiler (though the change in C++ code conventions means,
I think, that it will be a long time before such a compiler can be
used by a majority of substantial embedded projects).  We're
canvassing anyone we can think of with the funds or influence to help
make it happen.

It would be even more valuable if we could ensure that MIPS becomes a
"first-class" architecture for the evolving GCC - but the latter
surely is a big commitment for the core GCC group.

It's a pity that the different priorities of various funders and
developers mean that there is no baseline toolkit for Linux/MIPS, so
that such resources as are available are frequently used to re-invent
the wheel.

Anyone got any ideas how to make it better?

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

On 17th April (yes, I know that's a long time) Johannes wrote:

> I quickly discovered that mips16 support in gcc-2.95 is broken.
> ...
> gcc-3.1 does seem to generate correct code for my tiny
> test programs, but lacks mips16 support routines in
> libgcc.a when configured for target mips-linux.
> ...
> Dominic Sweetman from Algorithmics mentioned in a posting
> to the linux-mips list (http://oss.sgi.com/mips/mail.html)
> that they have numerous patches against an old gcc version.
> Has someone had a look at the Algorithmics gcc, or even
> attempted to incorporate thier patches into gcc-3.x?

I really owe you guys a reply, so I'll go for a cross-post.

Eric replied:

> mips16 support was broken for quite some time. Recently a lot of bug
> fixes have gone into making it quite usable, though fairly unstable...

Sounds fair.

> I have not looked at the Algorithmics code because I don't have
> copyright on it...

We do publish our sources on our web server.  Not only are they GPL
but we have a copyright assignment to the FSF in place (which I know
was sent to Jim Wilson of Cygnus, albeit in 1993...)

We're operating from a baseline which was a Cygnus/RedHat "2.96"
release made to MIPS Technologies in late 2000.  A snapshot from a
contract which had run into some kind of dissension, it had some new
MIPS16 support but it was very buggy (the regular 32-bit MIPS code
generator, too).  It has some nice features, though, like the "Haifa"
scheduler and the DFA extensions to machine descriptions for
superscalar CPUs.

It's true we have not contributed patches lately.  We don't really
have the resouces; our success rate used to be very low, and since
we're not working around the developing 3.x sources the prospects seem
even dimmer.

We're working (with funding from MIPS Technologies) on building a
toolchain which:

o Can build Linux kernel, libraries and applications alike;

o Is substantially more efficient than other GCC versions when
  producing MIPS application ("MIPS/ABI", PIC) code;

o Will produce ugly-but-correct PIC code for MIPS16 functions, so
  MIPS16 can be tested in a standard Linux environment;

o Operates to a known and documented ABI (even the forgotten details,
  like gprof...)

(The modesty of those ambitions should be measured against the reality
of today's Linux/MIPS...)

We should be done in 6 weeks or so.  Our intention is to provide this
port as both source and binary RPMs for free download, and to
encourage its widespread use.

We appreciate it would be great if this work was converged into a
robust 3.x compiler (though the change in C++ code conventions means,
I think, that it will be a long time before such a compiler can be
used by a majority of substantial embedded projects).  We're
canvassing anyone we can think of with the funds or influence to help
make it happen.

It would be even more valuable if we could ensure that MIPS becomes a
"first-class" architecture for the evolving GCC - but the latter
surely is a big commitment for the core GCC group.

It's a pity that the different priorities of various funders and
developers mean that there is no baseline toolkit for Linux/MIPS, so
that such resources as are available are frequently used to re-invent
the wheel.

Anyone got any ideas how to make it better?

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[Eric Christopher]

Dominic, 

> > I have not looked at the Algorithmics code because I don't have
> > copyright on it...
> 
> We do publish our sources on our web server.  Not only are they GPL
> but we have a copyright assignment to the FSF in place (which I know
> was sent to Jim Wilson of Cygnus, albeit in 1993...)
> 
It's great that your changes do get out in one form or another. I'm
personally uncertain as to the nature of copyright and how it would
affect if I looked at your code and put it into the mainline sources -
so I haven't :) 

> We're operating from a baseline which was a Cygnus/RedHat "2.96"
> release made to MIPS Technologies in late 2000.  A snapshot from a
> contract which had run into some kind of dissension, it had some new
> MIPS16 support but it was very buggy (the regular 32-bit MIPS code
> generator, too).  It has some nice features, though, like the "Haifa"
> scheduler and the DFA extensions to machine descriptions for
> superscalar CPUs.
> 
I don't remember any new mips16 support, however, I do remember that the
work was quite old (more than 2 years now). MIPS32 support is quite a
bit better now, and with the acceptance of Vlad's DFA scheduler into
mainline the scheduling descriptions will be following shortly. 

> It's true we have not contributed patches lately.  We don't really
> have the resouces; our success rate used to be very low, and since
> we're not working around the developing 3.x sources the prospects seem
> even dimmer.
> 
The backend has changed a bit in the time, however, it hasn't changed so
much that the patches would be that difficult for you to bring forward.
I encourage you to reconsider contributing them. 

> We're working (with funding from MIPS Technologies) on building a
> toolchain which:
> 
> o Can build Linux kernel, libraries and applications alike;
> 
> o Is substantially more efficient than other GCC versions when
>   producing MIPS application ("MIPS/ABI", PIC) code;
> 
> o Will produce ugly-but-correct PIC code for MIPS16 functions, so
>   MIPS16 can be tested in a standard Linux environment;
> 
> o Operates to a known and documented ABI (even the forgotten details,
>   like gprof...)
> 
> (The modesty of those ambitions should be measured against the reality
> of today's Linux/MIPS...)
I'm not certain what you are actually fixing here as I've not seen any
descriptions of problems here. I'd love to fix any problems that you've
had reported in the mainline sources so that everyone can get the
benefit of the work you are doing. 


> It would be even more valuable if we could ensure that MIPS becomes a
> "first-class" architecture for the evolving GCC - but the latter
> surely is a big commitment for the core GCC group.
> 
I'm putting in a lot of effort to cleaning up the MIPS port and am
committed to the architecture. 

> It's a pity that the different priorities of various funders and
> developers mean that there is no baseline toolkit for Linux/MIPS, so
> that such resources as are available are frequently used to re-invent
> the wheel.
> 
> Anyone got any ideas how to make it better?
> 
The problem as I see it is that no one wants/cares to contribute their
changes back that they make, or at least file bug reports against the
problems that they have. Almost 90% of the bug reports I see are against
IRIX. People have to "re-invent the wheel" because the changes never
make it back into the official sources - everyone has their own one
offs. If we fix this then the work that all of the disparate groups are
doing will at least go toward a common goal. 

-eric 

-- 
A fire drill does not demand
a fire.

Re: [Fwd: Current state of MIPS16 support?]

[Eric Christopher]

<I'm not sure if I ever sent this, so I apologize if you received it
twice>

Dominic, 

> > I have not looked at the Algorithmics code because I don't have
> > copyright on it...
> 
> We do publish our sources on our web server.  Not only are they GPL
> but we have a copyright assignment to the FSF in place (which I know
> was sent to Jim Wilson of Cygnus, albeit in 1993...)
> 
It's great that your changes do get out in one form or another. I'm
personally uncertain as to the nature of copyright and how it would
affect if I looked at your code and put it into the mainline sources -
so I haven't :) 

> We're operating from a baseline which was a Cygnus/RedHat "2.96"
> release made to MIPS Technologies in late 2000.  A snapshot from a
> contract which had run into some kind of dissension, it had some new
> MIPS16 support but it was very buggy (the regular 32-bit MIPS code
> generator, too).  It has some nice features, though, like the "Haifa"
> scheduler and the DFA extensions to machine descriptions for
> superscalar CPUs.
> 
I don't remember any new mips16 support, however, I do remember that the
work was quite old (more than 2 years now). MIPS32 support is quite a
bit better now, and with the acceptance of Vlad's DFA scheduler into
mainline the scheduling descriptions will be following shortly. 

> It's true we have not contributed patches lately.  We don't really
> have the resouces; our success rate used to be very low, and since
> we're not working around the developing 3.x sources the prospects seem
> even dimmer.
> 
The backend has changed a bit in the time, however, it hasn't changed so
much that the patches would be that difficult for you to bring forward.
I encourage you to reconsider contributing them. 

> We're working (with funding from MIPS Technologies) on building a
> toolchain which:
> 
> o Can build Linux kernel, libraries and applications alike;
> 
> o Is substantially more efficient than other GCC versions when
>   producing MIPS application ("MIPS/ABI", PIC) code;
> 
> o Will produce ugly-but-correct PIC code for MIPS16 functions, so
>   MIPS16 can be tested in a standard Linux environment;
> 
> o Operates to a known and documented ABI (even the forgotten details,
>   like gprof...)
> 
> (The modesty of those ambitions should be measured against the reality
> of today's Linux/MIPS...)
I'm not certain what you are actually fixing here as I've not seen any
descriptions of problems here. I'd love to fix any problems that you've
had reported in the mainline sources so that everyone can get the
benefit of the work you are doing. 


> It would be even more valuable if we could ensure that MIPS becomes a
> "first-class" architecture for the evolving GCC - but the latter
> surely is a big commitment for the core GCC group.
> 
I'm putting in a lot of effort to cleaning up the MIPS port and am
committed to the architecture. 

> It's a pity that the different priorities of various funders and
> developers mean that there is no baseline toolkit for Linux/MIPS, so
> that such resources as are available are frequently used to re-invent
> the wheel.
> 
> Anyone got any ideas how to make it better?
> 
The problem as I see it is that no one wants/cares to contribute their
changes back that they make, or at least file bug reports against the
problems that they have. Almost 90% of the bug reports I see are against
IRIX. People have to "re-invent the wheel" because the changes never
make it back into the official sources - everyone has their own one
offs. If we fix this then the work that all of the disparate groups are
doing will at least go toward a common goal. 

-eric 

-- 
A fire drill does not demand
a fire.

Re: [Fwd: Current state of MIPS16 support?]

[Joe Buck]

> > > I have not looked at the Algorithmics code because I don't have
> > > copyright on it...

Dominic wrote:
> > We do publish our sources on our web server.  Not only are they GPL
> > but we have a copyright assignment to the FSF in place (which I know
> > was sent to Jim Wilson of Cygnus, albeit in 1993...)

Eric Christopher wrote:
> It's great that your changes do get out in one form or another. I'm
> personally uncertain as to the nature of copyright and how it would
> affect if I looked at your code and put it into the mainline sources -
> so I haven't :) 

Whose name and what company name would be on the copyright assignment?
We can check with the FSF list to see if it's on file.  Meanwhile it
should not go in.

Re: [Fwd: Current state of MIPS16 support?]

[Joe Buck]

> > > I have not looked at the Algorithmics code because I don't have
> > > copyright on it...

Dominic wrote:
> > We do publish our sources on our web server.  Not only are they GPL
> > but we have a copyright assignment to the FSF in place (which I know
> > was sent to Jim Wilson of Cygnus, albeit in 1993...)

Eric Christopher wrote:
> It's great that your changes do get out in one form or another. I'm
> personally uncertain as to the nature of copyright and how it would
> affect if I looked at your code and put it into the mainline sources -
> so I haven't :) 

Whose name and what company name would be on the copyright assignment?
We can check with the FSF list to see if it's on file.  Meanwhile it
should not go in.

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 973 bytes --]


Joe Buck (Joe.Buck@synopsys.com) writes:

> Dominic wrote:
> > > We do publish our sources on our web server.  Not only are they
> > > GPL but we have a copyright assignment to the FSF in place
> > > (which I know was sent to Jim Wilson of Cygnus, albeit in
> > > 1993...)
> 
> Eric Christopher wrote:
> > It's great that your changes do get out in one form or
> > another. I'm personally uncertain as to the nature of copyright
> > and how it would affect if I looked at your code and put it into
> > the mainline sources - so I haven't :)
> 
> Whose name and what company name would be on the copyright assignment?
> We can check with the FSF list to see if it's on file.  Meanwhile it
> should not go in.

I signed the assignment/waiver.  The companies involved are
Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
Cygnus) in October 1993 in the form recommended at that time.  Here's
a PDF.  Note the 'company stationery' has changed since 1993...


[-- Attachment #2: gnu-disclaimer.pdf --]
[-- Type: application/pdf, Size: 5345 bytes --]

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 233 bytes --]


Let me know if you need a contemporary form.

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 973 bytes --]


Joe Buck (Joe.Buck@synopsys.com) writes:

> Dominic wrote:
> > > We do publish our sources on our web server.  Not only are they
> > > GPL but we have a copyright assignment to the FSF in place
> > > (which I know was sent to Jim Wilson of Cygnus, albeit in
> > > 1993...)
> 
> Eric Christopher wrote:
> > It's great that your changes do get out in one form or
> > another. I'm personally uncertain as to the nature of copyright
> > and how it would affect if I looked at your code and put it into
> > the mainline sources - so I haven't :)
> 
> Whose name and what company name would be on the copyright assignment?
> We can check with the FSF list to see if it's on file.  Meanwhile it
> should not go in.

I signed the assignment/waiver.  The companies involved are
Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
Cygnus) in October 1993 in the form recommended at that time.  Here's
a PDF.  Note the 'company stationery' has changed since 1993...


[-- Attachment #2: gnu-disclaimer.pdf --]
[-- Type: application/pdf, Size: 5345 bytes --]

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 233 bytes --]


Let me know if you need a contemporary form.

--
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[law]

In message <15614.10904.705392.925058@gladsmuir.algor.co.uk>, Dominic Sweetman 
writes:
 > 
 > --MwF7gxnaJe
 > Content-Type: text/plain; charset=us-ascii
 > Content-Description: message body text
 > Content-Transfer-Encoding: 7bit
 > 
 > 
 > Joe Buck (Joe.Buck@synopsys.com) writes:
 > 
 > > Dominic wrote:
 > > > > We do publish our sources on our web server.  Not only are they
 > > > > GPL but we have a copyright assignment to the FSF in place
 > > > > (which I know was sent to Jim Wilson of Cygnus, albeit in
 > > > > 1993...)
 > > 
 > > Eric Christopher wrote:
 > > > It's great that your changes do get out in one form or
 > > > another. I'm personally uncertain as to the nature of copyright
 > > > and how it would affect if I looked at your code and put it into
 > > > the mainline sources - so I haven't :)
 > > 
 > > Whose name and what company name would be on the copyright assignment?
 > > We can check with the FSF list to see if it's on file.  Meanwhile it
 > > should not go in.
 > 
 > I signed the assignment/waiver.  The companies involved are
 > Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
 > Cygnus) in October 1993 in the form recommended at that time.  Here's
 > a PDF.  Note the 'company stationery' has changed since 1993...
What's important here is the assignment that is on file with the FSF.  That's
what needs to be checked.  

jeff

Re: [Fwd: Current state of MIPS16 support?]

[law]

In message <15614.10904.705392.925058@gladsmuir.algor.co.uk>, Dominic Sweetman 
writes:
 > 
 > --MwF7gxnaJe
 > Content-Type: text/plain; charset=us-ascii
 > Content-Description: message body text
 > Content-Transfer-Encoding: 7bit
 > 
 > 
 > Joe Buck (Joe.Buck@synopsys.com) writes:
 > 
 > > Dominic wrote:
 > > > > We do publish our sources on our web server.  Not only are they
 > > > > GPL but we have a copyright assignment to the FSF in place
 > > > > (which I know was sent to Jim Wilson of Cygnus, albeit in
 > > > > 1993...)
 > > 
 > > Eric Christopher wrote:
 > > > It's great that your changes do get out in one form or
 > > > another. I'm personally uncertain as to the nature of copyright
 > > > and how it would affect if I looked at your code and put it into
 > > > the mainline sources - so I haven't :)
 > > 
 > > Whose name and what company name would be on the copyright assignment?
 > > We can check with the FSF list to see if it's on file.  Meanwhile it
 > > should not go in.
 > 
 > I signed the assignment/waiver.  The companies involved are
 > Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
 > Cygnus) in October 1993 in the form recommended at that time.  Here's
 > a PDF.  Note the 'company stationery' has changed since 1993...
What's important here is the assignment that is on file with the FSF.  That's
what needs to be checked.  

jeff

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

Jeff,

>  > I signed the assignment/waiver.  The companies involved are
>  > Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
>  > Cygnus) in October 1993 in the form recommended at that time.  Here's
>  > a PDF.  Note the 'company stationery' has changed since 1993...
> 
> What's important here is the assignment that is on file with the FSF.  That's
> what needs to be checked.  

Are you in a position to do that?  If not, who is?

-- 
Dominic Sweetman, 
Algorithmics Ltd
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

Jeff,

>  > I signed the assignment/waiver.  The companies involved are
>  > Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
>  > Cygnus) in October 1993 in the form recommended at that time.  Here's
>  > a PDF.  Note the 'company stationery' has changed since 1993...
> 
> What's important here is the assignment that is on file with the FSF.  That's
> what needs to be checked.  

Are you in a position to do that?  If not, who is?

-- 
Dominic Sweetman, 
Algorithmics Ltd
phone: +44 1223 706200 / fax: +44 1223 706250 / direct: +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[Phil Edwards]

> >  > I signed the assignment/waiver.  The companies involved are
> >  > Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
> >  > Cygnus) in October 1993 in the form recommended at that time.  Here's
> >  > a PDF.  Note the 'company stationery' has changed since 1993...
> > 
> > What's important here is the assignment that is on file with the FSF.  That's
> > what needs to be checked.  
> 
> Are you in a position to do that?  If not, who is?
> 
> -- 
> Dominic Sweetman, 
> Algorithmics Ltd

Here's what's on file:

    BINUTILS    Algorithmics Ltd.   1997-08-20
    Assigns changes.

    GCC Algorithmics Ltd.   1997-08-20
    Assigns changes.

    GDB Algorithmics Ltd.   1997-08-20
    Assigns changes.

There's also a disclaimer for changes to Emacs, if that matters here.  :-)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: [Fwd: Current state of MIPS16 support?]

[law]

In message <20020606055918.A13788@disaster.basement.lan>, Phil Edwards writes:
 > > >  > I signed the assignment/waiver.  The companies involved are
 > > >  > Algorithmics Ltd and DFS3 Ltd.  It was faxed to Jim Wilson (then at
 > > >  > Cygnus) in October 1993 in the form recommended at that time.  Here's
 > > >  > a PDF.  Note the 'company stationery' has changed since 1993...
 > > > 
 > > > What's important here is the assignment that is on file with the FSF.  T
 > hat's
 > > > what needs to be checked.  
 > > 
 > > Are you in a position to do that?  If not, who is?
 > > 
 > > -- 
 > > Dominic Sweetman, 
 > > Algorithmics Ltd
 > 
 > Here's what's on file:
 > 
 >     BINUTILS    Algorithmics Ltd.   1997-08-20
 >     Assigns changes.
 > 
 >     GCC Algorithmics Ltd.   1997-08-20
 >     Assigns changes.
 > 
 >     GDB Algorithmics Ltd.   1997-08-20
 >     Assigns changes.
 > 
 > There's also a disclaimer for changes to Emacs, if that matters here.  :-)
Thanks.  This likely means that we're better off getting a new assignment --
this kind of language "Assigns changes" typically means an assignment for a
specific set of changes.  If the scope of the changes increased over time,
then the new changes would not be covered by the old assignment.

I'd be much more comfortable if Algorithmics would sign a past & future 
assignment for binutils, gcc & gdb.

jeff

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

Eric,

> The backend has changed a bit in the time, however, it hasn't
> changed so much that the patches would be that difficult for you to
> bring forward.
>
> I encourage you to reconsider contributing them. 

I fear it's "when time permits" at the moment.  The number of changes
is sufficiently large that it will take concentrated effort for 2-4
weeks, and this is very difficult to find.

> > We're working (with funding from MIPS Technologies) on building a
> > toolchain which:
> > 
> > o Can build Linux kernel, libraries and applications alike;
> > 
> > o Is substantially more efficient than other GCC versions when
> >   producing MIPS application ("MIPS/ABI", PIC) code;
> > 
> > o Will produce ugly-but-correct PIC code for MIPS16 functions, so
> >   MIPS16 can be tested in a standard Linux environment;
> > 
> > o Operates to a known and documented ABI (even the forgotten details,
> >   like gprof...)
> > 
> > (The modesty of those ambitions should be measured against the reality
> > of today's Linux/MIPS...)
> 
> I'm not certain what you are actually fixing here as I've not seen any
> descriptions of problems here...

Hmm.  Linux/MIPS suffers from widespread and diffuse toolchain
problems: I thought that much was pretty clear to all involved.  I
agree it seems a pity that the scheme of work laid out above should be
necessary...

> I'd love to fix any problems that you've had reported in the
> mainline sources so that everyone can get the benefit of the work
> you are doing.

Rather than snow you with a hundred compiler patches, I wonder whether
it might be better to share our regression test changes?  The tests
are likely to be a whole lot more portable than compiler patches.  If
you run them on a recent GCC 3.x compiler, you'll be in a much better
position to know to what extent our 2.96+ work is still relevant.

If this seems a good idea please mailto:sde@algor.co.uk and we'll ftp
the test sources to the place of your choice, or point you at them on
our web server.

> I'm putting in a lot of effort to cleaning up the MIPS port and am
> committed to the architecture. 

It sounds like you're in the role of maintainer of GCC for MIPS
targets.  You may not be free to answer this: but does that mean that
Red Hat have guaranteed you'll have the time to fulfill that
responsibility even during periods when Red Hat don't happen to win
relevant contracts from MIPS vendors?

If so that would be excellent...

> > It's a pity that the different priorities of various funders and
> > developers mean that there is no baseline toolkit for Linux/MIPS, so
> > that such resources as are available are frequently used to re-invent
> > the wheel.
> > 
> > Anyone got any ideas how to make it better?
>
> The problem as I see it is that no one wants/cares to contribute their
> changes back that they make, or at least file bug reports against the
> problems that they have.

During most of the last few years (as I understand it) it has been
difficult to establish a baseline to patch against, or find someone
who had the time to attend to bug reports.

As you'll know it's much harder to test the compiler as used for
'embedded' targets, because the diversity of OS' used makes it
hard to re-use tests.  Something better should be possible now
Linux/MIPS is less flaky.

> Almost 90% of the bug reports I see are against IRIX.

That does suggest you're missing some pretty large chunks of the
community!

> People have to "re-invent the wheel" because the changes never make
> it back into the official sources - everyone has their own one offs.
> If we fix this then the work that all of the disparate groups are
> doing will at least go toward a common goal. 

We believe that a large number of man hours will be required to
identify and merge all major valuable features and then chase out
the bugs, before there can be a release which everyone has reason to
adopt.

We certainly can't afford to put in those hours unless we win
contracts; I suspect Red Hat can't, either.

-- 
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: [Fwd: Current state of MIPS16 support?]

[Daniel Jacobowitz]

On Wed, Jun 05, 2002 at 04:39:45PM +0100, Dominic Sweetman wrote:
> > I'm not certain what you are actually fixing here as I've not seen any
> > descriptions of problems here...
> 
> Hmm.  Linux/MIPS suffers from widespread and diffuse toolchain
> problems: I thought that much was pretty clear to all involved.  I
> agree it seems a pity that the scheme of work laid out above should be
> necessary...

...

> > Almost 90% of the bug reports I see are against IRIX.
> 
> That does suggest you're missing some pretty large chunks of the
> community!

No, that's not what it suggests at all.  It suggests to me that the
dubious state of Linux/MIPS toolchains is due to one of two things:
  - A pre-existing acceptance of this rather than any real problems
  - A reluctance to file bug reports

We've been using GCC for MIPS for several years now and seen relatively
few significant problems, so I suspect the former.  There's definitely
some of the latter as well, since we've hit more roadblocks on MIPS
than on, say, x86 or PowerPC; it's not our worst problem architecture,
though.  And we've been able to fix them all relatively easily.

I'm sure GCC would benefit from access to your regression tests, though :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [Fwd: Current state of MIPS16 support?]

[cgd]

At Wed, 5 Jun 2002 15:40:14 +0000 (UTC), "Dominic Sweetman" wrote:
> I fear it's "when time permits" at the moment.  The number of changes
> is sufficiently large that it will take concentrated effort for 2-4
> weeks, and this is very difficult to find.

For what it's worth, if you expend the effort while you go, it saves
much time in the long run, both in terms of maintaining the changes,
and merging them.


> During most of the last few years (as I understand it) it has been
> difficult to establish a baseline to patch against, or find someone
> who had the time to attend to bug reports.

As someone who's been maintaining a MIPS toolchain (based on gcc,
binutils, etc.) for a couple of years, I dunno that that makes sense.

There seems to have been some confusion in the community about which
versions to use, etc.  But, for most purposes, i've found that the
latest releases have worked "pretty well" -- certainly well enough to
use for development with a small number of patches -- for linux mips
and other mips targets.  We've been using gcc 3.0.x now for a while;
last i looked the linux mips pages recommended against that, and I
really don't understand why...  Soon we'll be switching to 3.1.


> > Almost 90% of the bug reports I see are against IRIX.
> 
> That does suggest you're missing some pretty large chunks of the
> community!


> > People have to "re-invent the wheel" because the changes never make
> > it back into the official sources - everyone has their own one offs.
> > If we fix this then the work that all of the disparate groups are
> > doing will at least go toward a common goal. 
> 
> We believe that a large number of man hours will be required to
> identify and merge all major valuable features and then chase out
> the bugs, before there can be a release which everyone has reason to
> adopt.
> 
> We certainly can't afford to put in those hours unless we win
> contracts; I suspect Red Hat can't, either.

This puts you into an interesting position:

Presumably your customers desire both features of new GCC/binutils,
but also want support for your improvements.

The way it looks to me, by not getting your changes put back into the
public sources as you go, you've managed both to make a large chunk of
work for yourself if you want to catch up and to put yourself at a
competitive disadvantage in the eyes of customers who place high value
in current GCC features.


FWIW, it's not that hard to get changes back in if you try.  Over the
past couple of years, basically starting as an "outsider," i've
managed to get ... about a hundred fifty patches -- ranging from tiny
or trivial bug fixes to fairly huge changes -- pushed back into the
public sources, and have even managed to be appointed the mips gdb
'sim' maintainer...  The result is, many of the tool problems we found
have now been fixed, and since we put in test case entries where
possible should stay fixed, and now our source merges are much easier
and go much more quickly.



cgd

Re: [Fwd: Current state of MIPS16 support?]

[Dominic Sweetman]

I wholeheatedly agree that it would be a really good thing if we were
all working around a common, recent, source tree...

I'm finding this discussion useful because it's identifying people who
are working in the area, and I'm wondering whether we can come
together in the short term on building a better regression test
suite...

> There seems to have been some confusion in the community about which
> versions to use, etc.  But, for most purposes, i've found that the
> latest releases have worked "pretty well" -- certainly well enough to
> use for development with a small number of patches...

Difference in perception here.

Algorithmics have been maintaining GNU C for about ten years for our
'embedded' customers, some of whom have very large and demanding code
bases.  

Up to and including the 2.96+ release we currently work with, no GCC
version we've taken on has been fit for use by our MIPS customers
without a large number of fixes, including significant changes to
nominally non-machine-dependent code.

If you experienced a big improvement in quality on moving to some more
recent version, I'd love to know and that's worth telling everyone.

But if you're saying "it's always been more or less all right" then we
are bound to suspect you're not looking hard enough...

> Presumably your customers desire both features of new GCC/binutils,
> but also want support for your improvements.

They want high reliability (which requires fairly lengthy
development schedules) and the latest version... I'm sure yours do
too, but the requirements compete somewhat.

> FWIW, it's not that hard to get changes back in if you try.

Thanks for the encouragement.

Dominic Sweetman, 
Algorithmics Ltd

Re: [Fwd: Current state of MIPS16 support?]

[cgd]

At Thu, 6 Jun 2002 10:14:33 +0100 (BST), Dominic Sweetman wrote:
> Difference in perception here.

Noted.


> Up to and including the 2.96+ release we currently work with, no GCC
> version we've taken on has been fit for use by our MIPS customers
> without a large number of fixes, including significant changes to
> nominally non-machine-dependent code.
>
> If you experienced a big improvement in quality on moving to some more
> recent version, I'd love to know and that's worth telling everyone.
> 
> But if you're saying "it's always been more or less all right" then we
> are bound to suspect you're not looking hard enough...

"I don't know."  I didn't really spend a _lot_ of time staring at the
gnu toolchain until about 2 or 3 years ago (mips tools, 2 or so years
8-).  Before that, i relied on tools that others had massaged ... and
invariably, yes, they did have at least a few "important" bug fixes
(often pulled in from later development versions of the tools).  I
think even going back 2 and change years, we had some problems with
the versions of gcc at that time, and, for some sets of compile flags
(for us, -membedded-pic) a _lot_ of problems with binutils.

As of gcc 3.0.4 and w/ binutils 2.12.1 (with patches to each, but
generally not bug-fixes .... though we undoubtedly still have a few),
at least for us, they seem to work well for linux and for some amount
of stand-alone embedded development work.

I wouldn't disagree, BTW, that the current tools for mips seem to have
some shortcomings.  I also wouldn't claim that we've comprehensively
tested the tools.  8-)


I think the goal of improving test suites to show additional bugs is a
very good one.  Personally, I've been trying to make sure regression
tests get added for bugs we find & fix, but there will always be more
bugs to find.



chris