Re: deprecate i960 now?

Re: deprecate i960 now?

[Robert Dewar]

<<I'll second it.  I think most manufacturing capacity for 960 things is
gone now, and while certain companies had a stock pile of parts, in
time, even those will be gone.
>>

This is definitely false, there are live projects using this chip, which
expect to be supported for a very long time, and Intel is still definitely
manufacturing these chips.

Re: deprecate i960 now?

[Richard Henderson]

On Fri, Oct 04, 2002 at 07:49:41AM -0400, Robert Dewar wrote:
> This is definitely false, there are live projects using this chip, which
> expect to be supported for a very long time, and Intel is still definitely
> manufacturing these chips.

All of which does not affect the fact that we have no maintainer.


r~

Re: deprecate i960 now?

[Robert Dewar]

<<But are any of them considering using gcc 3?  If none of them are ever going
to upgrade to gcc 3, then we don't need the i960 port in gcc 3.
>>

They are certaqinly not using gcc 3 now, since they are using gnat, I don
't know about future plans, to be checked

Re: deprecate i960 now?

[Robert Dewar]

We certainly know of significant users of gcc on the i960.

Re: deprecate i960 now?

[Jim Wilson]

>We certainly know of significant users of gcc on the i960.

But are any of them considering using gcc 3?  If none of them are ever going
to upgrade to gcc 3, then we don't need the i960 port in gcc 3.

We can be sure that none of them are using gcc 3 currently, because no gcc 3.x
version has had usable i960 support.

Jim

deprecate i960 now?

[Richard Henderson]

It seems that gdb obseleted i960 on 2002-08-22.  This makes it
fairly painful for gcc folk to test on i960, since that killed
the simulator as well.

I propose that we follow suit and add i960 to the deprecated list
for 3.3 so that it is removed in 3.4.

Thoughts?



r~

Re: deprecate i960 now?

[Mike Stump]

On Thursday, October 3, 2002, at 10:32 AM, Richard Henderson wrote:
> I propose that we follow suit and add i960 to the deprecated list
> for 3.3 so that it is removed in 3.4.

I'll second it.  I think most manufacturing capacity for 960 things is 
gone now, and while certain companies had a stock pile of parts, in 
time, even those will be gone.

Re: deprecate i960 now?

[Stan Shebs]

Mike Stump wrote:

> On Thursday, October 3, 2002, at 10:32 AM, Richard Henderson wrote:
>
>> I propose that we follow suit and add i960 to the deprecated list
>> for 3.3 so that it is removed in 3.4.
>
>
> I'll second it.  I think most manufacturing capacity for 960 things is 
> gone now, and while certain companies had a stock pile of parts, in 
> time, even those will be gone.
>
Intel sez they're cranking them in large volumes, and making record revenue
too.  They're not doing new designs though.

The algorithm I use to detect obsolete architectures is Google - if the only
references to an architecture are in GNU sources or in historical 
retrospectives,
then it's dead.  If the company is selling chips, it's not dead yet 
(although it
moight be stone cold in a moment :-) ).

Stan

Re: deprecate i960 now?

[Branko Čibej]

Stan Shebs wrote:

> Mike Stump wrote:
>
>> On Thursday, October 3, 2002, at 10:32 AM, Richard Henderson wrote:
>>
>>> I propose that we follow suit and add i960 to the deprecated list
>>> for 3.3 so that it is removed in 3.4.
>>
>>
>>
>> I'll second it.  I think most manufacturing capacity for 960 things 
>> is gone now, and while certain companies had a stock pile of parts, 
>> in time, even those will be gone.
>>
> Intel sez they're cranking them in large volumes, and making record 
> revenue
> too.  They're not doing new designs though.

i960 seems to be the XOR processor of choice on ATA RAID boards (Promise 
Fasttrak SX6000, 3ware Escalade series). I doubt those compaines are 
using stockpiled ships in their flagship products.

-- 
Brane ÄŒibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: deprecate i960 now?

[Stan Shebs]

Richard Henderson wrote:

>It seems that gdb obseleted i960 on 2002-08-22.  This makes it
>fairly painful for gcc folk to test on i960, since that killed
>the simulator as well.
>
>I propose that we follow suit and add i960 to the deprecated list
>for 3.3 so that it is removed in 3.4.
>
>Thoughts?
>
You could use Intel's GDB perhaps, since they suggest it in their
massive collection of i960 info at http://www.intel.com/design/i960.

