comp.lang.ada
 help / color / mirror / Atom feed
* Re: Using the GNAT defined attribute: 'Enum_Rep
@ 1997-09-09  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1997-09-09  0:00 ` W. Wesley Groleau x4923
  0 siblings, 1 reply; 17+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1997-09-09  0:00 UTC (permalink / raw)



"W. Wesley Groleau x4923" <wwgrol@PSESERV3.FW.HAC.COM> writes:
>Whoa!  Communication breakdown.  I said "is this true?" to someone's
>claim that the ABSENCE of an enum-rep-clause, makes the representation
>the same as the 'pos.  For most CPUs, making the internal rep.
>the same as 'pos is probably the simplest and most efficient
>approach.  But please cite LRM-83 or LRM-95 if it is illegal for
>a compiler, given
>
>  type Enum is (Zero, One, Two, Three, Four, Five, Six, Seven );
>
>(with no rep-clause), please cite LRM-83 or LRM-95 if it is
>illegal for an implementation to internally use
>
>  for Enum use (Zero  => 2#00000001#,
>                One   => 2#00000010#,
>                Two   => 2#00000100#,
>                Three => 2#00001000#,
>                Four  => 2#00010000#,
>                Five  => 2#00100000#,
>                Six   => 2#01000000#,
>                Seven => 2#10000000# );
>
    I'm not sure if you ever received my original response to you on
    this subject & I didn't post it to C.L.A. because I had not seen
    it in the listserver output from VM1.NODAK.EDU. (Is something
    wrong with this listserver? I seem to be missing out on large
    chunks of the conversation, seeing things badly out of date and
    not entirely sure that anything I post gets through.)

    Since you asked for the ARM references, I'll pass them along for
    the benefit of the curious:

>
>>      'Pos and 'Val. ... will work If and only if the representation is
>>     identical to the position numbers - what you get if you don't
>>     specify a representation. ....
>
>Is this true ?  Seems to me it's legal (though I've never seen
>it happen) for an implementation to generate anything it wanted
>for a representation as long as ordering, indexing, etc. worked.
>
>I can imagine a CPU where a bit per value is more efficient, i.e.,
>an implicit
>
>   for Enum use ( 0, 1, 2, 4, 8, 16, 32, ... );
>
>though, again, I've never seen that done.
>
    Section 3.5.1(7) of the ARM indicates that the position numbers of
    enumerations are 0, 1, ... as one would expect. Section 3.5.5
    talks about the 'Pos and 'Val operations which clearly are going
    to return 0, 1, ..., again as expected. Section 13.4 has all the
    details about enumeration representations and 13.4(8) states "For
    nonboolean enumeration types, if the coding is not specified for
    the type, then for each value of the type, the internal code shall
    be equal to its position number." Hence, the ARM requires internal
    representation of 0, 1, ... if you say nothing about it. Again,
    pretty much what your garden variety programmer is going to
    expect.

    I agree, there would be some food value in letting the
    implementation pick the representation which might best suit the
    machine (most commonly for booleans where representation might be
    faster using the sign bit - but that's allowed.) But I'm glad
    there's a certain clarity here about what you're going to get
    because (especially for us embedded guys where it really matters)
    surprises are what *really* hurt!

    It's interesting to read what the ARM says in 13.4(11) about using
    Unchecked_Conversion as the method of getting to the internal
    codes. Obviously, someone noticed that you'd need to do this and
    had a "preferred" method of getting there. But apparently, they
    missed the boat on how to guarantee an identical size between the
    two types in a manner that would self-correct. (Unless I'm being
    dense - which is why my original query was out there!) Maybe the
    intention was that if you knew enough to specify the
    representation then you'd likewise know enough to change the
    corresponding integer type (or Boolean array?) and that the one
    would be closely tied to the other.
===============================================================================

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "There's a fine line between fishing and standing on the shore
    looking like an idiot."

        --  Steven Wright
===============================================================================




^ permalink raw reply	[flat|nested] 17+ messages in thread
* Re: Using the GNAT defined attribute: 'Enum_Rep
@ 1997-09-09  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1997-09-09  0:00 ` Robert A Duff
  0 siblings, 1 reply; 17+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1997-09-09  0:00 UTC (permalink / raw)



Robert A Duff <bobduff@WORLD.STD.COM> writes:
>In article <97082719523509@psavax.pwfl.com>,
>Marin David Condic, 561.796.8997, M/S 731-96 <condicma@PWFL.COM> wrote:
>>    The ARM suggests using Unchecked_Conversion to get from here to
>>    there, but now you've got to create an integer type that is the
>>    same size as the enumerated type. Here's a code fragment:
>
>How about:
>
>    type Temp_Integer is range 0..2**User_Types.CL_Evt_Status'Size;
>
>and use Temp_Integer'Base?  Or:
>
>    type Temp_Integer is mod User_Types.CL_Evt_Status'Size;
>
>?
>
    That's pretty clever. Never thought of attempting to use the 'Size
    attribute in the type definition. I guess I had my brain wrapped
    around the axle with trying to use the 'Size attribute in the
    representation clause.

    Still, it would be very useful to have an attribute that is the
    inverse of 'Enum_Rep, taking a universal integer parameter and
    returning the corresponding enumeral - raising Constraint_Error if
    the integer did not match an enumeral internal representation. (Or
    possibly not raising the exception? Let it work a little like
    Unchecked_Conversion?)

    Thanks for the tip.

    MDC
Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
    "There's a fine line between fishing and standing on the shore
    looking like an idiot."

        --  Steven Wright
