-ve values in enumeration rep clauses.

-ve values in enumeration rep clauses.

[Darel Cullen]

Hi,
   Came across an interesting problem at work today.

What happens if for example :-

type A_Type is 
        ( A, B, C );

for A_Type use
        (       
          A => -1,
          B => -2,
          C => -3
        );

for A_Type'Size use 8;

Now - to be able to extract the -ve values via unchecked_conversion
from a byte proves impossible because the use 8 creates an unsigned
byte, so whats the best way to represent negative values from a
rep-claused enumerated type ?

-- 
Darel Cullen

Re: -ve values in enumeration rep clauses.

[James Rhodes]

Darel Cullen <Darel@djcull.demon.co.uk.demon.co.uk> wrote:
>Hi,
>   Came across an interesting problem at work today.
>
>What happens if for example :-
>
>type A_Type is 
>        ( A, B, C );
>
>for A_Type use
>        (       
>          A => -1,
>          B => -2,
>          C => -3
>        );
>
>for A_Type'Size use 8;
>

Doesn't the ordering of the values have to match the ordering
of the literals? i.e. the order of the integer values 
( -1 , -2 , -3 ) is decreasing hence illegal, so change
the order to ( -3 , -2 , -1 ) and change the enumerated values
appropriately.

As this is not what you asked, I'll not dwell on this.
     


>Now - to be able to extract the -ve values via unchecked_conversion
>from a byte proves impossible because the use 8 creates an unsigned
>byte, so whats the best way to represent negative values from a
>rep-claused enumerated type ?
>

Although I don't like using UNCHECKED_CONVERSION generally...
you could try something this

   type MY_INT is new INTEGER range -128 .. 127;
   for MY_INT'size use 8;

then instansiate and use UNCHECKED_CONVERSION in the usual way.

your compiler may (or may not ) have a predifined INTEGER type 
( such as SHORT_SHORT_INTEGER ) of this size already which you can
use.

You've not indicated what you are trying to do in more general 
terms so I'll not try to second guess you with different ideas.



Have a nice day,

   James.

Re: -ve values in enumeration rep clauses.

[Robert Dewar]

Darrel asked about an interesting problem where enuemration literals are
not ordered. This is of course illegal, as GNAT will be happy to inform you:

     1. procedure w is
     2.  type A_Type is
     3.         ( A, B, C );
     4.  for A_Type use
     5.         (
     6.           A => -1,
     7.           B => -2,
                  |
        >>> enumeration value for "B" not ordered

     8.           C => -3
                  |
        >>> enumeration value for "C" not ordered

     9.         );
    10.  for A_Type'Size use 8;
    11. begin
    12.    null;
    13. end;

Re: -ve values in enumeration rep clauses.

[Adam Beneschan]

Darel Cullen <Darel@djcull.demon.co.uk.demon.co.uk> writes:
 >Hi,
 >   Came across an interesting problem at work today.
 >
 >What happens if for example :-
 >
 >type A_Type is 
 >        ( A, B, C );
 >
 >for A_Type use
 >        (       
 >          A => -1,
 >          B => -2,
 >          C => -3
 >        );
 >
 >for A_Type'Size use 8;
 >
 >Now - to be able to extract the -ve values via unchecked_conversion
 >from a byte proves impossible because the use 8 creates an unsigned
 >byte, so whats the best way to represent negative values from a
 >rep-claused enumerated type ?
 >

I'm not following any of this.

First, the first rep clause for A_Type is illegal, because if you have
an enumeration rep clause, the integers have to be in ascending order
(assuming the enumeration literals are listed in order).  The integers
you have here are in descending order.

Second, I don't see how "use 8" creates an unsigned byte.  It simply
allocates 8 bits for each object of type A_Type.  From an Ada
standpoint, you can't call it "signed" or "unsigned", since the values
represented in those 8 bits are enumeration values and not integers.

If what you mean to say is that the compiler is generating
unsigned-byte instructions to deal A_Type, then your compiler probably
has a bug.  Even so, that shouldn't affect things too much if all the
integers in the rep clause are negative.  It would be worse if you
said 

   for A_Type use ( A => -1, B => 0, C => 1 );

and now, when you compare to A_Types, the generated code might
erroneously think A > C if it treates the bytes as unsigned during the
comparison.

I'm not sure how unchecked_conversion would be affected, though.  If
you say

     type Signed_Byte is integer range -128 .. 127;
     for Signed_Byte'size use 8;

     function To_Signed_Byte is new 
         Unchecked_Conversion (A_Type, Signed_Byte);

then when you convert an A_Type to a Signed_Byte, the compiler should
simply be copying the bit pattern, so it doesn't matter whether the
compiler thinks of A_Type as "signed" or "unsigned".  The
Unchecked_Conversion will make it signed.

If you're trying something like this:

     type Signed_Word is integer range -(2**31) .. 2**31-1;
     for Signed_Word'size use 32;

     function To_Signed_Word is new 
         Unchecked_Conversion (A_Type, Signed_Word);

I don't know what results you will get, and I don't recommend doing
this in any case.  I don't like using Unchecked_Conversion when the
two types don't have the same size.

In any case, if you want help with your problem, it would be best to
show us exactly what Ada code you were trying to run and what
unexpected results you got.  Your description doesn't make it clear
just what you were trying to do.

                                -- Adam

Re: -ve values in enumeration rep clauses.

[Pascal Ledru]

Obviously the range of your byte type should include negative values:

with Unchecked_Conversion;
with Text_IO;
procedure X is

  type A_Type is (A,B,C);

  for A_Type use
    ( A => -3,
      B => -2,
      C => -1 );

  for A_Type'Size use 8;

  --type Byte is new Integer range 0 .. 255;
  type Byte is new Integer range -126 .. 127;

  for Byte'Size use 8;

  function Convert is new Unchecked_Conversion
    ( Source => A_Type,
      Target => Byte );

begin
  Text_IO.Put_Line(Byte'Image( ( Convert(A) );
end;