* mpn/m68k/lshift.asm, mpn/m68k/rshift.asm: Support 16-bit int and

	stack alignment.
	* mpn/m68k/README: Add notes on this.

1 files changed, 34 insertions, 12 deletions

diff --git a/mpn/m68k/README b/mpn/m68k/README
index f03148b3b..7319896ff 100644
--- a/mpn/m68k/README
+++ b/mpn/m68k/README
@@ -37,17 +37,6 @@ The m5200 "coldfire", which is m68000 less a few instructions, currently has
 no assembler code support.
 
 
-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.
-
-
 STATUS
 
 The code herein is old and poorly maintained.  If somebody really cared, it
@@ -59,7 +48,8 @@ could be optimized substantially.  For example,
 * 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.
+  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.
@@ -88,6 +78,38 @@ 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,