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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b657b1c99e7e7039 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!usenet-fr.net!gegeweb.org!aioe.org!not-for-mail From: =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= Newsgroups: comp.lang.ada Subject: Re: bit numbers in packed arrays of Boolean Date: Tue, 31 Aug 2010 15:40:40 +0200 Organization: Ada @ Home Message-ID: References: <82r5hfghjr.fsf@stephe-leake.org> <8e4b6rF1dlU1@mid.individual.net> <108mw0hcfwlnl.1klsp2e3omofa.dlg@40tude.net> NNTP-Posting-Host: phGk+NigveeXIQAZXtx21g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 User-Agent: Opera Mail/10.61 (Win32) Xref: g2news1.google.com comp.lang.ada:13875 Date: 2010-08-31T15:40:40+02:00 List-Id: Le Tue, 31 Aug 2010 15:08:02 +0200, Dmitry A. Kazakov = a =C3=A9crit: > The representation =3D memory pattern. When RM says that S and T have = same > representation that is merely same pattern. It tells nothing about = > ordering > of bits. Any combination of 8-bits is same representation of Unsigned_= 8 = > and > Boolean array (1..8). If I understand correctly, this suggests bits representation should be = accessed (read/write) all the same way, whatever the type it implements.= If that is, may be this would be better to word it more explicitly. But = = this would be OK for elementary types only as this could always be broke= n = for composite types with some representation clause combinations. = Providing this is OK, this could not be enforced for the example array = type which is the subject of this topic. Or else, this would require som= e = conditions about paddings. I still feel this is implementation defined and I would not rely on it (= or = else I missed something). A tricky and imaginary example by the way: imagine a clever compiler wit= h = clever optimization, which would detect the application mostly access th= e = nth item of the array and far less oftenly access any other items, now l= et = say the target CPU has a special instruction to access bit value at #0 = (common practice on CISC processor), then it could choose to map this nt= h = item on bit #0. Do you feel the language would disallow such an optimization ? if it doe= s = not, this example shows this is implementation defined. Side note: a compiler could do something similar for an unpacked array a= s = well ; it could move the nth item at offset 0, to save processing of an = = offset while accessing an element which was determined as far more = frequently accessed than the others. Seems possible ? -- = =E2=80=9CDual licensing is the Perl's way to disinfect the GNU General P= ublic = Virus!=E2=80=9D (anonymous)