Re: 'SIZE attribute of a type

Re: 'SIZE attribute of a type

[elroy.jpl.nasa.gov!sdd.hp.com!mips!zaphod.mps.ohio-state.edu!unix.cis.pit]

gardner@tsd.arlut.utexas.edu (Donald Gardner) writes:
> 
> The 'SIZE attribute (for a type) is defined in LRM 13.7.2(5) as 
> 
> 	"...the minimum number of bits that is needed by the implementation
> 	to hold any possible object of this type...".  
> 
> Code from the compiler I am using returns the value 8 
> for CHARACTER'SIZE.  I was expecting a value of 7.  Which is 
> correct?  
> 
> If 8 is the correct value, is there way to obtain
> the value I want that is simpler than taking the log base 2 of
> CHARACTER'POS (CHARACTER'LAST)?

The value of 8 is correct. Why were you expecting 7? Were you applying
'SIZE to a subtype of CHARACTER? When you read "minimum number of bits
that is needed by the implementation" this means the minimum amount of
space used by the compiler. It does NOT mean the smallest amount of 
space that could possibly be used to implement the type. This is 
demonstrated when you do a Boolean'SIZE and get 8.  It is possible for
the compiler to use 1 bit but it instead uses 8.

Why not just "return 7;" if you want 7? You might want to explain the
problem more fully.

Robert Parkhill

Re: 'SIZE attribute of a type

[Danford Lehman]

In article 6171, Robert Parkhill answers Donald Gardner's query re why his
compiler's CHARACTER'SIZE = 8 vs. 7; the following excerpt from Commentary
AI-00536, which is ARG & WG9 approved, addresses the points raised by the
two articles and shows part of Mr. Parkhill's response to be incorrect.
Whether there will be any further change to the Ada83 ACVC test suite in
order to check for recently resolved representation issues is in question
--validation testing for Ada83 implementations might have ceased (i.e., no
new ACVC, no successive validation cycle--certificates extended 'til 1994!).
Under the current test suite, ACVC 1.11, some implementations indeed did not
have BOOLEAN'SIZE = 1 and thus failed some tests (they were advised of the
Commentary and not permitted these failures, and so presumably they changed
their attribute's value).

---Dan LEHMAN
-------------- *

-------------------------------------------------------------------------------
  The meaning of 'SIZE applied to a type, subtype, or object     AI-00536/08  1
  90-07-06                                                               BI  WA


| !standard 13.07.02 (05)                                 90-07-06  AI-00536/08
  !standard 13.02    (05)
  !class binding interpretation 88-11-08
| !status WG9-approved 90-06-15
  !status ARG-approved 89-10-25 (reviewed)
  !status ARG-approved (8-0-1) 89-06-14 (pending editorial review)
  !status ARG-approved (10-0-0) 89-02-28 (pending editorial review; ballot)
  !status work-item 89-01-30
  !status received 87-04-13
  !references AI-00551, AI-00554, AI-00555, AI-00561, AI-00825, 83-00914,
              83-00965, 83-00994, 83-00997, 83-01023, 83-01024
  !topic The meaning of 'SIZE applied to a type, subtype, or object

  !summary 89-07-28

  'SIZE  applied  to  an  object  yields  the  number of bits allocated for the
  object.  (This number may include padding bits that are part  of  the  stored
  value.)    (See  AI-00825  for  the value of 'SIZE applied to an object of an
  unconstrained subtype with discriminants.)

  If the size of a type or a first named subtype T  has  been  specified  by  a
  length  clause,  then T'SIZE yields the specified size, and the size of every
  subtype of T is also this value.

  If the size of a type or a first named subtype has been specified by a length
  clause,  then  an  object  of the type or any of its subtypes is allocated at
  least the specified number of bits, unless the object is  a  component  of  a
  record  and  the  component's  size has been determined by a record component
  clause (see AI-00551).  (Hence, every object of such a type has at least  the
  specified size except when a smaller size has been determined explicitly by a
  record component clause.)

  If the size of a type or a subtype S has not  been  determined  by  a  length
  clause  and  S  is  either  a  scalar subtype, a constrained array subtype, a
  constrained subtype with discriminants, an access type, a  task  type,  or  a
  private  type  whose  full type is one of these types, then S'SIZE yields the
  smallest number of bits that an implementation will allocate  for  an  object
  declared with the subtype indication S; objects whose size is determined by a
  record component clause are not considered in determining  the  value  of  S'
  SIZE.

# For the predefined type BOOLEAN, BOOLEAN'SIZE is one.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  An  implementation  shall  describe, in Appendix F, how the value of 'SIZE is
  determined for objects, types, and subtypes.

[...under !discussion ...]

  In effect, the recommendation requires that 'SIZE for a subtype  (other  than
  an   unconstrained   array   subtype   or   an   unconstrained  subtype  with
  discriminants) yield a value that is the smallest amount of  space  allocated
  for  an  object  of  that subtype in a packed array or a packed record.  This
  requirement is consistent with the role of the SIZE attribute when specifying
  the  effect of pragma PACK on arrays and records (see AI-00554 and AI-00555).
