comp.lang.ada
 help / color / mirror / Atom feed
From: "Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>
Subject: Re: Using the GNAT defined attribute: 'Enum_Rep
Date: 1997/09/09
Date: 1997-09-09T00:00:00+00:00	[thread overview]
Message-ID: <97090912331704@psavax.pwfl.com> (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
===============================================================================




             reply	other threads:[~1997-09-09  0:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-09  0:00 Marin David Condic, 561.796.8997, M/S 731-96 [this message]
1997-09-09  0:00 ` Using the GNAT defined attribute: 'Enum_Rep 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     ` Robert A Duff
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     ` 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
replies disabled

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