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.2 required=5.0 tests=BAYES_00,FROM_LOCAL_HEX, FROM_STARTS_WITH_NUMS autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,c9d5fc258548b22a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776eeb@t-domaingrabbing.de> Newsgroups: comp.lang.ada Subject: Re: How do I write directly to a memory address? Date: Thu, 10 Feb 2011 20:07:29 +0100 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Trace: individual.net JUIPONpqGHYdRqByuRe7vwkSJJDPJ1/+SKx/xLDad5jmEEf4oR Cancel-Lock: sha1:cMKX0mHtznqMOfIyn2T3kMSp0Bs= User-Agent: Opera Mail/11.01 (Win32) Xref: g2news1.google.com comp.lang.ada:17228 Date: 2011-02-10T20:07:29+01:00 List-Id: Adam Beneschan wrote: > A bit ordering is a method of interpreting the meaning of the storage > place attributes. High_Order_First (known in the vernacular as =E2=80=9C= big > endian=E2=80=9D) 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 =E2=80=9Clittle endian=E2=80=9D) means the opposite:= the first bit > is the least significant. Yes. And then read the GNAT RM 6.8 (Bit_Order clauses): |In the case where the non-standard value is specified, the effect is |to renumber bits within each byte. ... There they explain in great detail that the Bit_Order has nothing to do with the byte ordering. > 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#. Only if the value in question is a byte. That's what makes this sort of counting useless. If it were bit 2 of a 5-bit word, the value would suddenly be 2#01000# (or 16#08#, if you prefer base 16). Convention or not, it's at least confusing to make the bit numbers dependent on the number of available bits. > 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. That just means, we cannot have a declaration that will do on both machines, regardless of what bit-order you specify: |Components that are positioned across byte boundaries but do not |occupy an integral number of bytes. Given that bytes are not reordered,= |such fields would occupy a non-contiguous sequence of bits in memory, |requiring non-trivial code to reassemble. They are for this reason not |permitted, and any component clause specifying such a layout will be |flagged as illegal by GNAT. Given, that I happened to write a converter (in Ada) that creates such Ada record representations from an interface document where the bit numbering is mostly wrong (calling bit 15 of a 32-bit word the MSB can be called wrong - no matter how you look at it), I'm quite sure I know what I'm talking about and why such numbering is just confusing. > 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. I didn't say, Ada does it wrong. The "Ada way" also specifies that the Bit_Order has nothing to do with the Byte_Order (other than having some machine-dependent default), so there indeed is a _convention_ for exactly the reason you state - and I can respect that. > That's why I believe it would > be necessary to ask if someone started referring to "Bit 2" or "The > third bit" of something. Honestly, I would probably ask, too. Even if it were just to make sure my presumption was correct. I'm an Ada programmer, after all. ;) Vinzent. -- = You know, we're sitting on four million pounds of fuel, one nuclear weap= on, and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it? -- Rockhound, "Armageddon"