Non byte-aligned components in GNAT rejected

Non byte-aligned components in GNAT rejected

[Marc A. Criley]

(This is one of those situations where I wish I had the scratch to be an ACT
supported customer.)

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".

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 :-)

If I can't find a way to put these definition together, I'll have to shift
to an "accessor" approach where I just stuff and retrieve bits from an
undifferentiated bit buffer.

Marc A. Criley

-----------------------------------------------------------

package NBA is

   type VMF_Character is new Character range
     Character'Val(0) .. Character'Val(127);
   for VMF_Character'Size use 7;

   type Unit_Name_Type is array (1..64) of VMF_Character;
   for Unit_Name_Type'Component_Size use 7;
   for Unit_Name_Type'Size use 448;

   type Unit_Group_Type is record
      B : Boolean;
      Unit_Name : Unit_Name_Type;
   end record;
   for Unit_Group_Type use record
      B      at 0 range 0 .. 0;
      Unit_Name at 0 range 1 .. 448; -- This is rejected
   end record;

end NBA;

Re: Non byte-aligned components in GNAT rejected

[Stephen Leake]

mcq95@earthlink.net (Marc A. Criley) writes:

> GNAT 3.14p on W2K is rejecting one of my rep specs, stating that "large
> component must be on byte boundary".

Same message from GNAT 3.15a1 on WinNT 4.0.

I suspect putting characters on non-byte boundary is just not going to
happen. I tried adding 'pragma Pack' to the array, and using a
non-character element type for the array; no luck.

> If I can't find a way to put these definition together, I'll have to shift
> to an "accessor" approach where I just stuff and retrieve bits from an
> undifferentiated bit buffer.

I think that's what you'll have to do. Sorry :).

-- 
-- Stephe

Re: Non byte-aligned components in GNAT rejected

[Marin David Condic]

If you figure out a way to do that without resorting to a raw binary,
machine-dependent array that you pick apart manually, please drop me a line
and let me know how you did that. I've had long standing problems with
representation clauses on records that wouldn't let me do what I needed to
do and the only answer has been to go do it some sort of butt-ugly way that
looks more like C and makes everything dependent on hardware and the
implementation.

So much for record representation clauses being good for the embedded
programmer. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Marc A. Criley <mcq95@earthlink.net> wrote in message
news:254c16a.0212111032.451cab61@posting.google.com...
> (This is one of those situations where I wish I had the scratch to be an
ACT
> supported customer.)
>
> 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".
>
> 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 :-)
>
> If I can't find a way to put these definition together, I'll have to shift
> to an "accessor" approach where I just stuff and retrieve bits from an
> undifferentiated bit buffer.
>
> Marc A. Criley
>
> -----------------------------------------------------------
>
> package NBA is
>
>    type VMF_Character is new Character range
>      Character'Val(0) .. Character'Val(127);
>    for VMF_Character'Size use 7;
>
>    type Unit_Name_Type is array (1..64) of VMF_Character;
>    for Unit_Name_Type'Component_Size use 7;
>    for Unit_Name_Type'Size use 448;
>
>    type Unit_Group_Type is record
>       B : Boolean;
>       Unit_Name : Unit_Name_Type;
>    end record;
>    for Unit_Group_Type use record
>       B      at 0 range 0 .. 0;
>       Unit_Name at 0 range 1 .. 448; -- This is rejected
>    end record;
>
> end NBA;

Re: Non byte-aligned components in GNAT rejected

[Peter Richtmyer]

mcq95@earthlink.net (Marc A. Criley) wrote in message news:<254c16a.0212111032.451cab61@posting.google.com>...
> (This is one of those situations where I wish I had the scratch to be an ACT
> supported customer.)
> 
This is one of those (rare) situations where I am diappointed in Gnat.
Rational had no problems with the package. 
> 
> GNAT 3.14p on W2K is rejecting one of my rep specs, stating that "large
> component must be on byte boundary".
> 
Using Gnat 3.15p I had the same error you did.
I found a work-around that might be acceptable to you:

package NBA is

   type VMF_Character is new Character range
     Character'Val(0) .. Character'Val(127);
   for VMF_Character'Size use 7;

   type Unit_Name_Type is array (1..64) of VMF_Character;
   for Unit_Name_Type'Component_Size use 7;
   for Unit_Name_Type'Size use 448;

   type un_t is                          -- new
      record                             -- new
         un : Unit_Name_Type;            -- new
      end record;                        -- new
   -- for un_t'size use 448;             -- bad results!


   type Unit_Group_Type is record
      B : Boolean;
      -- Unit_Name : Unit_Name_Type;     -- deleted
      Unit_Name : un_t;                  -- new
   end record;
   for Unit_Group_Type use record
      B      at 0 range 0 .. 0;
      Unit_Name at 0 range 1 .. 448; -- This is OK now
   end record;

