Date: Fri, 4 Apr 2003 10:22:23 -0800 From: David Schultz <das@FreeBSD.ORG> To: Kris Kennaway <kris@obsecurity.org> Cc: Dag-Erling Smorgrav <des@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/alpha/alpha support.s src/sys/i386/i386 identcpu.c support.s src/sys/i386/include md_var.h src/sys/i386/isa npx.c src/sys/ia64/ia64 support.s src/sys/powerpc/powerpc bcopy.c src/sys/sparc64/sparc64 support.S ... Message-ID: <20030404182223.GA36706@HAL9000.homeunix.com> In-Reply-To: <20030404173635.GA22147@rot13.obsecurity.org> References: <200304041729.h34HTtVb027430@repoman.freebsd.org> <20030404173635.GA22147@rot13.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Kris Kennaway <kris@obsecurity.org>: > On Fri, Apr 04, 2003 at 09:29:55AM -0800, Dag-Erling Smorgrav wrote: > > > Define ovbcopy() as a macro which expands to the equivalent bcopy() call, > > to take care of the KAME IPv6 code which needs ovbcopy() because NetBSD's > > bcopy() doesn't handle overlap like ours. > > Was this for optimization reasons, hysterical raisins, or some other reason? The ovbcopy-->bcopy conversion doesn't make things any faster or slower, but it does make some minor optimizations impossible to implement in the future. I'm not sure I agree with the changes, but I don't violently disagree either. BTW, why does this change convert bcopy from a function pointer to a function that jumps to the address of a pointer? This looks like a net gain in lines of code and a net gain in pipeline stalls. Is there something in particular that it makes easier?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030404182223.GA36706>