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