Hi,
In the context of using types such as Unsigned_N from Interfaces, what
if you needed the bit ****fting operations? From looking at the RM,
they are only available for modular types defined in Interfaces:
Ada2005 RM2.5.4(28)
The same arithmetic operators are predefined for all signed integer
types defined by a signed_integer_type_definition (see 4.5, =93Operators
and Expression Evaluation=94). For modular types, these same operators
are predefined, plus bit-wise logical operators (and, or, xor, and
not). In addition, for the unsigned types declared in the language-
defined package Interfaces (see B.2), functions are defined that
provide bit-wise ****fting and rotating.
Of course, a good compiler would probably translate something like
2**X into a ****ft which is great. But what about
****ft_Arithmetic_Right or Rotate_Left? If I had to define my own, then
it probably would not be as efficient as a predefined one from
Interfaces. It would have been nice if the Ada standard guaranteed
such operations were available for user-defined modular types.
--Micronian Coder
On Jul 13, 9:03=A0am, Georg Bauhaus <rm.plus-
bug.t...@[EMAIL PROTECTED]
> wrote:
> On Sun, 2008-07-13 at 00:51 +0000, anon wrote:
> > Plus, when a programmer defines their own type in Ada, Ada adds
> > extra set of routines that are not based in hardware checks but
softwar=
e,
> > which slows a program down.
>
> I'm not sure there is some real context here. =A0There is no loss
> in speed and no cost in terms of additional checks for using
> either Unsigned_64 or "mod 2**64". (Or "mod 2**(something smaller)".)
> Below is an example to serve as one of many (really unnecessary)
> proofs that there is no overhead stemming from user defined types
> "mod 2**N". =A0(And no overhead stemming from user defined types
> in general---they are there for a reason in this real-time
> systems programming language, I should think.)
>
[Example code removed]
|
