fixed point types over an interface

fixed point types over an interface

[Allen Krell]

With Ada83, is it safe to assume that two different
compilers will store a fixed point type in the same way?

For example

Two processors are communicating over an interface.  The
applications for each processor are written/compiled
using compilers from two different vendors.

If each application has

type FX_PT_TYPE is delta .001 range -100 .. +100;
Variable : FX_PT_TYPE := 1.345;

Will the binary representation of 'Variable' 
be the same with both compilers?

Any help would be appreciated.

Allen Krell
jak@efogm.msd.ray.com

Re: fixed point types over an interface

[Matthew Heaney]

In article <32FBB550.41C67EA6@efogm.msd.ray.com>, Allen Krell
<jak@efogm.msd.ray.com> wrote:

>With Ada83, is it safe to assume that two different
>compilers will store a fixed point type in the same way?

No.

The only requirment (in the absence  of a specification of small) is that
the actual delta be smaller (power of 2) less than what was specified in
the type.

If you are sending the data over an interface, it is Very Strongly
Recommended that you specify Small for the type.

Also, (I think) it's also true that a compiler is allowed to reject a
specification of small that is not a power of 2, so you're better off only
using that power (if you can).  Note that that will also be more efficient.

The syntax is

type T is delta D range F .. L;
for T'Small use D;

This specifies the value of the LSB.


>Two processors are communicating over an interface.  The
>applications for each processor are written/compiled
>using compilers from two different vendors.

A ripe environment for problems.

>
>If each application has
>
>type FX_PT_TYPE is delta .001 range -100 .. +100;
>Variable : FX_PT_TYPE := 1.345;
>
>Will the binary representation of 'Variable' 
>be the same with both compilers?

Not necessarily.  You really should do this:

F_Delta : constant := 0.001;
type F is delta F_Delta range -100.0 .. 100.0;
for F'Small use F_Delta;

And while you're at it, put a size clause on there, too.

for F'Size use 32;  -- or whatever

If possible, use a power of 2 as the delta, as it'll be more portable.

F_Delta : constant := 1.0 / 1024;

Send the data over the interface using a fixed point type with a power of 2
delta, and convert it to whatever "internal" type is appropriate (be it
another fixed point type, or more likely some floating point type) when
it's received.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: fixed point types over an interface

[Robert Dewar]

Allen Krell said

<<With Ada83, is it safe to assume that two different
compilers will store a fixed point type in the same way?

For example

Two processors are communicating over an interface.  The
applications for each processor are written/compiled
using compilers from two different vendors.

If each application has

type FX_PT_TYPE is delta .001 range -100 .. +100;
Variable : FX_PT_TYPE := 1.345;

Will the binary representation of 'Variable'
be the same with both compilers?>>


The answer for both Ada 83 and Ada 95 is certainly not. As with all
data in the absence of rep clauses, there is lots of freedom for 
a compiler to decide how to store the data. In particular for fixed-point
some compilers will use the largest Small possible, and others will
use the smallest Small possible. 

To pin this down, you need to use a Small clause and a Size clause,
then you should be pretty safe relying on the result, although one
can imagine compilers doing weird things.

Re: fixed point types over an interface

[Mats Weber]

> Two processors are communicating over an interface.  The
> applications for each processor are written/compiled
> using compilers from two different vendors.

> To pin this down, you need to use a Small clause and a Size clause,
> then you should be pretty safe relying on the result, although one
> can imagine compilers doing weird things.

You may also run into big endian/little endian problems. If performance
is not a problem, passing the data in text representation will always
work and be portable.

Re: fixed point types over an interface

[Robert Dewar]

Mats said

<<You may also run into big endian/little endian problems. If performance
is not a problem, passing the data in text representation will always
work and be portable.>>

Another possibility is to use a target independent implementation of
Stream_IO, such as is provided with GLADE (the GNAT implementation of
the distributed annex PCS). GLADE uses XDR for stream representation,
which avoids any endian (or other target dependent) problems.

Re: fixed point types over an interface

[nassera]

