Re: How do I write directly to a memory address?

[Adam Beneschan <adam@irvine.com>]

On Feb 9, 12:44 pm, "Vinzent Hoefler"
<0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote:
> Simon Wight wrote:
> > "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de>
> > writes:
>
> >> So bit 3 of a 32-bit word is a different bit than that of a byte?
>
> > Yes. On big-endian hardware.
>
> That's a misconception, although a common one. Endianess is only defined
> for bytes, that's why it's also often called byte-order.

For what it's worth, the Ada RM contradicts you here (and conforms to
what Simon says).  And it just happens that I ran into this today,
while looking into an issue that had nothing to do with this
comp.lang.ada thread.  See 13.5.3(2):

A bit ordering is a method of interpreting the meaning of the storage
place attributes. High_Order_First (known in the vernacular as “big
endian”) means that the first bit of a storage element (bit 0) is the
most significant bit (interpreting the sequence of bits that represent
a component as an unsigned integer value). Low_Order_First (known in
the vernacular as “little endian”) means the opposite: the first bit
is the least significant.

So by that convention, bit 0 of a byte is the most-significant bit on
a big-endian machine, which would make bit 2 the one represented by
the value 16#20#.

There's a good reason for this, too.  Suppose you want to pack three
fields into a 16-bit word, where the three fields are 5, 5, and 6 bits
respectively.  On a big-endian machine, the second field would occupy
the least three significant bits of the byte at Addr, and the most-
significant two bytes at Addr+1.  If we call the bits in the first
byte bit 0 through bit 7, and the bits in the second byte bit 8
through bit 15, then the second field will occupy bits 5, 6, 7 (in the
first byte) and 8, 9 (in the second byte), using the convention
described in 13.5.3(2).  In Ada, we'd express this with a
representation clause that looks (in part) something like

   Second_Field  at 0 range 5..9;

If we did things the way you think is the "right" way, the second
field would occupy bits 2, 1, 0, 15, and 14.  Which would be most
unhelpful.  So clearly, since the ability to give our packed fields
consecutive bit numbers is much more important than ensuring that the
bit numbers remain the same when you convert an integer from one size
to a different size, the way Ada does things is the right way.

But I am still not convinced that there is "one right way", or one
right convention.  If some documentation that describes some data
format calls the high-order bit of a byte Bit 0, and they make it
clear that that's their convention, I don't think I could say for
certain that they're "wrong", in the sense that if someone pointed to
a dog and called it a "cat" they'd be wrong even if they tried to pull
a Humpty Dumpty and say "Well, that's my meaning for the word 'cat'".
We have dictionaries which can authoritatively show that their word
usage is wrong.  You say that this usage of "Bit 0" is "just wrong",
but can you point to any work that has as much authority as a
dictionary to support your statement?  That's why I believe it would
be necessary to ask if someone started referring to "Bit 2" or "The
third bit" of something.

                                -- Adam