🚀 go-pugleaf

In article <4e5b5u$7s5@weck.brokersys.com> jguthrie@brokersys.com  writes:

> Peter Moylan (peter@fourier.newcastle.edu.au) wrote:
> 
> : Now, with x a variable of type Cheat, you can do bit operations
> : on x.bits, and the answer will turn up in x.val.  This isn't
> : portable, but then operations requiring type-casting are
> : inherently non-portable in any language.
> 
> (At least you don't call it coercion.)
> 
> I disagree with your last statement, because an awful lot of experience
> suggests that it just isn't true in the most typical case.
> 
> Look, most everyone posting on this newsgroup programs for computers with
> certain characteristics.  These computers store signed integers with 
> twos-complement notation and use the IEEE floating-point formats.

Yes but one of reasons I sometimes have to use serious bit twiddling
is to read alien data tapes from systems that stored raw binary data
in well defined but either proprietory or non IEEE real number formats.
 
> computers use either 16 or 32 bits to hold INTEGERs and 32 or 64 bits to
> hold REALs.  

I do wonder what would happen to a lot of modern software if a new
and popular architecture appeared that chose non-standard data sizes 
say 7 bit bytes, 35 bit words and 42 bit addresses. I can guess :-)
It would be a severe test of truely portable code!

> Leaving alone the "endianness" of the processor (which
> really doesn't make any difference to what we're discussing) it is quite
> possible to write portable code that makes use of casts to BITSET().

It depends how you are intending to access the bits individually.
Among the bitset numbering orders I have seen are
	{31, 30, ....    1, 0}
	{24, 25, .... 32, 16, 17, ... 23, 8, 9,  ... 15,  7, 6, ... 0 }
	{7, 6,   .... 0,  15, 14, ... 8, 23, 22, ... 16,  31, 30, ... 24 }

You can write portable code that will work with all of these, but it
is easy to fall into the trap of machine dependence.

> Why is it dangerous to recognize that all of these data values are composed
> of bits?

Because you open up the can of worms about how the internal bits 
have been numbered - and there are no guarantees on that at all.
(Perhaps the new standard says something about this? I don't know). 
 
> I also take exception to your statement that you hardly ever need to use
> such code, and therefore, it must not be important.

I don't think he said the second part, and it is true that you very
rarely need to go down to the bits level unless you are programming
i/o devices at the hardware level or communicating with odd systems.
When you do need it then it can be crucial.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/