gcc.texi

GUN开源阻止下的编译器GCC

Charles LaBrec contributed the support for the Integrated Solutions
68020 system.

@item
Michael Tiemann of Cygnus Support wrote the front end for C++, as well
as the support for inline functions and instruction scheduling.  Also
the descriptions of the National Semiconductor 32000 series cpu, the
SPARC cpu and part of the Motorola 88000 cpu.

@item
Gerald Baumgartner added the signature extension to the C++ front-end.

@item
Jan Stein of the Chalmers Computer Society provided support for
Genix, as well as part of the 32000 machine description.

@item
Randy Smith finished the Sun FPA support.

@item
Robert Brown implemented the support for Encore 32000 systems.

@item
David Kashtan of SRI adapted GNU CC to VMS.

@item
Alex Crain provided changes for the 3b1.

@item
Greg Satz and Chris Hanson assisted in making GNU CC work on HP-UX for
the 9000 series 300.

@item
William Schelter did most of the work on the Intel 80386 support.

@item
Christopher Smith did the port for Convex machines.

@item
Paul Petersen wrote the machine description for the Alliant FX/8.

@item
Dario Dariol contributed the four varieties of sample programs
that print a copy of their source.

@item
Alain Lichnewsky ported GNU CC to the Mips cpu.

@item
Devon Bowen, Dale Wiles and Kevin Zachmann ported GNU CC to the Tahoe.

@item
Jonathan Stone wrote the machine description for the Pyramid computer.

@item
Gary Miller ported GNU CC to Charles River Data Systems machines.

@item
Richard Kenner of the New York University Ultracomputer Research
Laboratory wrote the machine descriptions for the AMD 29000, the DEC
Alpha, the IBM RT PC, and the IBM RS/6000 as well as the support for
instruction attributes.  He also made changes to better support RISC
processors including changes to common subexpression elimination,
strength reduction, function calling sequence handling, and condition
code support, in addition to generalizing the code for frame pointer
elimination.

@item
Richard Kenner and Michael Tiemann jointly developed reorg.c, the delay
slot scheduler.

@item
Mike Meissner and Tom Wood of Data General finished the port to the
Motorola 88000.

@item 
Masanobu Yuhara of Fujitsu Laboratories implemented the machine
description for the Tron architecture (specifically, the Gmicro).

@item
NeXT, Inc.@: donated the front end that supports the Objective C
language.
@c We need to be careful to make it clear that "Objective C"
@c is the name of a language, not that of a program or product.

@item
James van Artsdalen wrote the code that makes efficient use of
the Intel 80387 register stack.

@item
Mike Meissner at the Open Software Foundation finished the port to the
MIPS cpu, including adding ECOFF debug support, and worked on the
Intel port for the Intel 80386 cpu.

@item
Ron Guilmette implemented the @code{protoize} and @code{unprotoize}
tools, the support for Dwarf symbolic debugging information, and much of
the support for System V Release 4.  He has also worked heavily on the
Intel 386 and 860 support.

@item
Torbjorn Granlund implemented multiply- and divide-by-constant
optimization, improved long long support, and improved leaf function
register allocation.

@item
Mike Stump implemented the support for Elxsi 64 bit CPU.

@item
John Wehle added the machine description for the Western Electric 32000
processor used in several 3b series machines (no relation to the
National Semiconductor 32000 processor).

@ignore @c These features aren't advertised yet, since they don't fully work.
@item
Analog Devices helped implement the support for complex data types
and iterators.
@end ignore

@item
Holger Teutsch provided the support for the Clipper cpu.

@item
Kresten Krab Thorup wrote the run time support for the Objective C
language.

@item
Stephen Moshier contributed the floating point emulator that assists in
cross-compilation and permits support for floating point numbers wider
than 64 bits.

@item
David Edelsohn contributed the changes to RS/6000 port to make it
support the PowerPC and POWER2 architectures.

@item
Steve Chamberlain wrote the support for the Hitachi SH processor.

@item
Peter Schauer wrote the code to allow debugging to work on the Alpha.

@item
Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
MIL-STD-1750A.

@item
Michael K. Gschwind contributed the port to the PDP-11.
@end itemize

@node Funding
@chapter Funding Free Software

If you want to have more free software a few years from now, it makes
sense for you to help encourage people to contribute funds for its
development.  The most effective approach known is to encourage
commercial redistributors to donate.

Users of free software systems can boost the pace of development by
encouraging for-a-fee distributors to donate part of their selling price
to free software developers---the Free Software Foundation, and others.

The way to convince distributors to do this is to demand it and expect
it from them.  So when you compare distributors, judge them partly by
how much they give to free software development.  Show distributors
they must compete to be the one who gives the most.

To make this approach work, you must insist on numbers that you can
compare, such as, ``We will donate ten dollars to the Frobnitz project
for each disk sold.''  Don't be satisfied with a vague promise, such as
``A portion of the profits are donated,'' since it doesn't give a basis
for comparison.

Even a precise fraction ``of the profits from this disk'' is not very
meaningful, since creative accounting and unrelated business decisions
can greatly alter what fraction of the sales price counts as profit.
If the price you pay is $50, ten percent of the profit is probably
less than a dollar; it might be a few cents, or nothing at all.

Some redistributors do development work themselves.  This is useful too;
but to keep everyone honest, you need to inquire how much they do, and
what kind.  Some kinds of development make much more long-term
difference than others.  For example, maintaining a separate version of
a program contributes very little; maintaining the standard version of a
program for the whole community contributes much.  Easy new ports
contribute little, since someone else would surely do them; difficult
ports such as adding a new CPU to the GNU C compiler contribute more;
major new features or packages contribute the most.

By establishing the idea that supporting further development is ``the
proper thing to do'' when distributing free software for a fee, we can
assure a steady flow of resources into making more free software.

@display
Copyright (C) 1994 Free Software Foundation, Inc.
Verbatim copying and redistribution of this section is permitted
without royalty; alteration is not permitted.
@end display

@node Look and Feel
@chapter Protect Your Freedom---Fight ``Look And Feel''
@c the above chapter heading overflows onto the next line. --mew 1/26/93 

@quotation
@i{This section is a political message from the League for Programming
Freedom to the users of GNU CC.  We have included it here because the
issue of interface copyright is important to the GNU project.}
@end quotation

Apple, Lotus, and now CDC have tried to create a new form of legal
monopoly: a copyright on a user interface.

An interface is a kind of language---a set of conventions for
communication between two entities, human or machine.  Until a few years
ago, the law seemed clear: interfaces were outside the domain of
copyright, so programmers could program freely and implement whatever
interface the users demanded.  Imitating de-facto standard interfaces,
sometimes with improvements, was standard practice in the computer
field.  These improvements, if accepted by the users, caught on and
became the norm; in this way, much progress took place.

Computer users, and most software developers, were happy with this state
of affairs.  However, large companies such as Apple and Lotus would
prefer a different system---one in which they can own interfaces and
thereby rid themselves of all serious competitors.  They hope that
interface copyright will give them, in effect, monopolies on major
classes of software.

Other large companies such as IBM and Digital also favor interface
monopolies, for the same reason: if languages become property, they
expect to own many de-facto standard languages.  But Apple and Lotus are
the ones who have actually sued.  Apple's lawsuit was defeated, for
reasons only partly related to the general issue of interface copyright.

Lotus won lawsuits against two small companies, which were thus put out
of business.  Then Lotus sued Borland; Lotus won in the trial court (no
surprise, since it was the same court that had ruled for Lotus twice
before), but the court of appeals ruled in favor of Borland, which was
assisted by a friend-of-the-court brief from the League for Programming
Freedom.

Lotus appealed the case to the Supreme Court, which heard the case but
was unable to reach a decision.  This failure means that the appeals
court decision stands, in one portion of the United States, and may
influence the other appeals courts, but it does not set a nationwide
precedent.  The battle is not over, and it is not limited to the United
States.

The battle is extending into other areas of software as well.  In 1995 a
company that produced a simulator for a CDC computer was shut down by a
copyright lawsuit, in which CDC charged that the simulator infringed the
copyright on the manuals for the computer.

If the monopolists get their way, they will hobble the software field:

@itemize @bullet
@item
Gratuitous incompatibilities will burden users.  Imagine if each car
manufacturer had to design a different way to start, stop, and steer a
car.

@item
Users will be ``locked in'' to whichever interface they learn; then they
will be prisoners of one supplier, who will charge a monopolistic price.

@item
Large companies have an unfair advantage wherever lawsuits become
commonplace.  Since they can afford to sue, they can intimidate smaller
developers with threats even when they don't really have a case.

@item
Interface improvements will come slower, since incremental evolution
through creative partial imitation will no longer occur.
@end itemize

If interface monopolies are accepted, other large companies are waiting
to grab theirs:

@itemize @bullet
@item
Adobe is expected to claim a monopoly on the interfaces of various
popular application programs, if Lotus ultimately wins the case against
Borland.

@item
Open Computing magazine reported a Microsoft vice president as threatening
to sue people who imitate the interface of Windows.
@end itemize

Users invest a great deal of time and money in learning to use computer
interfaces.  Far more, in fact, than software developers invest in
developing @emph{and even implementing} the interfaces.  Whoever can own
an interface, has made its users into captives, and misappropriated
their investment.

To protect our freedom from monopolies like these, a group of
programmers and users have formed a grass-roots political organization,
the League for Programming Freedom.

The purpose of the League is to oppose monopolistic practices such as
interface copyright and software patents.  The League calls for a return
to the legal policies of the recent past, in which programmers could
program freely.  The League is not concerned with free software as an
issue, and is not affiliated with the Free Software Foundation.

The League's activities include publicizing the issues, as is being done
here, and filing friend-of-the-court briefs on behalf of defendants sued
by monopolists.

The League's membership rolls include Donald Knuth, the foremost
authority on algorithms, John McCarthy, inventor of Lisp, Marvin Minsky,
founder of the MIT Artificial Intelligence lab, Guy L.  Steele, Jr.,
author of well-known books on Lisp and C, as well as Richard Stallman,
the developer of GNU CC.  Please join and add your name to the list.
Membership dues in the League are $42 per year for programmers, managers
and professionals; $10.50 for students; $21 for others.

Activist members are especially important, but members who have no time
to give are also important.  Surveys at major ACM conferences have
indicated a vast majority of attendees agree with the League on both
issues (interface copyrights and software patents).  If just ten percent
of the programmers who agree with the League join the League, we will
probably triumph.

To join, or for more information, phone [phone] or write to:

@display
League for Programming Freedom
1 Kendall Square #143
P.O. Box 9171
Cambridge, MA 02139
@end display

You can also send electronic mail to @code{lpf@@uunet.uu.net}.

In addition to joining the League, here are some suggestions from the
League for other things you can do to protect your freedom to write