comp.lang.ada
 help / color / mirror / Atom feed
* Re: Enumerations
@ 1992-09-17 21:20 david.c.willett
  0 siblings, 0 replies; 11+ messages in thread
From: david.c.willett @ 1992-09-17 21:20 UTC (permalink / raw)


>From article <9209162110.AA21397@efftoo.boeing.com>, by crispen@efftoo.boeing.
com (crispen):
> First, the caveat: I *know* that without rep specs all data in Ada is
> abstract.
> 
> But what I'd like to know is, does anyone know of an Ada compiler
> which does not give a machine value of zero for the first element of
> an enumeration, one for the second, and so on?
> 
> Just idle curiosity, actually, since it came up in the context of a
> document I'm writing that's going to say, "Use rep specs for interface
> objects and don't trust different compilers to do the same thing".
> 
> Thanks,
> +-------------------------------+--------------------------------------+
> | Bob Crispen                   |   The owls are not what they seem    |
> | crispen@foxy.boeing.com       +--------------------------------------+
> | (205) 461-3296                |Opinions expressed here are mine alone|
> +-------------------------------+--------------------------------------+

I don't have an answer to your specific question, but as a matter of principle
I would use rep specs for all "interface objects" (I presume you mean objects
specified in an interface definition).  You may wish to consider supplying 
the interface definition as a package of type definitions replete with rep
specs.


-- 
Dave Willett          AT&T Federal Systems Advanced Technologies
attmail!dwillett      (AT&T FSAT)

A dog is a dog until he is facing you.  Then he is *MISTER* dog!

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

* Re: Enumerations
@ 1992-09-17 22:26 Darren Davenport 283-4173
  0 siblings, 0 replies; 11+ messages in thread
From: Darren Davenport 283-4173 @ 1992-09-17 22:26 UTC (permalink / raw)


In article <9209162110.AA21397@efftoo.boeing.com>, crispen@efftoo.boeing.com (c
rispen) writes:
|> First, the caveat: I *know* that without rep specs all data in Ada is
|> abstract.
|> 
|> But what I'd like to know is, does anyone know of an Ada compiler
|> which does not give a machine value of zero for the first element of
|> an enumeration, one for the second, and so on?
|> 
|> Just idle curiosity, actually, since it came up in the context of a
|> document I'm writing that's going to say, "Use rep specs for interface
|> objects and don't trust different compilers to do the same thing".
|> 
|> Thanks,
|> +-------------------------------+--------------------------------------+
|> | Bob Crispen                   |   The owls are not what they seem    |
|> | crispen@foxy.boeing.com       +--------------------------------------+
|> | (205) 461-3296                |Opinions expressed here are mine alone|
|> +-------------------------------+--------------------------------------+

You do not need to write that in your document because:

"The position number of the value of the first listed enumeration literal is
zero" LRM 3.5.1(4). 

Darren Davenport
McDonnell Douglas Space Systems Company, Houston Tx

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

* Re: Enumerations
@ 1992-09-17 23:40 Kevin Simonson
  0 siblings, 0 replies; 11+ messages in thread
From: Kevin Simonson @ 1992-09-17 23:40 UTC (permalink / raw)


     In article <1992Sep17.222636.4782@aio.jsc.nasa.gov>
davenpor@sweetpea.jsc.nasa.gov (Darren Davenport 283-4173) writes:

=In article <9209162110.AA21397@efftoo.boeing.com>, crispen@efftoo.boeing.com
=(crispen) writes:
...
=|> But what I'd like to know is, does anyone know of an Ada compiler
=|> which does not give a machine value of zero for the first element of
=|> an enumeration, one for the second, and so on?
=|> 
=|> Just idle curiosity, actually, since it came up in the context of a
=|> document I'm writing that's going to say, "Use rep specs for interface
=|> objects and don't trust different compilers to do the same thing".
...
=You do not need to write that in your document because:
=
="The position number of the value of the first listed enumeration literal is
=zero" LRM 3.5.1(4). 

     I was of the impression that the "position number" 3.5.1(4) referred
