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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,43ad9ab56ebde91c
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.213.71 with SMTP id nq7mr8716314pbc.2.1323681720358;
        Mon, 12 Dec 2011 01:22:00 -0800 (PST)
Path: 
 lh20ni13448pbb.0!nntp.google.com!news2.google.com!news3.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Does Ada support endiannes?
Date: Mon, 12 Dec 2011 11:23:40 +0200
Organization: Tidorum Ltd
Message-ID: <9klvdnF29pU1@mid.individual.net>
References: <23835087-313f-427c-b37e-4ff1bdef9d57@r6g2000yqr.googlegroups.com>
Mime-Version: 1.0
X-Trace: individual.net jBEi1COcYvXuRExRtFNJwwPPNdAJTyeqRgkXe3fPj3G9sZRpeQ
Cancel-Lock: sha1:zTnBNKq4r7nOiE8yR8CGq8k2f0o=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
In-Reply-To: 
 <23835087-313f-427c-b37e-4ff1bdef9d57@r6g2000yqr.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2011-12-12T11:23:40+02:00
List-Id: <comp.lang.ada>

On 11-12-12 10:57 , Gerd wrote:
> Hello,
>
> a while ago, I worked at Siemens company, with a (CHILL-)compiler that
> supports endianess similar to this:
>
> litte : Integer; pragma Datalayout(Little_Endian);
> big  : Integer; pragma Dtalayout(Big_Endian);
>
> little := big; -- compiler generates code for converting big endian to
> little endian
>
> if little = big -- compiler converts the variables to machines nativ
> format before testing
>
>
> Is there something similar available with Ada?

No.

> Or has someone any suggestions how to rewrite it in ada?

Assuming that the native format is big-endian, you could define a new type:

    type Little_Endian_Integer is record ... end record;

and write representation specifications to lay out the components of the 
type in a little-endian way. But you would then have write your own 
implementations of all arithmetic operations on Little_Endian_Integer, 
for example the "+" operator, including forms that mix types, for 
example for Integer + Little_Endian_Integer.

In practice, it would be much easier to write only two conversion 
functions, to convert to and from the non-native endianness, and call 
those functions only at the start and end of a computation to load and 
store the variables that use the non-native endianness.

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