New IA-32 back end in gcc-2.95

New IA-32 back end in gcc-2.95

[Erik Corry]

Hi,

On the front page of http://egcs.cygnus.com/ it says>

  June 15, 1999 Cygnus Solutions has donated a major rewrite
  of the Intel IA-32 back end, focusing on better optimization
  for the Pentium II. (Note that this will yet be included in
  gcc 2.95.)

Didn't you mean to say it _wouldn't_ be in gcc-2.95?

Why wasn't it called gcc-2.9 by the way.  Seems a little
fast to skip versions 2.9 to 2.94.  Perhaps you wanted to 
make it look like Linux-0.95, in which case I am looking
forward to gcc-2.99.15q  :-)

-- 
Erik Corry erik@arbat.com     Ceterum censeo, Microsoftem esse delendam!

Re: New IA-32 back end in gcc-2.95

[Gerald Pfeifer]

On Mon, 12 Jul 1999, Erik Corry wrote:
> On the front page of http://egcs.cygnus.com/ it says>
> 
>   June 15, 1999 Cygnus Solutions has donated a major rewrite
>   of the Intel IA-32 back end, focusing on better optimization
>   for the Pentium II. (Note that this will yet be included in
>   gcc 2.95.)
> 
> Didn't you mean to say it _wouldn't_ be in gcc-2.95?

Thanks for the hint. I have immediately fixed that by means of the
following patch.

Gerald

Index: index.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/index.html,v
retrieving revision 1.133
diff -r1.133 index.html
89c89
< <small>(Note that this will not be included in gcc 2.95.)</small>
---
> <small>(Note that this will not yet be included in gcc 2.95.)</small>
95c95
< <small>(Note that this will not be included in gcc 2.95.)</small>
---
> <small>(Note that this will not yet be included in gcc 2.95.)</small>
102c102
< <small>(Note that this will yet be included in gcc 2.95.)</small>
---
> <small>(Note that this will not yet be included in gcc 2.95.)</small>

Re: New IA-32 back end in gcc-2.95

[craig]

>Why wasn't it called gcc-2.9 by the way.  Seems a little
>fast to skip versions 2.9 to 2.94.  Perhaps you wanted to 
>make it look like Linux-0.95, in which case I am looking
>forward to gcc-2.99.15q  :-)

When EGCS started, they wanted to pick a version-numbering scheme that
accommodated EGCS as a distinct project not treading on GCC's feet.

Calling the first release "EGCS 3.0" or "EGCS 2.9" would have not
been well-received by many.  (I think they asked RMS if they could
call it "GCC 3", as was done when the gcc2 project started during
the gcc 1.x days, and he said no, or something like that.)

So "EGCS 1.0" made sense.

For GCC compatibility, they had to come up with a pair of major/minor
version numbers for use in preprocessor tests, i.e. __GNUC_MAJOR__
or whatever it's called.  (Or, not define __GNUC* stuff at all, using
__EGCS* stuff instead.  More elegant, but it'd have had the effect
of pushing the fork further into the user base, especially its code base,
than they wanted.)

They chose 2.91, or whatever, so it'd not "waste" a jump to a new major
version number (very wise) and so it'd stay well out of the way of
future gcc *minor* releases, a la 2.9, 2.10, and so on (also very wise).
(The only problem being the potential of GCC 2.11, say, introducing
whiz-bang new features users could conditionally use in their code,
which EGCS didn't support, making testing __GNUC_MINOR__ using > alone
not work right when compiling via EGCS.  Given the expectations concerning
the respective development paces of the two projects, which I believe
turned out to be substantial *underestimations* anyway, the thinking
was probably that this scenario was highly unlikely.)

However, having done that, the merge back into the GCC product line meant
they needed to pick a version number that didn't violate various
assumptions about version numbers.

2.9 or 2.10 would have made longtime EGCS users' code see the
__GNUC_MINOR__ value go *backwards*, possibly breaking code.

And, of course, 3.0 would have implied probably more about the scope
of the changes from GCC 2.8.1, or *especially* EGCS 1.1.2, than they
felt was appropriate.

