NameDateSize

..Today37

aors_n.asmH A D22-Aug-20172.4 KiB

gmp-mparam.hH A D22-Aug-20172.7 KiB

lshift.asmH A D22-Aug-20174 KiB

m68k-defs.m4H A D22-Aug-20175.9 KiB

mc68020/H22-Aug-20177

READMEH A D22-Aug-20174.7 KiB

rshift.asmH A D22-Aug-20174 KiB

t-m68k-defs.plH A D22-Aug-20172.6 KiB

README

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