[9fans] bcopy in APE

[9fans] bcopy in APE

[northern snowfall]

Finishing out my network stack redesign in netbsd, I glanced
at the source of the bcopy function. The BSD implementation,
found at /sys/lib/libsa/bcopy.c, increments while copying
octets if arg1 is greater than arg2.

However, the plan9 APE implementation of bcopy (found at
/sys/src/ape/lib/ap/gen/memmove.c) decrements.

My question is, why does the function need to increment or
decrement at all? And if there is a specific reason, why does
plan9's implementation do it opposite of the netbsd? I really
have no idea why the if(x < y) clause is needed.

Comments?
Don

http://www.7f.no-ip.com/~north_

Yes, soon. Just email me if you need something off the site.

Re: [9fans] bcopy in APE

[northern snowfall]

> My question is, why does the function need to increment or
> decrement at all?


Oh, I get it. Because we're preserving the source vector as best
we can. I was just overthinking. Anyone care to confirm or
elaborate?

> And if there is a specific reason, why does
> plan9's implementation do it opposite of the netbsd?


Aha! I just realized that the destination argument in the
plan9 memmove is the source argument in the BSD bcopy.
And, the memmove call in bcopy (/sys/src/ape/lib/bsd/bcopy.c)
flips the arguments appropriately. Hah, okay. Duh.

Obviously, I need sleep. G'night.
Don

http://www.7f.no-ip.com/~north_

Yes, soon. Just email me if you need something off the site.

Re: [9fans] bcopy in APE

[C H Forsyth]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

memmove(s+1, s, 8);

it's usually desirable that after the copy
s[2] gets what s[1] had in it, not s[0]
(and so on).  just checking the initial pointers
is fractionally cheaper than the full check for overlap, but
is enough to guarantee safety.
i did find that on 386 it was better to do the full
check because the forward copy was much faster,
and the cheap check, though safe, meant that
arbitrarily many copies ended up taking the reverse-copy path,
just because of malloc outcomes (say).

overlapped copy was used on some architectures to
set whole buffers to a value having set the first byte, but it's
otherwise not usually what's desired.

[-- Attachment #2: Type: message/rfc822, Size: 2947 bytes --]

From: northern snowfall <dbailey27@ameritech.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bcopy in APE
Date: Mon, 15 Sep 2003 03:36:36 -0500
Message-ID: <3F657A14.1090709@ameritech.net>

> My question is, why does the function need to increment or
> decrement at all?


Oh, I get it. Because we're preserving the source vector as best
we can. I was just overthinking. Anyone care to confirm or
elaborate?

> And if there is a specific reason, why does
> plan9's implementation do it opposite of the netbsd?


Aha! I just realized that the destination argument in the
plan9 memmove is the source argument in the BSD bcopy.
And, the memmove call in bcopy (/sys/src/ape/lib/bsd/bcopy.c)
flips the arguments appropriately. Hah, okay. Duh.

Obviously, I need sleep. G'night.
Don

http://www.7f.no-ip.com/~north_

Yes, soon. Just email me if you need something off the site.

Re: [9fans] bcopy in APE

[boyd, rounin]

> Finishing out my network stack redesign in netbsd, I glanced
> at the source of the bcopy function. The BSD implementation,
> found at /sys/lib/libsa/bcopy.c, increments while copying
> octets if arg1 is greater than arg2.

is this not the overlapping memory bcopy problem?