Given the history, I think they made the right decision.

I'd like to end my little soapbox speech by reminding everyone that the
"minor successor" to a version 2.99 is 2.100.  There is no rule I'm
aware of that version subfields need be <=, or ==, two digits.  I don't
want to see leading zeros either -- unless you're using Fortran formatted
I/O to print out version numbers, in which case you're excused.  ;-)

        tq vm, (burley)

Re: New IA-32 back end in gcc-2.95

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9907121711400.10447-100000@markab.dbai.tuwien.ac.at
>you write:
  > > Didn't you mean to say it _wouldn't_ be in gcc-2.95?
  > 
  > Thanks for the hint. I have immediately fixed that by means of the
  > following patch.
  > 
  > Gerald
  > 
  > Index: index.html
  > ===================================================================
  > RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/index.html,v
  > retrieving revision 1.133
  > diff -r1.133 index.html
  > 89c89
  > < <small>(Note that this will not be included in gcc 2.95.)</small>
  > ---
  > > <small>(Note that this will not yet be included in gcc 2.95.)</small>

"not yet be" -> "not be" please.

"not yet" implies that we may add it to gcc-2.95, which is untrue.

jeff

Re: New IA-32 back end in gcc-2.95

[Gerald Pfeifer]

On Mon, 12 Jul 1999, Jeffrey A Law wrote:
>> < <small>(Note that this will not be included in gcc 2.95.)</small>
>> ---
>> > <small>(Note that this will not yet be included in gcc 2.95.)</small>
> "not yet be" -> "not be" please.
> 
> "not yet" implies that we may add it to gcc-2.95, which is untrue.

Fixed. This is one of the disadvantages of me not being a native speaker,
I am afraid. :-/

Thanks Jeff!
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: New IA-32 back end in gcc-2.95

[Joe Buck]

Craig Burley wrote an excellent summary of the reason for the 2.95
version number.  I'll just add one minor point:

> And, of course, 3.0 would have implied probably more about the scope
> of the changes from GCC 2.8.1, or *especially* EGCS 1.1.2, than they
> felt was appropriate.

We (the steering committee and RMS) did discuss calling the reunified
version 3.0 (or else first do a 2.99, then a 3.0).  The main argument
against it is that a new major version would seem to be the right time to
introduce any major API changes.  We have one pending for C++, but the new
libstdc++ v3 will not be ready in time for 2.95.  The goal for the C++
front end is that gcc-3.0 will contain a fully compliant (modulo bugs, of
course) C++ library that lives in the std namespace, with an ABI that
can remain stable for some time.

> I'd like to end my little soapbox speech by reminding everyone that the
> "minor successor" to a version 2.99 is 2.100.  There is no rule I'm
> aware of that version subfields need be <=, or ==, two digits.

Right: this is especially important for programmers to remember: version
numbers are not floating point, but are a series of integers separated by
periods.  At least one Linux program (ppp or pppd, I believe) was broken
by the release of version 2.1.100 of the Linux kernel (the program was
trying to check for a bug fix or change that occurred in 2.1.xx for some
xx, and it interpreted 2.1.100 as 2.1.00 -- kind of like the Y2K bug).

I would be greatly suprised myself if we were to see a 2.99 major release,
but it's hard to predict the future.

Re: New IA-32 back end in gcc-2.95

[Martin v. Loewis]

> Didn't you mean to say it _wouldn't_ be in gcc-2.95?

Sorry, can't comment on this one. AFAIK, it is not included in gcc
2.95.

> Why wasn't it called gcc-2.9 by the way.  Seems a little fast to
> skip versions 2.9 to 2.94.  Perhaps you wanted to make it look like
> Linux-0.95, in which case I am looking forward to gcc-2.99.15q :-)

It is a successor to egcs 1.x, which had the gcc version 2.9x, and it
is a predecessor to gcc 3. The next version most likely will be named
gcc 2.95.1, gcc 2.96, or gcc 3.

Regards,
Martin

Re: New IA-32 back end in gcc-2.95

[Gerald Pfeifer]

On Mon, 12 Jul 1999, Jeffrey A Law wrote:
>> < <small>(Note that this will not be included in gcc 2.95.)</small>
>> ---
>> > <small>(Note that this will not yet be included in gcc 2.95.)</small>
> "not yet be" -> "not be" please.
> 
> "not yet" implies that we may add it to gcc-2.95, which is untrue.

Fixed. This is one of the disadvantages of me not being a native speaker,
I am afraid. :-/

Thanks Jeff!
Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: New IA-32 back end in gcc-2.95

[Gerald Pfeifer]

On Mon, 12 Jul 1999, Erik Corry wrote:
> On the front page of http://egcs.cygnus.com/ it says>
> 
>   June 15, 1999 Cygnus Solutions has donated a major rewrite
>   of the Intel IA-32 back end, focusing on better optimization
>   for the Pentium II. (Note that this will yet be included in
>   gcc 2.95.)
> 
> Didn't you mean to say it _wouldn't_ be in gcc-2.95?

Thanks for the hint. I have immediately fixed that by means of the
following patch.

Gerald

Index: index.html
===================================================================
RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/index.html,v
retrieving revision 1.133
diff -r1.133 index.html
89c89
< <small>(Note that this will not be included in gcc 2.95.)</small>
---
> <small>(Note that this will not yet be included in gcc 2.95.)</small>
95c95
< <small>(Note that this will not be included in gcc 2.95.)</small>
---
> <small>(Note that this will not yet be included in gcc 2.95.)</small>
102c102
< <small>(Note that this will yet be included in gcc 2.95.)</small>
---
> <small>(Note that this will not yet be included in gcc 2.95.)</small>

Re: New IA-32 back end in gcc-2.95

[Jeffrey A Law]

  In message < Pine.GSO.4.10.9907121711400.10447-100000@markab.dbai.tuwien.ac.at
>you write:
  > > Didn't you mean to say it _wouldn't_ be in gcc-2.95?
  > 
  > Thanks for the hint. I have immediately fixed that by means of the
  > following patch.
  > 
  > Gerald
  > 
  > Index: index.html
  > ===================================================================
  > RCS file: /egcs/carton/cvsfiles/wwwdocs/htdocs/index.html,v
  > retrieving revision 1.133
  > diff -r1.133 index.html
  > 89c89
  > < <small>(Note that this will not be included in gcc 2.95.)</small>
  > ---
  > > <small>(Note that this will not yet be included in gcc 2.95.)</small>

"not yet be" -> "not be" please.

"not yet" implies that we may add it to gcc-2.95, which is untrue.

jeff

Re: New IA-32 back end in gcc-2.95

[Joe Buck]

Craig Burley wrote an excellent summary of the reason for the 2.95
version number.  I'll just add one minor point:

> And, of course, 3.0 would have implied probably more about the scope
> of the changes from GCC 2.8.1, or *especially* EGCS 1.1.2, than they
> felt was appropriate.

We (the steering committee and RMS) did discuss calling the reunified
version 3.0 (or else first do a 2.99, then a 3.0).  The main argument
against it is that a new major version would seem to be the right time to
introduce any major API changes.  We have one pending for C++, but the new
libstdc++ v3 will not be ready in time for 2.95.  The goal for the C++
front end is that gcc-3.0 will contain a fully compliant (modulo bugs, of
course) C++ library that lives in the std namespace, with an ABI that
can remain stable for some time.

> I'd like to end my little soapbox speech by reminding everyone that the
> "minor successor" to a version 2.99 is 2.100.  There is no rule I'm
> aware of that version subfields need be <=, or ==, two digits.

Right: this is especially important for programmers to remember: version
numbers are not floating point, but are a series of integers separated by
periods.  At least one Linux program (ppp or pppd, I believe) was broken
by the release of version 2.1.100 of the Linux kernel (the program was
trying to check for a bug fix or change that occurred in 2.1.xx for some
xx, and it interpreted 2.1.100 as 2.1.00 -- kind of like the Y2K bug).

