21 Feb
2015
21 Feb
'15
2:49 p.m.
On 02/21/2015 12:26 PM, Mouse wrote:
Well, this makes it impossible to implement long long,
which (loosely
put) must have at least 64 bits of range. But let's pretend that long
long doesn't exist, or perhaps that all the bit counts you give are
doubled, or some such.
I think a double-precision type could be shoehorned if we decided to
describe as our subset of floating point terms--96 bits of precision in
two 64 bit words, with the exponent field of the more significant being
48 larger than the least significant--and both being unnormalized.
Basically 96 bits of integer spread across 128 bits.
Consider this one--in the arrangement described, there's no particular
reason that the exponent (protected padding bits if you will) need to be
in the most significant bit position in a word. You could exchange the
positions of the exponent and significand or even scatter the
exponent/padding bits among the significand bits.
How do bit logical operations (especially shift) operate then?
FSVO "byte", I agree. However, since
we've been discussing C, there's
a _lot_ of (C) code that assumes that char * has the same size and
representation as other pointer types, even though there's no
justification in the C spec for such an assumption. (POSIX, on the
other hand, may impose such a restriction; I don't have even a draft of
POSIX handy to check.)
One thing that I've never understood was the lack of a bit type in C
(not the struct bit length specification), but something encountered on
bit-addressed architectures. That is, a bit array starting and ending
at arbitrary addresses, complete with a pointer that can be dereferenced
to select a specific bit. Vector machines certainly use this capability
and C seems to be totally oblivious to it (c.f. sparse and control vectors).
The biggest problem of C to me is the existing code base that makes all
sorts of assumptions about data type and structures. Because this is
The Way Things Are, it becomes more difficult to propose alternative
architectures that might be more efficient. Witness the "nUxi" problem
that plagued early ports of That Operating System.
I recall the moan from one of my project members when confronted with
automatic optimization of C. "A *&^%$ pointer can refer to ANYTHING!"
Ah well, time for me to get back to coding for my ternary-based machine
that uses Murray code as its character set.
--Chuck