+++ /dev/null
-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
-\f
-Local Variables:
-mode: text
-End:
+++ /dev/null
-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.
git://gcc.gnu.org / gcc.git / commitdiff