I would be greatly suprised myself if we were to see a 2.99 major release,
but it's hard to predict the future.

New IA-32 back end in gcc-2.95

[Erik Corry]

Hi,

On the front page of http://egcs.cygnus.com/ it says>

  June 15, 1999 Cygnus Solutions has donated a major rewrite
  of the Intel IA-32 back end, focusing on better optimization
  for the Pentium II. (Note that this will yet be included in
  gcc 2.95.)

Didn't you mean to say it _wouldn't_ be in gcc-2.95?

Why wasn't it called gcc-2.9 by the way.  Seems a little
fast to skip versions 2.9 to 2.94.  Perhaps you wanted to 
make it look like Linux-0.95, in which case I am looking
forward to gcc-2.99.15q  :-)

-- 
Erik Corry erik@arbat.com     Ceterum censeo, Microsoftem esse delendam!

Re: New IA-32 back end in gcc-2.95

[craig]

>Why wasn't it called gcc-2.9 by the way.  Seems a little
>fast to skip versions 2.9 to 2.94.  Perhaps you wanted to 
>make it look like Linux-0.95, in which case I am looking
>forward to gcc-2.99.15q  :-)

When EGCS started, they wanted to pick a version-numbering scheme that
accommodated EGCS as a distinct project not treading on GCC's feet.

Calling the first release "EGCS 3.0" or "EGCS 2.9" would have not
been well-received by many.  (I think they asked RMS if they could
call it "GCC 3", as was done when the gcc2 project started during
the gcc 1.x days, and he said no, or something like that.)

So "EGCS 1.0" made sense.

For GCC compatibility, they had to come up with a pair of major/minor
version numbers for use in preprocessor tests, i.e. __GNUC_MAJOR__
or whatever it's called.  (Or, not define __GNUC* stuff at all, using
__EGCS* stuff instead.  More elegant, but it'd have had the effect
of pushing the fork further into the user base, especially its code base,
than they wanted.)

They chose 2.91, or whatever, so it'd not "waste" a jump to a new major
version number (very wise) and so it'd stay well out of the way of
future gcc *minor* releases, a la 2.9, 2.10, and so on (also very wise).
(The only problem being the potential of GCC 2.11, say, introducing
whiz-bang new features users could conditionally use in their code,
which EGCS didn't support, making testing __GNUC_MINOR__ using > alone
not work right when compiling via EGCS.  Given the expectations concerning
the respective development paces of the two projects, which I believe
turned out to be substantial *underestimations* anyway, the thinking
was probably that this scenario was highly unlikely.)

However, having done that, the merge back into the GCC product line meant
they needed to pick a version number that didn't violate various
assumptions about version numbers.

2.9 or 2.10 would have made longtime EGCS users' code see the
__GNUC_MINOR__ value go *backwards*, possibly breaking code.

And, of course, 3.0 would have implied probably more about the scope
of the changes from GCC 2.8.1, or *especially* EGCS 1.1.2, than they
felt was appropriate.

Given the history, I think they made the right decision.

I'd like to end my little soapbox speech by reminding everyone that the
"minor successor" to a version 2.99 is 2.100.  There is no rule I'm
aware of that version subfields need be <=, or ==, two digits.  I don't
want to see leading zeros either -- unless you're using Fortran formatted
I/O to print out version numbers, in which case you're excused.  ;-)

        tq vm, (burley)

Re: New IA-32 back end in gcc-2.95

[Martin v. Loewis]

> Didn't you mean to say it _wouldn't_ be in gcc-2.95?

Sorry, can't comment on this one. AFAIK, it is not included in gcc
2.95.

> Why wasn't it called gcc-2.9 by the way.  Seems a little fast to
> skip versions 2.9 to 2.94.  Perhaps you wanted to make it look like
> Linux-0.95, in which case I am looking forward to gcc-2.99.15q :-)

It is a successor to egcs 1.x, which had the gcc version 2.9x, and it
is a predecessor to gcc 3. The next version most likely will be named
gcc 2.95.1, gcc 2.96, or gcc 3.

Regards,
Martin