Re: in which form real and integer values are saved in memory
- From: Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx>
- Date: 09 Jul 2009 02:50:05 -0700
Keith Thompson <kst-u@xxxxxxx> writes:
Tim Rentsch <txr@xxxxxxxxxxxxxxxxxxx> writes:
Keith Thompson <kst-u@xxxxxxx> writes:
Charlton Wilbur <cwilbur@xxxxxxxxxxxxxx> writes:
"BP" == Ben Pfaff <blp@xxxxxxxxxxxxxxx> writes:
BP> Ed Prochak <edprochak@xxxxxxxxx> writes:
>> intergers may be big endian or little endian, ones complement or
>> twos complement, BCD or others.
BP> I don't think that BCD is a valid representation for C integer
BP> types.
...unless there's no way for a conforming program to know the
difference.
It would be difficult to arrange that, though not impossible.
Depending on how this statement is meant, the proposition is
either trivially true or wrong.
Clearly a C implementation can use BCD to encode C values
using the simple trick of having one BCD digit per bit.
One octet (two nibbles) would hold two C "bits", or four
octets per char (with CHAR_BIT == 8).
That's not what I had in mind.
However, if "representation" is meant in the sense that
the Standard uses the term (as in "object representation",
for example), integers cannot be represented using
BCD, as that is not consistent with other requirements
for representation of integers.
What I was thinking of was an implementation that uses BCD for integer
representation (so that a stored bit pattern of 0001 0101 represents
the value 15), but that goes through substantial gyrations to make it
*appear* to be using a pure binary representation. If you examined
the underlying representations of objects using, say, a debugger,
you'd see the BCD, but the BCD representation wouldn't leak out to
become visible in the behavior of any program that avoids undefined
behavior. The implementation would satisfy the "least requirements"
of C99 5.1.2.3p5.
Yes, that would be another way of doing it. At the far end of the
spectrum, the entire program state could be represented as one
gigantic BCD-encoded integer (which would mean decoding/encoding
essentially the entire program state at every point). Just as silly
(or even sillier?), but of course the point is to ask whether it
can be done, not how useful it is.
This would be a very difficult and silly thing to do, but I'm not
convinced it would violate the standard.
The counterargument is that the representation requirements of 6.2.6.1
must be met by the underlying representation, and that satisfying
5.1.2.3p5 is insufficient.
To put it another way, it should be possible to implement C on top of
a binary virtual machine running on BCD hardware.
Right. BCD encoding (or any other computable encoding) is allowed
in the underlying hardware, but not in the C virtual machine.
.
- References:
- in which form real and integer values are saved in memory
- From: manish sahu
- Re: in which form real and integer values are saved in memory
- From: Ed Prochak
- Re: in which form real and integer values are saved in memory
- From: Ben Pfaff
- Re: in which form real and integer values are saved in memory
- From: Charlton Wilbur
- Re: in which form real and integer values are saved in memory
- From: Keith Thompson
- Re: in which form real and integer values are saved in memory
- From: Tim Rentsch
- Re: in which form real and integer values are saved in memory
- From: Keith Thompson
- in which form real and integer values are saved in memory
- Prev by Date: Re: beginner with programming, how to learn to debug and few C general questions
- Next by Date: Re: goto
- Previous by thread: Re: in which form real and integer values are saved in memory
- Next by thread: Re: in which form real and integer values are saved in memory
- Index(es):
Relevant Pages
|
