Ada 83 - avoiding unchecked conversions.

Ada 83 - avoiding unchecked conversions.

[Ensco Vendor]

we have two 16 bit integers which we need to assemble into a single 32
bit integer (one is high order, the other low order).  We wish to avoid
unchecked conversion if we can.  Is there a standard accepted way of
doing this?

      Mary Cronk  ENSCO at Lockheed Martin, Owego, NY, US

       mary.m.cronk@lmco.com

Re: Ada 83 - avoiding unchecked conversions.

[Robert I. Eachus]

In article <329C63BC.41C6@lmco.com> Mary Cronk <mary.m.cronk@lmco.com> writes:

  > we have two 16 bit integers which we need to assemble into a single 32
  > bit integer (one is high order, the other low order).  We wish to avoid
  > unchecked conversion if we can.  Is there a standard accepted way of
  > doing this?

   I could ask why you want to avoid Unchecked_Conversion, since in
this case the message of the name is exactly what you apparently want,
a conversion that does no checking.

   But I won't ask.

   The best way to do this in Ada 95 is to have the low order word
declared as a modular type, and the upper word as a 16-bit integer:

  type Mod16 is mod 2**16;
  type Int16 is range -2**15..2**15-1;
  type Int32 is range -2**31..2**31-1;
  ...
  function Merge_Halves(High: Int16; Low: Mod16) return Int32 is
  begin return Int32(High) * 2**16 + Int32(Low); end Merge_Halves;

  If you are using Ada 83 and want portability, or you have the low
order bits in a signed number for some reason:

  function Merge_Halves(High, Low: Int16) return Int32 is
  begin
    if Low >= 0 then
       return Int32(High) * 2**16 + Int32(Low);
    else
       return Int32(High) * 2**16 + (2**16 + Int32(Low));
    end if;
  end Merge_Halves;

  You may be tempted to write:

       return Int32(High + 1) * 2**16 + Int32(Low);

  But that risks overflow, as does just omitting the parentheses.  A
VERY clever compiler might be able to figure out a way to simplify the
expression and still do no range checking, but I'll settle for
compilers that replace the multiply with a shift, and only do an
overflow check on the final add.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada 83 - avoiding unchecked conversions.

[Robert Dewar]

Mary asks

"we have two 16 bit integers which we need to assemble into a single 32
bit integer (one is high order, the other low order).  We wish to avoid
unchecked conversion if we can.  Is there a standard accepted way of
doing this?
"


I always wonder when people say "I want to do X without using the obvious
method for doing X". Can you explain why you don't want to use unchecked
conversion here. Is there a real technical reason, or simply some kind
of arbitrary rule in action?

Of course you can do this assembly using multiplication (X * 2**16 + y).
which is more appropriate depends on EXACTLY the abstract semantics of
what you are doing (I mean which of unchecked conversion or multiplication)

Re: Ada 83 - avoiding unchecked conversions.

[Robert Dewar]

Darel says

"
In this case, I wouldnt be surprised if the employer had some kind
of 'coding standards' that generally tend to remove alot of
the more useful features of a language , such as unchecked
conversion/deallocation, or compiler pragmas, these documents tend to
be sweeping, and have to be adhered too."


Sure I realize that this happens sometimes, but I like to know when it
is happening, I have no interest in spending my time helping people
recover from their own deliberately idiotic behavior.

Once I heard a presentation from someone talking about AI in C vs Ada.
He announced that C was much more efficient than Ada for this purposes.
Digging into this nonsense claim, we discovered that he was using new
for each allocation in the case of Ada, but in C was not using malloc
for each allocation, but instead had written his own storage allocator
for the C case. There followed the following discussion.

Q. But why aren't you using malloc in C?

A. Much too inefficient, we could not afford the inefficiency!

Q. But then why not do the same thing in Ada?

A. Impossible to do it in Ada!

Q. What are you talking about, of course you can do this using chapter
   13 facilities.

A. We aren't allowed to use anything from chapter 13

