MatCat.OpenSource/8sa1-gcc
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

README.NS32K: Remove file.

Browse Source 
* README.NS32K: Remove file.
	* README-bugs: Remove file.

From-SVN: r36807
This commit is contained in:
Gerald Pfeifer 2000-10-09 15:19:20 +02:00 committed by Gerald Pfeifer
parent 3ec840ea2e
commit 1146cfde1c
3 changed files with 8 additions and 323 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
gcc/ChangeLog
View File

@ -1,3 +1,11 @@
2000-10-09 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
* README.NS32K: Remove file.
2000-10-09 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
* README-bugs: Remove file.
2000-10-08 Philipp Thomas <pthomas@suse.de>
* aclocal.m4 (AM_GNU_GETTEXT): Fix non portable use of == operator
for test.

144
gcc/README-bugs
View File

@ -1,144 +0,0 @@
The purpose of GCC pretesting is to verify that the new GCC
distribution, about to be released, works properly on your system *with
no change whatever*, when installed following the precise
recommendations that come with the distribution.
Here are some guidelines on how to do pretesting so as to make it
helpful. All of them follow from common sense together with the
nature of the purpose and the situation.
* It is absolutely vital that you mention even the smallest change or
departure from the standard sources and installation procedure.
Otherwise, you are not testing the same program that I wrote. Testing
a different program is usually of no use whatever. It can even cause
trouble if you fail to tell me that you tested some other program
instead of what I know as GCC. I might think that GCC works, when in
fact it has not been properly tried, and might have a glaring fault.
* Even changing the compilation options counts as a change in the
program. The GCC sources specify which compilation options to use.
Some of them are specified in makefiles, and some in machine-specific
configuration files.
You have ways to override this--but if you do, then you are not
testing what ordinary users will do. Therefore, when pretesting, it
is vital to test with the default compilation options.
(It is okay to test with nonstandard options as well as testing with
the standard ones.)
* The machine and system configuration files of GCC are parts of
GCC. So when you test GCC, you need to do it with the
configuration files that come with GCC.
If GCC does not come with configuration files for a certain machine,
and you test it with configuration files that don't come with GCC,
this is effectively changing GCC. Because the crucial fact about
the planned release is that, without changes, it doesn't work on that
machine.
To make GCC work on that machine, I would need to install new
configuration files. That is not out of the question, since it is
safe--it certainly won't break any other machines that already work.
But you will have to rush me the legal papers to give the FSF
permission to use a large piece of text.
* Look for recommendations for your system.
You can find these recommendations in the Installation node of the
manual, and in the file INSTALL. (These two files have the same text.)
These files say which configuration name to use for your machine, so
use the ones that are recommended. If you guess, you might guess
wrong and encounter spurious difficulties. What's more, if you don't
follow the recommendations then you aren't helping to test that its
recommendations are valid.
These files may describe other things that you need to do to make GCC
work on your machine. If so, you should follow these recommendations
also, for the same reason.
Also look at the Trouble chapter of the manual for items that
pertain to your machine.
* Don't delay sending information.
When you find a problem, please double check it if you can do so
quickly. But don't spend a long time double-checking. A good rule is
always to tell me about every problem on the same day you encounter
it, even if that means you can't find a solution before you report the
problem.
I'd much rather hear about a problem today and a solution tomorrow
than get both of them tomorrow at the same time.
* Make each bug report self-contained.
If you refer back to another message, whether from you or from someone
else, then it will be necessary for anyone who wants to investigate
the bug to find the other message. This may be difficult, it is
probably time-consuming.
To help me save time, simply copy the relevant parts of any previous
messages into your own bug report.
In particular, if I ask you for more information because a bug report
was incomplete, it is best to send me the *entire* collection of
relevant information, all together. If you send just the additional
information, that makes me do extra work. There is even a risk that
I won't remember what question you are sending me the answer to.
* Always be precise when talking about changes you have made. Show
things rather than describing them. Use exact filenames (relative to
the main directory of the distribution), not partial ones. For
example, say "I changed Makefile" rather than "I changed the
makefile". Instead of saying "I defined the MUMBLE macro", send a
diff that shows your change.
* Always use `diff -c' to make diffs. If you don't include context,
it may be hard for me to figure out where you propose to make the
changes. I might have to ignore your patch because I can't tell what
it means.
* When you write a fix, keep in mind that I can't install a change
that would break other systems.
People often suggest fixing a problem by changing machine-independent
files such as toplev.c to do something special that a particular
system needs. Sometimes it is totally obvious that such changes would
break GCC for almost all users. I can't possibly make a change like
that. All I can do is send it back to you and ask you to find a fix
that is safe to install.
Sometimes people send fixes that *might* be an improvement in
general--but it is hard to be sure of this. I can install such
changes some of the time, but not during pretest, when I am trying to
get a new version to work reliably as quickly as possible.
The safest changes for me to install are changes to the configuration
files for a particular machine. At least I know those can't create
bugs on other machines.
* Don't try changing GCC unless it fails to work if you don't change it.
* Don't even suggest changes that would only make GCC cleaner.
Every change I install could introduce a bug, so I won't install
a change unless I see it is necessary.
* If you would like to suggest changes for purposes other than fixing
serious bugs, don't wait till pretest time. Instead, send them just
after I make a release. That's the best time for me to install them.
* In some cases, if you don't follow these guidelines, your
information might still be useful, but I might have to do more work to
make use of it. Unfortunately, I am so far behind in my work that I
just can't get the job done unless you help me to do it efficiently.
Thank you
rms
Local Variables:
mode: text
End:

179
gcc/README.NS32K
View File

@ -1,179 +0,0 @@
This file describes the implementation notes of the GNU C Compiler for
the National Semiconductor 32032 chip (and 32000 family).
Much of this file was obsolete. It described restrictions caused by
bugs in early versions of of the ns32032 chip and by bugs in sequent
assemblers and linkers of the time.
Many (all?) of the chip bugs were fixed in later revisions and
certainly fixed by later chips in the same series (ns32332 and
ns32532).
Conditional code to support sequent assembler and/or linker restrictions
has not been removed deliberately, but has probably not been tested in
a *very* long time.
Support for one sequent assembler bug has *not* been retained.
It was necessary to say:
addr _x,rn
cmpd _p,rn
rather than:
cmpd _p,@_x
This used to be forced by the use of "rmn" register constraints rather
than "g". This is bad for other platforms which do not have this
restraint.
It is likely that there are no Balance 8000's still in operation, but
if there are and the assembler bug was never fixed then the easiest
way to run gcc would be to also run gas.
The code required by the sequent assembler is still generated when the
-fpic flag is in effect and this is forced by the appropriate
definition of LEGITIMATE_PIC_OPERAND_P. If support for the old sequent
assembler bug is required, then this could be achieved by adding the
test from LEGITIMATE_PIC_OPERAND to the GO_IF_LEGITIMATE_ADDRESS
definition. Of course, this should be conditional on something in the
sequent.h config file.
The original contents of this file appear below as an historical note.
SEQUENT_ADDRESS_BUG mentioned below has been replaced by
INDEX_RATHER_THAN_BASE. Note that merlin.h still defines
SEQUENT_ADDRESS_BUG even though it is not used anywhere. Since it has
been like this for a long time, presumably either the
SEQUENT_ADDRESS_BUG is not required for the merlin, or no one is using
gcc on the merlin anymore.
HISTORICAL NOTE
The 32032 machine description and configuration file for this compiler
is, for NS32000 family machine, primarily machine independent.
However, since this release still depends on vendor-supplied
assemblers and linkers, the compiler must obey the existing
conventions of the actual machine to which this compiler is targeted.
In this case, the actual machine which this compiler was targeted to
is a Sequent Balance 8000, running DYNIX 2.1.
The assembler for DYNIX 2.1 (and DYNIX 3.0, alas) does not cope with
the full generality of the addressing mode REGISTER RELATIVE.
Specifically, it generates incorrect code for operands of the
following form:
sym(rn)
Where `rn' is one of the general registers. Correct code is generated
for operands of the form
sym(pn)
where `pn' is one of the special processor registers (sb, fp, or sp).
An equivalent operand can be generated by the form
sym[rn:b]
although this addressing mode is about twice as slow on the 32032.
The more efficient addressing mode is controlled by defining the
constant SEQUENT_ADDRESS_BUG to 0. It is currently defined to be 1.
Another bug in the assembler makes it impossible to compute with
explicit addresses. In order to compute with a symbolic address, it
is necessary to load that address into a register using the "addr"
instruction. For example, it is not possible to say
cmpd _p,@_x
Rather one must say
addr _x,rn
cmpd _p,rn
The ns32032 chip has a number of known bugs. Any attempt to make the
compiler unaware of these deficiencies will surely bring disaster.
The current list of know bugs are as follows (list provided by Richard
Stallman):
1) instructions with two overlapping operands in memory
(unlikely in C code, perhaps impossible).
2) floating point conversion instructions with constant
operands (these may never happen, but I'm not certain).
3) operands crossing a page boundary. These can be prevented
by setting the flag in tm.h that requires strict alignment.
4) Scaled indexing in an insn following an insn that has a read-write
operand in memory. This can be prevented by placing a no-op in
between. I, Michael Tiemann, do not understand what exactly is meant
by `read-write operand in memory'. If this is referring to the special
TOS mode, for example "addd 5,tos" then one need not fear, since this
will never be generated. However, is this includes "addd 5,-4(fp)"
then there is room for disaster. The Sequent compiler does not insert
a no-op for code involving the latter, and I have been informed that
Sequent is aware of this list of bugs, so I must assume that it is not
a problem.
5) The 32032 cannot shift by 32 bits. It shifts modulo the word size
of the operand. Therefore, for 32-bit operations, 32-bit shifts are
interpreted as zero bit shifts. 32-bit shifts have been removed from
the compiler, but future hackers must be careful not to reintroduce
them.
6) The ns32032 is a very slow chip; however, some instructions are
still very much slower than one might expect. For example, it is
almost always faster to double a quantity by adding it to itself than
by shifting it by one, even if that quantity is deep in memory. The
MOVM instruction has a 20-cycle setup time, after which it moves data
at about the speed that normal moves would. It is also faster to use
address generation instructions than shift instructions for left
shifts less than 4. I do not claim that I generate optimal code for all
given patterns, but where I did escape from National's "clean
architecture", I did so because the timing specification from the data
book says that I will win if I do. I suppose this is called the
"performance gap".
Signed bitfield extraction has not been implemented. It is not
provided by the NS32032, and while it is most certainly possible to do
better than the standard shift-left/shift-right sequence, it is also
quite hairy. Also, since signed bitfields do not yet exist in C, this
omission seems relatively harmless.
Zero extractions could be better implemented if it were possible in
GCC to provide sized zero extractions: i.e. a byte zero extraction
would be allowed to yield a byte result. The current implementation
of GCC manifests 68000-ist thinking, where bitfields are extracted
into a register, and automatically sign/zero extended to fill the
register. See comments in ns32k.md around the "extzv" insn for more
details.
It should be noted that while the NS32000 family was designed to
provide odd-aligned addressing capability for multi-byte data (also
provided by the 68020, but not by the 68000 or 68010), many machines
do not opt to take advantage of this. For example, on the sequent,
although there is no advantage to long-word aligning word data, shorts
must be int-aligned in structs. This is an example of another
machine-specific machine dependency.
Because the ns32032 is has a coherent byte-order/bit-order
architecture, many instructions which would be different for
68000-style machines, fold into the same instruction for the 32032.
The classic case is push effective address, where it does not matter
whether one is pushing a long, word, or byte address. They all will
push the same address.
The macro FUNCTION_VALUE_REGNO_P is probably not sufficient, what is
needed is FUNCTION_VALUE_P, which also takes a MODE parameter. In
this way it will be possible to determine more exactly whether a
register is really a function value register, or just one that happens
to look right.