* Re: 'SIZE attribute of a type
@ 1991-11-13 17:01 elroy.jpl.nasa.gov!sdd.hp.com!mips!zaphod.mps.ohio-state.edu!unix.cis.pit
0 siblings, 0 replies; 21+ messages in thread
From: elroy.jpl.nasa.gov!sdd.hp.com!mips!zaphod.mps.ohio-state.edu!unix.cis.pit @ 1991-11-13 17:01 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-11-14 16:45 Danford Lehman
0 siblings, 0 replies; 21+ messages in thread
From: Danford Lehman @ 1991-11-14 16:45 UTC (permalink / raw)
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.
[...]
===============================================================================
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-11-14 19:58 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit
0 siblings, 0 replies; 21+ messages in thread
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit @ 1991-11-14 19:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-11-14 20:15 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit
0 siblings, 0 replies; 21+ messages in thread
From: cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit @ 1991-11-14 20:15 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-06 18:50 Brian Hanafee
0 siblings, 0 replies; 21+ messages in thread
From: Brian Hanafee @ 1991-12-06 18:50 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-06 20:04 parkhill
0 siblings, 0 replies; 21+ messages in thread
From: parkhill @ 1991-12-06 20:04 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-06 20:15 parkhill
0 siblings, 0 replies; 21+ messages in thread
From: parkhill @ 1991-12-06 20:15 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-06 21:07 Richard Pattis
0 siblings, 0 replies; 21+ messages in thread
From: Richard Pattis @ 1991-12-06 21:07 UTC (permalink / raw)
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."
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-06 21:14 Ed Matthews
0 siblings, 0 replies; 21+ messages in thread
From: Ed Matthews @ 1991-12-06 21:14 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-07 0:32 Donald Gardner
0 siblings, 0 replies; 21+ messages in thread
From: Donald Gardner @ 1991-12-07 0:32 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-09 13:24 Ed Matthews
0 siblings, 0 replies; 21+ messages in thread
From: Ed Matthews @ 1991-12-09 13:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-10 8:23 paul goffin
0 siblings, 0 replies; 21+ messages in thread
From: paul goffin @ 1991-12-10 8:23 UTC (permalink / raw)
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 +
+-------------+-------------------------------------------------------+
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-10 12:30 mcsun!uknet!yorkohm!minster!mjl-b
0 siblings, 0 replies; 21+ messages in thread
From: mcsun!uknet!yorkohm!minster!mjl-b @ 1991-12-10 12:30 UTC (permalink / raw)
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 |
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-11 18:29 elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gv
0 siblings, 0 replies; 21+ messages in thread
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gv @ 1991-12-11 18:29 UTC (permalink / raw)
>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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-12 3:17 Mark Biggar
0 siblings, 0 replies; 21+ messages in thread
From: Mark Biggar @ 1991-12-12 3:17 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-12 15:18 elroy.jpl.nasa.gov!swrinde!mips!samsung!caen!umeecs!dip.eecs.umich.edu!wa
0 siblings, 0 replies; 21+ messages in thread
From: elroy.jpl.nasa.gov!swrinde!mips!samsung!caen!umeecs!dip.eecs.umich.edu!wa @ 1991-12-12 15:18 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-12 15:36 elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu
0 siblings, 0 replies; 21+ messages in thread
From: elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu @ 1991-12-12 15:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-12 22:49 Robert I. Eachus
0 siblings, 0 replies; 21+ messages in thread
From: Robert I. Eachus @ 1991-12-12 22:49 UTC (permalink / raw)
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...
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-13 15:23 agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ca
0 siblings, 0 replies; 21+ messages in thread
From: agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ca @ 1991-12-13 15:23 UTC (permalink / raw)
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-----------------------------------
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-13 16:00 Alex Blakemore
0 siblings, 0 replies; 21+ messages in thread
From: Alex Blakemore @ 1991-12-13 16:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: 'SIZE attribute of a type
@ 1991-12-13 17:24 elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!ds
0 siblings, 0 replies; 21+ messages in thread
From: elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!ds @ 1991-12-13 17:24 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~1991-12-13 17:24 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1991-11-14 20:15 'SIZE attribute of a type cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit
-- strict thread matches above, loose matches on Subject: below --
1991-12-13 17:24 elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!ds
1991-12-13 16:00 Alex Blakemore
1991-12-13 15:23 agate!spool.mu.edu!yale.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!ca
1991-12-12 22:49 Robert I. Eachus
1991-12-12 15:36 elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu
1991-12-12 15:18 elroy.jpl.nasa.gov!swrinde!mips!samsung!caen!umeecs!dip.eecs.umich.edu!wa
1991-12-12 3:17 Mark Biggar
1991-12-11 18:29 elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!gv
1991-12-10 12:30 mcsun!uknet!yorkohm!minster!mjl-b
1991-12-10 8:23 paul goffin
1991-12-09 13:24 Ed Matthews
1991-12-07 0:32 Donald Gardner
1991-12-06 21:14 Ed Matthews
1991-12-06 21:07 Richard Pattis
1991-12-06 20:15 parkhill
1991-12-06 20:04 parkhill
1991-12-06 18:50 Brian Hanafee
1991-11-14 19:58 cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!pacbell.com!iggy.GW.Vit
1991-11-14 16:45 Danford Lehman
1991-11-13 17:01 elroy.jpl.nasa.gov!sdd.hp.com!mips!zaphod.mps.ohio-state.edu!unix.cis.pit
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox