From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c9d5fc258548b22a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,CP1252 Path: g2news2.google.com!postnews.google.com!r4g2000prm.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: How do I write directly to a memory address? Date: Wed, 9 Feb 2011 19:03:40 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <67063a5b-f588-45ea-bf22-ca4ba0196ee6@l11g2000yqb.googlegroups.com> <4d5008a5$0$6879$9b4e6d93@newsspool2.arcor-online.net> <4d5031fe$0$6765$9b4e6d93@newsspool3.arcor-online.net> <1f229967-d3cf-42b6-8087-c97ee08652f3@i40g2000yqh.googlegroups.com> <4d51169e$0$7657$9b4e6d93@newsspool1.arcor-online.net> <1bnp0pw1c8r5b$.guxc48qweiwe.dlg@40tude.net> <4d51a1c0$0$19486$882e7ee2@usenet-news.net> <87411ec5-c197-4143-8ef1-ab9ddb20bcc6@q40g2000prh.googlegroups.com> <505a0855-ed01-4819-9d8e-025ad8d5cb51@y12g2000prf.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1297307050 26644 127.0.0.1 (10 Feb 2011 03:04:10 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 10 Feb 2011 03:04:10 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r4g2000prm.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:18173 Date: 2011-02-09T19:03:40-08:00 List-Id: On Feb 9, 12:44=A0pm, "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 =93big endian=94) 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 =93little endian=94) 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