diff --git a/gcc/ChangeLog b/gcc/ChangeLog index bffccfd3460..dd3cdb73a8c 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,11 @@ +2000-10-09 Gerald Pfeifer + + * README.NS32K: Remove file. + +2000-10-09 Gerald Pfeifer + + * README-bugs: Remove file. + 2000-10-08 Philipp Thomas * aclocal.m4 (AM_GNU_GETTEXT): Fix non portable use of == operator for test. diff --git a/gcc/README-bugs b/gcc/README-bugs deleted file mode 100644 index 06e15bb8af7..00000000000 --- a/gcc/README-bugs +++ /dev/null @@ -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: diff --git a/gcc/README.NS32K b/gcc/README.NS32K deleted file mode 100644 index 8e3610e33b5..00000000000 --- a/gcc/README.NS32K +++ /dev/null @@ -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.