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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d842554064cfae31 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-16 08:15:16 PST Path: archiver1.google.com!news2.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!newsfeed.mathworks.com!cyclone.swbell.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail Message-ID: <3DFDF666.5CE6A184@raytheon.com> From: Mark Johnson X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Non byte-aligned components in GNAT rejected References: <254c16a.0212111032.451cab61@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Dec 2002 09:51:02 -0600 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1040053874 192.27.48.39 (Mon, 16 Dec 2002 09:51:14 CST) NNTP-Posting-Date: Mon, 16 Dec 2002 09:51:14 CST Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:31897 Date: 2002-12-16T09:51:02-06:00 List-Id: "Marc A. Criley" wrote: > > (This is one of those situations where I wish I had the scratch to be an ACT > supported customer.) > I have had some similar problems with other structures and took the opportunity to ask ACT for clarification. The comments below have some basis on that discussion as well as some other ideas I have for you. > I'm in the midst of creating type definitions, both scalar and records, for > a thoroughly bit-oriented message set, i.e., absolutely NO regard is paid to > byte boundaries, other than the first and the last bytes of the messages. > > GNAT 3.14p on W2K is rejecting one of my rep specs, stating that "large > component must be on byte boundary". > As noted in the GNAT Reference Manual... For non-primitive types, including packed arrays with a size greater than 64 bits, component clauses must respect the alignment requirement of the type, in particular, always starting on a byte boundary, and the length must be a multiple of the storage unit. > From a compiler implementor perspective, I can see where that limitation is > coming from, but this message format is extracted from a MIL-STD, and this > situation leads me to think that I may not be able to define a "natural" > record specification for messages defined in that standard. Are there any > other representation attributes I ought to try? I've tried 'Alignment and > gotten nowhere with that, so I'm open to suggestion (particularly if they > work on the cut-down package that's attached :-) > I also tried setting 'Alignment to zero. GNAT will generate an error message for that. The ARM in 13.3 (30, 31) states that the compiler should support specified alignments that are a multiple of the storage elements per word & need not support alignments that cannot be easily loaded and stored by the available machine instructions. In addition there is a note in the AARM 13.3(38f) which states "Specifying an Alignment of 0 in an attribute_definition_clause does not require the implementation to do anything (except return 0 when the Alignment is queried)...." Which basically again says the compiler doesn't have to support that kind of behavior. I am a little disturbed that it is an error (not a warning), but not enough to pay ACT to fix it. Having said that, an idea comes to mind. In your specific case of 7 bit packed data, you could implement the array in two or more pieces. Something like... type Unit_Name_Piece is array (1..8) of VMF_Character; // 7 bytes long type Unit_Group_Type is record B : Boolean; Unit_Name_1 : VMF_Character; // 1 Unit_Name_2 : Unit_Name_Piece; // 2..9 ... and repeat ... end record; And provide a pair of functions that put the pieces into and out of the full sized array. That might simplify the implementation of the accessor function you describe later. This also has the advantage of using data types that are short enough to have arbitrary alignment if you need that. > [snip remainder] --Mark