1This file describes the implementation notes of the GNU C Compiler for 2the National Semiconductor 32032 chip (and 32000 family). 3 4Much of this file was obsolete. It described restrictions caused by 5bugs in early versions of of the ns32032 chip and by bugs in sequent 6assemblers and linkers of the time. 7 8Many (all?) of the chip bugs were fixed in later revisions and 9certainly fixed by later chips in the same series (ns32332 and 10ns32532). 11 12Conditional code to support sequent assembler and/or linker restrictions 13has not been removed deliberately, but has probably not been tested in 14a *very* long time. 15 16Support for one sequent assembler bug has *not* been retained. 17It was necessary to say: 18 19 addr _x,rn 20 cmpd _p,rn 21 22rather than: 23 24 cmpd _p,@_x 25 26 27This used to be forced by the use of "rmn" register constraints rather 28than "g". This is bad for other platforms which do not have this 29restraint. 30 31It is likely that there are no Balance 8000's still in operation, but 32if there are and the assembler bug was never fixed then the easiest 33way to run gcc would be to also run gas. 34 35The code required by the sequent assembler is still generated when the 36-fpic flag is in effect and this is forced by the appropriate 37definition of LEGITIMATE_PIC_OPERAND_P. If support for the old sequent 38assembler bug is required, then this could be achieved by adding the 39test from LEGITIMATE_PIC_OPERAND to the GO_IF_LEGITIMATE_ADDRESS 40definition. Of course, this should be conditional on something in the 41sequent.h config file. 42 43The original contents of this file appear below as an historical note. 44SEQUENT_ADDRESS_BUG mentioned below has been replaced by 45INDEX_RATHER_THAN_BASE. Note that merlin.h still defines 46SEQUENT_ADDRESS_BUG even though it is not used anywhere. Since it has 47been like this for a long time, presumably either the 48SEQUENT_ADDRESS_BUG is not required for the merlin, or no one is using 49gcc on the merlin anymore. 50 51HISTORICAL NOTE 52 53The 32032 machine description and configuration file for this compiler 54is, for NS32000 family machine, primarily machine independent. 55However, since this release still depends on vendor-supplied 56assemblers and linkers, the compiler must obey the existing 57conventions of the actual machine to which this compiler is targeted. 58In this case, the actual machine which this compiler was targeted to 59is a Sequent Balance 8000, running DYNIX 2.1. 60 61The assembler for DYNIX 2.1 (and DYNIX 3.0, alas) does not cope with 62the full generality of the addressing mode REGISTER RELATIVE. 63Specifically, it generates incorrect code for operands of the 64following form: 65 66 sym(rn) 67 68Where `rn' is one of the general registers. Correct code is generated 69for operands of the form 70 71 sym(pn) 72 73where `pn' is one of the special processor registers (sb, fp, or sp). 74 75An equivalent operand can be generated by the form 76 77 sym[rn:b] 78 79although this addressing mode is about twice as slow on the 32032. 80 81The more efficient addressing mode is controlled by defining the 82constant SEQUENT_ADDRESS_BUG to 0. It is currently defined to be 1. 83 84Another bug in the assembler makes it impossible to compute with 85explicit addresses. In order to compute with a symbolic address, it 86is necessary to load that address into a register using the "addr" 87instruction. For example, it is not possible to say 88 89 cmpd _p,@_x 90 91Rather one must say 92 93 addr _x,rn 94 cmpd _p,rn 95 96 97The ns32032 chip has a number of known bugs. Any attempt to make the 98compiler unaware of these deficiencies will surely bring disaster. 99The current list of know bugs are as follows (list provided by Richard 100Stallman): 101 1021) instructions with two overlapping operands in memory 103(unlikely in C code, perhaps impossible). 104 1052) floating point conversion instructions with constant 106operands (these may never happen, but I'm not certain). 107 1083) operands crossing a page boundary. These can be prevented 109by setting the flag in tm.h that requires strict alignment. 110 1114) Scaled indexing in an insn following an insn that has a read-write 112operand in memory. This can be prevented by placing a no-op in 113between. I, Michael Tiemann, do not understand what exactly is meant 114by `read-write operand in memory'. If this is referring to the special 115TOS mode, for example "addd 5,tos" then one need not fear, since this 116will never be generated. However, is this includes "addd 5,-4(fp)" 117then there is room for disaster. The Sequent compiler does not insert 118a no-op for code involving the latter, and I have been informed that 119Sequent is aware of this list of bugs, so I must assume that it is not 120a problem. 121 1225) The 32032 cannot shift by 32 bits. It shifts modulo the word size 123of the operand. Therefore, for 32-bit operations, 32-bit shifts are 124interpreted as zero bit shifts. 32-bit shifts have been removed from 125the compiler, but future hackers must be careful not to reintroduce 126them. 127 1286) The ns32032 is a very slow chip; however, some instructions are 129still very much slower than one might expect. For example, it is 130almost always faster to double a quantity by adding it to itself than 131by shifting it by one, even if that quantity is deep in memory. The 132MOVM instruction has a 20-cycle setup time, after which it moves data 133at about the speed that normal moves would. It is also faster to use 134address generation instructions than shift instructions for left 135shifts less than 4. I do not claim that I generate optimal code for all 136given patterns, but where I did escape from National's "clean 137architecture", I did so because the timing specification from the data 138book says that I will win if I do. I suppose this is called the 139"performance gap". 140 141 142Signed bitfield extraction has not been implemented. It is not 143provided by the NS32032, and while it is most certainly possible to do 144better than the standard shift-left/shift-right sequence, it is also 145quite hairy. Also, since signed bitfields do not yet exist in C, this 146omission seems relatively harmless. 147 148 149Zero extractions could be better implemented if it were possible in 150GCC to provide sized zero extractions: i.e. a byte zero extraction 151would be allowed to yield a byte result. The current implementation 152of GCC manifests 68000-ist thinking, where bitfields are extracted 153into a register, and automatically sign/zero extended to fill the 154register. See comments in ns32k.md around the "extzv" insn for more 155details. 156 157 158It should be noted that while the NS32000 family was designed to 159provide odd-aligned addressing capability for multi-byte data (also 160provided by the 68020, but not by the 68000 or 68010), many machines 161do not opt to take advantage of this. For example, on the sequent, 162although there is no advantage to long-word aligning word data, shorts 163must be int-aligned in structs. This is an example of another 164machine-specific machine dependency. 165 166 167Because the ns32032 is has a coherent byte-order/bit-order 168architecture, many instructions which would be different for 16968000-style machines, fold into the same instruction for the 32032. 170The classic case is push effective address, where it does not matter 171whether one is pushing a long, word, or byte address. They all will 172push the same address. 173 174 175The macro FUNCTION_VALUE_REGNO_P is probably not sufficient, what is 176needed is FUNCTION_VALUE_P, which also takes a MODE parameter. In 177this way it will be possible to determine more exactly whether a 178register is really a function value register, or just one that happens 179to look right. 180