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: a07f3367d7,7b60a2e8329f4e64 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII X-Received: by 10.180.97.198 with SMTP id ec6mr1724997wib.5.1358655486515; Sat, 19 Jan 2013 20:18:06 -0800 (PST) Path: o9ni8418wio.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues Date: Fri, 18 Jan 2013 07:15:01 +0100 Organization: A noiseless patient Spider Message-ID: References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com> <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com> <63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com> Mime-Version: 1.0 Injection-Date: Fri, 18 Jan 2013 06:15:02 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="709a3b9124d052b085bf6fc3f0a2adab"; logging-data="18818"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+cvzTi5uiFdRw7fPuM6+as" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 In-Reply-To: <63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com> Cancel-Lock: sha1:81N1BNEt0Sv9mPXe3Wf9NW3TyO0= X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: 2013-01-18T07:15:01+01:00 List-Id: Le 17/01/2013 23:16, awdorrin a �crit : > This is why I thought the Bit_Order flag was used to fix. > On Intel, using Bit_Order = System.High_Order_First, > I would have expected to see: 0xcb 0xa0 I didn't follow the discussion closely, but from this remark it seems you are confusing bit order and byte order. High_Order_First is only about bit order, i.e. whether, in a 32 bits value f.e., the leftmost bit is numbered 31 or 0. It has nothing to do (and no effect) on the order in which the various bytes that make up this value are stored in memory. Regarding the use of "at": you can always use 0 and number the bits starting from the beginning of the record (and bit numbers are not limited to 31). "at" just saves you a multiplication by the number of bits in a storage unit. It is there because you normally use representation clauses in connection with some low level device, and the idea was to allow to copy directly from your hardware reference manual, using the same description. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr