Representation clause for enumeratives

Representation clause for enumeratives

[Sandro Binetti]

 Hi everybody,

Suppose you have an enumerative type like the following:

type TYP_ENUM is (A,B,C);

for TYP_ENUM use(
        16#00000002#,
        16#00000004#,
        16#80000000#  -- <<<<< NOTICE THIS VALUE !!!

);

My GHS AdaMulti compiler reports this error:

 LRM:4.9(35), The static expression which is not part of a larger
static expression is outside the base range of its expected type.

My Gnat compiler, on the other side, does not say anything.

What's wrong with this such a 16#80000000#  value?
--
Ciao, Sandro


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Tarjei T. Jensen]

Sandro Binetti wrote 
>type TYP_ENUM is (A,B,C);
>
>for TYP_ENUM use(
>        16#00000002#,
>        16#00000004#,
>        16#80000000#  -- <<<<< NOTICE THIS VALUE !!!
>
>);

[snip]

>What's wrong with this such a 16#80000000#  value?

Have you tried to insert a size directive. e.g

type TYP_ENUM is (A,B,C);

for TYP_ENUM'size use 32;

for TYP_ENUM use (
        16#00000002#,
        16#00000004#,
        16#80000000
);

Perhaps that would work?

Greetings,

Re: Representation clause for enumeratives

[M. Kotiaho]

Robert Dewar wrote:

> In article <95u470$ho1$1@nnrp1.deja.com>,
>   Sandro Binetti <sandrobinetti@my-deja.com> wrote:
> > In article <95tre2$f33@news.kvaerner.com>,
> >   "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
> > > Have you tried to insert a size directive. e.g
> > >
> > > type TYP_ENUM is (A,B,C);
> > >
> > > for TYP_ENUM'size use 32;
> >
> > Done. But the problem is still the same ...
> > Why?
>
> Presumably a capacity limitation in the compiler you are
> using, not a terribly justifiable one, so you should bring
> this to the attention of the vendor. Most likely the decision
> is to use a signed 32-bit integer to represent enumerations,
> which as you see in this case can be an annoying restriction.
>
> Sent via Deja.com
> http://www.deja.com/

Indeed, GNAT on WinNT (Pentium-II) will allow the following:

    type TYP_ENUM is (A,B,C);

    for TYP_ENUM use(
       -16#8000000000000000#,
        16#00000002#,------#
        16#7FFFFFFFFFFFFFFF#  -- <<<<< NOTICE THIS VALUE !!!
 );

Apparently, GNAT is using a signed 64-bit integer.

Incidently, both compilers are sticking to the
"at least" portion of the implementation advice -- they
just define System.Min_Int and System.Max_Int differently:

