22 Feb
2015
22 Feb
'15
3:49 a.m.
On Sat, Feb 21, 2015 at 09:51:52AM -0800, Chuck Guzis wrote:
[...]
However, given such a generous word length, the
designers of this machine
decide not to dedicate special hardware toward handling 64 bit integers, but
have said that 48 bits should be long enough for anyone, and so treat integer
arithmetic as a subset of floating point (straightforward enough). So not all
values of a 64 bit word reflect valid integers--the exponent must be a
certain value--anything else is floating point.
Perhaps surprisingly, this model is actually used in several non-C languages on
real-world (virtual) machines, albeit with IEEE 754 double-precision
floating-point numbers (aka "binary64") which can actually exactly represent
all of the integers between -2^53 and +2^53. No, there's no off-by-one error on
those numbers: 2^53 is the first floating-point number where the exponent can
only represent multiples of two instead of all of the integers, but that's fine
because 2^53 *is* divisible by two.
Now, here's where we get into sticky territory.
Since C draws no data type
distinctions between bitwise logical operations on ints and arithmetic
operations, is it possible to implement C on this machine? It should be
obvious that bitwise logical operations on a 64 bit int, whose upper 16 bits
must conform to a special case of a float, that all logical operations on an
int do not result in legal int values.
What you appear to be describing is taking the float64 value, treating the bits
as an int64_t, doing the bitwise operation, and then treating those bits as a
float64 again. That will indeed summon nasal demons on any machine and not just
your hypothetical one. Instead, it needs to do actual representation
conversions.
Section 6.2.6.2 ("Integer types") seems to throw a spanner in the works. It
describes an integer as containing N "value bits", each of which represent
values 1 through 2^(N-1), zero or more "padding bits" which may contain any
values the implementation desires, plus a sign bit for signed types. This is
*almost* compatible with IEEE 754 floating point in that the exponent can go
into the padding bits, but the value bits vary meaning depending on the
exponent. In this case, an alternative floating-point representation would
suffice, as would just ignoring that bit of the standard as being unreasonable
and making no practical difference.
This wording likewise torpedoes C on a non-binary machine, but again I'd just
ignore this imposition of a specific integer representation as ridiculous.
Binary operations would be rather tedious and have to be implemented in a slow
library call in much the same way as for floating-point on machines without
FPUs, but it's doable.