# Since  it  is  intended  that  pragma  PACK  for  boolean  arrays  produce  a
# representation  with  no gaps between components (see AI-00555), BOOLEAN'SIZE
# is specified to be one.  Similarly, since  pragma  PACK  is  applied  to  the
# predefined type STRING, CHARACTER'SIZE must at least equal the number of bits
# allocated for a component of an object having type STRING.  If a component of
# type  CHARACTER  in  a  packed  record can be allocated only seven bits, then
# CHARACTER'SIZE would equal seven even if eight bits are used  for  components
# in  objects  of  type  STRING  (see  AI-00555).  No size is specified for the
# CHARACTER type  so  an  implementation  is  allowed  to  decide  how  closely
# components of type CHARACTER are packed in STRINGs.

[...]
===============================================================================

Re: 'SIZE attribute of a type

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit]

Boy if I could somehow get my foot out of my mouth.

Appologies again.

I meant to state that the posting mentions Representation Attributes
in 13.7.2:5 X'SIZE and did not mention the use of the chapter 13
feature Length Clauses 13.2 T'Size (for Some_Type'Size use 1), or
a representation clause 13.3-13.4, or use of pragma Pack.

Robert Parkhill

Re: 'SIZE attribute of a type

[cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit]

Having read the posting more closely I think it just states that if a
chapter 13 feature is used to set the size of a TYPE then the
representation attribute X'SIZE should reflect that size.  No need to
post any responses to any questions.

Thanks

Re: 'SIZE attribute of a type

[Brian Hanafee]

In article <EACHUS.91Dec6115421@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Robert
 I. Eachus) writes:
>   P.S.  To avoid getting compiler vendors too upset with me, please,
>if you are going to report this bug for a particular compiler, post
>here.  Then only the first to find the bug needs to report it.
>
>
>					   Robert I. Eachus

The Meridian Ada compiler for the DecStation 3100 failed the test.

Meridian Ada Compiler [v4.1 Aug  4, 1990] Target DECstation
Meridian Code Generator [v3.0 Oct 18, 1990] Target DECstation
Meridian BAMP [v4.0 Jul 27, 1990]

I will send mail to Support@Meridian.com if I do not see any other
postings by Monday, December 9.

--
Brian Hanafee                         Advanced Decision Systems
bhanafee@ads.com                      1500 Plymouth Street
(415) 960-7300                        Mountain View, CA 94043-1230

Re: 'SIZE attribute of a type

[parkhill]

You are correct. I was wrong.

Robert Parkhill



I kind of wonder what use the attribute Type_Name'Size is for normal
programming.  Imagine a compiler that could pack type Boolean into a 
single bit in a record but could not pack bits in a boolean array.  

Re: 'SIZE attribute of a type

[parkhill]

As was stated in a previous posting by another author if a compiler 
can pack an array of character such that each character only uses 7 
bits then Character'Size should return 7.

Image a compiler was smart enough to understand baised number ranges.

   type b is range 9 .. 10;
        or
   type b is range 2**31 - 2 .. 2**31 - 1;


If the compiler can generate code that only uses 1 bit then b'Size
should return 1.

Re: 'SIZE attribute of a type

[Richard Pattis]

The following output restuls from Alsys FirstAda 4.4 (I believe the most
up to date version of this 286 product):

 Boolean'SIZE is  8
 Bool_Obj'SIZE is  8
 Bool_Array'SIZE is  32
 Character'SIZE is  8
 Char_Obj'SIZE is  8
 Boolean'SIZE should be 1.  Please report this error to the compiler
 vendor and reference AI-536.


-- 
------------------------------------------------------------------------------
  Richard E. Pattis			"Programming languages are like
  Department of Computer Science	 pizzas - they come in only "too"
    and Engineering			 sizes: too big and too small."

Re: 'SIZE attribute of a type

[Ed Matthews]