In article <dewar.855629889@merv>, dewar@merv.cs.nyu.edu says...
>
>Mats said
>
><<You may also run into big endian/little endian problems. If performance
>is not a problem, passing the data in text representation will always
>work and be portable.>>
>
>Another possibility is to use a target independent implementation of
>Stream_IO, such as is provided with GLADE (the GNAT implementation of
>the distributed annex PCS). GLADE uses XDR for stream representation,
>which avoids any endian (or other target dependent) problems.
>

good choice. I just wanted to also add that Sun NFS and Sun RPC
also uses XDR.

man xdr: (on solaris 2.5)

DESCRIPTION
     XDR routines allow C programmers to describe arbitrary  data
     structures  in  a  machine-independent  fashion.   Data  for
     remote procedure calls (RPC)  are  transmitted  using  these
     routines.

by the way, I wonder why the man output above mentions only "C programmers".

Nasser

Re: fixed point types over an interface

[Mats Weber]

Robert Dewar wrote:
> 
> Laurent Pautet said
> 
> <<GLADE is only 95% XDR in order to follow LRM requirements. The 5%
> comes from the XDR 4 bytes rule (basically strings).>>

> These primitive values are written in accordance with the rules in the XDR
> standard, which are followed 100% accurately.
> 
> If you want to intercommunicate with another language, that other language
> must understand the sequence of items that is written into the stream.
> For example if we use 'Output on a four character string with bounds 1..4,
> then six elements are written:
> 
>   lower bound
>   upper bound
>   first character
>   second character
>   third character
>   fourth character
> 
> each of these six elements is represented using the XDR standard. The
> "other language" code must read these six elements and assemble them into
> whatever makes best sense for representing this particular aggregate data
> item.

Does each of these six elements occupy 4 bytes in the message ?

Re: fixed point types over an interface

[Jon S Anthony]

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

