Help needed in port to GNAT95 from verdix

Help needed in port to GNAT95 from verdix

[Paul Hussein]

I do not understand  why a piece of code that works on verdix will not now
work an gnat95, and this is an important piece of code. If anyone could help
it would be most appreciated.


When I run this code sample, and the code itself  in our system I get a
constraint error.
This code endeavours to turn any type into an array of floats for passing
over the network.



generic
   -- Type that is to be packed
   type Object_Type is private;
package Packer is
   type Packed_Object_Type is array ( POSITIVE range <> ) of FLOAT;
   --
   -- PURPOSE:
   -- Packs the object into the array of floats
   --
   function Pack   ( Object : in Object_Type ) return Packed_Object_Type;
   --
   -- PURPOSE:
   -- Unpacks the object from the array of floats
   --
   function UnPack ( Packed_Object : in Packed_Object_Type ) return
Object_Type;
end Packer;
--
-- Standard Packages
--
with UNCHECKED_CONVERSION;
package body Packer is
   --
   -- PURPOSE:
   -- Packs the object into the array of floats
   --
   function Pack ( Object : in Object_Type ) return Packed_Object_Type is
      Size_Of_Array : POSITIVE := Object_Type'size/FLOAT'size + 1;
      subtype Local_Packed_Object_Type is Packed_Object_Type ( 1 ..
Size_Of_Array );
      Packed_Object : Local_Packed_Object_Type;
      function To_Array is new UNCHECKED_CONVERSION
        ( Source => Object_Type,
          Target => Local_Packed_Object_Type );
   begin --Pack
      Packed_Object := To_Array ( Object );
      return Packed_Object;
   end Pack;
   --
   -- PURPOSE:
   -- Unpacks the object from the array of floats
   --
   function UnPack ( Packed_Object : in Packed_Object_Type ) return
Object_Type is
      Size_Of_Array : POSITIVE := Object_Type'size/FLOAT'size + 1;
      subtype Local_Packed_Object_Type is Packed_Object_Type ( 1 ..
Size_Of_Array );
      function To_Object is new UNCHECKED_CONVERSION
        ( Source => Local_Packed_Object_Type,
          Target => Object_Type );
   begin --UnPack
      return To_Object ( Packed_Object );
   end UnPack;
end Packer;

package Sim_Support is
   type Data_Array is array ( POSITIVE range <> ) of FLOAT;
end Sim_Support;

with Packer;
with Text_IO;
with Sim_Support;
procedure Test is
   type Affile is ( red, green );
   type strings is array ( 1.. 20 ) of STRING(1..10);
   type ar is array ( 1 .. 10 ) of integer;
   type blob ( switch : boolean := true ) is
      record
         case switch is
            when true =>
               a : Affile := Affile'first;
               b : ar;
            when false =>
               c : strings;
         end case; --switch
      end record;
   package p is new packer ( blob );
   procedure pack
      ( Data   : in blob;
        Floats : out Sim_Support.Data_Array ) is
   begin
      declare
         Packed : constant P.Packed_Object_Type :=
            P.Pack ( data );
      begin
         Floats := Sim_Support.Data_Array ( Packed );
      end;
   end;
   procedure unpack
      ( Data   : out blob;
        Floats : in Sim_Support.Data_Array ) is
   begin
      Data := P.UnPack ( P.Packed_Object_Type ( Floats ) );
   end;
   to_convert : blob;
   Floats     : Sim_Support.Data_Array ( 1 .. 10_000 );
begin --test
   text_io.put_line ( integer'image (blob'size) );
   text_io.put_line ( integer'image (Floats'size) );
   to_convert.a := green;
   for I in to_convert.b'range loop
      to_convert.b(I) := I;
   end loop;
   pack
      ( Data   => to_convert,
        Floats => Floats );
   unpack
      ( Data   => to_convert,
        Floats => Floats );
end test;

Re: Help needed in port to GNAT95 from verdix

[Mats Weber]

Paul Hussein wrote:
> 
> I do not understand  why a piece of code that works on verdix will not now
> work an gnat95, and this is an important piece of code. If anyone could help
> it would be most appreciated.

Because it contains assumptions about the 'Size of Float, and
unchecked_conversion to/from an array of floats. Consider yourself lucky if
this ports between different versions of the Verdix compiler.

> When I run this code sample, and the code itself  in our system I get a
> constraint error.
> This code endeavours to turn any type into an array of floats for passing
> over the network.

A very bad idea. Not any sequence of bits is a valid float.

If you really have to convert to something, then use 

   type Byte is 0 .. 255;
   for Byte'Size use 8;
   type Byte_Array is array (Positive range <>) of Byte;
   pragma Pack(Byte_Array);

where any sequence of bits is a valid value.

Re: Help needed in port to GNAT95 from verdix

[Charles Hixson]

It seems to me that I have been reading that it should be:
type Byte is -128..127;
or it won't fit into 8 bits, which certainly seems to be what you are
planning here.  Something about values requiring symmetry around 0?

Please let me know if I'm confused, as Ada is by no means my primary
language.

Mats Weber wrote:
> 
> Paul Hussein wrote:
> >
> > I do not understand  why a piece of code that works on verdix will not now
> > work an gnat95, and this is an important piece of code. If anyone could help
> > it would be most appreciated.
> 
> Because it contains assumptions about the 'Size of Float, and
> unchecked_conversion to/from an array of floats. Consider yourself lucky if
> this ports between different versions of the Verdix compiler.
> 
> > When I run this code sample, and the code itself  in our system I get a
> > constraint error.
> > This code endeavours to turn any type into an array of floats for passing
> > over the network.
> 
> A very bad idea. Not any sequence of bits is a valid float.
> 
> If you really have to convert to something, then use
> 
>    type Byte is 0 .. 255;
>    for Byte'Size use 8;
>    type Byte_Array is array (Positive range <>) of Byte;
>    pragma Pack(Byte_Array);
> 
> where any sequence of bits is a valid value.

-- 
Charles Hixson	charleshixson@earthling.net
(510) 464-7733	or chixso@mtc.dst.ca.us

Re: Help needed in port to GNAT95 from verdix

[Robert Dewar]

Bob Duff said

<<Byte'Size will be 8 by default, given the above.  Also, if you say:

    type Byte is range 0..2**8-1;

then Byte'Size will still be 8 by default.  (And of course you can say
"for Byte'Size use 8;" in either case; you're just confirming the
default.)
>>


Technically true, but *highly* misleading. The RM is badly flawed in the
area of size (the 83 RM was better, because it left things looser, the
Ada 95 RM tried to tighten things up and got it wrong!)

Yes, it is true that Byte'Size will be 8 by default (because this is what
the Ada 95 -- rather mistakenly -- requires). But the Ada 95 RM does NOT
require that objects of type Byte take 8 bits. 

The trouble is that most people think of the size of an object as being
determined by the size of the type, but that is generally not true in 
Ada 95 (though it was typically true in the default case in Ada 83).

Consider:

	type r is range 0 .. 5;

A typical Ada 83 implementation will likely make the size of "r" objects be
8 bits, and set r'size to 8. 

A typical Ada 95 implementation will likely make the size of "r" objects be
8 bits, but r'size is required to be 3.

We have found in GNAT that the most compatible approach (i.e. compatible
to typical Ada 83 implementations), is to make the size of objects of a
given subtype by default take up the same size as the base type, regardless
of subtype range. So in GNAT:

    type Byte is range 0..2**8-1;

since Byte'Base is obviously required to be large than 8 bits, we allocate
16 bits by default for objects of type Byte. This can of course be
overridden by giving a size clause, either for the object OR FOR THE TYPE, so
in GNAT

    for Byte'Size use 8;

causes objects to by 8 bits by default.

If you are only using GNAT, the entire size mess is cleaned yup nicely by
use of the implenmentation defined attributes Object_SIze and Value_Size
which properly separate these two aspects of Size. In Ada 83, it was left
rather vague as to which of these two was being talked about. In Ada 95,
the RM requires that the SIze attribute return the size of values, rather
than the size of objects.

That's a mistake in my view, but it's too late now.

Note: the latest version of GNAT implements an attribute
VADS_Size, which gives exactly the size value that would have been
given by the VADS Ada 83 compiler (some of our customers found that the
incompatible changes to the meaning of 'Size were just too extensive
to be fixable).

FOr example, the common Ada 83 paradigm for do it yourself streams, namely
using 'Size on the type of an object to find out how many bits to read
or write, is likely to break badly in Ada 95 ports of such code.

Re: Help needed in port to GNAT95 from verdix

[Matthew Heaney]

In article <355B319B.BAFDC332@earthling.net>, Charles Hixson
<charleshixson@earthling.net> wrote:

(start of quote)
It seems to me that I have been reading that it should be:
type Byte is -128..127;
or it won't fit into 8 bits, which certainly seems to be what you are
planning here.  Something about values requiring symmetry around 0?
(end of quote)

No - that was my fault.  I was trying to figure out why the size of an
object wasn't being set to 8 bits as requested, but I my hypothesis re the
range of the base type was incorrect.  Sorry for the confusion.

Anyway, if you need a data type to represent a raw, uninterpreted sequence
of 8 bits (ie byte), then use the types in Interfaces.  That is a
predefined package, and so the types are already declared for you. 
Something like

type Byte is new Interfaces.Unsigned_8;