(Copied from Lutz Donnerhacke's post)
>Implementation Advice
> 9. The recommended level of support for
enumeration_representation_clauses is:
>      1. An implementation should support at least the internal codes
in the
>         range System.Min_Int..System.Max_Int. An implementation need
not
>         support enumeration_representation_clauses for boolean types.

Markku Kotiaho

Re: Representation clause for enumeratives

[Steve O'Neill]

I'm making an assumption here that you are choosing these enumeration
values to match to some hardware encoding.  When I have found myself in
similar situations in the past I have usually taken a different route.

Rather than try to encode the enumeration values (which frequently leads to
frustration and maintenance issues) I would instead create an array of
appropriately typed objects that are indexed by the enumeration that I was
trying to map.  I would index into, search through, etc. that array
whenever I wanted to convert to/from the external hardware to the internal
meaning.  It might not seem as elegant or as potentially efficient as
assigning the enumeration value directly but in my experience it is a lot
less painful.  With the proper encapsulation and design metaphor it can
actually turn out to be fairly intuitive.

Steve O'Neill

"M. Kotiaho" wrote:

> Robert Dewar wrote:
>
> > In article <95u470$ho1$1@nnrp1.deja.com>,
> >   Sandro Binetti <sandrobinetti@my-deja.com> wrote:
> > > In article <95tre2$f33@news.kvaerner.com>,
> > >   "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
> > > > Have you tried to insert a size directive. e.g
> > > >
> > > > type TYP_ENUM is (A,B,C);
> > > >
> > > > for TYP_ENUM'size use 32;
> > >
> > > Done. But the problem is still the same ...
> > > Why?
> >
> > Presumably a capacity limitation in the compiler you are
> > using, not a terribly justifiable one, so you should bring
> > this to the attention of the vendor. Most likely the decision
> > is to use a signed 32-bit integer to represent enumerations,
> > which as you see in this case can be an annoying restriction.
> >
> > Sent via Deja.com
> > http://www.deja.com/
>
> Indeed, GNAT on WinNT (Pentium-II) will allow the following:
>
>     type TYP_ENUM is (A,B,C);
>
>     for TYP_ENUM use(
>        -16#8000000000000000#,
>         16#00000002#,------#
>         16#7FFFFFFFFFFFFFFF#  -- <<<<< NOTICE THIS VALUE !!!
>  );
>
> Apparently, GNAT is using a signed 64-bit integer.
>
> Incidently, both compilers are sticking to the
> "at least" portion of the implementation advice -- they
> just define System.Min_Int and System.Max_Int differently:
>
> (Copied from Lutz Donnerhacke's post)
> >Implementation Advice
> > 9. The recommended level of support for
> enumeration_representation_clauses is:
> >      1. An implementation should support at least the internal codes
> in the
> >         range System.Min_Int..System.Max_Int. An implementation need
> not
> >         support enumeration_representation_clauses for boolean types.
>
> Markku Kotiaho

Re: Representation clause for enumeratives

[Sandro Binetti]

In article <3A82C8DC.1505AC5@avidyne.com>,
  Steve O'Neill <soneill@avidyne.com> wrote:
> I'm making an assumption here that you are choosing these enumeration
> values to match to some hardware encoding.

OK! That's the case!

[ ... snip ... ]

Thank you, Steve.

--
Ciao, Sandro


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Martin Dowie]

also, if you are using the enumeration a lot for, say, array indexing _not_
having underlying representations tends to lead to much faster code. You
lose a little CPU time at the interface to do the conversion, but you may
find you gain many times that amount in your application.

If you want to save some typing make a few generics to do the conversions.
I know of several projects where precisely this sort of thing is happening
(and not just limited to enumeration conversions :-).

Come to think of it, I can hardly remember the last time I use a rep. clause
for an enumeration...

Steve O'Neill <soneill@avidyne.com> wrote in message
news:3A82C8DC.1505AC5@avidyne.com...
> Rather than try to encode the enumeration values (which frequently leads
to
> frustration and maintenance issues) I would instead create an array of
> appropriately typed objects that are indexed by the enumeration that I was
> trying to map.  I would index into, search through, etc. that array
> whenever I wanted to convert to/from the external hardware to the internal
> meaning.  It might not seem as elegant or as potentially efficient as
> assigning the enumeration value directly but in my experience it is a lot
> less painful.  With the proper encapsulation and design metaphor it can
> actually turn out to be fairly intuitive.
[snip]

Re: Representation clause for enumeratives

[Marin David Condic]

There is no law that says a compiler has to honor your representation
clause. It can legally recognize the rep clause and just simply reject
it. It is possible that your compiler has some built-in limitation that
prohibits using an unsigned, 32 bit representation for an enumeration.
Check with the compiler documentation or the compiler vendor.

MDC

Sandro Binetti wrote:

> In article <95tre2$f33@news.kvaerner.com>,
>   "Tarjei T. Jensen" <tarjei.jensen@kvaerner.com> wrote:
> > Have you tried to insert a size directive. e.g
> >
> > type TYP_ENUM is (A,B,C);
> >
> > for TYP_ENUM'size use 32;
>
> Done. But the problem is still the same ...
> Why?
>
> --
> Ciao, Sandro
>
> Sent via Deja.com
> http://www.deja.com/

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================

Re: Representation clause for enumeratives

[Rod Chapman]

In article <95tqbh$ag7$1@nnrp1.deja.com>,
  Sandro Binetti <sandrobinetti@yahoo.com> wrote:
>  Hi everybody,
>
> Suppose you have an enumerative type like the following:
<snip...>

Our usual coding standards for critical and real-time work
advise against the use of enumerated types with rep. clauses -
the code gen. and runtime impact is just too gross.

Try compiling the example with "gcc -c -gnatG" and see
what you get!  (No particular issue with GNAT here, it's just
the -gnatG option is uniquely instructive in illustrating
the point).
 - Rod



Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Robert Dewar]

In article <95uh36$to0$1@nnrp1.deja.com>,
  Rod Chapman <r_c_chapman@my-deja.com> wrote:

> Our usual coding standards for critical and real-time work
> advise against the use of enumerated types with rep. clauses
-
> the code gen. and runtime impact is just too gross.

I disagree with this advice, and the reason behind it. That's
MUCH too broad. There is no runtime impact if you do not use
the type for loops, arithmetic (succ/pred) or array subscripts.
If all you use it for is just assigning and comparing and
literal bit output, then this can be a valuable feature.

Yes, you could use named integers, but they would allow general
arithmetic which is likely meaningless.

For example, if you have a type representing possible opcodes
on a machine and a compiler uses them only in the context of
statements like

   generate (shr, .....)

that's perfectly reasonable, and has no deleterious runtime
impact.

It is almost ALWAYS wrong to advise that a particular feature
of the language should NEVER be used :-)



Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Rod Chapman]

In article <962ndo$g08$1@nnrp1.deja.com>,
  Robert Dewar <dewar@gnat.com> wrote:
> In article <95uh36$to0$1@nnrp1.deja.com>,
>   Rod Chapman <r_c_chapman@my-deja.com> wrote:

> I disagree with this advice, and the reason behind it. That's
> MUCH too broad. There is no runtime impact if you do not use
> the type for loops, arithmetic (succ/pred) or array subscripts.

Point taken - We may well add a warning to the Examiner for
those usages.
 - Rod


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Greg Bek]

Sandro,
What I think is happening is that AdaMulti is using a 32 bit signed type
to represent enumerated values.  The 16#8000_0000# value is outside
this range.

The supplied example compiles with Apex.

But if for instance you changed it to 16#8_0000_0000# (thinking you
had more than 32 bits) you would get the error:
10:28:19 >>> Line 8: for Typ_Enum use (16#00000002#, 16#00000004#,
16#8_0000_0000#);
10:28:19 *** The internal codes exceed the values representable with the
largest target integer type
This is because Apex uses a 32 bit unsigned type to store enumerated values.

Basically you have hit a compiler limit.  I'm not sure if you can use a
negative number for
the enumerated values with your compiler, if you can then reordering your
enumerated
type declaration to:

 type Typ_Enum is (C, A, B);

    for Typ_Enum use
       (-16#80000000#,16#00000002#, 16#00000004# )
     --^^^^ note the minus sign

Greg
-------------------------------------------
Greg Bek  mailto:gab@rational.com
Product Manager
Rational Software, Cupertino CA 95014
Ph: +1 408 863 4394   Fax: + 1 408 863 4180
-------------------------------------------
Sandro Binetti wrote in message <95tqbh$ag7$1@nnrp1.deja.com>...
> Hi everybody,
>
>Suppose you have an enumerative type like the following:
>
>type TYP_ENUM is (A,B,C);
>
>for TYP_ENUM use(
>        16#00000002#,
>        16#00000004#,
>        16#80000000#  -- <<<<< NOTICE THIS VALUE !!!
>
>);
>
>My GHS AdaMulti compiler reports this error:
>
> LRM:4.9(35), The static expression which is not part of a larger
>static expression is outside the base range of its expected type.
>
>My Gnat compiler, on the other side, does not say anything.
>
>What's wrong with this such a 16#80000000#  value?
>--
>Ciao, Sandro
>
>
>Sent via Deja.com
>http://www.deja.com/

Re: Representation clause for enumeratives

[Ken Garlington]

As an aside, here's some fun you can have with the following package in GNAT
3.12p:

: package Big_Enum is
:
:    type Object is  (A, B, C);
:
:    for Object use(
:       16#0000_0002#,
:       16#0000_0004#,
:       16#8000_0000#
:       );
:
:    for Object'Size use 32;
:
: end Big_Enum;

-- This works:

   for Object use(
      16#0000_0000#,
      16#7FFF_FFFF#,
      16#8000_0000#
      );

-- But change it to the following, and you get "value not in range of type
'Standard.Integer'"
-- (I only changed the first value to -1; it's not in Standard.Integer? :)

   for Object use(
      -1,
      16#7FFF_FFFF#,
      16#8000_0000#
      );

-- This works fine....

   for Object use(
      1,
      2,
      16#FFFF_FFFF#
      );

-- But the following draws the Standard.Integer message...

   for Object use(
      -16#FFFF_FFFF#,
      -2,
      -1
      );

Tsk - these limited enumeration representation ranges... :)

I wouldn't mind this behavior in a numeric type...

type Hardware_Numeric is range (-16#8000# .. 16#7FFF#) or ( 16#0000# ..
16#FFFF#);

A : Hardware_Numeric := -1; -- all further literals must be in range of
first clause...
X : Hardware_Numeric := 16#8000#; -- all further literals must be in range
of second clause...

Get that into Ada 0Y for me, will ya? :)

Re: Representation clause for enumeratives

[Robert Dewar]

In article <LRKg6.1443$y03.158823@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> As an aside, here's some fun you can have with the following
package in GNAT
> 3.12p:
>
> : package Big_Enum is
> :
> :    type Object is  (A, B, C);
> :
> :    for Object use(
> :       16#0000_0002#,
> :       16#0000_0004#,
> :       16#8000_0000#
> :       );

That's fine, GNAT will use a 32-bit unsigned representation

> -- But change it to the following, and you get "value not in
>range of type
> 'Standard.Integer'"
> -- (I only changed the first value to -1; it's not in
Standard.Integer? :)
>
>    for Object use(
>       -1,
>       16#7FFF_FFFF#,
>       16#8000_0000#
>       );

No, it's the 2**31 value at the end (16#8000_0000#) that
is not in the range of Standard.Integer. GNAT will use a
32 bit unsigned representation if it can, but if you use
a negative value, you force the use of a signed representation.
Note that biasing is not an option here, since the values must
denote actual representations.

> -- This works fine....
>
>    for Object use(
>       1,
>       2,
>       16#FFFF_FFFF#
>       );

Because a 32-bit unsigned representation can be used

> -- But the following draws the Standard.Integer message...
>
>    for Object use(
>       -16#FFFF_FFFF#,
>       -2,
>       -1
>       );

Because now a 32-bit unsigned representation cannot be used,
so a 32-bit signed representation must be used and the
first value is out of range.

> Tsk - these limited enumeration representation ranges... :)

Reread the above comments and I think things will be clear.
GNAT does its best to satisfy the semantic requirements, while
obeying the size restriction you have placed. It will choose
either a signed or unsigned representation, extending the
number of cases that can be covered, but it cannot fit more
bits into 32 bits than fit :-)

