 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Old Wolf
Guest
|
 Posted: Mon Aug 28, 2006 3:04 pm Post subject: Left-shift of signed integers |
 |
|
In the C standard, if E1 is a signed int, then E1 << 1 is explicitly
defined as (E1 * 2), with undefined behaviour if this value is larger
than INT_MAX.
But the C++ standard (1998 version) says:
The value of E1 << E2 is E1 (interpreted as a bit pattern)
leftshifted E2 bit positions; vacated bits are zerofilled.
and has no comment on the resulting value. Does this mean
left shifts of signed integers are undefined? What if the int
has padding bits interspersed with value bits, and the shift
results in a trap representation? What if 0x4000 is left-shifted
by one bit, when INT_MAX is 0x7FFF ?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
 |
Guest
|
| Posted: Mon Aug 28, 2006 5:33 pm Post subject: Re: Left-shift of signed integers |
|
|
Old Wolf wrote:
| Quote: | In the C standard, if E1 is a signed int, then E1 << 1 is explicitly
defined as (E1 * 2), with undefined behaviour if this value is larger
than INT_MAX.
But the C++ standard (1998 version) says:
The value of E1 << E2 is E1 (interpreted as a bit pattern)
leftshifted E2 bit positions; vacated bits are zerofilled.
and has no comment on the resulting value. Does this mean
left shifts of signed integers are undefined? What if the int
has padding bits interspersed with value bits, and the shift
results in a trap representation? ...
|
The C++98 standard was approved before C99; as a result, the portions
of C++98 that are compatible with some version of the C standard, are
closer to the wording in C90 than to the (mostly) improved wording of
C99. Technically, therefore, C++98 incorporates many of the defects
that were fixed in C99. In general, I would recommend assuming that
some future version of the C++ standard will contain similar revisions
to fix those same defects. In the meantime I would recommend avoiding
writing code where the difference matters, if possible.
Padding bits were formally recognised only in C99, therefore the C90
wording that was copied over into C++98 didn't have to worry about
them. The C99 wording implies that they are skipped over by the shift.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Tue Aug 29, 2006 12:15 am Post subject: Re: Left-shift of signed integers |
|
|
Old Wolf wrote:
| Quote: | In the C standard, if E1 is a signed int, then E1 << 1 is explicitly
defined as (E1 * 2), with undefined behaviour if this value is larger
than INT_MAX.
But the C++ standard (1998 version) says:
The value of E1 << E2 is E1 (interpreted as a bit pattern)
leftshifted E2 bit positions; vacated bits are zerofilled.
and has no comment on the resulting value. Does this mean
left shifts of signed integers are undefined?
|
That's correct; left shifts of signed integers result
in undefined behavior. Try them on a UNISYS A series (48-bit signed magnitude)
or B series (36-bit ones complement) machine, or a PDP-10 (36-bit
ones complement) family machine. Admittedly there's very little running
hardware that isn't byte-oriented twos complement. But UNISYS is still
selling those things.
Ref: http://www.unisys.com/eprise/main/admin/corporate/doc/dorado-280-spec.pdf
http://www.unisys.com/eprise/main/admin/corporate/doc/ClearPath_Plus_Libra_Model_300_Server_Spec_Sheet.pdf
The UNISYS B series, the old UNIVAC 1100 line, is the longest-lived line in
computing, dating back to the vacuum-tube UNIVAC 1101 in 1951.
Considering that UNISYS pushes Java, which has standardized numeric formats, the
problems of simulating twos-complement arithmetic on the old iron have
been solved. With the PDP-10 line dead, it would probably be acceptable
to insist that C++ implementations now use a twos-complement representation.
John Nagle
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
Bo Persson
Guest
|
| Posted: Tue Aug 29, 2006 9:10 am Post subject: Re: Left-shift of signed integers |
|
|
"John Nagle" <nagle (AT) animats (DOT) com> skrev i meddelandet
news:X6HIg.1263$Cq4.306 (AT) newssvr25 (DOT) news.prodigy.net...
| Quote: | Old Wolf wrote:
In the C standard, if E1 is a signed int, then E1 << 1 is
explicitly
defined as (E1 * 2), with undefined behaviour if this value is
larger
than INT_MAX.
But the C++ standard (1998 version) says:
The value of E1 << E2 is E1 (interpreted as a bit pattern)
leftshifted E2 bit positions; vacated bits are zerofilled.
and has no comment on the resulting value. Does this mean
left shifts of signed integers are undefined?
That's correct; left shifts of signed integers result
in undefined behavior. Try them on a UNISYS A series (48-bit signed
magnitude)
or B series (36-bit ones complement) machine, or a PDP-10 (36-bit
ones complement) family machine. Admittedly there's very little
running
hardware that isn't byte-oriented twos complement. But UNISYS is
still
selling those things.
Ref:
http://www.unisys.com/eprise/main/admin/corporate/doc/dorado-280-spec.pdf
http://www.unisys.com/eprise/main/admin/corporate/doc/ClearPath_Plus_Libra_Model_300_Server_Spec_Sheet.pdf
The UNISYS B series, the old UNIVAC 1100 line, is the longest-lived
line in
computing, dating back to the vacuum-tube UNIVAC 1101 in 1951.
Considering that UNISYS pushes Java, which has standardized numeric
formats, the
problems of simulating twos-complement arithmetic on the old iron
have
been solved.
|
No, it has not really. The "solution" is to add additional processors,
with the "proper" hardware support for Java standard types.
| Quote: | With the PDP-10 line dead, it would probably be acceptable
to insist that C++ implementations now use a twos-complement
representation.
|
To make left shift of signed integers defined, or some other
improvement?
How about requiring 32-bits, byte addressed, IEEE floating point, no
EBCDIC, little endian, non-segmented memory, no padding bits?
Why is it so important to have fixed hardware characteristics, for
everyone?
And if you don't like Unisys, what about these guys:
http://www-03.ibm.com/systems/z/
Bo Persson
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
kanze
Guest
|
| Posted: Tue Aug 29, 2006 3:23 pm Post subject: Re: Left-shift of signed integers |
|
|
Old Wolf wrote:
| Quote: | In the C standard, if E1 is a signed int, then E1 << 1 is explicitly
defined as (E1 * 2), with undefined behaviour if this value is larger
than INT_MAX.
|
That's interesting, because it is a real change compared to C90.
And existing practice as well. Note that it also says that it
is undefined behavior if E1 is negative!
| Quote: | But the C++ standard (1998 version) says:
The value of E1 << E2 is E1 (interpreted as a bit pattern)
leftshifted E2 bit positions; vacated bits are zerofilled.
and has no comment on the resulting value.
|
The C standard also says this. It then comments on what it
means.
| Quote: | Does this mean left shifts of signed integers are undefined?
|
No. It means that the value bits of the representation will be
left shifted, with 0's bits inserted to the right.
| Quote: | What if the int has padding bits interspersed with value bits,
|
They don't count. In general, padding bits are invisible,
except when considering the relationship between the size of an
object, and its max and min values. Otherwise, they wouldn't be
padding bits, but would participate in the value representation.
| Quote: | and the shift results in a trap representation? What if 0x4000
is left-shifted by one bit, when INT_MAX is 0x7FFF ?
|
The C++ standard says that you will get whatever integer is
represented by the bit pattern 0x8000. Note that on a one's
complement or a signed magnitude machine, this may be a trapping
value. Which is probably why the C standard is worded the way
it is.
Personally, I would have preferred that the "clarification" be
more along the lines of "the value is the value represented by
the resulting bit pattern, and may be trapping." Followed, if
need be, by some statements like those in the C standard,
guaranteeing that it won't be trapping for certain values.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
John Nagle
Guest
|
| Posted: Thu Aug 31, 2006 12:52 am Post subject: Re: Left-shift of signed integers |
|
|
Bo Persson wrote:
| Quote: | "John Nagle" <nagle (AT) animats (DOT) com> skrev i meddelandet
news:X6HIg.1263$Cq4.306 (AT) newssvr25 (DOT) news.prodigy.net...
Considering that UNISYS pushes Java, which has standardized numeric
formats, the
problems of simulating twos-complement arithmetic on the old iron
have
been solved.
No, it has not really. The "solution" is to add additional processors,
with the "proper" hardware support for Java standard types.
|
Surprisingly enough, UNISYS is actually supporting Java
on the OS2200 36-bit CPUs.
http://ecommunity.unisys.com/unisys/solution_center/sc_documents/whitepaper/41264862-100.pdf
Yes, you can also plug in an x86 CPU board and run Java on it in the
same cabinet, but you don't have to.
However, it appears that UNISYS does not support C++ for the OS2200 line, so
perhaps we can forget about ones complement hardware.
IBM mainframes have 32-bit twos-complement integers, but the floating point
formats are not IEEE compatible. No problem there.
It looks like there's nothing left that runs C++ and doesn't have twos
complement integers.
John Nagle
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ] |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
