Byte Swapping Constrained Data Types

[Brian Barker]

ObjectAda for Windows 7.2.2 Native

This is more of an Ada specific question if someone could help me.

I have declared an enumerated type like so:

type Terminal is ( Null_Terminal, Primary, Secondary, Console );

for Terminal use
( Null_Terminal => 0,
Primary => 1,
Secondary => 2,
Console => 3);

for Terminal'Size use 32;


I also have created a procedure based off of a generic byte-swap
routine:

procedure Swap is new Endian.Generic_Swap(Terminal);

I receive a record over TCP/IP and it is in Big Endian format, so I
must byte swap it. I have already copied the raw network data into my
structure that contains the Terminal type. When I try to byte swap it
I receive a constraint error, because the big endian value of Terminal
is out of range.

Swap(My_Record.Sending_Terminal); -- <- Sending_Terminal is of
type Terminal

I want to keep the generic swap, because I have so many abstract data
types. I just want to get around this constraint range check when I
try to pass the value into the swap routine. Does anyone have a
better suggestion?

[Beard, Frank Randolph CIV]

As soon as you reference the Terminal variable, range checking
occurs. You are going to have to swap the bytes before you
reference it.

For instance:

procedure Some_Routine is

type Intermediate_Type is mod 2**32;

procedure Swap is new Endian.Generic_Swap(Intermediate_Type);

function To_Terminal is
Ada.Unchecked_Conversion(Intermediate_Type, Terminal);

begin

--+ Copying your raw network data into the intermediate.

--+ Swap.
Swap(My_Intermediate);

--+ Convert it.
My_Terminal := To_Terminal(My_Intermediate);

We had a case similar to yours but we used a rep clause instead.
Ours about 72 bits of data into a record structure. We used
the rep clause to lay it out from the data stream. The Swap
is more flexible, because we had different rep clauses depending
on what system we were running.

Frank

_______________________________________________
comp.lang.ada mailing list
comp.l...@ada-france.org
http://www.ada-france.org/mailman/listinfo/comp.lang.ada

[Brian Barker]

Since I couldn't use the generic function to swap my original type
(Terminal). I created some other swap functions called swap_2, swap_4,
swap_8. They each take in a system.address as the only argument. So now I
have,

Swap_4(My_Record.Sending_Terminal'ADDRESS); -- <- Sending_Terminal is of
type Terminal

This works, but I don't like it because I could accidently call Swap_4 on a
16 bit value and cause problems.

I've tried to avoid Unchecked_Conversion in the past, but it looks to
provide a safer solution to the problem.

Is Unchecked_Conversion an expensive operation? I will be converting a good
bit of data over a periodic rate.

Also, will the compiler generate an error on the following line if the size
of Terminal changes (say from 32 bits down to 16), but not
Intermediate_Type?

function To_Terminal is
Ada.Unchecked_Conversion(Intermediate_Type, Terminal);

Brian

--

----------------------------------------------------
This mailbox protected from junk email by Matador
from MailFrontier, Inc. http://info.mailfrontier.com

"Beard, Frank Randolph CIV" <frank...@navy.mil> wrote in message
news:mailman.123.106667437...@ada-france.org...

[Beard, Frank Randolph CIV]

-----Original Message-----
From: Brian Barker [mailto:bba...@ball.com]

> Is Unchecked_Conversion an expensive operation? I will be converting a good
> bit of data over a periodic rate.

Unchecked_Conversion is typically very fast. We've never had it impact
our performance that we've noticed. You could create some timing tests
just to check, but I wouldn't worry about it unless you are not meeting
some reasonable performance criteria.

> Also, will the compiler generate an error on the following line if the size
> of Terminal changes (say from 32 bits down to 16), but not
> Intermediate_Type?

The VAX Ada compiler would let you get away with differing sizes for
Unchecked_Conversion. IIRC, you could convert a smaller size into a
larger size, but not the other way around.

Currently, I can only address the Aonix OA compiler, but that just happens
to be the one you're working with. I haven't tried it since OA v7.1.2a and
we're currently on OA v7.2.2. Assuming it still works the same, you will
get a compiler error that tells you they must be the same size.

Someone else would have to tell you about GNAT, if you're interested.

Frank

[Jeffrey Carter]

Brian Barker wrote:

> type Terminal is ( Null_Terminal, Primary, Secondary, Console );
>
> for Terminal use
> ( Null_Terminal => 0,
> Primary => 1,
> Secondary => 2,
> Console => 3);

Get rid of this. It buys you nothing, and may cost you something. Some
compilers generate extra code for enumeration types with a
representation clause to deal with the possibility that the codes have
holes and are used for indexing or for loop counters.

> for Terminal'Size use 32;
>
> I also have created a procedure based off of a generic byte-swap
> routine:
>
> procedure Swap is new Endian.Generic_Swap(Terminal);
>
> I receive a record over TCP/IP and it is in Big Endian format, so I
> must byte swap it. I have already copied the raw network data into my
> structure that contains the Terminal type. When I try to byte swap it
> I receive a constraint error, because the big endian value of Terminal
> is out of range.

What you're receiving over the network is not of type Terminal. You need
to receive it into a type that corresponds to all the possible values
you can receive, and their byte-swapped equivalents (probably
Unsigned_32), swap that, then unchecked convert it to your Terminal type.

Concerning the "efficiency" of Unchecked_Conversion, why are you
worrying about a problem you have no evidence even exists?
Unchecked_Conversion is the correct idiom to use. Use it. Measure the
result. Only if that reveals efficiency problems directly related to the
use of Unchecked_Conversion should you worry about.

Unchecked_Conversion usually does nothing. Given

type A is ...;
type B is ...;

pragma Assert (A'Size = B'Size);

function To_B is new Unchecked_Conversion (Target => B, Source => A);

X : A;
Y : B;
...
Y := To_B (X);

The assignment typically simply copies the bits of X into Y. The whole
point of this being unchecked is that it AVOIDS the checks that the type
system would usually require.

--
Jeff Carter
"Brave Sir Robin ran away."
Monty Python and the Holy Grail
59