===============================================================================




^ permalink raw reply	[flat|nested] 17+ messages in thread
* Using the GNAT defined attribute: 'Enum_Rep
@ 1997-08-27  0:00 Marin David Condic, 561.796.8997, M/S 731-96
  1997-09-03  0:00 ` W. Wesley Groleau x4923
  1997-09-08  0:00 ` Robert A Duff
  0 siblings, 2 replies; 17+ messages in thread
From: Marin David Condic, 561.796.8997, M/S 731-96 @ 1997-08-27  0:00 UTC (permalink / raw)




    Here's a little problem which I could use some help handling:

    I get external data for my program which is extracted from the
    internal representation of an enumerated type. That is to say, I'm
    getting integers which correspond to the representation clause of
    the enumerated type, not the position. On input, they are read as
    integers and I'd like to convert them to the enumerated type.

    The ARM suggests using Unchecked_Conversion to get from here to
    there, but now you've got to create an integer type that is the
    same size as the enumerated type. Here's a code fragment:

    --
    type Temp_Integer is range Integer'First..Integer'Last ;
    for Temp_Integer'Size use User_Types.CL_Evt_Status'Size ;
                            --^^^^^^^^^^^^^^^^^^^^^^ The enumerated type.

    function
        CVT_Evt_Status
    is new
        Ada.Unchecked_Conversion (
            Source  => Temp_Integer ;
            Target  => User_Types.CL_Evt_Status) ;

    You can now use the CVT_Evt_Status function to get from the
    external integer to the internal representation. However, the
    declaration of Temp_Integer might not work because you don't know
    that the 'Size of the enumerated type is big enough for the range.
    You can easily build a custom one-off that will work if you know
    enough about the type and it's representation, but it would be
    nicer to have a general solution which will work for any
    enumerated type & representation.

    GNAT is nice enough to provide the attribute: 'Enum_Rep which
    returns a Universal_Integer of the internal representation of an
    enumerated object. (I'm surprised this isn't standard!) This is a
    great answer when I'm writing the data out - all I've got to worry
    about is that the enumeral doesn't create a constraint_error when
    assigned to an integer object for output. What I'd like is a
    corresponding "'Integer_Rep" (or some other more appropriate name)
    attribute which converted from a Universal_Integer to the internal
    representation of the enumerated type - risking only
    Constraint_Error if the integer is not a member of the
    representation set.

    Has anyone got a suggestion as to how this can be done more
    elegantly with some other attributes or Unchecked_Conversion? I
    don't see any simple way to do this. (Please don't suggest 'Pos
    and 'Val. These will work If and only if the representation is
    identical to the position numbers - what you get if you don't
    specify a representation. What I've got are representations with
    gaps in them.) Thanks for any suggestions you have to offer.

    MDC

Marin David Condic, Senior Computer Engineer     ATT:        561.796.8997
Pratt & Whitney GESP, M/S 731-96, P.O.B. 109600  Fax:        561.796.4669
West Palm Beach, FL, 33410-9600                  Internet:   CONDICMA@PWFL.COM
===============================================================================
  "I saw a bank that said "24 Hour Banking", but I don't have that much time."
        --  Steven Wright
===============================================================================




^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~1997-09-11  0:00 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-09-09  0:00 Using the GNAT defined attribute: 'Enum_Rep Marin David Condic, 561.796.8997, M/S 731-96
1997-09-09  0:00 ` W. Wesley Groleau x4923
1997-09-11  0:00   ` Robert Dewar
  -- strict thread matches above, loose matches on Subject: below --
1997-09-09  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-09-09  0:00 ` Robert A Duff
1997-08-27  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-09-03  0:00 ` W. Wesley Groleau x4923
1997-09-06  0:00   ` Robert Dewar
1997-09-08  0:00     ` W. Wesley Groleau x4923
1997-09-08  0:00       ` Matthew Heaney
1997-09-08  0:00     ` Robert A Duff
1997-09-08  0:00   ` Robert A Duff
1997-09-08  0:00     ` W. Wesley Groleau x4923
1997-09-08  0:00       ` Matthew Heaney
1997-09-09  0:00         ` Robert A Duff
1997-09-11  0:00           ` Robert Dewar
1997-09-08  0:00 ` Robert A Duff

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