> <<You may also run into big endian/little endian problems. If performance
> is not a problem, passing the data in text representation will always
> work and be portable.>>
> 
> Another possibility is to use a target independent implementation of
> Stream_IO, such as is provided with GLADE (the GNAT implementation of

Or an ORB, which handles this stuff (among other various similar sorts
of things) as well.  And works between pieces written in C, Ada, C++,
and ST (and Java, though that is not yet official...)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: fixed point types over an interface

[Laurent Pautet]

    (Robert Dewar) writes:
    >> <<You may also run into big endian/little endian problems. If
    >> performance is not a problem, passing the data in text
    >> representation will always work and be portable.>>
    >> 
    >> Another possibility is to use a target independent
    >> implementation of Stream_IO, such as is provided with GLADE
    >> (the GNAT implementation of

    Jon> Or an ORB, which handles this stuff (among other various
    Jon> similar sorts of things) as well.  And works between pieces
    Jon> written in C, Ada, C++, and ST (and Java, though that is not
    Jon> yet official...)

Except that some Ada stream requirements will be violated.

Re: fixed point types over an interface

[Laurent Pautet]

    >> Another possibility is to use a target independent
    >> implementation of Stream_IO, such as is provided with GLADE
    >> (the GNAT implementation of the distributed annex PCS). GLADE
    >> uses XDR for stream representation, which avoids any endian (or
    >> other target dependent) problems.

    nassera> good choice. I just wanted to also add that Sun NFS and
    nassera> Sun RPC also uses XDR.

    nassera> man xdr: (on solaris 2.5)

    nassera> DESCRIPTION XDR routines allow C programmers to describe
    nassera> arbitrary data structures in a machine-independent
    nassera> fashion.  Data for remote procedure calls (RPC) are
    nassera> transmitted using these routines.

    nassera> by the way, I wonder why the man output above mentions
    nassera> only "C programmers".

Because it doesn't apply to Ada :-) For instance:

XDR says :

The representation of all items requires a multiple of four bytes (or
32 bits) of data.

LRM says :

For composite types, the Write or Read attribute for each component is
called in a canonical order ... Read and Write should use the smallest
number of stream elements needed to represent all values in the base
range of the scalar type.

So a string of 7 characters is stored on 8 bytes with XDR and 7 with Ada.

GLADE is only 95% XDR in order to follow LRM requirements. The 5%
comes from the XDR 4 bytes rule (basically strings).

Re: fixed point types over an interface

[Samuel Tardieu]

>>>>> "Nasser" == nassera  <nassera@net.com> writes:

Nasser> by the way, I wonder why the man output above mentions only "C
Nasser> programmers".

Probably because some XDR functions are in fact C macros. Blah :)

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: fixed point types over an interface

[Robert Dewar]

Laurent Pautet said

<<GLADE is only 95% XDR in order to follow LRM requirements. The 5%
comes from the XDR 4 bytes rule (basically strings).>>

This is confusing and misleading. It is true that a string is not output
in XDR format, but that is because strings are not output in streams 
ever. Instead the semantics of Ada is that a string is output as a series
of characters. These characters are indeed output in the format required
by XDR. 

Yes, you might expect that a string in Ada would be output in a format
corresponding to a string as described in the XDR standard, but really
there is no reason to expect such a correspondence. Clearly a string
in Ada is a rather different beast, because for one thing it typically
includes bounds.

So, here is the exact statement of what is going on:

When the default stream attribtutes are used, the operates are first broken
down into a series of operations on primitive data values. The rules for
this breakdown are part of the Ada rules, and hence streams in Ada have
no requirement for dealing with composite values, since they are defined
to be a sequence of primitive values.

These primitive values are written in accordance with the rules in the XDR
standard, which are followed 100% accurately.

If you want to intercommunicate with another language, that other language
must understand the sequence of items that is written into the stream.
For example if we use 'Output on a four character string with bounds 1..4,
then six elements are written:

  lower bound
  upper bound
  first character
  second character
  third character
  fourth character

each of these six elements is represented using the XDR standard. The
"other language" code must read these six elements and assemble them into
whatever makes best sense for representing this particular aggregate data
item.

Re: fixed point types over an interface

[Jon S Anthony]

In article <rcaybcudtnk.fsf@quasimodo.enst.fr> Laurent Pautet <pautet@inf.enst.fr> writes:

>     >> Another possibility is to use a target independent
>     >> implementation of Stream_IO, such as is provided with GLADE
>     >> (the GNAT implementation of
> 
>     Jon> Or an ORB, which handles this stuff (among other various
>     Jon> similar sorts of things) as well.  And works between pieces
>     Jon> written in C, Ada, C++, and ST (and Java, though that is not
>     Jon> yet official...)
> 
> Except that some Ada stream requirements will be violated.

What's that have to do with it?  You want to move the information from
once place to another in such a way that it behaves the same after
that is done.  That's what an ORB does.  Works fine.

Given this context the specific ins and outs of Ada streams per se are
irrelevant.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: fixed point types over an interface

[Jacob Sparre Andersen]

Laurent Pautet (pautet@inf.enst.fr) wrote:

|^^^^^^^^^^
| Because it doesn't apply to Ada :-) For instance:
|
| XDR says :
|
| The representation of all items requires a multiple of four bytes (or
| 32 bits) of data.
|
| LRM says :
|
| For composite types, the Write or Read attribute for each component is
| called in a canonical order ... Read and Write should use the smallest
| number of stream elements needed to represent all values in the base
| range of the scalar type.
 ^^^^^^^^^^

Is there anything that prevents the "stream elements" to fill 32 bits?

If I read 13.13.1 in the LRM correctly, then there's absolutely nothing that
prevents type Stream_Element from being declared as "mod 32".


Greetings,

Jacob
--
Jacob Sparre Andersen                            http://www.nbi.dk/%7Esparre/
Center for Chaos and Turbulence Studies          Phone: (+45) 39 65 53 51
The Niels Bohr Institute                                (+45) 35 32 53 05
--
"In the long run we are all dead", John Maynard Keynes (1923)

Re: fixed point types over an interface

[Robert Dewar]

Jacob says

<<| For composite types, the Write or Read attribute for each component is
| called in a canonical order ... Read and Write should use the smallest
| number of stream elements needed to represent all values in the base
| range of the scalar type.
 ^^^^^^^^^^

Is there anything that prevents the "stream elements" to fill 32 bits?

If I read 13.13.1 in the LRM correctly, then there's absolutely nothing that
prevents type Stream_Element from being declared as "mod 32".>>


Right, that would be perfectly valid, but in any case, the part of yoru
quote after the ... is only implementation advice, and this means that
it should be followed unless there is good reason not to follow it, and
in any case whether you follow it or not has nothing to do with
conformance.