GNAT's internal format for Discriminant Records? 
Author Message
 GNAT's internal format for Discriminant Records?

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



Tue, 05 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Quote:

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

[...]



Tue, 05 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

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.



Wed, 06 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

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



Thu, 07 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

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.



Thu, 07 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Quote:

> We're trying to do some fixed format record layouts and are
> looking into using discriminants.

Do you mean "discriminant" or "tag"?

Quote:
> 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.

OO features would only apply to "tags," not "discriminants."

Quote:
> 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.

This statement makes me very nervous...

Quote:
> Any ideas/comments on this subject would be appreciated!

Simple: do NOT use tagged types to communicate with an external piece of
hardware.  I would be loathe to use even discriminant records.

Your best bet for doing external I/O is to use straight records.

Or perhaps use the Streams facility to convert the data from an internal
format (tagged or discriminated record or whatever) to external format
(an array of stream elements).

Do not play funny tricks with addresses to be able to transmit a tagged
type to an external device.  This is Ada, not C, and there are much
cleaner techniques for doing this sort of thing.



Fri, 08 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Quote:

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

Yes.  This is absolutely correct.

Do not try to transmit tagged types externally.

Use the streams facility to convert a type having an internal format
into a stream element array (which is its external format).



Fri, 08 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Robert Dewar wrote in an earlier message ...

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

That is fine and was assumed in this case.  After looking at the
background of how tagged types work, I gathered that it was a
pointer to some internal RTL data structure.

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

Currently, our current version of AdaMulti (1.8.8D), does NOT
allocate any extra space when a discriminant is used within a record.
Now, a few of us have some feeling that this may be due to the fact
that GNAT has an Annex-E (Dist. Systems) implementation and GHS
does not (currently).

Quote:
>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.

I would try this route, but it would appear to me (after looking through
all of our Ada95 books -- Ada95 as a second language, Ada95
concurrency, Ada95 for C/C++ programmers, and the worst book
of the bunch, Programming in Ada95), that this is no trivial exercise!
I've played around with streams and no lights are coming on in my
head with regards to how to get Ada95 to perform this feat!  I would
gladly do this in C++ any day -- and NO I'm not trying to start a war
here -- I'm just telling it like I see it!

-- Rick



Fri, 08 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Quote:

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

> I would try this route, but it would appear to me (after looking through
> all of our Ada95 books -- Ada95 as a second language, Ada95
> concurrency, Ada95 for C/C++ programmers, and the worst book
> of the bunch, Programming in Ada95), that this is no trivial exercise!
> I've played around with streams and no lights are coming on in my
> head with regards to how to get Ada95 to perform this feat!

If you provide more specific info about what you're trying to do, then
perhaps I and others can help you.

Note that "Ada95" doesn't "perform this feat," you do, the programmer.
All Ada does is provide a standard interface (Stream I/O) for doing the
conversion.  It's up to the programmer actually implement the conversion
routines.

You need to study the RM and Rationale to learn more about streams.

Please do not try to directly send a tagged type across an external
interface.



Fri, 08 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

<<Note that "Ada95" doesn't "perform this feat," you do, the programmer.
All Ada does is provide a standard interface (Stream I/O) for doing the
conversion.  It's up to the programmer actually implement the conversion
routines.

That's not quite right. The default stream conversion routines are
perfectly satisfactory for most purposes.



Sat, 09 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Matthew said

<<Do not try to transmit tagged types externally.

Of course transmitting from one partition to another, even on a different
machine, even possibly a machine with a different architecture, is just
fine if you use the facilities of Annex E in an implementation that
supports full distribution, and indeed the remote dispatching capabilities
here are very powerful.



Sat, 09 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

<<Currently, our current version of AdaMulti (1.8.8D), does NOT
allocate any extra space when a discriminant is used within a record.
Now, a few of us have some feeling that this may be due to the fact
that GNAT has an Annex-E (Dist. Systems) implementation and GHS
does not (currently).

What does it mean to use a discriminant within a record. It is not clear
what you mean here, since your terminology seems a bit confused. Perpahs
you could give an example. Most certainly any difference has nothingf to
do with distribution, and everythingf to do with the fact that you should
not be expecting the layouts to be the same in any case!

The streams are really quite easy to use in Ada (note that there is really
no facility in C that is equivalent, so perhaps your problem is that you
are expecting to find something that is familiar from C or C++, if so,
do not! The streams in Ada are a much higher level feature than is
available in C++ (note they have nothing to do with streams used to
read and write files in C/C++)



Sat, 09 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Some have suggested that this would be a good place to use XML, but, of
course, the overhead would be much higher than 32-bits per record.  On
the other hand, it is a problem that I would like to find a good
solution to also.  Probably the best that can be done is to maintain a
discriminated type for I/O and another "appropriate type" for internal
use.  This would minimize the overhead on disk-based records, and allow
transfer between systems.  It adds an overhead step of converting the
data from its external form to its internal form, and requires defining
methods all over the place to do the deed, but I haven't come across a
better approach.

Quote:

> 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

--




Sat, 09 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?

Quote:

> Some have suggested that this would be a good place to use XML, but, of
> course, the overhead would be much higher than 32-bits per record.  On
> the other hand, it is a problem that I would like to find a good
> solution to also.  Probably the best that can be done is to maintain a
> discriminated type for I/O and another "appropriate type" for internal
> use.  This would minimize the overhead on disk-based records, and allow
> transfer between systems.  It adds an overhead step of converting the
> data from its external form to its internal form, and requires defining
> methods all over the place to do the deed, but I haven't come across a
> better approach.

I agree with Mr. Dewar below that annex E is the way to go if and when
it is available. However, I work on a project which continues to use
Ada 83 and we have some very esoteric hardware interface requirements.
In one instance, our software has to talk to are particular kind of
hardware. They will be many (dozens) of instance of this hardware
in the environment. This hardware also has a software emulator
produced by a third party. We also have to talk to this emulator.
In fact, in many scenarios, we have configurations which involved
a mixture of actual hardware pieces and emulated pieces. We talk
to the hardware via memory mapped record structures. The simple
approach is to define a Ada record representing the entire
memory structure, rep clause it to fit the required layout as
defined by the hardware, and use an address clause to force
our object to the appropriate memory location. Viola!

Now, here's the rub. For some reason, the third party vendor
who produced the emulator got by with using a different memory
layout (go figure). This is really not too different from
moving data between heterogenous environments. For this,
we define the Ada record which establishes the 'base' record
type. We then define two derived types from this base record,
one for the hardware and one for the emulator. We then rep
clause each derived type according to its required layout.
We now can use simple type conversions between the memory-mapped
record objects and let Ada worry about the layout transformations.

Heterogenous environments not only vary according to layout,
but also vary according to the size of the types of the fields.
Assuming you can lock down the desired range of your numeric
fields (for instance), different environment may be using
16 bit vs 32 bit integers. This is handled quite naturally
by defining a ranged type and not relying on any particular
predefined type. As long as the range is there supported by
the resulting size, you can "grow" and "shrink" the field
in the rep clause as needed to accomodate the various environments
in use.

I've been very successful with this approach on various
projects. Its too bad I can't do this directly with tagged
types in Ada 95. But then Ada 95 provides other alternatives
to accompilish the same task, as Mr. Dewar points out.

Quote:


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

> --



--
Samuel T. Harris, Principal Engineer
Raytheon Training Incorporated
"If you can make it, We can fake it!"


Mon, 11 Dec 2000 03:00:00 GMT  
 GNAT's internal format for Discriminant Records?


Quote:
> In fact, in many scenarios, we have configurations which involved
> a mixture of actual hardware pieces and emulated pieces. We talk
> to the hardware via memory mapped record structures. The simple
> approach is to define a Ada record representing the entire
> memory structure, rep clause it to fit the required layout as
> defined by the hardware, and use an address clause to force
> our object to the appropriate memory location. Viola!

Might be good to use pragma Import (Ada, ...) on objects of these
types to make sure Ada doesn't initialize them.


Tue, 12 Dec 2000 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Default discriminant problem/GNAT compiler bug?

2. aliased discriminant record components

3. Help: Dynamic-size arrays using record discriminant.

4. Help with a constant of a discriminant record type

5. RECORDS( MFL:Key0 ) doesn't return correct record number

6. Why can't discriminant constrain scalar type in a record?

7. Joaquin's formatted messages and the end of formatting

8. GNAT internals question

9. Excel internal format & CW

10. Excel internal format

11. Internal Error '4412'

12. What causes 'Internal error 5333'?

 

 
Powered by phpBB® Forum Software