![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to NS32K.README CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / cmd / gcc|
Return to NS32K.README CVS log | Up to [Research Unix] / researchv10dc / cmd / gcc |
1.1 root 1: Copyright (C) 1987 Free Software Foundation, Inc.
2: Contributed by Michael Tiemann ([email protected])
3:
4: This file is part of GNU CC.
5:
6: GNU CC is distributed in the hope that it will be useful,
7: but WITHOUT ANY WARRANTY. No author or distributor
8: accepts responsibility to anyone for the consequences of using it
9: or for whether it serves any particular purpose or works at all,
10: unless he says so in writing. Refer to the GNU CC General Public
11: License for full details.
12:
13: Everyone is granted permission to copy, modify and redistribute
14: GNU CC, but only under the conditions described in the
15: GNU CC General Public License. A copy of this license is
16: supposed to have been given to you along with GNU CC so you
17: can know your rights and responsibilities. It should be in a
18: file named COPYING. Among other things, the copyright notice
19: and this notice must be preserved on all copies.
20:
21: This file describes the implementation notes of the GNU C Compiler for
22: the National Semiconductor 32032 chip (and 32000 family).
23:
24: The 32032 machine description and configuration file for this compiler
25: is, for NS32000 family machine, primarily machine independent.
26: However, since this release still depends on vendor-supplied
27: assemblers and linkers, the compiler must obey the existing
28: conventions of the actual machine to which this compiler is targeted.
29: In this case, the actual machine which this compiler was targeted to
30: is a Sequent Balance 8000, running DYNIX 2.1.
31:
32: The assembler for DYNIX 2.1 (and DYNIX 3.0, alas) does not cope with
33: the full generality of the addressing mode REGISTER RELATIVE.
34: Specifically, it generates incorrect code for operands of the
35: following form:
36:
37: sym(rn)
38:
39: Where `rn' is one of the general registers. Correct code is generated
40: for operands of the form
41:
42: sym(pn)
43:
44: where `pn' is one of the special processor registers (sb, fp, or sp).
45:
46: An equivalent operand can be generated by the form
47:
48: sym[rn:b]
49:
50: although this addressing mode is about twice as slow on the 32032.
51:
52: The more efficient addressing mode is controlled by defining the
53: constant SEQUENT_ADDRESS_BUG to 0. It is currently defined to be 1.
54:
55: Another bug in the assembler makes it impossible to compute with
56: explicit addresses. In order to compute with a symbolic address, it
57: is necessary to load that address into a register using the "addr"
58: instruction. For example, it is not possible to say
59:
60: cmpd _p,@_x
61:
62: Rather one must say
63:
64: addr _x,rn
65: cmpd _p,rn
66:
67:
68: The ns32032 chip has a number of known bugs. Any attempt to make the
69: compiler unaware of these deficiencies will surely bring disaster.
70: The current list of know bugs are as follows (list provided by Richard
71: Stallman):
72:
73: 1) instructions with two overlapping operands in memory
74: (unlikely in C code, perhaps impossible).
75:
76: 2) floating point conversion instructions with constant
77: operands (these may never happen, but I'm not certain).
78:
79: 3) operands crossing a page boundary. These can be prevented
80: by setting the flag in tm.h that requires strict alignment.
81:
82: 4) Scaled indexing in an insn following an insn that has a read-write
83: operand in memory. This can be prevented by placing a no-op in
84: between. I, Michael Tiemann, do not understand what exactly is meant
85: by `read-write operand in memory'. If this is refering to the special
86: TOS mode, for example "addd 5,tos" then one need not fear, since this
87: will never be generated. However, is this includes "addd 5,-4(fp)"
88: then there is room for disaster. The Sequent compiler does not insert
89: a no-op for code involving the latter, and I have been informed that
90: Sequent is aware of this list of bugs, so I must assume that it is not
91: a problem.
92:
93: 5) The 32032 cannot shift by 32 bits. It shifts modulo the word size
94: of the operand. Therefore, for 32-bit operations, 32-bit shifts are
95: interpreted as zero bit shifts. 32-bit shifts have been removed from
96: the compiler, but future hackers must be careful not to reintroduce
97: them.
98:
99: 6) The ns32032 is a very slow chip; however, some instructions are
100: still very much slower than one might expect. For example, it is
101: almost always faster to double a quantity by adding it to itself than
102: by shifting it by one, even if that quantity is deep in memory. The
103: MOVM instruction has a 20-cycle setup time, after which it moves data
104: at about the speed that normal moves would. It is also faster to use
105: address generation instructions than shift instructions for left
106: shifts less than 4. I do not claim that I generate optimal code for all
107: given patterns, but where I did escape from National's "clean
108: architecture", I did so because the timing specification from the data
109: book says that I will win if I do. I suppose this is called the
110: "performance gap".
111:
112:
113: Signed bitfield extraction has not been implemented. It is not
114: provided by the NS32032, and while it is most certainly possible to do
115: better than the standard shift-left/shift-right sequence, it is also
116: quite hairy. Also, since signed bitfields do not yet exist in C, this
117: omission seems relatively harmless.
118:
119:
120: Zero extractions could be better implemented if it were possible in
121: GCC to provide sized zero extractions: i.e. a byte zero extraction
122: would be allowed to yield a byte result. The current implementation
123: of GCC manifests 68000-ist thinking, where bitfields are extracted
124: into a register, and automatically sign/zero extended to fill the
125: register. See comments in ns32k.md around the "extzv" insn for more
126: details.
127:
128:
129: It should be noted that while the NS32000 family was designed to
130: provide odd-aligned addressing capability for multi-byte data (also
131: provided by the 68020, but not by the 68000 or 68010), many machines
132: do not opt to take advantage of this. For example, on the sequent,
133: although there is no advantage to long-word aligning word data, shorts
134: must be int-aligned in structs. This is an example of another
135: machine-specific machine dependency.
136:
137:
138: Because the ns32032 is has a coherent byte-order/bit-order
139: architecture, many instructions which would be different for
140: 68000-style machines, fold into the same instruction for the 32032.
141: The classic case is push effective address, where it does not matter
142: whether one is pushing a long, word, or byte address. They all will
143: push the same address.
144:
145:
146: The macro FUNCTION_VALUE_REGNO_P is probably not sufficient, what is
147: needed is FUNCTION_VALUE_P, which also takes a MODE parameter. In
148: this way it will be possible to determine more exactly whether a
149: register is really a function value register, or just one that happens
150: to look right.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.