gcc/README.NS32K

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