end NBA;

As you can see, the Unit_Name is still one variable,
using th same type definition, but is now a record 
within the record.

One odd thing, if you compile with the line that has
the "bad results!" comment, you will get the same old
Gnat error! Seems like strange behavior to me.

good luck,
Peter

Re: Non byte-aligned components in GNAT rejected

[Marc A. Criley]

Peter Richtmyer wrote:
> 
> Using Gnat 3.15p I had the same error you did.
> I found a work-around that might be acceptable to you:
> 
> package NBA is
> 
>    type VMF_Character is new Character range
>      Character'Val(0) .. Character'Val(127);
>    for VMF_Character'Size use 7;
> 
>    type Unit_Name_Type is array (1..64) of VMF_Character;
>    for Unit_Name_Type'Component_Size use 7;
>    for Unit_Name_Type'Size use 448;
> 
>    type un_t is                          -- new
>       record                             -- new
>          un : Unit_Name_Type;            -- new
>       end record;                        -- new
>    -- for un_t'size use 448;             -- bad results!
> 
>    type Unit_Group_Type is record
>       B : Boolean;
>       -- Unit_Name : Unit_Name_Type;     -- deleted
>       Unit_Name : un_t;                  -- new
>    end record;
>    for Unit_Group_Type use record
>       B      at 0 range 0 .. 0;
>       Unit_Name at 0 range 1 .. 448; -- This is OK now
>    end record;
> 
> end NBA;
> 
> As you can see, the Unit_Name is still one variable,
> using th same type definition, but is now a record
> within the record.

I compiled this with GNAT 3.15p on Win2K and 3.13p on Linux and still
got an error, albeit a different one:  "nba.ads:21:07: fields of "un_t"
must start at storage unit boundary".  Line 21 is the "Unit_Name :
un_t;" line.  What GNAT/OS did you use?

Marc

Re: Non byte-aligned components in GNAT rejected

[Peter Richtmyer]

"Marc A. Criley" <mcq95@earthlink.net> wrote in message news:<3DF9D537.1DB616B7@earthlink.net>...
 
> I compiled this with GNAT 3.15p on Win2K and 3.13p on Linux and still
> got an error, albeit a different one:  "nba.ads:21:07: fields of "un_t"
> must start at storage unit boundary".  Line 21 is the "Unit_Name :
> un_t;" line.  What GNAT/OS did you use?
> 
> Marc


Well do I feel foolish!

I was using Gnat and AdaGIDE, and a "Compile" did not show the error
with the compile options I was using.

But when I do a full "Build" (which I did not try previously), I do
get that same error above.

Sorry for the inconvenience.
Peter 

(to answer your (OBE) question, it was Win2K also)

Re: Non byte-aligned components in GNAT rejected

[Mark Johnson]

"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

Re: Non byte-aligned components in GNAT rejected

[Grein, Christoph]

> -----------------------------------------------------------
> 
> package NBA is
> 
>    type VMF_Character is new Character range
>      Character'Val(0) .. Character'Val(127);
>    for VMF_Character'Size use 7;
> 
>    type Unit_Name_Type is array (1..64) of VMF_Character;
>    for Unit_Name_Type'Component_Size use 7;
>    for Unit_Name_Type'Size use 448;
> 
>    type Unit_Group_Type is record
>       B : Boolean;
>       Unit_Name : Unit_Name_Type;
>    end record;
>    for Unit_Group_Type use record
>       B      at 0 range 0 .. 0;
>       Unit_Name at 0 range 1 .. 448; -- This is rejected
>    end record;
> 
> end NBA;
> _______________________________________________
The following works. You have to split the name so that it has the correct 
boundaries.

package NBA is

   type VMF_Character is new Character range
     Character'Val(0) .. Character'Val(127);
   for VMF_Character'Size use 7;

   type Unit_Name_Type is array (1..56) of VMF_Character;
   for Unit_Name_Type'Component_Size use 7;
   for Unit_Name_Type'Size use 56*7;

   type Unit_Last_Type is array (1..7) of VMF_Character;
   for Unit_Last_Type'Component_Size use 7;
   for Unit_Last_Type'Size use 7*7;

   type Unit_Group_Type is record
      B : Boolean;
      Unit_First: VMF_Character;
      Unit_Name : Unit_Name_Type;
      Unit_Last : Unit_Last_Type;
   end record;
   for Unit_Group_Type use record
      B          at 0 range    0 .. 0;
      Unit_First at 0 range    1 .. 7;          -- together
      Unit_Name  at 1 range    0 ..  56*7 - 1;  -- 64
      Unit_Last  at 1 range 56*7 .. (56+7)*7;   -- characters
   end record;

end NBA;