On Apr 12, 11:13 am, Jack Klein <jackkl...@[EMAIL PROTECTED]
> wrote:
> On Fri, 11 Apr 2008 15:33:41 CST, Olivier Langlois
> <olangl...@[EMAIL PROTECTED]
> wrote in comp.lang.c++.moderated:
> > The root for this behavior probably originates from C but I am really
> > curious why the standard makes the ****ft operator so unintuitive.
>
> The ****ft operator mimics the underlying behavior of the hardware,
> which differs on various architectures. This is exactly the same
> reason that right ****fting negative signed values and signed value
> overflow have undefined results, namely because what the underlying
> hardware does can be different.
Only ****fts to the left can produce undefined behavior in C++ - ****fts
to the right produce - at the very least - "implementation-defined"
results. In other words, ****fts to the right always lead to well-
defined and documented values, whereas even ****fting one-too-many bits
to the left - might well be fatal to the program. Now, perhaps thirty
years ago there were machines that could ****ft bits reliably only in
one direction - but those machines are long gone and forgotten - by
everyone, that is, except the C++ Standard.
> Nowadays, most modern processors mask the ****ft value before it goes
> to the ****fter hardware. When ****fting a 32-bit register, they mask
> the ****ft argument with 0x1f. This is especially true of processors
> with barrel ****fters that can ****ft by any number in a single cycle,
> instead of one cycle per bit ****fted.
>
> In many ways, C++ shares one of the most im****tant features of C,
> namely, you don't pay for what you don't use. The vast majority of
> programs never try to ****ft a value by too many bits, so the source
> statement turns into the minimal object code to use the hardware ****ft
> instruction.
The issue is not the code generated, but whether the generated code
will produce well-defined results. Clearly, leftward ****fts are just
as well-defined as rightward ****fts on any conceivable modern hardware
- so the bit-****fting description of the C++ Standard should be
updated (with "implementation-defined" or even "unspecified" in place
of "undefined" behavior) to reflect that reality.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
