Re: Overhead for type conversions?

["Nick Roberts" <nickroberts@blueyonder.co.uk>]

"Bobby D. Bryant" <bdbryant@mail.utexas.edu> wrote in message
news:pan.2003.07.25.01.01.43.5699@mail.utexas.edu...

> Given these declarations -
>
>    type f1 is new float;
>    type f2 is new float;
>
>    function "*"( left : in f1; right : in f2 ) return f1 is
>    begin
>       return( left * f1( right ) );
>    end "*";
>
> and given that run-time range checks are enabled, should I expect my
> compiler to execute range checking code for each f1*f2 multiplication,
> or will the compiler conclude from the definitions that the two types
> are always convertible without error regardless of the specific value,
> and thus not generate any code for a range check?

The type Standard.Float is unconstrained (RM95 3.5.7(12)), so the types f1
and f2 derived from it will also be unconstrained (RM95 3.4(6)). Thus, there
will be no range checks (there may be other checks).

I would also suggest that a function like this should be declared inline,
since it is likely that the eliminated call and return code would be bigger
(as well as much slower) than the intrinsic code for the multiplication
anyway.

Furthermore, should f1 and/or f2 become constrained in the future, such
inlining could give an optimising compiler the opportunity to eliminate
range checks (and to perform other optimisations).

> (In practice the compiler is GNAT.)

I can't help you with the specifics of GNAT; sorry.

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]