1Copyright 2001, 2003, 2004 Free Software Foundation, Inc. 2 3This file is part of the GNU MP Library. 4 5The GNU MP Library is free software; you can redistribute it and/or modify 6it under the terms of the GNU Lesser General Public License as published by 7the Free Software Foundation; either version 3 of the License, or (at your 8option) any later version. 9 10The GNU MP Library is distributed in the hope that it will be useful, but 11WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY 12or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public 13License for more details. 14 15You should have received a copy of the GNU Lesser General Public License 16along with the GNU MP Library. If not, see http://www.gnu.org/licenses/. 17 18 19 20 21 22 M68K MPN SUBROUTINES 23 24 25This directory contains mpn functions for various m68k family chips. 26 27 28CODE ORGANIZATION 29 30 m68k m68000, m68010, m68060 31 m68k/mc68020 m68020, m68030, m68040, and CPU32 32 33 34The m5200 "coldfire", which is m68000 less a few instructions, currently has 35no assembler code support. 36 37 38STATUS 39 40The code herein is old and poorly maintained. If somebody really cared, it 41could be optimized substantially. For example, 42 43* mpn_add_n and mpn_sub_n could, with more unrolling be improved from 6 to 44 close to 4 c/l (on m68040). 45 46* The multiplication loops could be sped up by using the FPU. 47 48* mpn_lshift by 31 should use the special-case mpn_rshift by 1 code, and 49 vice versa mpn_rshift by 31 use the special lshift by 1, when operand 50 overlap permits. 51 52* On 68000, mpn_mul_1, mpn_addmul_1 and mpn_submul_1 could check for a 53 16-bit multiplier and use two multiplies per limb, not four. 54 55 Similarly various other _1 operations like mpn_mod_1, mpn_divrem_1, 56 mpn_divexact_1, mpn_modexact_1c_odd. 57 58* On 68000, mpn_lshift and mpn_rshift could use a roll and mask instead of 59 lsrl and lsll. This promises to be a speedup, effectively trading a 6+2*n 60 shift for one or two 4 cycle masks. Suggested by Jean-Charles Meyrignac. 61 62* config.guess detects 68000, 68010, CPU32 and 68020 by running some code, 63 but relies on system information for 030, 040 and 060. Can they be 64 identified by running some code? Currently this only makes a difference 65 to the compiler options selected, since we have no specific asm code for 66 those chips. 67 68One novel idea for 68000 would be to use a 16-bit limb instead of 32-bits. 69This would suit the native 16x16 multiply, but might make it difficult to 70get full value from the native 32x32 add/sub/etc. This would be an ABI 71option, and would select "__GMP_SHORT_LIMB" in gmp.h. 72 73Naturally an entirely new set of asm subroutines would be needed for a 7416-bit limb. Also there's various places in the C code assuming limb>=long, 75which would need to be updated, eg. mpz_set_ui. Some of the nails changes 76may have helped cover some of this. 77 78 79ASM FILES 80 81The .asm files are put through m4 for macro processing, and with the help of 82configure give either MIT or Motorola syntax. The generic mpn/asm-defs.m4 83is used, together with mpn/m68k/m68k-defs.m4. See comments in those files. 84 85Not all possible syntax variations are covered. GCC config/m68k for 86instance has things like $ for immediates on CRDS or reversed cmp order for 87AT&T SGS. These could probably be handled if anyone really needs it. 88 89 90CALLING CONVENTIONS 91 92The SVR4 standard has an int of 32 bits, and all parameters 32-bit aligned 93on the stack. 94 95PalmOS and perhaps various embedded systems intended for 68000 however use 96an int of 16 bits and parameters only 16-bit aligned on the stack. This is 97generated by "gcc -mshort" (and is the default for the PalmOS gcc port, we 98believe). 99 100The asm files adapt to these two ABIs by checking sizeof(unsigned), coming 101through config.m4 as SIZEOF_UNSIGNED. Only mpn_lshift and mpn_rshift are 102affected, all other routines take longs and pointers, which are 32-bits in 103both cases. 104 105Strictly speaking the size of an int doesn't determine the stack padding 106convention. But if int is 16 bits then we can definitely say the host 107system is not SVR4, and therefore may as well assume we're in 16-bit stack 108alignment. 109 110 111REFERENCES 112 113"Motorola M68000 Family Programmer's Reference Manual", available online, 114 115 http://e-www.motorola.com/brdata/PDFDB/docs/M68000PM.pdf 116 117"System V Application Binary Interface: Motorola 68000 Processor Family 118Supplement", AT&T, 1990, ISBN 0-13-877553-6. Has details of calling 119conventions and ELF style PIC coding. 120 121 122 123---------------- 124Local variables: 125mode: text 126fill-column: 76 127End: 128