It would be somewhat of a departure to move from obsoleting long-dead
architectures to taking away ones that, in Intel's words (in their
FAQ) are still shipping in "high volumes".

Although I don't have any personal stake in i960 support, I'm a little
troubled by the idea of dropping embedded targets that are still
supported by proprietary compilers.  It makes it easy for the
proprietaries to point to the dropping of targets as a reason not
to use GNU for any target, because of the risk of arbitrary decisions
like this.  Chucking a never-taped-out oddball like the d30v doesn't
matter, but for a still-used processor like the i960 it really seems
like a retreat.

Stan

Re: deprecate i960 now?

[Joe Buck]

Stan Shebs writes:
> [ re: obsoleting the i960]
> It would be somewhat of a departure to move from obsoleting long-dead
> architectures to taking away ones that, in Intel's words (in their
> FAQ) are still shipping in "high volumes".

If we have no maintainer and no i960 processors, and the gdb folks are
taking away resources, we can't maintain it.  We can have an alternate
designation in such cases, "orphaned" rather than "deprecated", meaning
it's on hold until volunteers step up to the challenge of keeping it
going.

> Chucking a never-taped-out oddball like the d30v doesn't
> matter, but for a still-used processor like the i960 it really seems
> like a retreat.

Agreed, which is why an "orphaned" status might be better.  The code can
stay around, but maintainance goes on hold until someone takes it over.

Sometimes the threat of losing support smokes a skilled user or two out of
the woodwork who has the incentive to keep the tool he relies on going.

Re: deprecate i960 now?

[Phil Edwards]

On Thu, Oct 03, 2002 at 05:18:36PM -0700, Joe Buck wrote:
> If we have no maintainer and no i960 processors, and the gdb folks are
> taking away resources, we can't maintain it.  We can have an alternate
> designation in such cases, "orphaned" rather than "deprecated", meaning
> it's on hold until volunteers step up to the challenge of keeping it
> going.
[...]
> Agreed, which is why an "orphaned" status might be better.  The code can
> stay around, but maintainance goes on hold until someone takes it over.

I don't understand the advantage of keeping code in the tree that we
know doesn't work, or at least /will/ break given that there's nobody
maintaining it.  Surely a future interested developer can fetch the last-
known-working version of i960 code from CVS with not much difficulty.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: deprecate i960 now?

[Stan Shebs]

Joe Buck wrote:

>Stan Shebs writes:
>
>>[ re: obsoleting the i960]
>>It would be somewhat of a departure to move from obsoleting long-dead
>>architectures to taking away ones that, in Intel's words (in their
>>FAQ) are still shipping in "high volumes".
>>
>
>If we have no maintainer and no i960 processors, and the gdb folks are
>taking away resources, we can't maintain it.  We can have an alternate
>designation in such cases, "orphaned" rather than "deprecated", meaning
>it's on hold until volunteers step up to the challenge of keeping it
>going.
>
Weighing the very real confusion of having dead code in CVS (will
infrastructure patches have to include i960 changes?  would I still
have to fix the known i960 problems in libobjc? :-) ) vs the vague
fears of bad publicity for dropping old targets, I think I'd rather
rely on CVS and delete the code.

>Sometimes the threat of losing support smokes a skilled user or two out of
>the woodwork who has the incentive to keep the tool he relies on going.
>
That was the theory of obsoleting non-multi-arch configs in GDB; all
it needed was someone to spend a couple days on a mostly mechanical
conversion, and even then there was nobody (me included) willing to
spend that much time on the i960, which says something...

There may be nothing to my concern too - back in Cygnus days, the
"available for every embedded target you can think of" was a valuable
line in the hard sell to potential GNU customers, but there's been
some consolidation in embedded-land and GCC is now more generally
accepted too, so I don't know if the breadth claim is still important.

Stan

Re: deprecate i960 now?

[Jim Wilson]

>If we have no maintainer ...

Technically, we have a maintainer, me, however, I have no interest in fixing
any i960 bugs at present, and offer to resign every time the topic comes up.
There is some small benefit to listing me as maintainer, since at least then
people know who to ask questions of.  I answered a few i960 ABI questions for
Richard Henderson yesterday.  So the question here is whether it is better to
have no maintainer at all or a maintainer who is willing to answer questions
but not willing to fix bugs.  Either way is fine with me.

Jim