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=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Examining individual bytes of an integer
Date: Fri, 19 Oct 2018 19:38:10 +0300
Organization: Tidorum Ltd
Message-ID: <g2ufjeFdlimU1@mid.individual.net>
References: <9d90fa3e-f800-4086-bf97-a65474a8140a@googlegroups.com>
 <pq0706$60k$1@dont-email.me> <g2hqooFq0usU1@mid.individual.net>
 <4ddbc9bf-0e2e-466d-8238-d8f709b985e1@googlegroups.com>
 <g2k5fbF9thnU1@mid.individual.net> <pq2sm7$in8$1@franka.jacob-sparre.dk>
 <35f53cd9-4979-49b8-a5df-2c1cf0764507@googlegroups.com>
 <pq5out$fu2$1@franka.jacob-sparre.dk>
 <39be8a25-cc06-4db4-9481-7f484077522d@googlegroups.com>
 <pqatam$ukb$1@franka.jacob-sparre.dk> <g2tbq4F6gseU1@mid.individual.net>
 <0a401e8f-e6a1-4513-b3f0-af1959774d1c@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net NUmG/QchkqJpdWlKh6cmPwl/ntXk6AJon7yXlmw3s61OWOqgn+
Cancel-Lock: sha1:hep22vMNQw3nTB4/lmVjjenFlLI=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
In-Reply-To: <0a401e8f-e6a1-4513-b3f0-af1959774d1c@googlegroups.com>
Xref: reader02.eternal-september.org comp.lang.ada:54656
Date: 2018-10-19T19:38:10+03:00
List-Id: <comp.lang.ada>

On 18-10-19 11:28 , AdaMagica wrote:
> Am Freitag, 19. Oktober 2018 08:27:19 UTC+2 schrieb Niklas Holsti:
>> On 18-10-19 00:18 , Randy Brukardt wrote:
>>> "AdaMagica" wrote in message
>>> news:39be8a25-cc06-4db4-9481-7f484077522d@googlegroups.com...
>>> ...
>>>> There remains the other statement:
>>>> "By reasonable induction  :-)  the second, third, etc. array elements
>>>> follow in increasing address order. But not _guaranteed_, I agree."
>>>>
>>>> I still claim that this has too be true (of course with a grain of salt for
>>>> packead arrays).
>>>
>>> I agree, it would make indexing calculations really expensive if it isn't
>>> true. And I don't see a compiler author doing that on purpose.
>>
>> Oh, I'm not so sure... Storing by *reverse* index order should not be
>> much more expensive, if at all.
>
> Hm, but what would be the purpose or gain? Just for the fun of it?

Who knows? Perhaps the target machine has some funny instructions that 
make it easier to check index ranges for reverse indexing? The Pascal 
compiler had no particular reason for placing the components in reverse 
order, and for sure it surprised the users who noticed it (I don't 
recall why they noticed it; perhaps they tried to interface with C code 
or with HW).

Or maybe the compiler sees that the array is always traversed from high 
indices to low, and the machine has some memory prefetching that works 
better when data is accessed in increasing address order?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .