> Yes. In practice the usual question is whether the compiler will
> evaluate the operands from left to right or from right to left,
> but the compiler is within its rights to evaluate the operands in
> any order it wants.
For ia64, it would be good to evaluate the operands in parallel.
One
([EMAIL PROTECTED]) nobly encouraged empiricism thusly...
> Just to encourage empiricism, I usually check stuff like that with
>
> % cat > foo.c
> main(){
> int i;
> i = 1 , 2;
> printf("%d\n",i);
> }
> % gcc foo.c
> % ./a.out
> 1
>
> or similar if I'm confused.
Indeed.
([EMAIL PROTECTED]) nobly encouraged empiricism thusly...
Just to encourage empiricism, I usually check stuff like that with
% cat foo.c
main(){
int i;
i = 1 , 2;
printf("%d\n",i);
}
% gcc foo.c
% ./a.out
1
or similar if I'm confused.
Indeed. Further curiosity
Yes. In practice the usual question is whether the compiler will
evaluate the operands from left to right or from right to left,
but the compiler is within its rights to evaluate the operands in
any order it wants.
For ia64, it would be good to evaluate the operands in parallel.
One could
[CC trimmed]
Bill Wendling wrote:
>
> Also sprach Tom Leete:
> }
> } You are correct that in C the rightmost argument is always
> } at the open end of the stack, and that varargs require that.
> } The opposite is called the Pascal convention.
> }
> Where in the standard does it say this? It's
On Tue, Oct 17, 2000 at 07:42:31AM +, Peter Samuelson wrote:
> So, if you choose left-to-right, how do you implement varargs? Keep in
> mind that prototypes are optional. I bet anything your solution is
> slower and more complex than right-to-left, as all known compilers do.
Calling a
> [Matti Aarnio]
> > > That depends mainly on question: Does your stack grow up or down ?
Actually a combination -- which direction do arguments grow in relation
to stack growth direction, and do you have a stack push instruction.
> [Ben Pfaff]
> > No it doesn't. It depends mainly on
On Tue, Oct 17, 2000 at 10:40:12AM +0100, Bernd Schmidt wrote:
> > I compiled using "gcc -S -Wall -O2 -fomit-frame-pointer -m486" to generate
> > the assembler code. The old code is 17 instructions long and the new code
> > is 11 instructions. As well as being shorter, simple timing test
Bill Wendling <[EMAIL PROTECTED]> writes:
> Also sprach Bernd Schmidt:
> } > Looking at the above code, I noticed that there are a lot of ++
> } > operations. I rewrote the code as:
> } >
> } > setup_from[0] = setup_from[1] = eaddrs[0];
> } > setup_from[2] = setup_from[3] =
On Tue, 17 Oct 2000, Horst von Brand wrote:
> Richard Guenther <[EMAIL PROTECTED]> said:
> > The following one is wrong, tho - should be rather
> > str[i] = dn[i]; i++;
>
> > > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
> >
Also sprach Tom Leete:
}
} You are correct that in C the rightmost argument is always
} at the open end of the stack, and that varargs require that.
} The opposite is called the Pascal convention.
}
Where in the standard does it say this? It's probably done most of the
time in this fashion for
Also sprach Bernd Schmidt:
} > Looking at the above code, I noticed that there are a lot of ++
} > operations. I rewrote the code as:
} >
} > setup_from[0] = setup_from[1] = eaddrs[0];
} > setup_from[2] = setup_from[3] = eaddrs[1];
} > setup_from[4] = setup_from[5] = eaddrs[2];
Also sprach Mark Montague:
}
} dn[i], i++ evaluates to i, but str[i] = dn[i], i++ sets str[i] to
} dn[i] first, then increments i returning its previous value, which is
} discarded. Which was probably specified this way so
}
} for(i=1,j=2; something; something else)
}
} works as expected,
Bernd Schmidt <[EMAIL PROTECTED]> said:
> On Tue, 17 Oct 2000, Richard Guenther wrote:
> > On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> > > On Tue, 17 Oct 2000, Richard Guenther wrote:
> > > > The following one is wrong, tho - should be rather
> > > > str[i] = dn[i]; i++;
> > >
>
Richard Guenther <[EMAIL PROTECTED]> said:
> On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> The following one is wrong, tho - should be rather
> str[i] = dn[i]; i++;
> > diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
> d/drivers/isdn/sc/debug.c
> > ---
Peter Samuelson wrote:
>
> [Matti Aarnio]
> > > That depends mainly on question: Does your stack grow up or down ?
>
> [Ben Pfaff]
> > No it doesn't. It depends mainly on whether the ABI for the machine
> > says that arguments are pushed onto the stack in left-to-right or
> >
Richard Guenther <[EMAIL PROTECTED]> writes:
> On Tue, 17 Oct 2000, Bernd Schmidt wrote:
>
> > On Tue, 17 Oct 2000, Richard Guenther wrote:
> >
> > > On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> > >
> > > > I've been playing with some gcc patches to detect code with undefined
> > > > behaviour
On Tue, 17 Oct 2000, Richard Guenther wrote:
> On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> > On Tue, 17 Oct 2000, Richard Guenther wrote:
> > > The following one is wrong, tho - should be rather
> > > str[i] = dn[i]; i++;
> >
> > Nope. (Well, at least you need to add extra
On Tue, 17 Oct 2000, Bernd Schmidt wrote:
> On Tue, 17 Oct 2000, Richard Guenther wrote:
>
> > On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> >
> > > I've been playing with some gcc patches to detect code with undefined
> > > behaviour of the i = i++ variety. The patch below fixes all places in
> Looking at the above code, I noticed that there are a lot of ++
> operations. I rewrote the code as:
>
> setup_from[0] = setup_from[1] = eaddrs[0];
> setup_from[2] = setup_from[3] = eaddrs[1];
> setup_from[4] = setup_from[5] = eaddrs[2];
> setup_from += 6;
>
> I compiled
On Tue, 17 Oct 2000, Helge Hafting wrote:
> Bernd Schmidt wrote:
> >
> > I've been playing with some gcc patches to detect code with undefined
> > behaviour of the i = i++ variety. The patch below fixes all places in
> > the kernel that I could find. Note that in some cases, it wasn't
> >
On Tue, 17 Oct 2000, Richard Guenther wrote:
> On Mon, 16 Oct 2000, Bernd Schmidt wrote:
>
> > I've been playing with some gcc patches to detect code with undefined
> > behaviour of the i = i++ variety. The patch below fixes all places in
> > the kernel that I could find. Note that in some
On Mon, 16 Oct 2000, Bernd Schmidt wrote:
> I've been playing with some gcc patches to detect code with undefined
> behaviour of the i = i++ variety. The patch below fixes all places in
> the kernel that I could find. Note that in some cases, it wasn't
> entirely clear what the code intended,
Bernd Schmidt wrote:
>
> I've been playing with some gcc patches to detect code with undefined
> behaviour of the i = i++ variety. The patch below fixes all places in
> the kernel that I could find. Note that in some cases, it wasn't
> entirely clear what the code intended, so I had to guess.
[Matti Aarnio]
> > That depends mainly on question: Does your stack grow up or down ?
[Ben Pfaff]
> No it doesn't. It depends mainly on whether the ABI for the machine
> says that arguments are pushed onto the stack in left-to-right or
> right-to-left order. You could do either on x86,
Peter Samuelson wrote:
[Matti Aarnio]
That depends mainly on question: Does your stack grow up or down ?
[Ben Pfaff]
No it doesn't. It depends mainly on whether the ABI for the machine
says that arguments are pushed onto the stack in left-to-right or
right-to-left order. You
Richard Guenther [EMAIL PROTECTED] said:
On Mon, 16 Oct 2000, Bernd Schmidt wrote:
The following one is wrong, tho - should be rather
str[i] = dn[i]; i++;
diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
d/drivers/isdn/sc/debug.c
---
Bernd Schmidt [EMAIL PROTECTED] said:
On Tue, 17 Oct 2000, Richard Guenther wrote:
On Tue, 17 Oct 2000, Bernd Schmidt wrote:
On Tue, 17 Oct 2000, Richard Guenther wrote:
The following one is wrong, tho - should be rather
str[i] = dn[i]; i++;
Nope. (Well, at
Also sprach Mark Montague:
}
} dn[i], i++ evaluates to i, but str[i] = dn[i], i++ sets str[i] to
} dn[i] first, then increments i returning its previous value, which is
} discarded. Which was probably specified this way so
}
} for(i=1,j=2; something; something else)
}
} works as expected,
Also sprach Bernd Schmidt:
} Looking at the above code, I noticed that there are a lot of ++
} operations. I rewrote the code as:
}
} setup_from[0] = setup_from[1] = eaddrs[0];
} setup_from[2] = setup_from[3] = eaddrs[1];
} setup_from[4] = setup_from[5] = eaddrs[2];
}
Also sprach Tom Leete:
}
} You are correct that in C the rightmost argument is always
} at the open end of the stack, and that varargs require that.
} The opposite is called the Pascal convention.
}
Where in the standard does it say this? It's probably done most of the
time in this fashion for
On Tue, 17 Oct 2000, Horst von Brand wrote:
Richard Guenther [EMAIL PROTECTED] said:
The following one is wrong, tho - should be rather
str[i] = dn[i]; i++;
diff -x log.build -x .* -dru linux-2.4/drivers/isdn/sc/debug.c linux-2.4-fixe
d/drivers/isdn/sc/debug.c
---
Bill Wendling [EMAIL PROTECTED] writes:
Also sprach Bernd Schmidt:
} Looking at the above code, I noticed that there are a lot of ++
} operations. I rewrote the code as:
}
} setup_from[0] = setup_from[1] = eaddrs[0];
} setup_from[2] = setup_from[3] = eaddrs[1];
}
On Tue, Oct 17, 2000 at 10:40:12AM +0100, Bernd Schmidt wrote:
I compiled using "gcc -S -Wall -O2 -fomit-frame-pointer -m486" to generate
the assembler code. The old code is 17 instructions long and the new code
is 11 instructions. As well as being shorter, simple timing test indicate
On Tue, Oct 17, 2000 at 07:42:31AM +, Peter Samuelson wrote:
So, if you choose left-to-right, how do you implement varargs? Keep in
mind that prototypes are optional. I bet anything your solution is
slower and more complex than right-to-left, as all known compilers do.
Calling a varargs
[CC trimmed]
Bill Wendling wrote:
Also sprach Tom Leete:
}
} You are correct that in C the rightmost argument is always
} at the open end of the stack, and that varargs require that.
} The opposite is called the Pascal convention.
}
Where in the standard does it say this? It's probably
Matti Aarnio <[EMAIL PROTECTED]> writes:
> On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
> > Yes. In practice the usual question is whether the compiler will
> > evaluate the operands from left to right or from right to left,
> > but the compiler is within its rights to evaluate
On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
> > > $ The order of evaluation of the function designator, the
> > > $ arguments, and subexpressions within the arguments is
> > > $ unspecified, ...
> >
> > I sit surprised and corrected. With every version of every C compiler
On Mon, 16 Oct 2000, Mike Castle wrote:
> On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote:
> > tmp = *p++;
> > *q = f(tmp, *p++);
> > return p;
> >
> > is equivalent to more idiomatic
> >
> > *q = f(p[0], p[1]);
> > return p+2;
>
>
> Which gets better assembler out of
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote:
> tmp = *p++;
> *q = f(tmp, *p++);
> return p;
>
> is equivalent to more idiomatic
>
> *q = f(p[0], p[1]);
> return p+2;
Which gets better assembler out of various versions of gcc?
mrc
--
Mike Castle Life is like a
>-Original Message-
>From: Alexander Viro [mailto:[EMAIL PROTECTED]]
[snip]
>
>No arguments here, but proposed fixes were remarkably ugly. Example:
>
>tmp = *p++;
>*q = f(tmp, *p++);
>return p;
>
>is equivalent to more idiomatic
>
>*q = f(p[0], p[1]);
>return p+2;
>
>And example with
Jonathan George <[EMAIL PROTECTED]> writes:
> > $ The order of evaluation of the function designator, the
> > $ arguments, and subexpressions within the arguments is
> > $ unspecified, ...
> >--
>
> I sit surprised and corrected. With every version of every C compiler on
> every OS
-Original Message-
From: Ben Pfaff [mailto:[EMAIL PROTECTED]]
>Jonathan George <[EMAIL PROTECTED]> writes:
>
>> This patch has many bogus corrections where new variables were created,
but
>> the order of evaluation is already unambiguous.
>>
>> For example each comma separated clause in
On 16 Oct 2000, Ben Pfaff wrote:
> Jonathan George <[EMAIL PROTECTED]> writes:
>
> > This patch has many bogus corrections where new variables were created, but
> > the order of evaluation is already unambiguous.
> >
> > For example each comma separated clause in an expression is guaranteed
Jonathan George <[EMAIL PROTECTED]> writes:
> This patch has many bogus corrections where new variables were created, but
> the order of evaluation is already unambiguous.
>
> For example each comma separated clause in an expression is guaranteed to be
> completely evaluated before the next
Also sprach Abramo Bagnara:
}
} Isn't this more efficient?
} n = (x>>32) | (x<<32);
} n = ((n & 0xLL)<<16) | (n & 0xLL)>>16;
} n = ((n & 0x00ff00ff00ff00ffLL)<<8) | (n & 0xff00ff00ff00ff00LL)>>8;
}
} 6 shift
} 4 and
} 3 or
}
Plus 3 assigns...but they
At 01:21 PM 10/16/00, Jeff Garzik wrote:
>Bernd Schmidt wrote:
> > diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
> linux-2.4-fixed/drivers/net/tulip/tulip_core.c
> > --- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
> > +++
Bernd Schmidt wrote:
>
> +
> +#define ___swab64(x) \
> +({ \
> + __u64 __x = (x); \
> + ((__u64)( \
> + (__u64)(((__u64)(__x) & (__u64)0x00ffULL) << 56) | \
> + (__u64)(((__u64)(__x) & (__u64)0xff00ULL) << 40) | \
> +
On Mon, 16 Oct 2000, Jeff Garzik wrote:
> > --- linux-2.4/drivers/scsi/aha152x.cMon Oct 16 13:51:24 2000
> > +++ linux-2.4-fixed/drivers/scsi/aha152x.c Mon Oct 16 14:51:29 2000
> > @@ -1280,7 +1280,8 @@
> > scsi_unregister(shpnt);
> >
Bernd Schmidt wrote:
> diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
>linux-2.4-fixed/drivers/net/tulip/tulip_core.c
> --- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
> +++ linux-2.4-fixed/drivers/net/tulip/tulip_core.c Mon Oct 16 15:40:12
Bernd Schmidt wrote:
diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
linux-2.4-fixed/drivers/net/tulip/tulip_core.c
--- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
+++ linux-2.4-fixed/drivers/net/tulip/tulip_core.c Mon Oct 16 15:40:12 2000
On Mon, 16 Oct 2000, Jeff Garzik wrote:
--- linux-2.4/drivers/scsi/aha152x.cMon Oct 16 13:51:24 2000
+++ linux-2.4-fixed/drivers/scsi/aha152x.c Mon Oct 16 14:51:29 2000
@@ -1280,7 +1280,8 @@
scsi_unregister(shpnt);
Bernd Schmidt wrote:
+
+#define ___swab64(x) \
+({ \
+ __u64 __x = (x); \
+ ((__u64)( \
+ (__u64)(((__u64)(__x) (__u64)0x00ffULL) 56) | \
+ (__u64)(((__u64)(__x) (__u64)0xff00ULL) 40) | \
+
At 01:21 PM 10/16/00, Jeff Garzik wrote:
Bernd Schmidt wrote:
diff -x log.build -x .* -dru linux-2.4/drivers/net/tulip/tulip_core.c
linux-2.4-fixed/drivers/net/tulip/tulip_core.c
--- linux-2.4/drivers/net/tulip/tulip_core.cMon Oct 16 13:51:23 2000
+++
Also sprach Abramo Bagnara:
}
} Isn't this more efficient?
} n = (x32) | (x32);
} n = ((n 0xLL)16) | (n 0xLL)16;
} n = ((n 0x00ff00ff00ff00ffLL)8) | (n 0xff00ff00ff00ff00LL)8;
}
} 6 shift
} 4 and
} 3 or
}
Plus 3 assigns...but they may get optimized
Jonathan George [EMAIL PROTECTED] writes:
This patch has many bogus corrections where new variables were created, but
the order of evaluation is already unambiguous.
For example each comma separated clause in an expression is guaranteed to be
completely evaluated before the next comma
On 16 Oct 2000, Ben Pfaff wrote:
Jonathan George [EMAIL PROTECTED] writes:
This patch has many bogus corrections where new variables were created, but
the order of evaluation is already unambiguous.
For example each comma separated clause in an expression is guaranteed to be
-Original Message-
From: Ben Pfaff [mailto:[EMAIL PROTECTED]]
Jonathan George [EMAIL PROTECTED] writes:
This patch has many bogus corrections where new variables were created,
but
the order of evaluation is already unambiguous.
For example each comma separated clause in an
-Original Message-
From: Alexander Viro [mailto:[EMAIL PROTECTED]]
[snip]
No arguments here, but proposed fixes were remarkably ugly. Example:
tmp = *p++;
*q = f(tmp, *p++);
return p;
is equivalent to more idiomatic
*q = f(p[0], p[1]);
return p+2;
And example with copying the string
Jonathan George [EMAIL PROTECTED] writes:
$ The order of evaluation of the function designator, the
$ arguments, and subexpressions within the arguments is
$ unspecified, ...
--
I sit surprised and corrected. With every version of every C compiler on
every OS I have ever
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote:
tmp = *p++;
*q = f(tmp, *p++);
return p;
is equivalent to more idiomatic
*q = f(p[0], p[1]);
return p+2;
Which gets better assembler out of various versions of gcc?
mrc
--
Mike Castle Life is like a clock:
On Mon, 16 Oct 2000, Mike Castle wrote:
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote:
tmp = *p++;
*q = f(tmp, *p++);
return p;
is equivalent to more idiomatic
*q = f(p[0], p[1]);
return p+2;
Which gets better assembler out of various versions of gcc?
On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
$ The order of evaluation of the function designator, the
$ arguments, and subexpressions within the arguments is
$ unspecified, ...
I sit surprised and corrected. With every version of every C compiler on
every OS
Matti Aarnio [EMAIL PROTECTED] writes:
On Mon, Oct 16, 2000 at 04:55:08PM -0400, Ben Pfaff wrote:
Yes. In practice the usual question is whether the compiler will
evaluate the operands from left to right or from right to left,
but the compiler is within its rights to evaluate the
64 matches
Mail list logo
