Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Jun 2001 14:56:56 -0700 (PDT)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Peter Pentchev <roam@orbitel.bg>
Cc:        Mikhail Teterin <mi@aldan.algebra.com>, jlemon@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: Inline optimized bzero (was Re: cvs commit: src/sys/netinet tcp_subr.c)
Message-ID:  <200106232156.f5NLuu574208@earth.backplane.com>
References:  <200106231912.f5NJCUE01011@aldan.algebra.com> <200106232102.f5NL2fY73920@earth.backplane.com> <20010624003559.D564@ringworld.oblivion.bg>

next in thread | previous in thread | raw e-mail | index | archive | help

:
:Hi,
:
:Just a minor remark: this should either go in machine-dependent code,
:and really work on a size of the MD int type, or it should be called
:bzero32() or something, and work with int32_t.
:
:Other than that, yes, this looks like it would be a Good Thing(tm).
:
:G'luck,
:Peter
:
:-- 
:Nostalgia ain't what it used to be.

    It's machine independant... even if sizeof(int) changes.  Or it should
    be.  Oops.. not quite.  The 'bytes -= 4' should be 
    'bytes -= sizeof(int)'.  I'll fix that now.  There... NOW it's
    machine independant!

    The issue here is that in order to call bzerol() you have to know that
    the pointer and size you are passing is at least integer-aligned
    (whatever that size winds up being on the architecture).  Since nearly
    all structures in the system have an 'int', 'long', or pointer
    declaration, they will be so-aligned and thus be compatible with
    bzerol().  Calling bzerol() bzero32() makes no such guarentee, because
    'int' could very well be 64 bits and then bzero32() wouldn't be
    sufficiently optimal.

						-Matt

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200106232156.f5NLuu574208>