Re: Help needed in port to GNAT95 from verdix

[Jean-Pierre Rosen]

>A typical Ada 83 implementation will likely make the size of "r" objects be
>8 bits, and set r'size to 8.
>
>A typical Ada 95 implementation will likely make the size of "r" objects be
>8 bits, but r'size is required to be 3.

Wouldn't Byte'Base'Size tell you the truth ?

--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Help needed in port to GNAT95 from verdix

[Niklas Holsti]

Paul Hussein wrote:
> 
> I do not understand  why a piece of code that works on verdix will not now
> work an gnat95, and this is an important piece of code. If anyone could help
> it would be most appreciated.
> 
> When I run this code sample, and the code itself  in our system I get a
> constraint error.
> This code endeavours to turn any type into an array of floats for passing
> over the network.

Using floats here is quite surprising, but perhaps you know what you
are doing... I would have used storage_units. Also, you might want to
check out the Ada 95 stream concept, with the 'Read and 'Write
services.

[ elided package spec ]

> with UNCHECKED_CONVERSION;
> package body Packer is
>    --
>    -- PURPOSE:
>    -- Packs the object into the array of floats
>    --
>    function Pack ( Object : in Object_Type ) return Packed_Object_Type is
>       Size_Of_Array : POSITIVE := Object_Type'size/FLOAT'size + 1;
>       subtype Local_Packed_Object_Type is Packed_Object_Type ( 1 ..
> Size_Of_Array );
>       Packed_Object : Local_Packed_Object_Type;
>       function To_Array is new UNCHECKED_CONVERSION
>         ( Source => Object_Type,
>           Target => Local_Packed_Object_Type );

It seems quite likely that the exact size of the Source and Target
types will differ. Unchecked conversion between types of different
sizes is IMHO rather risky, from a portability point of view.
Same comment for the unchecked conversion in Packer.UnPack.

[ elided rest of Packer ]

> with Packer;
> with Text_IO;
> with Sim_Support;
> procedure Test is
 
[ elided a bit ]

>    package p is new packer ( blob );
>    procedure pack
>       ( Data   : in blob;
>         Floats : out Sim_Support.Data_Array ) is
>    begin
>       declare
>          Packed : constant P.Packed_Object_Type :=
>             P.Pack ( data );
>       begin
>          Floats := Sim_Support.Data_Array ( Packed );

According to my trial run, this tries to assign an array of
length 52 to an array of length 10000. Constraint error
is to be expected.

I cannot imagine how you got this to work under Verdix, except
by turning off constraint checks. The length of the Packed array
may have been different, due to a different lay-out of the "blob"
type under Verdix and GNAT, but the length must surely have been
less than 10000.

Do check out the streams and 'Read, 'Write. I think they are what
you need here.

Re: Help needed in port to GNAT95 from verdix

[Larry Kilgallen]

In article <dewar.895190155@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> The trouble is that most people think of the size of an object as being
> determined by the size of the type, but that is generally not true in 
> Ada 95 (though it was typically true in the default case in Ada 83).

I have not run into this problem, but I might.

It would be nice to be able to buy a book with this sort of thing
highlighted; perhaps titled "Non-Obvious Ada".

Of course there is not much motivation for someone to _write_ such
a book if sales would be limited to no more than the readership of
this newsgroup.

Larry Kilgallen

Re: Help needed in port to GNAT95 from verdix

[Robert Dewar]

J-P Rosen asks

<<Wouldn't Byte'Base'Size tell you the truth ?
>>

In practice, probablyt yes for integer types, but definitely NOT for
enumeration types which are their own base types, and definitely not
for composite types.

Re: Help needed in port to GNAT95 from verdix

[John McCabe]

kilgallen@eisner.decus.org (Larry Kilgallen) wrote:

>It would be nice to be able to buy a book with this sort of thing
>highlighted; perhaps titled "Non-Obvious Ada".
>
>Of course there is not much motivation for someone to _write_ such
>a book if sales would be limited to no more than the readership of
>this newsgroup.

Well I still know many people who use Ada, and will be using Ada for a 
number of years to come but who have absolutely no Internet access at 
all, so I can see a much larger audience for such a book than just those 
who read this newsgroup.

By your reasoning, it's a wonder why John Barnes, Norman Cohen et al 
bothered to write their books.

Personally I think it would be a brilliant idea for such a book to be 
written. I would certainly buy it.

-- 
Best Regards
John McCabe

=====================================================================
Any opinions expressed are mine and based on my own experience.  They
  should in no way be taken as the opinion of anyone I am currently
     working with, or of the company I am currently working for.
       If you have a problem with anything I say, SPEAK TO ME!
                (remove "nospam." to reply by e-mail)
=====================================================================