Re: RFC: New userspace fetch/store API

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> 	int err = 0;
>>> 	long hisflags = ufetch_64(flag1p, &err) | ufetch_64(flag2p, &err);

>>> 	if (err) return EFAULT;

>>> 	do_something(hisflags);

>> I like this, because it swaps the cost of the value that is always
>> needed (which was expensive) versus the one that isn't expected
>> often (the error case, was cheap).

> Huh?  The code always has to access err to work correctly.  You don't
> save anything.

Let's look at the no-error (presumably common) case:

if (ufetch_64(flag1p,&val1)) return(EFAULT);
if (ufetch_64(flag2p,&val2)) return(EFAULT);
do_something(val1|val2)
->
ufetch_64 fetches first value
ufetch_64 writes through its second argument, returns false
ufetch_64 fetches second value
ufetch_64 writes through its second argument, returns false
caller reads val1
caller reads val2
caller computes val1|val2
caller does something with it

versus

uint64_t hisflags = ufetch_64(flag1p, &err) | ufetch_64(flag2p, &err);
if (err) return EFAULT;
do_something(hisflags);
->
ufetch_64 fetches first value
ufetch_64 doesn't write through its second argument, returns val1
ufetch_64 fetches second value
ufetch_64 doesn't write through its second argument, returns val2
caller computes val1|val2
caller reads err, tests it, discovers no error
caller does something with it

Looks to me as though the second way saves two writes and one read.
Even if you test error after each call, instead of once after the whole
sequence, you save two writes.  What am I missing?

(The reading of val1 and val2 in the first case, and the calls to
ufetch_64 in the second case, may be switched, but that doesn't affect
the counts.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B