From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8b5b40006550b942 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-08 00:59:29 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!adsl-213-200-246-247.cybernet.CH!not-for-mail From: Vinzent 'Gadget' Hoefler Newsgroups: comp.lang.ada Subject: Re: data types & efficiency Date: Mon, 08 Mar 2004 09:58:37 +0100 Organization: JeLlyFish software Message-ID: References: <5ohg40ls073v1b5d8idail4t365f57l8os@jellix.jlfencey.com> NNTP-Posting-Host: adsl-213-200-246-247.cybernet.ch (213.200.246.247) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: news.uni-berlin.de 1078736367 62553050 I 213.200.246.247 ([175126]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:6132 Date: 2004-03-08T09:58:37+01:00 List-Id: 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 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.