> I wouldn't mind this behavior in a numeric type...
>
> type Hardware_Numeric is range (-16#8000# .. 16#7FFF#) or (
16#0000# ..
> 16#FFFF#);
>
> A : Hardware_Numeric := -1; -- all further literals must be
in range of
> first clause...
> X : Hardware_Numeric := 16#8000#; -- all further literals
must be in range
> of second clause...
>
> Get that into Ada 0Y for me, will ya? :)

Hmmm! I think we will place more emphasis on the smiley here
than the suggestion :-) :-)

But you are confusing issues here, most certainly the idea of
a single type that somehow flips between signed and unsigned
is of course ludicrous.

But here we have separate types, and the RM quite specifically
does NOT specify limitations on the ranges of values that can
be accepted, so the compiler is free to choose any appropriate
underlying representation type.

Yes, it is definitely a non-required, but very useful, behavior
that GNAT will use either signed or unsigned representations
here (after all, the ability to use a signed representation
gives the original questioner what they wanted).

P.S. The one undesirable behavior in GNAT that I see, and will
fix is that the error flag is not clearly placed on the
particular literal that is causing trouble!

>
>


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:962n4v$fmg$1@nnrp1.deja.com...
: In article <LRKg6.1443$y03.158823@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > As an aside, here's some fun you can have with the following
: package in GNAT
: > 3.12p:
:
: > -- But change it to the following, and you get "value not in
: >range of type
: > 'Standard.Integer'"
: > -- (I only changed the first value to -1; it's not in
: Standard.Integer? :)
: >
: >    for Object use(
: >       -1,
: >       16#7FFF_FFFF#,
: >       16#8000_0000#
: >       );
:
: No, it's the 2**31 value at the end (16#8000_0000#) that
: is not in the range of Standard.Integer. GNAT will use a
: 32 bit unsigned representation if it can, but if you use
: a negative value, you force the use of a signed representation.

Hence the smiley face :) in the prior post :) By the way, this description
of the shifting of the allowable range (selecting different unbiased
representations) would be very useful in the GNAT user guide. I couldn't
find it.

: P.S. The one undesirable behavior in GNAT that I see, and will
: fix is that the error flag is not clearly placed on the
: particular literal that is causing trouble!

Which was also my point.

Re: Representation clause for enumeratives

[Robert Dewar]

In article <27eh6.3787$y03.254014@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> By the way, this description
> of the shifting of the allowable range (selecting different
> unbiased representations) would be very useful in the GNAT
> user guide. I couldn't find it.

Information on representation matters is really part of the
language, and in particular is required to be documented by
RM M(43). All such information is in the GNAT reference manual,
not in the users guide (which is about how to use the compiler,
rather than how to write programs). The divisision is not
always perfectly clear, but in this case, there is a chapter
called "Representation Clauses and Pragmas", which a section
called "Enumeration Clauses", that contains this information
as well as other important information.

In particular, one very important item which is (very
unfortunately) left implementation defined is what happens
if you have an array whose index type is an enumeration type
with holes. There are two implementations:

1. Use the representation to index, fast, but can waste space
(a lot of space if you have a rep clause like the one that
started this thread).

2. Use the pos value to index, slow, but compact

GNAT chooses the second, mostly because Verdix chose the
second, and we generally choose to be Verdix Ada 83 compatible
in such matters (in this case, this is also the choice made by
DEC Ada 83 and other Ada 83 compilers).


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:963tos$atu$1@nnrp1.deja.com...
: In article <27eh6.3787$y03.254014@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > By the way, this description
: > of the shifting of the allowable range (selecting different
: > unbiased representations) would be very useful in the GNAT
: > user guide. I couldn't find it.
:
: Information on representation matters is really part of the
: language, and in particular is required to be documented by
: RM M(43). All such information is in the GNAT reference manual,
: not in the users guide (which is about how to use the compiler,
: rather than how to write programs). The divisision is not
: always perfectly clear, but in this case, there is a chapter
: called "Representation Clauses and Pragmas", which a section
: called "Enumeration Clauses", that contains this information
: as well as other important information.

Perhaps this is in the 3.13p version of the reference manual? My version
3.12p dated 6 September 1999 does not have the specific information I
suggested. I searched for the word "representation", and found the following
with at least minimal bearing on the subject:

[Under "Implementation Defined Pragmas"]

No_Enumeration_Maps - similar to Discard_Names in C.5, but this is a
restriction instead. For enumeration types with representation clauses the
following attributes are not allowed....

[Under "Implementation Defined Attributes"]

Enum_Rep - for every enumeration subtype S, S'Enum_Rep denotes a
function....

[Under "Implementation Advice"]

3.5.5(8): Enumeration Values  - For the evaluation of a call on S'Pos for an
enumeration subtype, if the value of the operand does not correspond....
Followed.

13.4(9-10): Enumeration Representation Clauses - The recommended level of
support for enumeration representation clauses is: An implementation need
not support enumeration representation clauses for boolean types, but should
at minimum support the internal codes in the range
System.Min_Int.System.Max_Int [sic]. Followed.

[Under "Interfacing to Other Languages" -> "Interfacing to C"]

Ada enumeration types map to C enumeration types directly if pragma
Convention C is specified, which causes them to have int length. Without
pragma Convention C, Ada enumeration types map to 8, 16, or 32 bits (i.e. C
types signed char, short, int respectively) depending on the number of
values passed. This is the only case in which pragma Convention C affects
the representation of an Ada type.

[Under "Compatibility Guide" -> "Representation Clauses"]

There is no mention of enumeration representation clauses in this section.

: In particular, one very important item which is (very
: unfortunately) left implementation defined is what happens
: if you have an array whose index type is an enumeration type
: with holes. There are two implementations:
:
: 1. Use the representation to index, fast, but can waste space
: (a lot of space if you have a rep clause like the one that
: started this thread).
:
: 2. Use the pos value to index, slow, but compact
:
: GNAT chooses the second, mostly because Verdix chose the
: second, and we generally choose to be Verdix Ada 83 compatible
: in such matters (in this case, this is also the choice made by
: DEC Ada 83 and other Ada 83 compilers).

This must also have been introduced after the 3.12p version...

: Sent via Deja.com
: http://www.deja.com/

Re: Representation clause for enumeratives

[Robert Dewar]

In article <9Dlh6.4497$y03.296626@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:

> (lots of comments on an obsolete version of GNAT
> documentation snipped)

> Perhaps this is in the 3.13p version of the reference manual?
> My version 3.12p dated 6 September 1999 does not have the
> specific information I
> suggested.

Ahem -- we are now well into the 21st century, and indeed the
18 month old version you refer to is VERY out of date. 3.13
has been out for a year, and 3.14 will appear shortly. I
suggest updating :-)


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Laurent Guerby]

Robert Dewar <dewar@gnat.com> writes:
> Ahem -- we are now well into the 21st century, and indeed the
> 18 month old version you refer to is VERY out of date. 3.13
> has been out for a year, and 3.14 will appear shortly. I
> suggest updating :-)

May be more users would update and reread documentation if each new
manual had a "new and updated" section. (I already made this remark
has a customer BTW, so this is not only "free user" wishlist ;-)

You can't expect users to reread a few hundred (boring even if
well-written) pages they've already mostly read every six monthes and
do the mental diff (if it's even possible).

The release notes for the technical part is very good, why not do the
same for the documentation?

I really hope the GNAT 3.14 documentation will have such a section,
otherwise I probably won't read it, and this will nullify GNAT people
work on it (at least for me).

-- 
Laurent Guerby <guerby@acm.org>

Re: Representation clause for enumeratives

[Robert Dewar]

In article <86pugpbct5.fsf@acm.org>,
  Laurent Guerby <guerby@acm.org> wrote:

> May be more users would update and reread documentation if
> each new manual had a "new and updated" section. (I already
> made this remark has a customer BTW, so this is not only
> "free user" wishlist ;-)

The features file is intended to exactly satisfy this need.
What we see most customers doing is to read through the
features file (it's pretty long, but that's because there
are a lot of new features :-) Each feature has a few line
description, and if you are interested in finding more, then
you can look in the manual for details.

> You can't expect users to reread a few hundred (boring even
> if  well-written) pages they've already mostly read every six
> monthes and do the mental diff (if it's even possible).

Exactly, that's why we provide the features file.

> The release notes for the technical part is very good, why
> not do the same for the documentation?
>
> I really hope the GNAT 3.14 documentation will have such a
> section, otherwise I probably won't read it, and this will
> nullify GNAT people work on it (at least for me).

You should read through the features file. That ends up being
a guide for new documentation features as well as new technical
features in the compiler. For example, here is one of several
entries in the 3.14 features file relating to documentation:

NF-314-7718-001 Linker_Options extensions now documented

  The documentation (GNAT Reference Manual) has been
  enhanced to contain full documentation of the GNAT
  implementation of the Linker_Options pragma. GNAT
  allows multiple arguments, and also allows the use
  of ASCII.NUL to separate arguments in a single string.

Robert Dewar
Ada Core Technologies


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Laurent Guerby]

Robert Dewar <dewar@gnat.com> writes:
>   Laurent Guerby <guerby@acm.org> wrote:
> > The release notes for the technical part is very good, why
> > not do the same for the documentation?
> >
> > I really hope the GNAT 3.14 documentation will have such a
> > section, otherwise I probably won't read it, and this will
> > nullify GNAT people work on it (at least for me).
> 
> You should read through the features file. That ends up being
> a guide for new documentation features as well as new technical
> features in the compiler. For example, here is one of several
> entries in the 3.14 features file relating to documentation:

I do read and appreciate the feature file (as said in the first
paragraph). However, I don't think all the changes to the
documentation are mentionned (editorial, reorganisation and
corrections as well as new features doc, well all that's worth
rereading in the new documentation version), if the 3.14 feature is
more complete on this point that's great!

-- 
Laurent Guerby <guerby@acm.org>

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:9657rb$biv$1@nnrp1.deja.com...
: In article <9Dlh6.4497$y03.296626@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
:
: > (lots of comments on an obsolete version of GNAT
: > documentation snipped)
:
: > Perhaps this is in the 3.13p version of the reference manual?
: > My version 3.12p dated 6 September 1999 does not have the
: > specific information I
: > suggested.
:
: Ahem -- we are now well into the 21st century, and indeed the
: 18 month old version you refer to is VERY out of date. 3.13
: has been out for a year, and 3.14 will appear shortly. I
: suggest updating :-)

I know, I'm terrible about that. For example, I am *still* using Windows 98!

(How long has the public release of 3.13 been available? The download site
has file dates of  8/2/2000...)


:
:
: Sent via Deja.com
: http://www.deja.com/

Re: Representation clause for enumeratives

[Robert Dewar]

In article <27eh6.3787$y03.254014@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> : P.S. The one undesirable behavior in GNAT that I see, and
> : will fix is that the error flag is not clearly placed on
> : the particular literal that is causing trouble!
>
> Which was also my point.

OK, well it would help to be a little less obscure when making
such points in future :-) In particular, the flag is placed on
the representation clause itself, not on the wrong literal, so
it is not wrongly placed, just not as specifically placed as
you might like.

What is quite helpful is to quote -gnatl output in such cases
in comp.lang.ada listings, because then it is very clear what
the message is applying to, if you only quote the brief errors
we don't really know what line numbers are being referenced,
because we don't have the full program.

In fact I would not have noticed this at all if I had not
bothered to make a full example and compile it myself!


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:963tu2$b0f$1@nnrp1.deja.com...
: In article <27eh6.3787$y03.254014@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > : P.S. The one undesirable behavior in GNAT that I see, and
: > : will fix is that the error flag is not clearly placed on
: > : the particular literal that is causing trouble!
: >
: > Which was also my point.
:
: OK, well it would help to be a little less obscure when making
: such points in future :-) In particular, the flag is placed on
: the representation clause itself, not on the wrong literal, so
: it is not wrongly placed, just not as specifically placed as
: you might like.
:
: What is quite helpful is to quote -gnatl output in such cases
: in comp.lang.ada listings, because then it is very clear what
: the message is applying to, if you only quote the brief errors
: we don't really know what line numbers are being referenced,
: because we don't have the full program.

I'd like that, but I use the AdaGIDE that comes with 3.12p, and it doesn't
allow the messages to be cut and pasted.

:  In fact I would not have noticed this at all if I had not
: bothered to make a full example and compile it myself!
:
:
: Sent via Deja.com
: http://www.deja.com/

Re: Representation clause for enumeratives

[Robert Dewar]

In article <aDlh6.4498$y03.296626@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> I'd like that, but I use the AdaGIDE that comes with 3.12p,
> and it doesn't allow the messages to be cut and pasted.

Again, I suggest an update, also it is really not that hard
to enter the necessary commands (surely someone coming from
a VMS background can manage to do things in command mode :-)


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:9657ua$bjh$1@nnrp1.deja.com...
: In article <aDlh6.4498$y03.296626@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > I'd like that, but I use the AdaGIDE that comes with 3.12p,
: > and it doesn't allow the messages to be cut and pasted.
:
: Again, I suggest an update, also it is really not that hard
: to enter the necessary commands (surely someone coming from
: a VMS background can manage to do things in command mode :-)

Manage, yes -- but there's a difference from it being *possible* and being
*easy* to do (particularly when you're scrambling to finish exploring the
idea before going to work, and you haven't used command mode in a while).
Surely someone coming from an Ada background understands this distinction :)

In any case, I downloaded 3.13p (and AdaGIDE, which still doesn't allow
copies from the message screen). The 3.13p reference manual is much clearer
on the subject, although the phrase "The only restriction on enumeration
clauses is that the range of values must be representable" is still open to
interpretation. For example, I'd argue that -16#FFFF_FFFF# .. -1 is both
"representable" in 32 bits and in the range System.Min_Int ..
System.Max_Int. Words about treating a set with no negative values as
unsigned values, and as unbiased signed values otherwise would have been
clearer to me.

Re: Representation clause for enumeratives

[Robert Dewar]

In article <OExh6.5397$y03.334735@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> For example, I'd argue that -16#FFFF_FFFF# .. -1 is both
> "representable" in 32 bits and in the range System.Min_Int ..
> System.Max_Int.

> Words about treating a set with no negative values as
> unsigned values, and as unbiased signed values otherwise
> would have been clearer to me.

Don't hesitate to make documentation suggestions, many
improvements to the documentation come from suggestions
sent to report@gnat.com.

In this particular case, the RM of course does not allow
biasing of representations when an enumeration representation
clause is present, since this is one of the few (really the
only) case where the RM has something to say about
representation, and indeed the ACVC tests (I wrote the relevant
ones :-) test this by doing unchecked conversion.

But it never hurts to emphasize things in the documentation,
so I agree it would be helpful to point out that biased
representations cannot be used for enumeration types!


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:967ar9$sq7$1@nnrp1.deja.com...
: In article <OExh6.5397$y03.334735@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > For example, I'd argue that -16#FFFF_FFFF# .. -1 is both
: > "representable" in 32 bits and in the range System.Min_Int ..
: > System.Max_Int.
:
: > Words about treating a set with no negative values as
: > unsigned values, and as unbiased signed values otherwise
: > would have been clearer to me.
:
: Don't hesitate to make documentation suggestions, many
: improvements to the documentation come from suggestions
: sent to report@gnat.com.
:
: In this particular case, the RM of course does not allow
: biasing of representations when an enumeration representation
: clause is present, since this is one of the few (really the
: only) case where the RM has something to say about
: representation, and indeed the ACVC tests (I wrote the relevant
: ones :-) test this by doing unchecked conversion.

Would "biased" be the correct term for a representation of -16#FFFF_FFFF#
.. -1, where you use two's complement convention to store all negative
numbers (and ignore overflow)?

I'm also curious about how the ACVC tests use unchecked conversion in a
portable manner in this case. In particular, what are you converting _to_?

: But it never hurts to emphasize things in the documentation,
: so I agree it would be helpful to point out that biased
: representations cannot be used for enumeration types!
:
:
: Sent via Deja.com
: http://www.deja.com/

Re: Representation clause for enumeratives

[Robert Dewar]

In article <Ndyg6.1048$y03.96769@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> I don't know if either behavior is considered "wrong" by the
standard. I'm
> not comfortable with the GNAT behavior, since it treats
16#8000_0000# as a
> legal 32-bit integer value, although it is not in the range
Standard.Integer
> on the same machine.

Who says that the range of enumeration values is restricted
to Standard.Integer, in fact no one says it, and the RH in
the RM encourages you to go up to maxint which for GNAT
is 2**63-1. Why you should be uncomfortable because GNAT
does NOT implement a limitation which

(a) would not be helpful
(b) would violate implementation advice

is puzzling indeed!

> This just encourages the confusion between hex numbers
> and bit-patterns. I do see the utility of doing it this way,
> however.

I don't understand the confusion. GNAT chooses a large enough
signed or unsigned integer type to cover the range of values
provided.

Note that 16#8000_0000# is the number 2**32, it is a POSITIVE
number, nothing at all to do with the largest negative number.
I think the confusion is coming from the use of base 16, and
suddenly that is translating into bit patterns in your mind???

Any time you write 16#8000_0000# in your program, you could
equally well write 2147483648. The meaning is 100% identical.
If the first looks like a bit pattern to you, and the second
looks like an integer, then that's your confusion, not Ada's
:-)


Sent via Deja.com
http://www.deja.com/

Re: Representation clause for enumeratives

[David C. Hoos, Sr.]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:962mh2$f9v$1@nnrp1.deja.com...
> In article <Ndyg6.1048$y03.96769@news.flash.net>,
>   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> > I don't know if either behavior is considered "wrong" by the
> standard. I'm
> > not comfortable with the GNAT behavior, since it treats
> 16#8000_0000# as a
<snip>
> Note that 16#8000_0000# is the number 2**32, it is a POSITIVE

I believe Robert meant 2**31 here.

> number, nothing at all to do with the largest negative number.
> I think the confusion is coming from the use of base 16, and
> suddenly that is translating into bit patterns in your mind???
>
> Any time you write 16#8000_0000# in your program, you could
> equally well write 2147483648. The meaning is 100% identical.
> If the first looks like a bit pattern to you, and the second
> looks like an integer, then that's your confusion, not Ada's
> :-)

Re: Representation clause for enumeratives

[Ken Garlington]

"Robert Dewar" <dewar@gnat.com> wrote in message
news:962mh2$f9v$1@nnrp1.deja.com...
: In article <Ndyg6.1048$y03.96769@news.flash.net>,
:   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
: > I don't know if either behavior is considered "wrong" by the
: standard. I'm
: > not comfortable with the GNAT behavior, since it treats
: 16#8000_0000# as a
: > legal 32-bit integer value, although it is not in the range
: Standard.Integer
: > on the same machine.
:
: Who says that the range of enumeration values is restricted
: to Standard.Integer, in fact no one says it...

Well, actually GNAT says it under certain circumstances... see subsequent
posts!

This is the part I'm not confortable with... that the allowable range for a
enumeration type which is explicitly constrained to 32 bits shifts depending
upon how the enumeration values are written. Again, I see its utility in
practice, but I can also see how it might confuse new Ada users who try to
do the same thing in different contexts (see end).

, and the RH in
: the RM encourages you to go up to maxint which for GNAT
: is 2**63-1. Why you should be uncomfortable because GNAT
: does NOT implement a limitation which
:
: (a) would not be helpful
: (b) would violate implementation advice
:
: is puzzling indeed!
:
: > This just encourages the confusion between hex numbers
: > and bit-patterns. I do see the utility of doing it this way,
: > however.
:
: I don't understand the confusion. GNAT chooses a large enough
: signed or unsigned integer type to cover the range of values
: provided.
:
: Note that 16#8000_0000# is the number 2**32, it is a POSITIVE
: number, nothing at all to do with the largest negative number.
: I think the confusion is coming from the use of base 16, and
: suddenly that is translating into bit patterns in your mind???
:
: Any time you write 16#8000_0000# in your program, you could
: equally well write 2147483648. The meaning is 100% identical.
: If the first looks like a bit pattern to you, and the second
: looks like an integer, then that's your confusion, not Ada's
: :-)

Actually, the confusion is from the original poster (we really have to work
on your social skills, Robert :). The confusion is that 16#8000_0000# does,
indeed, look very much like a bit pattern as represented in certain other
popular languages. Further adding to the confusion is that this enumeration
value, when read as an Integer, is in fact not 2147483648 but -2147483648.
Particularly for engineers with a hardware/assembly background (who also
tend to be the ones who want to write this kind of code), the distinction
between an Unsigned_Integer, an Integer, and an integer on a
two's-complement machine is often difficult to grasp. Trust me -- I get to
hear about this confusion all of the time. In fact, on one recent project, I
had to write and distribute a three-page paper on this sort of distinction
due to the number of questions in this area (e.g. "Why won't this stupid
compiler do bit strings right?").


:
:
: Sent via Deja.com
: http://www.deja.com/

Re: Representation clause for enumeratives

[Stuart Palin]

Robert Dewar wrote:
> 
> In article <3A829EB8.A098925E@baesystems.com>,
>   Stuart Palin <stuart.palin@baesystems.com> wrote:
<snip some rubbish code>

> You could try it, but it would of course not compile :-)
<snip compiler response>
> 
> It is always a good idea to try compiling examples before
> you post them. I supposedly know Ada reasonably well, but I
> still find it easy to have a mind-slip now and then, and try
> to follow this discipline myself :-)

I plead guilty to ignoring Robert's oft given advice, and apologize to
the court :-)

I would write out the proper answer 100 times - but I don't think anyone
would like that; however, for the record I provide what I should have
written (checked with XD-Ada [83]).

  type TYP_ENUM is (C,A,B);
    -- NOTICE: 'C' has the lowest value representation and
    --         so must come first.

  for TYP_ENUM use(
     -16#80000000#,  -- NOTICE: the "-"
      16#00000002#,
      16#00000004#);

(other caveats and advice given elsewhere in this thread apply)

--
Stuart Palin