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: 103376,e49db73f947323a6
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!feeder3.cambriumusenet.nl!feed.tweaknews.nl!87.79.20.105.MISMATCH!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 18 Apr 2011 17:52:51 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: GNAT for a PPC Mac OS X machine
References: <C9D0B17B.9891%yaldnif.w@blueyonder.co.uk>
 <m2vcydos58.fsf@pushface.org> <C9D1575A.98E0%yaldnif.w@blueyonder.co.uk>
 <m2oc43q539.fsf@pushface.org> <C9D209D9.9928%yaldnif.w@blueyonder.co.uk>
In-Reply-To: <C9D209D9.9928%yaldnif.w@blueyonder.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4dac5e53$0$6887$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 18 Apr 2011 17:52:51 CEST
NNTP-Posting-Host: ba5f32de.newsspool2.arcor-online.net
X-Trace: 
 DXC=6WC^OKOjA6b9kIfcjg:0fdA9EHlD;3Ycb4Fo<]lROoRa8kF<OcfhCOk97XY\S;VTVlnc\616M64>jLh>_cHTX3jm<88<AQeh92`
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:19832
Date: 2011-04-18T17:52:51+02:00
List-Id: <comp.lang.ada>

On 18.04.11 16:31, Bill Findlay wrote:

> And this is fine in Intel.  But on PPC, we get the error:
> 
>     92.    for Q_register'Size use word'Size;
>                                         |
>         >>> size for "Q_register" too small, minimum allowed is 64
> 
> It's puzzling that the compiler refuses to give Q_register the size that it
> happily gave to word.  (The aspect clause is there to support unchecked
> conversions between the word and Q_register types.)

Just guessing: Apple's 32-bit/64-bit PowerPC Function Calling Conventions
(which refer to the PowerPC ABI) indicate that there is a number of
alignment modes, including packed alignment; the GCC docs mention that
some modes are not supported, IIUC.

OTOH, Apple recommends not to pack data, for better performance.
Continuing guess work, if KDF9.word were 64 bits wide, perhaps the record
(or a derived one, for computing) could have another 16 padding bits
and then be layed out to match KDF9.word's 64 bit representation
on PowerPC?