In article <EACHUS.91Dec6115421@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Robert
 I. Eachus) writes:
>
>   Not quite.  AI-00536/08-BI-WA requires that Boolean'SIZE = 1.
>Objects of type Boolean may have a size of 8 (or 32, or whatever), but
>Boolean must have 'SIZE = 1 so that (packed) Boolean arrays are bit
>vectors.  Most vendors do fiercely pack bit vectors, but some still
>get Boolean'SIZE wrong.  (This is a very recent AI.) A quick test
>program:

Am I alone, or does anyone else think this is crazy?  

If I read the AI correctly, then Foo'Size is likely > 1 where Foo is an object
of type Boolean, but Boolean'Size is 1.  Why the discrepancy?  The results
are counter-intuitive. 

Boolean'Size = 1 seems to have nothing to do with packing bit vectors.

I fail to see the wisdom behind this AI.
-- 

Ed Matthews                                                edm@verdix.com
Verdix Corporation Headquarters                            (703) 378-7600
Chantilly, Virginia

Re: 'SIZE attribute of a type

[Donald Gardner]

parkhill@email.sp.unisys.com (parkhill) writes:

>As was stated in a previous posting by another author if a compiler 
>can pack an array of character such that each character only uses 7 
>bits then Character'Size should return 7.

>Image a compiler was smart enough to understand baised number ranges.

>   type b is range 9 .. 10;
>        or
>   type b is range 2**31 - 2 .. 2**31 - 1;


>If the compiler can generate code that only uses 1 bit then b'Size
>should return 1.

Oh, that compilers were so cleverly written!

Consider an application that is transferring data over a slow serial
channel.  If a compiler used the minimum number of bits needed to
represent a type and the number of bits used was readily available
(hopefully from the 'SIZE attribute), the task of maximizing
communications throughput would be simplified.  My original
posting regarding the 'SIZE attribute of a type was motivated
by such a need to determine the actual number of bits used to 
represent a type, rather than the number of bits used to store it.

Re: 'SIZE attribute of a type

[Ed Matthews]

In article <EACHUS.91Dec9003230@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Robert
 I. Eachus) writes:

>-- If I were going to write an ACVC test for this, I would not test
>-- Boolean'SIZE = 1.  Instead I would test that Boolean arrays are
>-- represented correctly.  That is what users care about.

Now this is sensible and you will find that Verdix packs bit vectors just
fine right now.  This was my point.  If things work fine now and 
Boolean'Size returns a sensible value (i.e., the amount of storage used
for a single boolean value in the absence of pragma Pack), why mess
around and create the discrepancy where Boolean'Size returns a (potentially)
silly value?

-- 

Ed Matthews                                                edm@verdix.com
Verdix Corporation Headquarters                            (703) 378-7600
Chantilly, Virginia

Re: 'SIZE attribute of a type

[paul goffin]

In article <EACHUS.91Dec6115421@Dr_No.mitre.org> eachus@Dr_No.mitre.org (Robert
 I. Eachus) writes:
>In article <5830@email.sp.unisys.com> parkhill@email.sp.unisys.com (parkhill) 
writes:
>
>>  This is demonstrated when you do a Boolean'SIZE and get 8.  It is
>>  possible for the compiler to use 1 bit but it instead uses 8.
>
>   Not quite.  AI-00536/08-BI-WA requires that Boolean'SIZE = 1.
>Objects of type Boolean may have a size of 8 (or 32, or whatever), but
>Boolean must have 'SIZE = 1 so that (packed) Boolean arrays are bit
>vectors.  Most vendors do fiercely pack bit vectors, but some still
>get Boolean'SIZE wrong.  (This is a very recent AI.) A quick test
>program:
>
[deleted]

A short while ago, I was writing an Ada source code preprocessor/database
system.  This was necessary because of the way we were implementing
a multi-computer system which communicated with shared memory.

I found that some of the assumptions I had made about the Boolean type
used by Telesoft were wrong. (Of course, when I checked the manual, the
correct description was there; I just didn't take it all in when designing
my preprocessor.)

Part of my preprocessor was concerned with sharing memory between systems
programmed in Ada and systems programmed in FORTRAN.  The FORTRAN compiler
allowed a non-zero value to be true.  Ada was far more strict :
16#0000# = False; 16#0001# = True.

That caused a slight upset; but the really annoying thing was:

An object of type Boolean occupied 16 bits.
Arrays of type Boolean consisted of elements each 8 bits in size.

