From: wood@gen-rtx.rtp.dg.com (Tom Wood)
Subject: Re: gcc 2.1 on a DG Aviion
Date: Thu, 9 Apr 92 18:34:56 GMT
Organization: Data General Corporation, RTP, NC.

Jim Reiss) writes:

> Does anyone know of a way to keep gcc v2.x for m88k systems from adding
> movstrSI and movstrHI calls to the objects it generates?  The -fno-inline
> option doesn't seem to do enough.  MIPS versions of the compiler have
> a -mmemcpy option which appears to do something like this, but not the m88k
> one.  Anyone have any thoughts?  Any ideas appreciated.
> 
> Oh, in case anyone is wondering "why?", an object library is not 88open
> compliant if it contains references to "movstrHI48x18" and "movstrSI64n64"
> and "movstrSI96x16".  Just ask the library verifier.

The 88open Object Compatibility Standard makes provisions to allow a
compiler to use support routines referenced by compiled code.  That's
exactly what the movstr functions are.  I admit that this is a bit
unusual for a C compiler to be doing, but on the m88100, there are
good reasons to do this.

One solution to your problem is to supply a copy of gnulib along with
your object libarary.  You can even include the mov*.o objects if you
want.  This is the solution recommended by Data General.

The -mmemcpy option (shoot, why not make it just -memcpy) is certainly
worth considering.  Personally, I'd prefer to not add another option
as this complicates the testing process.  You could get the effect of
having this option by rebuilding the compiler and modifying the function
`expand_block_move' in m88k.c to not choose either `block_move_loop'
or `block_move_no_loop'.  It would probably be a good idea to increase
the point where a straight-line sequence of ld/st operations is used
instead of a call to memcpy from 3 to say 8.  Here's a patch that does
this:

*** m88k.c.orig	Thu Apr  9 14:24:04 1992
--- m88k.c	Thu Apr  9 14:24:37 1992
*************** expand_block_move (dest_mem, src_mem, op
*** 390,409 ****
      align = 4;
    else if (align <= 0 || align == 3)
      abort ();	/* block move invalid alignment.  */
  
!   if (constp && bytes <= 3 * align)
      block_move_sequence (operands[0], dest_mem, operands[1], src_mem,
  			 bytes, align, 0);
! 
    else if (constp && bytes <= best_from_bytes[align])
      block_move_no_loop (operands[0], dest_mem, operands[1], src_mem,
  			bytes, align);
  
    else if (constp && align == 4)
      block_move_loop (operands[0], dest_mem, operands[1], src_mem,
  		     bytes, align);
! 
    else
      {
  #ifdef TARGET_MEM_FUNCTIONS
        emit_library_call (gen_rtx (SYMBOL_REF, Pmode, "memcpy"), 0,
--- 390,409 ----
      align = 4;
    else if (align <= 0 || align == 3)
      abort ();	/* block move invalid alignment.  */
  
!   if (constp && bytes <= 8 * align)
      block_move_sequence (operands[0], dest_mem, operands[1], src_mem,
  			 bytes, align, 0);
! #if 0 /* Don't use the movstr functions.  */
    else if (constp && bytes <= best_from_bytes[align])
      block_move_no_loop (operands[0], dest_mem, operands[1], src_mem,
  			bytes, align);
  
    else if (constp && align == 4)
      block_move_loop (operands[0], dest_mem, operands[1], src_mem,
  		     bytes, align);
! #endif
    else
      {
  #ifdef TARGET_MEM_FUNCTIONS
        emit_library_call (gen_rtx (SYMBOL_REF, Pmode, "memcpy"), 0,
---
			Tom Wood	(919) 248-6067
			Data General, Research Triangle Park, NC
			wood@dg-rtp.dg.com
Xref: sparky comp.sys.m88k:188 comp.sys.m68k:564 comp.unix.admin:2783