to was the value returned by the "'pos" attribute, and that that value
could be very different from the "machine value" that Crispen seems to be
talking about.  I'm not convinced we've found an answer to his question
yet.

                                     ---Kevin Simonson

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

* Re: Enumerations
@ 1992-09-18  1:39 Michael Feldman
  0 siblings, 0 replies; 11+ messages in thread
From: Michael Feldman @ 1992-09-18  1:39 UTC (permalink / raw)


In article <1992Sep17.234026.27654@beaver.cs.washington.edu> simonson@cs.washin
gton.edu (Kevin Simonson) writes:
>
[stuff deleted]
>=
>="The position number of the value of the first listed enumeration literal is
>=zero" LRM 3.5.1(4). 
>
>     I was of the impression that the "position number" 3.5.1(4) referred
>to was the value returned by the "'pos" attribute, and that that value
>could be very different from the "machine value" that Crispen seems to be
>talking about.  I'm not convinced we've found an answer to his question
>yet.

No we haven't. The position number is _not_ the same as the machine value.
I have tried this on every compiler I have access to (about a dozen of
different makes and models), and not found any in which the machine
values are not 0,1,...This is not required by the LRM, but I find myself
wondering why an implementer would do it differently. It's so _easy_
this way.

I will post a little tricky program to play with stuff like this.
The only way I've found to learn the machine values (other than
the documentation), is to do an unchecked conversion to integer,
then display the value in binary or hex, and stare at it.

Mike Feldman 
------------------------------------------------------------------------
Michael B. Feldman
co-chair, SIGAda Education Committee

Professor, Dept. of Electrical Engineering and Computer Science
School of Engineering and Applied Science
The George Washington University
Washington, DC 20052 USA
(202) 994-5253 (voice)
(202) 994-5296 (fax)
mfeldman@seas.gwu.edu (Internet)

"Americans wants the fruits of patience -- and they want them now."
------------------------------------------------------------------------
>
>                                     ---Kevin Simonson

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

* Re: Enumerations
@ 1992-09-18 15:41 Mark A Biggar
  0 siblings, 0 replies; 11+ messages in thread
From: Mark A Biggar @ 1992-09-18 15:41 UTC (permalink / raw)


In article <1992Sep17.222636.4782@aio.jsc.nasa.gov> davenpor@sweetpea.jsc.nasa.
gov (Darren Davenport 283-4173) writes:
>In article <9209162110.AA21397@efftoo.boeing.com>, crispen@efftoo.boeing.com (
crispen) writes:
>|> First, the caveat: I *know* that without rep specs all data in Ada is
>|> abstract.
>|> But what I'd like to know is, does anyone know of an Ada compiler
>|> which does not give a machine value of zero for the first element of
>|> an enumeration, one for the second, and so on?
>|> Just idle curiosity, actually, since it came up in the context of a
>|> document I'm writing that's going to say, "Use rep specs for interface
>|> objects and don't trust different compilers to do the same thing".
>You do not need to write that in your document because:
>"The position number of the value of the first listed enumeration literal is
>zero" LRM 3.5.1(4). 

Sorry, but that only says that E'POS(E'FIRST) must be 0, it dosn't say
anything about what bits are actually stored in memory.  Rememeber that even
if there is a rep spec specifing the stored values of the enumeration, the abov
e
identity is still true.  In fact, the only way to determine what bit values
are being used for a given enumeration literal is to use UNCHECKED_CONVERSION
to translate to a suitable integer type.  Now as a Quality Of Implementation
issue I would expect that most Ada compilers, in the absense of a rep spec,
do store the value E'POS(X) for enumeration literal X, but the LRM does not
require it.  I also do not believe that Ada9x gives any relief in this area.

--
Mark Biggar
mab@wdl1.wdl.loral.com

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

* Re: Enumerations
@ 1992-09-18 17:54 Michael Feldman
  0 siblings, 0 replies; 11+ messages in thread
From: Michael Feldman @ 1992-09-18 17:54 UTC (permalink / raw)


In article <1992Sep18.154145.6086@wdl.loral.com> mab@wdl39.wdl.loral.com (Mark 
A Biggar) writes:
[ stuff deleted]

>identity is still true.  In fact, the only way to determine what bit values
>are being used for a given enumeration literal is to use UNCHECKED_CONVERSION
>to translate to a suitable integer type.  Now as a Quality Of Implementation
>issue I would expect that most Ada compilers, in the absense of a rep spec,
>do store the value E'POS(X) for enumeration literal X, but the LRM does not
>require it.  I also do not believe that Ada9x gives any relief in this area.

Your use of the word "relief" suggests that you think something is broken
here. What's wrong with this? Ada - as a matter of design philosophy -
tries to separate abstraction from implementation. You write down a sequence
of enumeration literals; 99.9% of the time you could not care less what the
corresponding bits are. For the 0.1% of the time when you do care (oh, OK,
so maybe it's a few percent), you use repspecs. This is bad? What's
wrong with the implementer choosing an easy set of _default_ reps as
long as your repspec override is obeyed faithfully?

Mike Feldman

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

* Re: Enumerations
@ 1992-09-19  0:40 John Goodenough
  0 siblings, 0 replies; 11+ messages in thread
From: John Goodenough @ 1992-09-19  0:40 UTC (permalink / raw)


The one case in which you might expect a compiler to provide a default
enumeration representation different from that of the position number is for
the predefined type BOOLEAN.  My understanding is that on some architectures
it can be more efficient to code FALSE as a negative number (e.g., all ones)
and TRUE as a non-negative number (e.g., all zeroes).  As I recall, it was at
least partly for this reason that the LRM did not specify the default
representation for enumeration types.  

Robert Dewar is fond of pointing out (as a way of highlighting the common
confusion between an abstract value and its representation) that it should not
be considered peculiar that the LRM fails to specify a default representation
for enumeration values; it doesn't specify the default representation of
integers either!  

John B. Goodenough					Goodenough@sei.cmu.edu
Software Engineering Institute				412-268-6391

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

* Re: Enumerations
@ 1992-09-19  1:18 Mark A Biggar
  0 siblings, 0 replies; 11+ messages in thread
From: Mark A Biggar @ 1992-09-19  1:18 UTC (permalink / raw)


In article <1992Sep18.175423.25826@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael
 Feldman) writes:
>In article <1992Sep18.154145.6086@wdl.loral.com> mab@wdl39.wdl.loral.com (Mark
 A Biggar) writes:
>[ stuff deleted]
>
>>.. I also do not believe that Ada9x gives any relief in this area.
>Your use of the word "relief" suggests that you think something is broken
>here. What's wrong with this? Ada - as a matter of design philosophy -
>tries to separate abstraction from implementation. You write down a sequence
>of enumeration literals; 99.9% of the time you could not care less what the
>corresponding bits are. For the 0.1% of the time when you do care (oh, OK,
>so maybe it's a few percent), you use repspecs. This is bad? What's
>wrong with the implementer choosing an easy set of _default_ reps as
>long as your repspec override is obeyed faithfully?

It was suggested early in the Ada9X effort that there should be attributes
like 'POS and 'VAL that delt with the real stored values of enumerations.
These were dropped as part of the Zero-budget simplifications.
All I ment by relief was that Ada9x did not provide a more convienent method
of dealing with the stroed values of enumeration literals then that provided
by Ada83.

--
Mark Biggar
mab@wdl1.wdl.loral.com

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

* Re: Enumerations
@ 1992-09-19  2:31 Michael Feldman
  0 siblings, 0 replies; 11+ messages in thread
From: Michael Feldman @ 1992-09-19  2:31 UTC (permalink / raw)


In article <1992Sep19.011823.15070@wdl.loral.com> mab@wdl39.wdl.loral.com (Mark
 A Biggar) writes:
>
>It was suggested early in the Ada9X effort that there should be attributes
>like 'POS and 'VAL that delt with the real stored values of enumerations.
>These were dropped as part of the Zero-budget simplifications.
>All I ment by relief was that Ada9x did not provide a more convienent method
>of dealing with the stroed values of enumeration literals then that provided
>by Ada83.
>
But I'm still puzzled. Why do you need to do this? Either you care about
the values, or you don't (depends on the application). If you don't care,
you treat the enumeration as purely abstract. If you _do_ care, you 
write a repspec, _then_ you treat the enumeration as abstract. Am I
missing something? Under what circumstances do you need to deal
directly with the stored values?

Mike Feldman

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

* Re: Enumerations
@ 1992-09-20 22:32 Gary Morris @pulsar
  0 siblings, 0 replies; 11+ messages in thread
From: Gary Morris @pulsar @ 1992-09-20 22:32 UTC (permalink / raw)


In <1992Sep19.004035.22312@sei.cmu.edu> Goodenough@sei.cmu.edu (John Goodenough
) writes:
>The one case in which you might expect a compiler to provide a default
>enumeration representation different from that of the position number is for
>the predefined type BOOLEAN.  My understanding is that on some architectures
>it can be more efficient to code FALSE as a negative number (e.g., all ones)
>and TRUE as a non-negative number (e.g., all zeroes).  

This is true on the 68000 family processors, using 0 for false and -1 for
true is more efficient that 0 and 1.  Our current 68020 code generator takes
advantage of this.
--GaryM
-- 
Gary Morris                     Internet: garym@telesoft.com
Ada Software Development        UUCP:     uunet!telesoft!garym
TeleSoft, San Diego, CA         Phone:    +1 619-457-2700

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

* Re: Enumerations
@ 1992-09-22 14:27 Chris Elliott
  0 siblings, 0 replies; 11+ messages in thread
From: Chris Elliott @ 1992-09-22 14:27 UTC (permalink / raw)


In article <9209162110.AA21397@efftoo.boeing.com> crispen@efftoo.boeing.com (cr
ispen) writes:
>But what I'd like to know is, does anyone know of an Ada compiler
>which does not give a machine value of zero for the first element of
>an enumeration, one for the second, and so on?
>
>Just idle curiosity, actually, since it came up in the context of a
>document I'm writing that's going to say, "Use rep specs for interface
>objects and don't trust different compilers to do the same thing".



I don't think the LRM defines the starting machine representation
of an enumeration type.  The position of that type is defined to
start at zero in 3.5.1, even if you use a representation clause.
However the position is not necessarily the same as the machine
representation.  To sum up:  If it ain't in the LRM, don't count
on it.

-Chris Elliott   celliott@gelac.lockheed.com

-- 
Chris Elliott - celliott@gelac.lockheed.com

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

end of thread, other threads:[~1992-09-22 14:27 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1992-09-20 22:32 Enumerations Gary Morris @pulsar
  -- strict thread matches above, loose matches on Subject: below --
1992-09-22 14:27 Enumerations Chris Elliott
1992-09-19  2:31 Enumerations Michael Feldman
1992-09-19  1:18 Enumerations Mark A Biggar
1992-09-19  0:40 Enumerations John Goodenough
1992-09-18 17:54 Enumerations Michael Feldman
1992-09-18 15:41 Enumerations Mark A Biggar
1992-09-18  1:39 Enumerations Michael Feldman
1992-09-17 23:40 Enumerations Kevin Simonson
1992-09-17 22:26 Enumerations Darren Davenport 283-4173
1992-09-17 21:20 Enumerations david.c.willett

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