An alternative to Unchecked Conversion

An alternative to Unchecked Conversion

[Tom_Hargraves]

Related to "Questions about Unchecked_Conversion".

There have been some good responses to the related topic. I agree with the
sentiment that Unchecked_Conversion should be rarely if ever used. However if
you HAVE TO use it, it does come with an overhead. It is a routine which has to
be called, and it may end up copying data around and cost you cpu time.

So when you HAVE TO, e.g. to copy Ada structures onto byte streams being
transmitted over a 'hardware' interface, there's another technique which has
been around for a while. In the fortran era it was implemented using the common
block and equivalence statements.

The technique is simply to map the Ada structure directly onto the 'other' data
structure.

It has the following advantages:
1. It's fast, there is no data transfer 'cost'.
2. The data structures can be different sizes.

It has the following disadvantages:
1. If your Ada structure contains constrained types, then a write to the
'other' data structure can subsequently cause a constraint error when you come
to read the data.
2. Timing and synchronisation become a issue if the reader and writer are not
in the same task/thread.

If used with care, it is a good technique I've used for the simulation of
memory mapped external interfaces.

Here's a little one byte example. The output is as expected.

Maybe there are other techniques to achieve the same result with the Ada95
extentions? (I am not too familiar with all the new techniques which Ada95
provides, but I'm enjoying discovering them!)

Regards,
Tom H.

with Text_Io;
procedure Test_Use_Address is
   type Unsigned_Byte is range 0 .. 2**8 - 1;
   for Unsigned_Byte'Size use 8;

   My_Char : Character     := 'A';
   My_Byte : Unsigned_Byte;
   for My_Byte'Address use My_Char'Address;
begin
   Text_Io.Put_Line( "Before My_Byte assignment, My_Char = " & My_Char);
   My_Byte := Unsigned_Byte(Character'Pos('B'));
   Text_Io.Put_Line( "After  My_Byte assignment, My_Char = " & My_Char);
      -- Expected Output:
      -- Before My_Byte assignment, My_Char = A
      -- After  My_Byte assignment, My_Char = B
end;

Re: An alternative to Unchecked Conversion

[Matthew Heaney]

In article <OF2D01D779.211C774B-ON88256849.006FEEEF@ray.ca> , 
Tom_Hargraves@Raytheon.com  wrote:

> There have been some good responses to the related topic. I agree with the
> sentiment that Unchecked_Conversion should be rarely if ever used.

This is very naive.  Of course you should use Unchecked_Conversion.
It's a clean way to bypass the type system, when you need to.

Of course, if you don't need to bypass the type system, then there's no
need to use UC.  So the sentiment should be

  Don't bypass the type system unless you need to.

However, when doing low-level, systems programming, you often need to
perform type conversions, and UC is just what you need.  So of course
you should use it!

Re: An alternative to Unchecked Conversion

[Richard D Riehle]

In article <38596575_4@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:

>This is very naive.  Of course you should use Unchecked_Conversion.
>It's a clean way to bypass the type system, when you need to.

Good response, Matthew.  I think the issue is that Ada is, by default,
type safe.  The C family of languages is, by default, type unsafe. This
is also true of some other languages.  There are times when one requires
type unsafe.  Ada lets you relax the default with unchecked conversion.  

For the C family of languages, one can improve type safety, but type 
unsafe is always lying in the shallows waiting to swallow you like an
anaconda waiting for an unwary monkey.  

Richard Riehle

Re: An alternative to Unchecked Conversion

[Ted Dennison]

In article <83brtl$c0m$1@nntp2.atl.mindspring.net>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:

> unsafe is always lying in the shallows waiting to swallow you like an
> anaconda waiting for an unwary monkey.

You dare compare humans with monkeys? I'm calling the school board right
now! :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: An alternative to Unchecked Conversion

[Richard D Riehle]

In article <83disr$qbr$1@nnrp1.deja.com>,
	Ted Dennison <dennison@telepath.com> wrote:

>In article <83brtl$c0m$1@nntp2.atl.mindspring.net>,
>  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
>
>> unsafe is always lying in the shallows waiting to swallow you like an
>> anaconda waiting for an unwary monkey.
>
>You dare compare humans with monkeys? I'm calling the school board right
>now! :-)

No, Ted.  I am comparing programmers with monkeys.  Big difference.  :-)

Re: An alternative to Unchecked Conversion

[Tom Hargraves]

Oops. Excuse my English. I meant to express the opinion that
Unchecked_Conversion _need_ rarely if ever be used, in 'normal' programming
practice. So I think we are in agreement here. Why disable one of the best
features of Ada if you don't need to :-)

I welcome comments re. the technical merits of address mapping vs.
unchecked_conversion. For me address mapping worked fine, whereas
unchecked_conversion did a lot of additional data copying. So that's why I
didn't use it. What did I loose?

Yours curiously,
Tom H.

Matthew Heaney <matthew_heaney@acm.org> wrote in message
news:38596575_4@news1.prserv.net...
> In article <OF2D01D779.211C774B-ON88256849.006FEEEF@ray.ca> ,
> Tom_Hargraves@Raytheon.com  wrote:
>
> > There have been some good responses to the related topic. I agree with
the
> > sentiment that Unchecked_Conversion should be rarely if ever used.
>
> This is very naive.  Of course you should use Unchecked_Conversion.
> It's a clean way to bypass the type system, when you need to.
>
> Of course, if you don't need to bypass the type system, then there's no
> need to use UC.  So the sentiment should be
>
>   Don't bypass the type system unless you need to.
>
> However, when doing low-level, systems programming, you often need to
> perform type conversions, and UC is just what you need.  So of course
> you should use it!

Re: An alternative to Unchecked Conversion

[DuckE]

Tom Hargraves <tharg@vtcinet.com> wrote in message
news:3859701a@rsl2.rslnet.net...
> Oops. Excuse my English. I meant to express the opinion that
> Unchecked_Conversion _need_ rarely if ever be used, in 'normal'
programming
> practice. So I think we are in agreement here. Why disable one of the best
> features of Ada if you don't need to :-)
>
> I welcome comments re. the technical merits of address mapping vs.
> unchecked_conversion. For me address mapping worked fine, whereas
> unchecked_conversion did a lot of additional data copying. So that's why I
> didn't use it. What did I loose?

Using the address mapping does work fine... when you get it right.

In my experience code lives and is maintained for years.  Over the years it
is common for type definitions to change.

If you have overlaid a variable declartion using:

  firstView : firstBigRecord;
  secondView : secondBigRecord;
  for secondView'Address use firstView'Address;

Everything works fine... if and only if the two record sizes are the same.
If secondBigRecord is smaller than firstBigRecord, no problem.  If
secondBigRecord is larger than firstBigRecord, then accessing values at the
end of secondView are accessing memory that has not been allocated.  This is
similar to indexing beyond the end of an array in C.

In a large code base the definition of "firstBigRecord" and
"secondBigRecord" may live in separate subsystems.  A maintenance programmer
could change the structure of one of these records and be in for a surprise.

I'd add this to your disadvantages list.

SteveD
>
> Yours curiously,
> Tom H.

Re: An alternative to Unchecked Conversion

[Matthew Heaney]

In article <3859701a@rsl2.rslnet.net> , "Tom Hargraves" 
<tharg@vtcinet.com> wrote:

> I welcome comments re. the technical merits of address mapping vs.
> unchecked_conversion. For me address mapping worked fine, whereas
> unchecked_conversion did a lot of additional data copying. So that's why I
> didn't use it. What did I loose?

The object declaration

declare
  function To_Unsigned is
    new Unchecked_Conversion (Character, Unsigned_8);

  C_As_Byte : constant Unsigned_8 := To_Unsigned ('A');
begin

should be identical to the declaration

declare
  C : constant Character := 'A';
begin


If the former is more expensive than the latter, then your compiler is
broken.  

Re: An alternative to Unchecked Conversion

[Lutz Donnerhacke]

* Matthew Heaney wrote:
>The object declaration
>
>declare
>  function To_Unsigned is
>    new Unchecked_Conversion (Character, Unsigned_8);
>
>  C_As_Byte : constant Unsigned_8 := To_Unsigned ('A');
>begin
>
>should be identical to the declaration
>
>declare
>  C : constant Character := 'A';
>begin
>
>If the former is more expensive than the latter, then your compiler is
>broken.  

Nope. The former one contains a restriction to 8 bit which can be
considerably slower that using the native character size of the processor.

Re: An alternative to Unchecked Conversion

[Matthew Heaney]

In article <slrn85keec.46.lutz@taranis.iks-jena.de> , lutz@iks-jena.de 
(Lutz Donnerhacke) wrote:

> Nope. The former one contains a restriction to 8 bit which can be
> considerably slower that using the native character size of the processor.

Let's try again.


This declaration:

declare
  type Byte is mod 2 ** Character'Size;
  for Byte'Size use Character'Size;

  function To_Byte is new Unchecked_Conversion (Character, Byte);

  B : constant Byte := To_Byte ('A');
begin


should have the same efficiency as this declaration

declare
  C : constant Character := 'A';
begin

Re: An alternative to Unchecked Conversion

[Simon Wright]

Brian Orpin <abuse@borpin.co.uk> writes:

> Well the Tartan Ada (83) compiler we are using doesn't allow us to use
> address mapping as it requires all address statements to be static.
> 
> With SYSTEM;
> Use SYSTEM;
> 
>   Procedure TEST Is
>      Type TEST_TYPE Is New INTEGER;
>      For TEST_TYPE'Size Use 32;
> 
>      X : TEST_TYPE;
>      Y : TEST_TYPE;
>      For X Use At Y'Address;
> 
>   Begin
> 
>      X := 1;
> 
>   End TEST;
> 
>    9|     Y : TEST_TYPE;
> test.ada:10:1:
>   10|     For X Use At Y'Address;
>                         ^1
> ***  1 Error 3271: A static expression is expected here (RM83 4.9)

I was expecting GNAT to complain similarly about this but neither
3.11p nor 3.12a2 does, so clearly I haven't understood.

Under similar circumstances, the typical solution is like

     X : TEST_TYPE;
     Y : TEST_TYPE;
     Y_Address : constant Address := Y'Address;
     For X'Address  Use Y_Address;

(Brian, are you still using 83? because "For X Use At Y'Address" is an
83-ism)

Re: An alternative to Unchecked Conversion

[Simon Wright]

Brian Orpin <abuse@borpin.co.uk> writes:

> On 17 Dec 1999 22:13:05 +0000, Simon Wright <simon@pogner.demon.co.uk>
> wrote:
[...]
> >     X : TEST_TYPE;
> >     Y : TEST_TYPE;
> >     Y_Address : constant Address := Y'Address;
> >     For X'Address  Use Y_Address;
> 
> Tried this and got 
> 
>    9|   Y_ADDR : Constant ADDRESS := Y'Address;
> test.ada:10:1:
>   10|   For X'Address Use Y_ADDR;
>         ^1
> ***  1 Error 3208: This length representation clause does not specify a
> legal
> ***     attribute (RM83 13.2 (3))

Does using the 'use at' construct help anyway?

Re: An alternative to Unchecked Conversion

[Robert Dewar]

In article <x7vvh5twpzs.fsf@pogner.demon.co.uk>,
  Simon Wright <simon@pogner.demon.co.uk> wrote:
> > >     X : TEST_TYPE;
> > >     Y : TEST_TYPE;
> > >     Y_Address : constant Address := Y'Address;
> > >     For X'Address  Use Y_Address;
> >
> > Tried this and got
> >
> >    9|   Y_ADDR : Constant ADDRESS := Y'Address;
> > test.ada:10:1:
> >   10|   For X'Address Use Y_ADDR;
> >         ^1
> > ***  1 Error 3208: This length representation clause does
not specify a
> > legal
> > ***     attribute (RM83 13.2 (3))


Read the RM, and follow the rule there! The above code clearly
does NOT follow this rule!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: An alternative to Unchecked Conversion

[Rex Reges]

Brian Orpin wrote:
> 
> Well the Tartan Ada (83) compiler we are using doesn't allow us to use
> address mapping as it requires all address statements to be static.
> 
> With SYSTEM;
> Use SYSTEM;
> 
>   Procedure TEST Is
>      Type TEST_TYPE Is New INTEGER;
>      For TEST_TYPE'Size Use 32;
> 
>      X : TEST_TYPE;
>      Y : TEST_TYPE;
>      For X Use At Y'Address;
> 
>   Begin
> 
>      X := 1;
> 
>   End TEST;
> 
>    9|     Y : TEST_TYPE;
> test.ada:10:1:
>   10|     For X Use At Y'Address;
>                         ^1
> ***  1 Error 3271: A static expression is expected here (RM83 4.9)
> 

This is a problem with Ada83, but it is a little more subtle. I think
the problem you have here is that you are trying to do this overlay (the
Jovial term) on two items on the stack.  If you put your declarations in
a package, it should work.

However, I had assumed the intent of an address rep clause was to
support device drivers and DMA.  Unchecked conversion works better than
overlays in many cases since it can detect things that an address
overlay can't (like mod boundaries, packed bits, packed items smaller
than a storage unit, etc.). Also, unchecked conversion can do more
efficient memory moves by switching to double register loads (64 bit
loads) as soon as a 64 bit boundary is hit. 

Also, to support overlays, the compiler writers had to add the Pragma
Volatile so that "tautology" errors didn't occur (checking the same
variable over and over when it can't change as far as the compiler
knows.  Some compilers would just optimize out the second test on a
variable that it didn't know was overlayed.

The static expression requirement is a problem when writing a device
driver since the device's location is located at a physical address and
the expression required is a logical address. One can call a system
routine to map the physical to logical, but then the address is not
static. I assume most compilers extended Ada83 with the ability to call
To_Logical_Address( Physical_Address : in System.Address ) return
System.Address.

For Ada95, it doesn't seem to be a problem to have a run-time value for
the address rep clause.  The "aliased" specification on a declaration
tells the compiler that you expect the variable to be volatile. We
create MMAP regions at run-time and overlay a data structure on these
memory regions for sharing between processes. As far as the compiler can
tell, data magically appears out of nowhere in these structures (mostly
queues).

However, several gurus here now claim that unchecked conversion should
never be used. Either they use overlays or they call the C library
routine "memmov" instead. Their claim is that "memmov" is faster and
more portable than unchecked conversion. I disagree. It seems to me that
overlaying stack items and block memory moves are poor programming
styles, but I'm not a guru.

--------------

Rex Reges

"De gustibus non est disputandum."

Re: An alternative to Unchecked Conversion

[Matthew Heaney]

In article <385AD199.D1428985@Boeing.com> , Rex Reges 
<Rex.R.Reges@Boeing.com>  wrote:

> However, several gurus here now claim that unchecked conversion should
> never be used.

I can promise you that no "gurus" say "never use unchecked_conversion."
Whoever tells you that is giving you bad advice!

--
"The Bible, which I hold to be the word of God, is a book of faith, not
of science," said the Rev. Parker Druttan, pastor of St. John's
Episcopal Church of Charleston, speaking against a resolution to allow
the teaching of creationism in West Virginia schools.

Re: An alternative to Unchecked Conversion

[Robert Dewar]

In article <385AD199.D1428985@Boeing.com>,
  Rex Reges <Rex.R.Reges@Boeing.com> wrote:
> >      gnat r
You should NEVER use this construction in Ada 83,
since it is erroneous. Whoever tells you in Ada 83
to use this rather than unchecked conversion is
simply not very knowledgable on the language
and should not be payed much attention.

In Ada 95, it is permissible, though implementation
dependent to use address clauses. There is no requirement
that an address clause be static, but there are restrictions
on what expressions are allowed. A compiler is not required
to accept the exact form above, though many, including GNAT
will allow this form.

In GNAT, a specific warning will be given if you do not use
a pragma Import for the overlaying variable and it requires
initialization. Generally the use of a pragma Import is
always appropriate, since what does and does not require
initialization is implementation dependent.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: An alternative to Unchecked Conversion

[Charles H. Sampson]

Tom Hargraves <tharg@vtcinet.com> wrote:

> Oops. Excuse my English. I meant to express the opinion that
> Unchecked_Conversion _need_ rarely if ever be used, in 'normal' programming
> practice. So I think we are in agreement here. Why disable one of the best
> features of Ada if you don't need to :-)
> 
> I welcome comments re. the technical merits of address mapping vs.
> unchecked_conversion. For me address mapping worked fine, whereas
> unchecked_conversion did a lot of additional data copying. So that's why I
> didn't use it. What did I loose?

     I missed the beginning of this thread, although I was participating
in the other one.  Coming to in a few day late, I'm surprised to see 
that no one has mentioned what I consider the primary shortcoming of 
overlaying, the shortcoming that puts it into my personal list of for-
bidden features.

     Overlaying is one of those features that is very easy to write and
to get working "just as wanted" with little difficulty.  The problem 
with it comes during maintenance and that problem is that modification 
of one of the participants changes the values of the others.  It takes 
very little time after the overlay has been created for even the creator
to forget about it and the maintenance programmer doesn't even have the
luxury of forgetting.  All he knows is that for some reason the value of
a variable is wrong and, as he reads the code, he can't see where the 
incorrect value is being assigned.

     Of course, there are some techniques that reduce this problem.  If
a maintainer's environment supports a "find all references" capability,
then one of those references will be any overlay statements, leaving him
with the job of running down all modifications of the other partici-
pants.   Some debugging environments allow monitoring, to catch  vari-
ables the moment they change.  Unfortunately, unless you have a hardware
assist, monitoring can immensely slow down execution--not very useful in
a real-time program in particular.

     Because of this, because of the amount of time I've spent over a 
long career running down problems caused by overlaying, I'll not use it
unless absolutely necessary.  I'll use UC in preference, even in the 
rare cases when memory copying is involved, unless it can be shown that
this causes an unacceptable execution penalty.

     On the other hand, I would be against forbidding overlaying in a 
programming standard.  My preference would be to allow use only after 
justification and approval.

                                Charlie


     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.

Re: An alternative to Unchecked Conversion

[Mark A Biggar]

Tom_Hargraves@Raytheon.com wrote:
> 
> Related to "Questions about Unchecked_Conversion".
> 
> There have been some good responses to the related topic. I agree with the
> sentiment that Unchecked_Conversion should be rarely if ever used. However if
> you HAVE TO use it, it does come with an overhead. It is a routine which has to
> be called, and it may end up copying data around and cost you cpu time.

Most compilers implement Unchecked_Conversion as an implisit inlined routine
with no more (actually less as there are no checks done) overhead then
an assignment statement.
 
> So when you HAVE TO, e.g. to copy Ada structures onto byte streams being
> transmitted over a 'hardware' interface, there's another technique which has
> been around for a while. In the fortran era it was implemented using the common
> block and equivalence statements.
> 
> The technique is simply to map the Ada structure directly onto the 'other' data
> structure.
> 
> It has the following advantages:
> 1. It's fast, there is no data transfer 'cost'.
> 2. The data structures can be different sizes.
> 
> It has the following disadvantages:
> 1. If your Ada structure contains constrained types, then a write to the
> 'other' data structure can subsequently cause a constraint error when you come
> to read the data.
> 2. Timing and synchronisation become a issue if the reader and writer are not
> in the same task/thread.

3. There is no guarentee in the LRM that it will work correctly (although
most implementations will "Do The Right Thing").  So it definitely not
protable, while Unchecked_conversion is Guarenteed to be.

--
Mark Biggar
mark.a.biggar@lmco.com

Re: An alternative to Unchecked Conversion

[Jeff Creem]

<Tom_Hargraves@Raytheon.com> wrote in message
news:OF2D01D779.211C774B-ON88256849.006FEEEF@ray.ca...
> Related to "Questions about Unchecked_Conversion".
>
> There have been some good responses to the related topic. I agree with the
> sentiment that Unchecked_Conversion should be rarely if ever used. However
if
> you HAVE TO use it, it does come with an overhead. It is a routine which
has to
> be called, and it may end up copying data around and cost you cpu time.
>


it may or it may not. There have been many instances with a few compilers
that I have
used in which many instances of unchecked conversion caused absolutely no
copy and
no function call. The overlay approach is sometimes useful but I would not
yank out that
big stick unless you really need it.