Q. Why not?

A. It would result in non-portable code

Q. No less portable than your C code??

A. Our C code is completely portable, we have run it on two different
   machines.

etc. you get the idea :-)

Re: Ada 83 - avoiding unchecked conversions.

[Darel Cullen]

In article <dewar.849275146@merv>, Robert Dewar <dewar@merv.cs.nyu.edu>
spoke thus :-
>Mary asks

[snip]
>
>"
>
>
>I always wonder when people say "I want to do X without using the obvious
>method for doing X". Can you explain why you don't want to use unchecked
>conversion here. Is there a real technical reason, or simply some kind
>of arbitrary rule in action?
>
>Of course you can do this assembly using multiplication (X * 2**16 + y).
>which is more appropriate depends on EXACTLY the abstract semantics of
>what you are doing (I mean which of unchecked conversion or multiplication)
>

In this case, I wouldnt be surprised if the employer had some kind
of 'coding standards' that generally tend to remove alot of
the more useful features of a language , such as unchecked
conversion/deallocation, or compiler pragmas, these documents tend to 
be sweeping, and have to be adhered too.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Darel J. Cullen                    Software Engineer
Email: Darel@djcull.demon.co.uk                      
Url: http://www.djcull.demon.co.uk/                 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: Ada 83 - avoiding unchecked conversions.

[Ted Dennison]

Ensco Vendor wrote:
> 
> we have two 16 bit integers which we need to assemble into a single 32
> bit integer (one is high order, the other low order).  We wish to avoid
> unchecked conversion if we can.  Is there a standard accepted way of
> doing this?
> 

Does the target object have to be a 32-bit integer, or does it just have
to be the *size* of a 32-bit integer? Often times folks will back
themselves into a corner where they have to do unchecked conversion
because they didn't choose their data types very well.

Of course, often there is some sort of I/O or system binding that
REQUIRES use of an unnatural data type. In that case, unchecked
conversion is the proper tool for the job. Doing any kind of semantic
calisthenics simply to aviod unchecked conversion is liable to cause
more problems than are solved.

-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: Ada 83 - avoiding unchecked conversions.

[Matthew Heaney]

>Ensco Vendor wrote:
>> 
>> we have two 16 bit integers which we need to assemble into a single 32
>> bit integer (one is high order, the other low order).  We wish to avoid
>> unchecked conversion if we can.  Is there a standard accepted way of
>> doing this?

Unchecked conversion is the accepted way of doing this:

function To_Integer_32 (Low, High : Integer_16)
   return Integer_32 is

   type Integer_32_Record is
      record
         High_Order : Integer_16;
         Low_Order : Integer_16;
      end record;

   for Integer_32_Record use
      record
         High_Order at 0 range 16 .. 32;
         Low_Order at 0 range 0 .. 15;
      end record;

   for Integer_32_Record'Size use 32;

   function To_Integer_32 is 
      new Unchecked_Conversion (
         Integer_32_Record, 
         Integer_32);

   The_Record : constant Integer_32_Record := (
      High_Order => High, 
      Low_Order => Low);
begin
   return To_Integer_32 (The_Record);
end;

Because the source and target types have the same size, this should be
completely portable.

Some shops have the rule "Thou shalt not use Unchecked_Conversion."  But
this is silly; use it when it makes sense.

The proper place to use Unchecked_Conversion is at the interface boundary
of the sytem.  That seems to be the case for you, because you're
manipulating types whose size is known explicitly (16 and 32 bit integers).

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ada 83 - avoiding unchecked conversions.

[Richard Riehle]

On Sun, 1 Dec 1996, Darel Cullen wrote:

  In reply to a well-stated comment on the captioned topic,

> In this case, I wouldnt be surprised if the employer had some kind
> of 'coding standards' that generally tend to remove alot of
> the more useful features of a language , such as unchecked
> conversion/deallocation, or compiler pragmas, these documents tend to 
> be sweeping, and have to be adhered too.

  Does anyone else find it odd that the people who make up rules about
  programming are often people who no longer write programs.  In some
  cases, they are people who have never written code in the language
  for which they are defining such rules.

  Richard Riehle

Re: Ada 83 - avoiding unchecked conversions.

[Matthew Heaney]

In article <32AED68A.48BE@aisf.com>, "Chris Sparks (Mr. Ada)"
<sparks@AISF.COM> wrote:

>> function To_Integer_32 (Low, High : Integer_16)
>>    return Integer_32 is
>>
>>    type Integer_32_Record is
>>       record
>>          High_Order : Integer_16;
>>          Low_Order : Integer_16;
>>       end record;
>>
>>    for Integer_32_Record use
>>       record
>>          High_Order at 0 range 16 .. 32;
>
>You mean 31.
>
>>          Low_Order at 0 range 0 .. 15;
>
>You have to be careful here due to portability and bit ordering.

Someone else also pointed that out to me.  Does anyone know how to use the
Bit_Order attribute to make this portable?

Is this acceptable:

   for Integer_32_Record'Bit_Order use System.Low_Bit_First;

I'm confused because I'm not sure whether storage unit 0 refers to the most
significant bit or the least significant.  Does the Bit_Order attribute
only affect the interpretation of the bits, or of the storage unit too?


>  The_Record_Address : constant System.Address := The_Record'Address;
>  Result             : Integer_32;
>  for Result'Address use The_Record_Address;  -- New way
>--for Result      use at The_Record_Address;  -- Old way

I disagree with this "solution."  Overlays are never the way to go when
Unchecked_Conversion will do.


>> Some shops have the rule "Thou shalt not use Unchecked_Conversion."
>> But this is silly; use it when it makes sense.
>
>I concur.  Using Address Clauses would not be the right choice when
>a component within a structure has an initializing value (pointers,
>explicit initializations).

Yes, that it true, but it's still not the right solution here. 
Unchecked_Conversion is.

>> The proper place to use Unchecked_Conversion is at the interface
>> boundary of the sytem.  That seems to be the case for you, because you're
>> manipulating types whose size is known explicitly (16 and 32 bit integers).
>
>I don't know what this means.

"Close-to-metal" programming.  Think of a program as a system with definate
boundaries.  The boundaries for an embedded system, say, are the computer
itself (the OS or kernal, etc) and hardware devices over which you perform
external I/O.

When you do external device I/O, you have to know explicitly what the size
and representation is of all the data you exchange with the other
processor, because you both have to agree on a common format.  Ada excels
in this area because it allows you to state explicitly what the
representation of the data is by using size clauses and representation
clauses.

But knowing the representation of the data is only important at the
hardware level, ie "the interface boundary."  Internal to the software
there's a lot going on that doesn't depend on representation of the data,
so we want to practice some information hiding by letting the compiler
choose the representation.

For example,

   type T is range 1 .. 10;

I can use type T to do some calculations, but I certainly don't care if T
occupies 8, 16, or 32 bits.

It's a perfectly valid request to not use Unchecked_Conversion on types
like T, because I'm inside the software system.  But at the I/O layer, I
can't use types like T because I really do need to know T's representation
(because I have to send it to someone else outside the system).

So yes, I often really do need to use Unchecked_Conversion - at the
interface boundary.

Shops that make rules like "Don't use Unchecked_Conversion" mean well but
are confusing the internal and external aspects of the (software) system.

This confusion is also the reason why shops often say "Thou shalt not use
predefined types, because it's not portable."  This too is another silly
rule.  

It would be perfectly valid for such a rule at the interface layer, because
I have to know the representation of my types.  But internal to the
software system, I don't care, and using predefined types is just another
form of information hiding.

I've often seen code like this

   type Stack is limited private;

   type Length_Type is range ...
   for Lenght_Type'Size use 32;

   function Length (S : Stack) return Length_Type;
...
private
   type Stack is ...;
end;

