>Number:         2572
>Category:       kern
>Synopsis:       kernel could use memcpy/memmove/memset to its own advantage
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 26 20:50:02 1996
>Last-Modified:
>Originator:     J.T. Conklin
>Organization:
	
>Release:        1.2_BETA
>Environment:
	
System: NetBSD slave.cygnus.com 1.2_ALPHA NetBSD 1.2_ALPHA (GENERIC) #7: Thu Jun 13 14:30:47 PDT 1996 jtc@slave.cygnus.com:/usr/src/sys/arch/sun3/compile/GENERIC sun3

>Description:
Compilers like gcc "know" about memcpy, memmove and memset and can replace
the function calls with equivalent code when appropriate.  This is not true
with the traditional BSD bcopy, ovbcopy, and bzero functions currently used.
The inline functions can result in smaller and/or faster code.

I added macros that mapped bcopy to memcpy in sys/systm.h, and gcc decided
to inline about ~40% of the calls in my i386 GENERIC kernel.

The gcc in the NetBSD tree is not able to inline memset, but I have 
submitted a patch to the FSF which inlines memset when the second 
argument is zero.  It may not be worth converting bzero to memset
until a gcc with that feature is integrated into our tree, as 
memset requires an additional function argument.

>How-To-Repeat:
	
>Fix:
A cheezy fix is to use macros in sys/systm.h that map bzero, bcopy, and 
ovbcopy to their ansi equivalents.

	#define bcopy(s, t, n)		memcpy(t, s, n)
	#define ovbcopy(s, t, n)	memmove(t, s, n)
	#define bzero(s, n)		memset(s, 0, n)

Changing all the source files to use those functions is perhaps a better
solution.
>Audit-Trail:
>Unformatted: