comp.lang.ada
 help / color / mirror / Atom feed
From: Mark Johnson <mark_h_johnson@raytheon.com>
Subject: Re: Non byte-aligned components in GNAT rejected
Date: Mon, 16 Dec 2002 09:51:02 -0600
Date: 2002-12-16T09:51:02-06:00	[thread overview]
Message-ID: <3DFDF666.5CE6A184@raytheon.com> (raw)
In-Reply-To: 254c16a.0212111032.451cab61@posting.google.com

"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



  parent reply	other threads:[~2002-12-16 15:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-11 18:32 Non byte-aligned components in GNAT rejected Marc A. Criley
2002-12-11 19:28 ` Stephen Leake
2002-12-12 13:41 ` Marin David Condic
2002-12-12 18:25 ` Peter Richtmyer
2002-12-13 12:39   ` Marc A. Criley
2002-12-13 19:13     ` Peter Richtmyer
2002-12-16 15:51 ` Mark Johnson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-12-12  7:05 Grein, Christoph
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox