From: Richard Kenner Date: Thu, 15 Jun 1995 11:02:40 +0000 (-0400) Subject: entered into RCS X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=801f82a8023beaf57c0b7eeedfce74c5539c9a0a;p=gcc.git entered into RCS From-SVN: r9958 --- diff --git a/gcc/README.NS32K b/gcc/README.NS32K new file mode 100644 index 00000000000..93c5beaef54 --- /dev/null +++ b/gcc/README.NS32K @@ -0,0 +1,130 @@ +This file describes the implementation notes of the GNU C Compiler for +the National Semiconductor 32032 chip (and 32000 family). + +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.