GNAT's internal format for Discriminant Records?

GNAT's internal format for Discriminant Records?

[Rick Flower]

We're trying to do some fixed format record layouts and are
looking into using discriminants.. These record formats will be
used to send data to hardware boxes, so the overhead of
what Ada might add when using some of the slick OO features
of the language are being checked into.  Now, we've already
found that GNAT (3.10p under Solaris 2.6) adds the size of the
discriminant to the overall record size (i.e. if the discriminant is
4 bits, then 4 bits are added to the overall record size).  We
tried the same under GHS Adamulti (1.8.8D) and found that it
did NOT add that overhead.  Now, for a few reasons, it would
appear that if there are multiple platforms/compilers involved
perhaps the use of discriminants should be avoided -- am I
correct in this theory?

My reasons are listed below :

    o Portability amongst different compilers/targets
    o Fixed format record layouts that MUST not have any other
       "information", OR it must be stripped off due to these
       records being sent to hardware boxes.

We've also looked at Tagged-Types and found that GNAT
(and AdaMulti for that matter) puts a 32-bit word at the front
of a record for a tagged type and that it can be removed using some simple
address arithmetic.

Any ideas/comments on this subject would be appreciated!

Thanks!

-- Rick

Re: GNAT's internal format for Discriminant Records?

[Simon Wright]

"Rick Flower" <Rick.Flower@trw.com> writes:

> We're trying to do some fixed format record layouts and are
> looking into using discriminants.. These record formats will be
> used to send data to hardware boxes, so the overhead of
> what Ada might add when using some of the slick OO features
> of the language are being checked into.  Now, we've already
> found that GNAT (3.10p under Solaris 2.6) adds the size of the
> discriminant to the overall record size (i.e. if the discriminant is
> 4 bits, then 4 bits are added to the overall record size).  We
> tried the same under GHS Adamulti (1.8.8D) and found that it
> did NOT add that overhead.  Now, for a few reasons, it would
> appear that if there are multiple platforms/compilers involved
> perhaps the use of discriminants should be avoided -- am I
> correct in this theory?

If your hardware target needs to know what sort of record you are
passing to it then it must need the discriminant somehow?

If not, you could check out the GNAT pragma Unchecked_Union (see the
GNAT RM for 3.10):

pragma Unchecked_Union (first_subtype_local_name)

      This pragma is used to declare that first_subtype_local_name
should be equivalent to a C union type, and is intended only for use
in interfacing with C code that uses union types. In Ada terms, the
named type must obey the following rules:

            It is a non-tagged non-limited record type. 

            It has a single discrete discriminant with a default value. 

            The component list consists of a single variant part. 

            Each variant has a component list with a single component. 

            No nested variants are allowed. 

            No component has an explicit default value. 

            No component has a non-static constraint. 

      In addition, given a type that meets the above requirements, the
following restrictions apply to its use throughout the program:

            The discriminant name can be mentioned only in an aggregate. 

            No subtypes may be created of this type. 

            The type may not be constrained by giving a discriminant value. 

            The type cannot be passed as the actual for a generic formal
            with a discriminant. 

[...]

Re: GNAT's internal format for Discriminant Records?

[Tom Moran]

Discriminants are commonly placed in a record pretty much like any
other component, and you should be able to use record rep clauses to
force different compilers to all do what you want.  Tags are (in my
experience) 32 bits on the front and not movable.  If the hardware
gadget wants the data, but not the tag, how about
  type hardware_record is
     whatever : something;
  end record;
  type fancy is new some_tagged_type with record
     hardware_part : hardware_record;
  end record;
Then you don't care where the tag winds up because you just pass the
hardware_part to the hardware.

Re: GNAT's internal format for Discriminant Records?

[Robert Dewar]

Tom Moran says

<<Discriminants are commonly placed in a record pretty much like any
other component, and you should be able to use record rep clauses to
force different compilers to all do what you want.  Tags are (in my
experience) 32 bits on the front and not movable.  If the hardware
gadget wants the data, but not the tag, how about
>>


This is wrong, tags are typically pointers, so they are only 32-bits on
32-bit machines. GNAT on the Alpha, or on the MIPS in n64 mode will
allocate 64-bits for the tag.

Re: GNAT's internal format for Discriminant Records?

[Robert Dewar]

Rich said

<<We're trying to do some fixed format record layouts and are
looking into using discriminants.. These record formats will be
used to send data to hardware boxes, so the overhead of
what Ada might add when using some of the slick OO features
of the language are being checked into.  Now, we've already
found that GNAT (3.10p under Solaris 2.6) adds the size of the
discriminant to the overall record size (i.e. if the discriminant is
4 bits, then 4 bits are added to the overall record size).  We
tried the same under GHS Adamulti (1.8.8D) and found that it
did NOT add that overhead.  Now, for a few reasons, it would
appear that if there are multiple platforms/compilers involved
perhaps the use of discriminants should be avoided -- am I
correct in this theory?
>>


You can only assume that data is transferable between implementations
if the layout is fully specified by rep clauses, and generally this
may not be possible, e.g. for tagged types. Certainly the tag itself
will NOT be transferrable in practice in any case. Variant records
should be no problem, since you can specify the location of every
field including the discriminants. It seems most strange for a 
compiler to NOT include the discriminants in values of the type (this
is the normal implementation approach).

But I think that the whole idea of trying to interchange data at this
level is flawed for anything as complex as tagged types and variant
records. It is usually better to use a higher level approach, e.g.
use streams with your own stream read/write routines defined.

If you are using GNAT on multiple platforms, you can use GLADE (our
annex E Distributed Systems implementation), to implement heterogenous
distributed applications using XDR for data interchange.

Robert Dewar
Ada Core Technologies