Thus:

	Relay_1 : Boolean;

	Realy_2 : Array 1..2 of Boolean;

	-- These two Objects occupy the same ammount of memory
	-- (Not the same part of it, of course)

(I had assumed - wrongly - that Boolean objects and elements of Boolean
arrays would be the same size.)

Packed Booleans occupied 1 bit, of course.

As I said, the exact representation of Booleans was described in the manual;
my mistake!  Nevertheless, It did seem to me to be an odd representation.
-- 
+-------------+-------------------------------------------------------+
+ Paul Goffin +  Crosfield Electronics Ltd. U.K.  +44 442 230000x3357 +
+             +  My opinions are my OWN. - no one would pay for this  +
+-------------+-------------------------------------------------------+

Re: 'SIZE attribute of a type

[mcsun!uknet!yorkohm!minster!mjl-b]

In article <1991Dec7.003222.17204@titan.tsd.arlut.utexas.edu> gardner@tsd.arlut
.utexas.edu (Donald Gardner) writes:
>parkhill@email.sp.unisys.com (parkhill) writes:
>>Image a compiler was smart enough to understand baised number ranges.
>
>>   type b is range 9 .. 10;
>>        or
>>   type b is range 2**31 - 2 .. 2**31 - 1;
>
>
>>If the compiler can generate code that only uses 1 bit then b'Size
>>should return 1.
>
>Oh, that compilers were so cleverly written!
>
>Consider an application that is transferring data over a slow serial
>channel.  If a compiler used the minimum number of bits needed to
>represent a type and the number of bits used was readily available
>(hopefully from the 'SIZE attribute), the task of maximizing
>communications throughput would be simplified.

Yes, but if you _aren't_ writing a package that transfers data over a slow
serial link, you want fast, efficient code. Using one bit to represent the
above examples is neither fast nor efficient (and it adds to compile time
and compiler complexity).

If you want to use the smallest number of bits (for the transmission
example), then use a 'case' statement and convert it to a packed boolean
yourself. The time taken to do the conversion will be minimal compared to the
time taken to do the transmission.

Mathew

|Mathew Lodge             | "Baldrick, are the words 'I have a cunning plan' |
|mjl-b@minster.york.ac.uk |  heading towards this conversation with ill      |
|Summer: lodge%alsys@uknet|  deserved confidence?" -- Blackadder III         |

Re: 'SIZE attribute of a type

[elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gv]

>parkhill@email.sp.unisys.com (parkhill) writes: 
>>Image a compiler was smart enough to understand baised number ranges. 
>
>>   type b is range 9 .. 10; 
>>        or 
>>   type b is range 2**31 - 2 .. 2**31 - 1;
>
>
>>If the compiler can generate code that only uses 1 bit then b'Size 
>>should return 1.
> 
>Oh, that compilers were so cleverly written! 
>

> Deleted text.




My point on the compiler having the capability to use one bit is that I
find the utility of type_name'size is now questionable.  Lets say the
compiler is capable of using 1 bit but won't do it in most situations.
How can any programmer use type_name'size to any practical purpose?  It 
seems less useful than Entry_Name'Count.  However, I am sure that the 
justification for the change to type_name'size is rock solid.
 
Robert Parkhill

Re: 'SIZE attribute of a type

[Mark Biggar]

In article <5898@email.sp.unisys.com> parkhill@email.sp.unisys.com (parkhill) w
rites:
>>parkhill@email.sp.unisys.com (parkhill) writes: 
>>>Image a compiler was smart enough to understand baised number ranges. 
>>>   type b is range 9 .. 10; 
>>>        or 
>>>   type b is range 2**31 - 2 .. 2**31 - 1;
>>>If the compiler can generate code that only uses 1 bit then b'Size 
>>>should return 1.
>My point on the compiler having the capability to use one bit is that I
>find the utility of type_name'size is now questionable.  Lets say the
>compiler is capable of using 1 bit but won't do it in most situations.
>How can any programmer use type_name'size to any practical purpose?  It 
>seems less useful than Entry_Name'Count.  However, I am sure that the 
>justification for the change to type_name'size is rock solid.

I don't thing anyone would implement this as an automatic feature of an Ada
 compiler.  But, it is perfectly reasonable for the rep-clause

 for b'size use 1;

 to cause a compiler to do just what you want, while not having the
 rep-clause would make b'size something like 8, 16 or 32.

 b'size is the actual storage used for the type not the minimum possible.

 --
 Mark Biggar
 markb@agora.rain.rain.com

Re: 'SIZE attribute of a type

[elroy.jpl.nasa.gov!swrinde!mips!samsung!caen!umeecs!dip.eecs.umich.edu!wa]

In article <5898@email.sp.unisys.com> parkhill@email.sp.unisys.com (parkhill) w
rites:
>>parkhill@email.sp.unisys.com (parkhill) writes: 
>>>Image a compiler was smart enough to understand baised number ranges. 
>>
>>>   type b is range 9 .. 10; 
>>>        or 
>>>   type b is range 2**31 - 2 .. 2**31 - 1;
>>
>>
>>>If the compiler can generate code that only uses 1 bit then b'Size 
>>>should return 1.
>> 
>>Oh, that compilers were so cleverly written! 
>>
>
>> Deleted text.
>
>My point on the compiler having the capability to use one bit is that I
>find the utility of type_name'size is now questionable.  Lets say the
>compiler is capable of using 1 bit but won't do it in most situations.
>How can any programmer use type_name'size to any practical purpose?  It 
>seems less useful than Entry_Name'Count.  However, I am sure that the 
>justification for the change to type_name'size is rock solid.

Seems to me that the only reason you'd want the minimum number of bits
used to represent a type is if you wanted to implement that type with the
minimum number of bits allowed, eg, in a maximally packed record using
a "somewhat" portable rep clause.  (Not the most beautiful piece of code I
can imagine).

If you wanted to know the number of bits in a certain type of object (e.g,
a variable of a type) use object'size -- that's what it's for.

-- Chris

-- 
Christopher A. Warack                   warack@eecs.umich.edu
Graduate Dept, EECS			(313) 665-4789
University of Michigan

Re: 'SIZE attribute of a type

[elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu]

Mr Mark Biggar writes:

>I don't thing anyone would implement this as an automatic feature of an
>Ada compiler.  But, it is perfectly reasonable for the rep-clause

> for b'size use 1;

> to cause a compiler to do just what you want, while not having the
> rep-clause would make b'size something like 8, 16 or 32.

> b'size is the actual storage used for the type not the minimum possible.


If I am correctly understanding the interpretation of Type_Name'Size
the attribute should return the minimum number of bits objects of this
type might require.  So when a compiler usually uses 16 bits to represent
objects of type boolean, but in the case of pragma pack on a boolean array
only uses 1 bit, Boolean'Size must return 1.  In the case of of compiler
that can at some time understand and interpret baised types and produce
a very small range, than the compiler should generate and return that 
small number of bits for type_name'Size.  Remember, even if you do not use
pragma Pack in your program Boolean'Size still returns 1.  It doesn't
matter if you use the feature at all, it only depends upon whether the
compiler is capable of packing boolean arrays. 

I believe Object_Name'Size returns the actual storage used for an object.
There is little correlation between Object_Name'Size and Type_Name'Size.

If I am wrong anyone feel free to post a correction. I am clearly NOT an
Ada expert.

Robert Parkhill

Re: 'SIZE attribute of a type

[Robert I. Eachus]

In article <5901@email.sp.unisys.com> parkhill@email.sp.unisys.com (parkhill) w
rites:

   If I am correctly understanding the interpretation of Type_Name'Size
   the attribute should return the minimum number of bits objects of this
   type might require...

   I believe Object_Name'Size returns the actual storage used for an object.
   There is little correlation between Object_Name'Size and Type_Name'Size.

   If I am wrong anyone feel free to post a correction. I am clearly NOT an
   Ada expert.

-- Pretty much right.  The only thing missing is that if the size of a
-- type is set using a size clause, type'size, subtype'SIZE, and
-- object'SIZE are all equal to the value set by the size clause.  In
-- other words, if you ask for a specific size, that is the size for
-- everything of that type.  (Except a record component whose size is
-- set differently by a record representation clause.)

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...

Re: 'SIZE attribute of a type

[agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ca]

Well, now for the twist.  If I have understood this thread, the following
statement should minimize the storage for variables of type b:

    for b'Size use b'Size;

So I used a Verdix compiler (old) to see if it would even compile the
code--it does!  But for a Boolean type it still uses 8:

Domain/Ada Version 3.0.2 - March 23, 1990 
Type B has size               8
Variables of type B have size 8

How many compilers can compile this and then how many actually
use one bit for this type?  Very interesting...but cryptic.

----------------Cut Here-----------------------------------
with Text_IO;

procedure Test_B is

    type B is new Boolean;
    for B'Size use B'Size;

    B_variable : B;
begin
    Text_IO.Put_Line ("Type B has size              " &
                      Integer'Image (B'Size));
    Text_IO.Put_Line ("Variables of type B have size" &
                      Integer'Image (B_variable'Size));
end Test_B;
----------------Cut Here-----------------------------------

Re: 'SIZE attribute of a type

[Alex Blakemore]

In article <1991Dec13.152340.20444@software.org> smithd@software.org (Doug Smit
h) writes:
> If I have understood this thread, the following
> statement should minimize the storage for variables of type b:
>     for b'Size use b'Size;

Interesting idea.

> So I used a Verdix compiler (old) to see if it would even compile the
> code--it does!  But for a Boolean type it still uses 8:

> How many compilers can compile this and then how many actually
> use one bit for this type?  Very interesting...but cryptic.

Hi Doug,
  I ran this through our VMS Ada compiler and got the following.
I think you could read the LRM more than one way here.  Is there
an AI about this ? LRM excerpt is at the end.

--------------- Pruned listing from VAX Ada V2.2-38 --------------
    1   with Text_IO;
    2
    3   procedure Test_B is
    4
    5       type B is new Boolean;
    6       for B'Size use B'Size;
................1...........2
%ADAC-I, (2) The representation of type B at line 5 is forced here
%ADAC-E, (1) The representation of type B at line 5 has already been forced at 
line 6 [LRM 13.1(6)]
    7
    8       B_variable : B;
    9   begin
   10       Text_IO.Put_Line ("Type B has size              " &
   11                         Integer'Image (B'Size));
   12       Text_IO.Put_Line ("Variables of type B have size" &
   13                         Integer'Image (B_variable'Size));
   14   end Test_B;
--------------- end VAX Ada V2.2-38 listing --------------

For those unfamiliar with VMS, the messages preceeded with %ADAC-I
are informational messages which may help shed light on the subject 
but are not errors or even warnings.  Errors are preceeded with %ADAC-E.

LRM 13.1(6)
... certain occurrences of its name imply that the representation of the type
must already have been determined. ... A forcing occurrence is any occurrence
other than in a type or subtype declaration, or a representation clause for the
type itself. In any case, an occurrence within an expression is always forcing.
-- 
---------------------------------------------------------------------
Alex Blakemore           blakemore@software.org        (703) 742-7125
Software Productivity Consortium  2214 Rock Hill Rd, Herndon VA 22070

Re: 'SIZE attribute of a type

[elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!ds]

warack@dip.eecs.umich.edu (Christopher Warack) writes:
> In article <5898@email.sp.unisys.com> parkhill@email.sp.unisys.com (parkhill)
 writes:
> >>>Image a compiler was smart enough to understand baised number ranges. 
> >>
> >>>   type b is range 9 .. 10; 
> >>>        or 
> >>>   type b is range 2**31 - 2 .. 2**31 - 1;
> >>
> >>
> >>>If the compiler can generate code that only uses 1 bit then b'Size 
> >>>should return 1.
> >> 
> >>Oh, that compilers were so cleverly written! 
> >>
> >
> >> Deleted text.
> >
> >My point on the compiler having the capability to use one bit is that I
> >find the utility of type_name'size is now questionable.  Lets say the
> >compiler is capable of using 1 bit but won't do it in most situations.
> >How can any programmer use type_name'size to any practical purpose?  It 
> >seems less useful than Entry_Name'Count.  However, I am sure that the 
> >justification for the change to type_name'size is rock solid.
> 
> Seems to me that the only reason you'd want the minimum number of bits
> used to represent a type is if you wanted to implement that type with the
> minimum number of bits allowed, eg, in a maximally packed record using
> a "somewhat" portable rep clause.  (Not the most beautiful piece of code I
> can imagine).
> 
> If you wanted to know the number of bits in a certain type of object (e.g,
> a variable of a type) use object'size -- that's what it's for.
> 
> -- Chris
> 
> -- 
> Christopher A. Warack                   warack@eecs.umich.edu
> Graduate Dept, EECS			(313) 665-4789
> University of Michigan



You are quite correct,  one of the only reasons you would want to use the
minimum number of bits that minimum bits are required.  I am often 
required to write device drivers in Ada.  The device being communicated
with sets the protocol.  Some of the military devices I communicate with
used biased representation for input and output values.  If the compiler
could generate code for this I wouldn't have to do it.  I think
portability goes or when you are doing memory mapped I/O to external devices.

Yes, I know Object_Name'Size tells you the number of bits used by an
object.  What is Type_Name'Size for??

Robert Parkhill