Rep-spec question

Rep-spec question

[Joe Wisniewski]

Given the following:

type Rec is
   b : boolean;
end record;

for rec use record
   b at 0 range 0..63;
end record;
for rec'size use 64;

can any assumptions be made as to where the
byte(s) representing the boolean are stored?

Joe


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Ted Dennison]

In article <80ck3b$deu$1@nnrp1.deja.com>,
  Joe Wisniewski <wisniew@acm.org> wrote:
> Given the following:
>
> type Rec is
>    b : boolean;
> end record;
>
> for rec use record
>    b at 0 range 0..63;
> end record;
> for rec'size use 64;
>
> can any assumptions be made as to where the
> byte(s) representing the boolean are stored?

Not unless your compiler docs say so. I'm not even sure that is required
to compile.

If you want to put the boolean in a specific place, try using something
like:

for rec use record
   b at 1 range 5..5;  -- 6th bit of second byte
end record;
for rec'size use 64;

(This isn't guaranteed to compile either)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Joe Wisniewski]

In article <80clia$ein$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> In article <80ck3b$deu$1@nnrp1.deja.com>,
>   Joe Wisniewski <wisniew@acm.org> wrote:
> > Given the following:
> >
> > type Rec is
> >    b : boolean;
> > end record;
> >
> > for rec use record
> >    b at 0 range 0..63;
> > end record;
> > for rec'size use 64;
> >
> > can any assumptions be made as to where the
> > byte(s) representing the boolean are stored?
>
> Not unless your compiler docs say so. I'm not even sure that is
required
> to compile.
>
> If you want to put the boolean in a specific place, try using
something
> like:
>
> for rec use record
>    b at 1 range 5..5;  -- 6th bit of second byte
> end record;
> for rec'size use 64;
>
> (This isn't guaranteed to compile either)

   You are not saying that is required NOT to compile.
   Correct?

Joe
>
> --
> T.E.D.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Ted Dennison]

In article <80clr0$etf$1@nnrp1.deja.com>,
  Joe Wisniewski <wisniew@acm.org> wrote:
> In article <80clia$ein$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:

> > for rec'size use 64;
> >
> > (This isn't guaranteed to compile either)
>
>    You are not saying that is required NOT to compile.
>    Correct?

Yes!..er..No!..er, I'm not sure what your question really was. :-)

At the risk of opening the "implementation advice" can of worms again,
the size clause above is not required to be accepted by an
implementation. But if your vendor follows the recomendation in the
implementaion advice (which most should), then it will compile. The
implementation advice in question (from 13.3) is:

---
The recommended level of support for the Size attribute of objects is:

A Size clause should be supported for an object if the specified Size is
at least as large as its subtype's Size, and corresponds to a size in
storage elements that is a multiple of the object's Alignment (if the
Alignment is nonzero).
---

There's also the minor issue that a "storage element" is not required to
be 1 byte. But the vast majority of them (if not all) will be.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Robert Dewar]

In article <80cqb7$if9$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> At the risk of opening the "implementation advice" can of
> worms again,
> the size clause above is not required to be accepted by an
> implementation. But if your vendor follows the recomendation
in the
> implementaion advice (which most should), then it will
compile. The
> implementation advice in question (from 13.3) is:


Ted, please get this right in future :-) We just got through
discussing this. Implementation advice in chapter 13 becomes
*REQUIREMENTS* if the systems programming annex is implemented.
Since any serious compiler implements this annex, this is in
fact a requirement!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Ted Dennison]

In article <80djt4$4jt$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <80cqb7$if9$1@nnrp1.deja.com>,
>   Ted Dennison <dennison@telepath.com> wrote:
> > At the risk of opening the "implementation advice" can of
> > worms again,
> > the size clause above is not required to be accepted by an
> > implementation. But if your vendor follows the recomendation
> in the
> > implementaion advice (which most should), then it will
> compile. The
> > implementation advice in question (from 13.3) is:
>
> Ted, please get this right in future :-) We just got through

Say it enough and I might get it. :-)

But an even stronger statement than you made, such as "this works on all
known compilers", is not the same as "this is guaranteed to work on all
compilers". It is not.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Robert Dewar]

In article <80ek3j$qnq$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> But an even stronger statement than you made, such as "this
> works on all
> known compilers", is not the same as "this is guaranteed to
work on all
> compilers". It is not.


Sorry, I don't understand. You obviously do NOT use rep clauses
on a compiler that does not claim annex C conformance. Noting
that rep clauses are not guaranteed to be implemented in the
absence of annex C is of course true, but completely
uninteresting, since no one in practice who knows what they
are doing even a little bit would make the mistake of thinking
otherwise. In practice, all compilers that are intended for use
in environments where rep clauses make sense implement Annex C
in any case, so in practice, there is no problem here. Yes, I
suppose someone could be sufficiently unaware that they would
use a compiler that does not implement annex C and be suprised,
but that's just a special case of people not knowing the
language, and being surprised by their lack of knowledge.

If you are saying that you have a compiler that claims annex
C compliance and does not implement all the recommended clauses
in chapter 13, then the compiler is non-conforming, or more
pragmatically, you have found a bug in the compiler and should
report it.

It for sure is the case in Ada 95 that optional annexes are
optional, and (how amazing) compilers that do not implement
optional annexes cannot be expected by users to provide the
facilities in those annexes!


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Robert A Duff]

Ted Dennison <dennison@telepath.com> writes:

> There's also the minor issue that a "storage element" is not required to
> be 1 byte. But the vast majority of them (if not all) will be.
                                            ^^^^^^^^^^

The definition of "storage element" is of course determined by the hardware,
and most hardware these days has 8-bit bytes, but not all.
For example, the ADI SHARC chip has 32-bit storage elements,
so of course Averstar's SHARC Ada compiler reflects that.

- Bob

Re: Rep-spec question

[Robert Dewar]

In article <wccvh7913dw.fsf@world.std.com>,
Ted Dennison <dennison@telepath.com> writes:
>
> There's also the minor issue that a "storage element" is not
> required to be 1 byte. But the vast majority of them (if not
> all) will be.

Ted, you worry furiously (:-) that compilers might not implement
annex C because it is not required (when in practice in all
relevant cases, compilers DO implement annex C), yet you make
the suggestion ("if not all") that all compilers in practice
have storage_unit set to 8, which is most certainly not the
case (check the validated compilers list and VSR's, there is
more than one counter-example).


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Keith Thompson]

Ted Dennison <dennison@telepath.com> writes:
> In article <80clr0$etf$1@nnrp1.deja.com>,
[...]
> The implementation advice in question (from 13.3) is:
> 
> ---
> The recommended level of support for the Size attribute of objects is:
> 
> A Size clause should be supported for an object if the specified Size is
> at least as large as its subtype's Size, and corresponds to a size in
> storage elements that is a multiple of the object's Alignment (if the
> Alignment is nonzero).
> ---

Which raises some interesting questions.  This implies that an
implementation that follows the advice must accept the following:

    N : Integer;
    for N'Size use 1_000_000 * Integer'Size;

(assuming sufficient memory).  Where do the significant bits go?  What
if N is aliased, and you create a pointer to it (think about
endianness)?  If you pass N as a parameter, how many bits are actually
passed?

I think there's an AI that modifies the above advice.  As I recall, it
says that an implementation needn't accept a size clause for an
integer object if the specified size is bigger than the size of the
largest supported integer type.  (This could still make things
interesting if, for example, Short_Integer is 16 bits, and you declare
a Short_Integer object specified to be 32 or 64 bits, especially on a
big-endian machine.)  I'm too lazy to look up the AI; perhaps someone
else can do so.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
"Oh my gosh!  You are SO ahead of your time!" -- anon.

Re: Rep-spec question

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

>...I'm too lazy to look up the AI; perhaps someone
> else can do so.

AI's 51 and 109 talk about 'Size and 'Alignment.
As far as I know, they are not yet approved by the ARG.

- Bob

Re: Rep-spec question

[Robert Dewar]

In article <yecogd0pmc2.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> Which raises some interesting questions.  This implies that an
> implementation that follows the advice must accept the
> following:
>
>     N : Integer;
>     for N'Size use 1_000_000 * Integer'Size;
>
> (assuming sufficient memory).

GNAT says:

     1. package xxx is
     2.     N : Integer;
     3.     for N'Size use 1_000_000 * Integer'Size;
                                     |
        >>> warning: 31999936 bits of "N" unused

     4. end xxx;

> Where do the significant bits go?

If you care about this, don't use a silly declaration like
the one above :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Rep-spec question

[Nick Roberts]

Keith Thompson wrote:
> ...
> I think there's an AI that modifies the above advice.
> ...

It's AI95-00051/08 (98-04-01), which is binding. I won't quote the
entire thing wholesale, but in the middle it says:

-----

3. For a non-aliased object, the implementation should support a Size
clause specifying a Size up to (at least) the following values, which
depends on the class of the object.  (Similarly, the implementation
should support a Component_Size clause and a
record_representation_clause specifying the Size of a component up to
(at least) these values, depending on the class of the component.)

    - For a signed integer, up to the Size of the largest signed integer
      type supported by the implementation.

    - For a modular integer, up to the Size of the largest modular
      type supported by the implementation.

    - For an object of an enumerated type, up to the Size of the largest
      signed integer type, or the largest modular type, whichever is
      smaller.

For fixed point, floating point, access, and composite objects, the
implementation need not support any Size other than what would be chosen
by default.

In the discrete case, any extra bits are set to appropriate values when
assigning to the object whose Size has been specified; for example, the
value being assigned should be zero-extended or sign-extended as
appropriate.  When reading from the object, any extra bits may be
ignored.

-----

Which I think more or less clarifies the question.

-- 
Nick Roberts
Computer Consultant (UK)
http://www.callnetuk.com/home/nickroberts
http://www.adapower.com/lab/adaos

Re: Rep-spec question

[Robert A Duff]

Joe Wisniewski <wisniew@acm.org> writes:

> Given the following:
> 
> type Rec is
>    b : boolean;
> end record;
> 
> for rec use record
>    b at 0 range 0..63;
> end record;
> for rec'size use 64;
> 
> can any assumptions be made as to where the
> byte(s) representing the boolean are stored?

No.

- Bob

Re: Rep-spec question

[Tucker Taft]

Joe Wisniewski wrote:
> 
> Given the following:
> 
> type Rec is
>    b : boolean;
> end record;
> 
> for rec use record
>    b at 0 range 0..63;
> end record;
> for rec'size use 64;
> 
> can any assumptions be made as to where the
> byte(s) representing the boolean are stored?

You can pretty safely assume that an enumeration value is stored in
the low-order bits of the 64-bit component you have specified.  I would
expect this only to be supported on implementations that support
64-bit integers.

Another interesting question is what are the representations of False and
True.  I suspect that on some targets, True is all ones, while False is
zero.  On such a target, the answer to your question is "any byte". ;-)

> 
> Joe

-Tuck
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Rep-spec question

[Robert A Duff]

Tucker Taft <stt@averstar.com> writes:

> You can pretty safely assume that an enumeration value is stored in
> the low-order bits of the 64-bit component you have specified.

Right, but where the low-order bits are is determined by endianness.

- Bob