This is pure overkill: who cares what the representation of the stack
length attribute is?  It's also wrong because they didn't use a
representation clause on the representation of type Stack.  Are you going
to send the stack object across an interface?  If not, then why do you care
what the representation is?

   function Length (S : Stack) return Natural;

is a perfectly good use of a predefined type.

Another egregious example is with array declarations:

   type T_Array is array (Integer_32 range <>) of T;

This is completely wrong: who cares what the representation of the array
index subtype is?  You never care about that even at the interface layer, 
because you don't actually send the array index across the interface - only
the components of the array.

Which is why using a subtype of Positive is often the best type for an
array index subtype.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Ada 83 - avoiding unchecked conversions.

[Chris Sparks (Mr. Ada)]

Ensco Vendor wrote:
>
> we have two 16 bit integers which we need to assemble into a single 32
> bit integer (one is high order, the other low order).  We wish to
> avoid unchecked conversion if we can.  Is there a standard accepted
> way of doing this?

Matt Heaney wrote:
>
> Unchecked conversion is the accepted way of doing this:

It is an accepted way however not the only way.

> function To_Integer_32 (Low, High : Integer_16)
>    return Integer_32 is
>
>    type Integer_32_Record is
>       record
>          High_Order : Integer_16;
>          Low_Order : Integer_16;
>       end record;
>
>    for Integer_32_Record use
>       record
>          High_Order at 0 range 16 .. 32;

You mean 31.

>          Low_Order at 0 range 0 .. 15;

You have to be careful here due to portability and bit ordering.

>       end record;
>
>    for Integer_32_Record'Size use 32;
>
>    function To_Integer_32 is
>       new Unchecked_Conversion (
>          Integer_32_Record,
>          Integer_32);
>
>    The_Record : constant Integer_32_Record := (
>       High_Order => High,
>       Low_Order => Low);
> begin
>    return To_Integer_32 (The_Record);
> end;

Here's Mine:

with Interfaces; use Interfaces;
with System;

function To_Integer_32
  (Low  : in     Integer_16;
   High : in     Integer_16)
          return Integer_32 is

  type Integer_32_Record is record
    High_Order : Integer_16;
    Low_Order  : Integer_16;
  end record;

  for Integer_32_Record use record
    High_Order at 0 range 16 .. 31;
    Low_Order  at 0 range  0 .. 15;
  end record;

  for Integer_32_Record'Size use 32;

  The_Record : constant Integer_32_Record :=
    (High_Order => High,
     Low_Order  => Low);

  The_Record_Address : constant System.Address := The_Record'Address;
  Result             : Integer_32;
  for Result'Address use The_Record_Address;  -- New way
--for Result      use at The_Record_Address;  -- Old way

begin

  return Result;

end To_Integer_32;

with Interfaces;  use Interfaces;
with Ada.Text_IO; use Ada.Text_IO;

with To_Integer_32;

procedure T is

  A : Integer_32 := -1;

begin

  Put_Line ("A" & Integer_32'Image (A));

  A := To_Integer_32 (Low => 10, High => 0);

  Put_Line ("A" & Integer_32'Image (A));

  A := To_Integer_32 (Low => 0, High => 10);

  Put_Line ("A" & Integer_32'Image (A));

end T;

I compiled this with 3.07 under HPUX and got the following results:

A-1
A 655360
A 10

The low/high ordering is incorrectly represented for the HP (Portability
issue).

> Because the source and target types have the same size, this should be
> completely portable.

Yes.

> Some shops have the rule "Thou shalt not use Unchecked_Conversion."
> But this is silly; use it when it makes sense.

I concur.  Using Address Clauses would not be the right choice when
a component within a structure has an initializing value (pointers,
explicit initializations).

> The proper place to use Unchecked_Conversion is at the interface
> boundary of the sytem.  That seems to be the case for you, because you're
> manipulating types whose size is known explicitly (16 and 32 bit integers).

I don't know what this means.

Chris Sparks

Re: Ada 83 - avoiding unchecked conversions.

[Dewi Daniels]

On Wed, 11 Dec 1996 07:43:07 -0800, "Chris Sparks (Mr. Ada)"
<sparks@AISF.COM> wrote:

>  The_Record_Address : constant System.Address :=3D The_Record'Address;
>  Result             : Integer_32;
>  for Result'Address use The_Record_Address;  -- New way
>--for Result      use at The_Record_Address;  -- Old way

Ada 83 prohibits the use of address clauses to alias two variables
(LRM 13.5). I believe it's legal in Ada 95. My preference would be to
use an unchecked conversion.
--=20
Dewi Daniels
Marietta, Georgia

Re: Ada 83 - avoiding unchecked conversions.

[Chris Brand]

Matthew Heaney wrote:
>
[cut]
> But knowing the representation of the data is only important at the
> hardware level, ie "the interface boundary."  Internal to the software
> there's a lot going on that doesn't depend on representation of the data,
> so we want to practice some information hiding by letting the compiler
> choose the representation.
> 
[cut]
> 
> This confusion is also the reason why shops often say "Thou shalt not use
> predefined types, because it's not portable."  This too is another silly
> rule.
> 
> It would be perfectly valid for such a rule at the interface layer, because
> I have to know the representation of my types.  But internal to the
> software system, I don't care, and using predefined types is just another
> form of information hiding.
> 
[examples cut]

I worked on a project where the rule was not to use predefined types.
We had a package defining the "base types" to use, with all their
representation clauses and everything and we had to base our types on
these.
The main type was an "Integer_16".

This was great while we were using a 286 target. It was only when we
ported
it to a 486 target (where 16-bit values need more work than 32-bit ones)
that we noticed the disadvantage of such a rule. Left to itself, the
compiler would have chosen a 16-bit value for most things on the 286 and
a 32-bit value on the 486.

Of course, if you take these things away, people have to think about
"what is a sensible upper bound for this type ?" :-)

-- 
Chris
Stating my own opinions, not those of my company.

Re: Ada 83 - avoiding unchecked conversions.

[Richard Kenner]

In article <32b03008.564464@netnews.worldnet.att.net> dewi@cableol.co.uk (Dewi Daniels) writes:
>Ada 83 prohibits the use of address clauses to alias two variables
>(LRM 13.5). I believe it's legal in Ada 95. My preference would be to
>use an unchecked conversion.

An unchecked conversion is much more efficient.  Using an address
clause not only forces the object into memory, but disables many
optimizations on it (essentially treats it as volatile).

Re: Ada 83 - avoiding unchecked conversions.

[Stephen Leake]

Chris Brand wrote:
> 
> Matthew Heaney wrote:
> >
> [cut]
> > But knowing the representation of the data is only important at the
> > hardware level, ie "the interface boundary."  Internal to the software
> > there's a lot going on that doesn't depend on representation of the data,
> > so we want to practice some information hiding by letting the compiler
> > choose the representation.
> >
> [cut]
> >
> > This confusion is also the reason why shops often say "Thou shalt not use
> > predefined types, because it's not portable."  This too is another silly
> > rule.
> >
> > It would be perfectly valid for such a rule at the interface layer, because
> > I have to know the representation of my types.  But internal to the
> > software system, I don't care, and using predefined types is just another
> > form of information hiding.
> >
> [examples cut]
> 
> I worked on a project where the rule was not to use predefined types.
> We had a package defining the "base types" to use, with all their
> representation clauses and everything and we had to base our types on
> these.
> The main type was an "Integer_16".
> 
> This was great while we were using a 286 target. It was only when we
> ported
> it to a 486 target (where 16-bit values need more work than 32-bit ones)
> that we noticed the disadvantage of such a rule. Left to itself, the
> compiler would have chosen a 16-bit value for most things on the 286 and
> a 32-bit value on the 486.
> 
> Of course, if you take these things away, people have to think about
> "what is a sensible upper bound for this type ?" :-)

Perhaps there should have been a type "Fast_Integer", with the
understanding that it was at least 16 bits (this is of course just
Standard.Integer). Then programmers can use Fast_Integer when they don't
really care about the size.


> 
> --
> Chris
> Stating my own opinions, not those of my company.

-- 
- Stephe

Re: Ada 83 - avoiding unchecked conversions.

[BGaffney42]

I'm sorry, I must be missing something.  Why would you want to use
Unchecked_Conversion or some form of overlay for this problem?  Why can't
the following function be used (assuming Integer_16 and Integer_32 are
defined with appropriate ranges and 'Sizes?

    function Convert (Hi, Lo : Integer_16) return Integer_32 is
        Shift_16 : constant Integer_32 := 2**16;
    begin
        if Lo < 0 then
            return Integer_32(Hi) * Shift_16 + (Shift_16 +
Integer_32(Lo));
        else
            return Integer_32(Hi) * Shift_16 + Integer_32(Lo);
        end if;
    end Convert;

-- _really_ psycho engineer 
-- using Ada as a toy and _not_ working for an Ada vendor!
                                                                 --Brian
Gaffney

Re: Ada 83 - avoiding unchecked conversions.

[Robert A Duff]

In article <32B17F46.123B@gsfc.nasa.gov>,
Stephen Leake  <Stephen.Leake@gsfc.nasa.gov> wrote:
>Perhaps there should have been a type "Fast_Integer", with the
>understanding that it was at least 16 bits (this is of course just
>Standard.Integer). Then programmers can use Fast_Integer when they don't
>really care about the size.

Sometimes, you want "an integer of at least so-and-so range, but I don't
mind if it has more range, so long as it doesn't cost me any
efficiency".  To say that in Ada 95:

    type Specific_Range is range -10_000..10_000;
    subtype T is Specific_Range'Base;

Then use T all over.

Other times, you want an integer type that has something to do with the
amount of addressable memory on the machine.  E.g. type String, where
the index type is Integer, and one presumes that Integer is 16 bits on a
16-bit machine, and 32 bits on a 32-bit machine -- that makes sense,
since you won't want to create 10 megabyte strings on the 16-bit
machine, but you might on the 32-bit machine.

- Bob

Re: Ada 83 - avoiding unchecked conversions.

[Eric Miller]

Richard Kenner wrote:
> 
> In article <32b03008.564464@netnews.worldnet.att.net> dewi@cableol.co.uk (Dewi Daniels) writes:
> >Ada 83 prohibits the use of address clauses to alias two variables
> >(LRM 13.5). I believe it's legal in Ada 95. My preference would be to
> >use an unchecked conversion.
> 
> An unchecked conversion is much more efficient.  Using an address
> clause not only forces the object into memory, but disables many
> optimizations on it (essentially treats it as volatile).

I'm fairly certain that we're heading into compiler-specific territory
now.  Efficiency issues are tough to generalize.

I used to work at the same company as a guy who was having problems with
a program that ran (essentially in batch) for several hours.  One of his
optimizations was to switch all the unchecked conversions to conversions
using overlays.  Apparently on that compiler (VAX Ada 1.something)
unchecked conversion was doing some checks.

My recommendation is to use unchecked conversion because you're doing
just what your code says you're doing.  Overlays just give the reader
one more thing to think about.

Eric

Re: Ada 83 - avoiding unchecked conversions.

[Robert Dewar]

iEric said


"using overlays.  Apparently on that compiler (VAX Ada 1.something)
unchecked conversion was doing some checks.
"


Note that the unchecked in unchecked conversion is talking about omitting
normal compile time checks for type correctness. It is NOT talking about
runtime checking (whatever that might mean). In general you cannot assume
that unchecked conversion takes no code. Some of the time it may take
no code, but there is no reason to think, or even considerable desirable,
that a compiler would never generate code for an unchecked conversion. 
Sometimes you would get the wrong result in the absence of generating
code. For example, suppose that packed 5 bit arrays were stored left
justified in a register, and 5 bit integers were stored right justified.
Well the compiler had beetter emit a shift for the unchecked conversion
or it will get the wrong result (remembr that the semantics of
unchecked conversion is quite well defined, it is not some kind of
implementation dependent unknown op0eration).

Re: Ada 83 - avoiding unchecked conversions.

[Robert A Duff]

In article <dewar.850929268@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>iEric said
>"using overlays.  Apparently on that compiler (VAX Ada 1.something)
>unchecked conversion was doing some checks.
>"
>Note that the unchecked in unchecked conversion is talking about omitting
>normal compile time checks for type correctness. It is NOT talking about

Another efficiency issue about unch_conv is whether or not it makes a
copy.  An instance of U_C is a function, so one would normally assume
that calling it makes a copy of the argument.  This is what the Ada 83
RM said, and this is no doubt why U_C was inefficient in some early
version of VAX Ada.  However, the Ada 83 ARG ruled that the function
result may be returned by reference in some cases, and Ada 95 agrees
with that ruling (see 13.9(12)).  So if you do:

    Some_Procedure(Unch_Conv(X));

then Some_Procedure might actually be receiving the address of X, rather
than the address of a copy of X.  This is different (and often more
efficient) than the semantics normal function calls.  And the difference
is detectable.

- Bob

Re: Ada 83 - avoiding unchecked conversions.

[Robert I. Eachus]

In article <32B6905F.FC4@tiac.net> Eric Miller <ewmiller@tiac.net> writes:

  > I used to work at the same company as a guy who was having
  > problems with a program that ran (essentially in batch) for
  > several hours.  One of his optimizations was to switch all the
  > unchecked conversions to conversions using overlays.  Apparently
  > on that compiler (VAX Ada 1.something) unchecked conversion was
  > doing some checks.

   As I remember it, early versions of VAX Ada flushed stored state in
the compiler in a couple of cases where it later turned out not to be
needed.  As I remember it, two cases were on all statement labels and
on all subprogram calls, even if inlined.  This caused the stack
pointer to be reloaded.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Ada 83 - avoiding unchecked conversions.

[Keith Thompson]

In <dewar.850929268@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
[...]
> Note that the unchecked in unchecked conversion is talking about omitting
> normal compile time checks for type correctness. It is NOT talking about
> runtime checking (whatever that might mean). In general you cannot assume
> that unchecked conversion takes no code. Some of the time it may take
> no code, but there is no reason to think, or even considerable desirable,
> that a compiler would never generate code for an unchecked conversion. 

Certainly unchecked conversion can require some code in some cases, but
one wouldn't normally expect that code to include constraint checks.

> Sometimes you would get the wrong result in the absence of generating
> code. For example, suppose that packed 5 bit arrays were stored left
> justified in a register, and 5 bit integers were stored right justified.
> Well the compiler had beetter emit a shift for the unchecked conversion
> or it will get the wrong result (remembr that the semantics of
> unchecked conversion is quite well defined, it is not some kind of
> implementation dependent unknown op0eration).

I agree that the compiler needs to emit a shift for this case, but
it shouldn't generate a check that the result is within the declared
range of its subtype.  This makes it the programmer's responsibility to
guarantee that the result will be a valid value of the target subtype
(if possible, by using a target subtype that covers all possible bit
patterns), or to deal with it properly if it isn't.

On the other hand, if the result of a unchecked conversion is assigned
to an object, there may well be a constraint check on the assignment.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: Ada 83 - avoiding unchecked conversions.

[Robert Dewar]

Keity says

"I agree that the compiler needs to emit a shift for this case, but
it shouldn't generate a check that the result is within the declared
range of its subtype.  This makes it the programmer's responsibility to
guarantee that the result will be a valid value of the target subtype
(if possible, by using a target subtype that covers all possible bit
patterns), or to deal with it properly if it isn't."


Notice that the shouldn't here corresponds to implementation advice in the
RM, not to any requirement, so code that counts on there being no check
is potentially non-portable.