README
上传用户:qaz666999
上传日期:2022-08-06
资源大小:2570k
文件大小:4k
- Copyright 2001, 2003, 2004 Free Software Foundation, Inc.
- This file is part of the GNU MP Library.
- The GNU MP Library is free software; you can redistribute it and/or modify
- it under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 3 of the License, or (at your
- option) any later version.
- The GNU MP Library is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public
- License for more details.
- You should have received a copy of the GNU Lesser General Public License
- along with the GNU MP Library. If not, see http://www.gnu.org/licenses/.
- M68K MPN SUBROUTINES
- This directory contains mpn functions for various m68k family chips.
- CODE ORGANIZATION
- m68k m68000, m68010, m68060
- m68k/mc68020 m68020, m68030, m68040, and CPU32
- The m5200 "coldfire", which is m68000 less a few instructions, currently has
- no assembler code support.
- STATUS
- The code herein is old and poorly maintained. If somebody really cared, it
- could be optimized substantially. For example,
- * mpn_add_n and mpn_sub_n could, with more unrolling be improved from 6 to
- close to 4 c/l (on m68040).
- * The multiplication loops could be sped up by using the FPU.
- * mpn_lshift by 31 should use the special-case mpn_rshift by 1 code, and
- vice versa mpn_rshift by 31 use the special lshift by 1, when operand
- overlap permits.
- * On 68000, mpn_mul_1, mpn_addmul_1 and mpn_submul_1 could check for a
- 16-bit multiplier and use two multiplies per limb, not four.
- Similarly various other _1 operations like mpn_mod_1, mpn_divrem_1,
- mpn_divexact_1, mpn_modexact_1c_odd.
- * On 68000, mpn_lshift and mpn_rshift could use a roll and mask instead of
- lsrl and lsll. This promises to be a speedup, effectively trading a 6+2*n
- shift for one or two 4 cycle masks. Suggested by Jean-Charles Meyrignac.
- * config.guess detects 68000, 68010, CPU32 and 68020 by running some code,
- but relies on system information for 030, 040 and 060. Can they be
- identified by running some code? Currently this only makes a difference
- to the compiler options selected, since we have no specific asm code for
- those chips.
- One novel idea for 68000 would be to use a 16-bit limb instead of 32-bits.
- This would suit the native 16x16 multiply, but might make it difficult to
- get full value from the native 32x32 add/sub/etc. This would be an ABI
- option, and would select "__GMP_SHORT_LIMB" in gmp.h.
- Naturally an entirely new set of asm subroutines would be needed for a
- 16-bit limb. Also there's various places in the C code assuming limb>=long,
- which would need to be updated, eg. mpz_set_ui. Some of the nails changes
- may have helped cover some of this.
- ASM FILES
- The .asm files are put through m4 for macro processing, and with the help of
- configure give either MIT or Motorola syntax. The generic mpn/asm-defs.m4
- is used, together with mpn/m68k/m68k-defs.m4. See comments in those files.
- Not all possible syntax variations are covered. GCC config/m68k for
- instance has things like $ for immediates on CRDS or reversed cmp order for
- AT&T SGS. These could probably be handled if anyone really needs it.
- CALLING CONVENTIONS
- The SVR4 standard has an int of 32 bits, and all parameters 32-bit aligned
- on the stack.
- PalmOS and perhaps various embedded systems intended for 68000 however use
- an int of 16 bits and parameters only 16-bit aligned on the stack. This is
- generated by "gcc -mshort" (and is the default for the PalmOS gcc port, we
- believe).
- The asm files adapt to these two ABIs by checking sizeof(unsigned), coming
- through config.m4 as SIZEOF_UNSIGNED. Only mpn_lshift and mpn_rshift are
- affected, all other routines take longs and pointers, which are 32-bits in
- both cases.
- Strictly speaking the size of an int doesn't determine the stack padding
- convention. But if int is 16 bits then we can definitely say the host
- system is not SVR4, and therefore may as well assume we're in 16-bit stack
- alignment.
- REFERENCES
- "Motorola M68000 Family Programmer's Reference Manual", available online,
- http://e-www.motorola.com/brdata/PDFDB/docs/M68000PM.pdf
- "System V Application Binary Interface: Motorola 68000 Processor Family
- Supplement", AT&T, 1990, ISBN 0-13-877553-6. Has details of calling
- conventions and ELF style PIC coding.
- ----------------
- Local variables:
- mode: text
- fill-column: 76
- End: