Return to NS32K.README CVS log

Up to [Research Unix] / researchv10dc / cmd / gcc

Annotation of researchv10dc/cmd/gcc/NS32K.README, revision 1.1

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.