Re: data types & efficiency

[Vinzent 'Gadget' Hoefler <nntp-2004-03@t-domaingrabbing.de>]

Davide wrote:

>Well, requirements are to "redefine" the predefined types as Boolean,
>Integerer, etc...
>to enforce the indepence from compiler in terms of their internal
>representation.

Hmm, strange requirements. Sounds a little bit like someone just wants
<stdint.h> in Ada. ;)

>So I will define for example:
>
>type UNSIGNED_INT_32_TYPE is range 0..(2**32)-1:
>for  UNSIGNED_INT_32_TYPE'SIZE use 32;
>
>to be used instead of the predefined Integer type.

Ok, that's clear.

>One thing that I don't know is if I define:
>
>subtype SMALLER_INT_TYPE is UNSIGNED_INT_32_TYPE range 0..150;
>
>then, generally, the compiler can still optimize the representation in spite
>of  the clause:
>for  UNSIGNED_INT_32_TYPE'SIZE use 32;

No, it can't (at least I think so). It can do this if you derive a
"new" type from it, but not for a subtype. A subtype always has the
same representation as its base type.

Hmm, at least that's *my* interpretation of the RM, so it can be
totally wrong. :)

>My compiler's (Adamulti) manual is not clear about this. I made an
>experiment with GNAT and it seems that it represents
>SMALLER_INT_TYPE  as a byte.

Hmm. No, not exactly:

|with Ada.Text_IO;
|
|procedure t is
|   type Unsigned_32 is range 0 .. 2**32 - 1;
|   for Unsigned_32'Size use 32;
|
|   subtype Smaller_Int is Unsigned_32 range 0 .. 63;
|   -- for Smaller_Int'Size use 32;
|   x : Unsigned_32;
|   y : Smaller_Int;
|   z : Smaller_Int;
|   for z'Size use 8;
|begin
|   Ada.Text_IO.Put_Line (Integer'Image (Unsigned_32'Size));
|   Ada.Text_IO.Put_Line (Integer'Image (Smaller_Int'Size));
|
|   Ada.Text_IO.Put_Line (Integer'Image (x'Size));
|   Ada.Text_IO.Put_Line (Integer'Image (y'Size));
|   Ada.Text_IO.Put_Line (Integer'Image (z'Size));
|end t;

Output is:

| 32
| 6
| 32
| 32
| 8

So, yes, for the subtype it "optimizes" the size (it simply spits out
the minimum size needed to represent the specified range) ->
Smaller_Int'Size gives 6 here.

But for an actual object of that subtype it uses that of the base
type, of course (y'Size gives 32, too) - unless you specify a
different size for the object itself (z'Size gives 8).

To be honest, my understanding of RM 13.3(39-57) is not very good. So
it is perhaps better to delegate this question to the real language
lawyers here in c.l.a. :)

>So this compiler still optimizes the subtype.
>In this case your answer:
>
>>3) Declare the type by specifying its range and let the compiler
>>figure out what could be more efficient on the hardware.
>
>would make sense also for my particular case.

Well, it seems you can't define a representation for a subtype, only
for an object of that subtype.

Given that, your "requirements" don't make much sense too me, because
even if you define a representation for each of the "redefined" types,
you still can change for each object declared, if you need to do so.

And BTW, "independence from the compiler in terms of internal
representation" really sounds quite unportable to me. For instance, if
you try to do that on a 24-bit DSP, there is no 32-bit representation
available at all, simply because the target-architecture can't do that
(it must be either 24 or 48 bits). But the possibility of defining an
Integer that can represent 2**32 different values is still there.

So IMO doing such things would break more that it could possibly fix.


Vinzent.