Enhancement needed (was strange record size ?)

Enhancement needed (was strange record size ?)

[Michael Pickett]

At Robert Dewar's request, this thread has been moved from chat@gnat.com
to CLA on the grounds that it had ceased to be GNAT-specific.

The thread originated when a poster noted that GNAT and another compiler
adopted different record sizes, and that the other compiler's strategy
served the poster's purposes better. Robert pointed out that GNAT
followed the Implementation Advice in the RM in respect of the effects
of trying to set the Size attribute, whereas the other compiler appeared
not to. There was a protracted exchange involving many posters, and it
seems that the original requirement can be met, albeit not in the non-
portable way that had been assumed by the poster.

If, through this summary, I have in any way misrepresented anyone or
anything that transpired in this thread, I humbly apologise.

Feeling that GNAT had been somewhat unfairly criticised in the
discussion, and being ever ready to jump on to a bandwagon, I added a
further comment to the thread, part of which Robert has included at the
head of yet a further comment which I have reproduced below. My
intention in commenting earlier was to encourage contributions to the
further development and improvement of the language where a programmer
had identified a deficiency. Robert may have misunderstood my
intentions, for, although I can find no fault in what he writes, he does
not appear to agree with what I wrote. :-( Therefore, let me set out a
few bullet points which I hope will clarify what I have to say, and then
we can pull those to bits also, in due course. :-)

* Ada is not perfect. It is not yet at the end of its life as far as
development is concerned. Although the current five year review of the
ISO Standard is not going to give us an Ada 2000 (we are going to get a
Technical Corrigendum to tidy up a few points) we are already looking
towards a possible Ada 2005. If anyone has identified genuine (or even
merely perceived) deficiencies in the language, please would they bring
these to the attention of the language maintenance team rather than risk
undermining Ada's reputation or perhaps the reputations of its
implementors.

* If there is some perfectly reasonable effect that cannot be achieved
in a portable way, (subject to limitations imposed by context and
environment,) that may well be considered to be a language deficiency.

* Implementation Advice is a useful mechanism for persuading an
implementor to adopt (or avoid) a particular approach where it would be
inappropriate to introduce a normative clause. (Unfortunately, the
Standard does not provide any background on what qualifies a clause to
be a recommendation rather than a requirement.)

* A programmer should not need to rely on the use of non-portable code.

I have interspersed a few comments in Robert's text.

Note that I believe the original poster's problem has been resolved
satisfactorily from everyone's point of view. This posting does not
address that issue, and hence the change in title.

In message <20000911122532.7E0E734D80@nile.gnat.com>, Robert Dewar
<dewar@gnat.com> writes
><<<<If it can be shown that the /only/ way to achieve a particular but
>perfectly reasonable effect in Ada is to rely on Implementation Advice
>being taken or not taken, or on some other permitted implementation
>choice, then that is a weakness in the Ada Standard and should be
>reported to the language maintenance team. It is not a reason in itself
>for criticising the particular choice made by the compiler implementor,
>although it may be one of the factors which determines whether or not
>the compiler in question is suitable.
>>>
>>>
>
>THe IA in this case says that size clauses should not have a certain effect.
>The issue is not one of relying on this, but rather the inversion, the
>suggestion here was that (a) compilers should ignore this advice and
>(b) it is reasonable for programs to *rely* on compilers NOT following
>the implementatoin advice, and that (c) compilers that DO follow the
>implementation advice are therefore somehow irritiating :-)
>
>So the above para is not really applicable in this case.

But I did say "rely on Implementation Advice being taken or NOT taken,"
so I think it /is/ applicable. I do agree with your analysis of what was
said, though.

>
>However, it is in fact, though very reasonable sounding, not correct. There
>are many many situations in which a program must rely on things that are
>NOT in the standard, and could NOT be in the standard.

I'm sure you are right. I'm only interested in "things that are NOT in
the standard" but OUGHT to be. I was not speaking against the use of
Implementation Advice. Please don't think I want to over-specify the
language; there are already people who think it is over-specified,
(well, over-restricted, really) and I don't want to fuel too much of
that sort of thing.

>
>For example, when you write
>
>   a := A + B;
>
>you realy on the fact that the compiler will generate some kind of add
>instruction, but a compiler that called a recursive routine that worked
>something like
>
>  function "+" (A,B : Integer) is
>  begin
>     if B = 0 then
>        return A;
>     elsif B > 0 then
>        return (Integer'Succ (A) + Integer'Pred (B));
>     else
>        return (Integer'Pred (A) + Integer'Succ (B));
>     end if;
>  end;
>
>would of course conform to the RM, and we have no way AT ALL to prohibit
>this ludicrous code. If we thought there was a problem, we could add
>implementatoin advice, but in this case, we don't bother, since we
>don't think the above is realistic.

I agree. But equally I would not like to see that it was only
Implementation Advice that recommended that A + B should result in the
sum of the two quantities. :-)

>
>IA is used in cases where we cannot make normative requirements because
>
>either
>
>a) the issue is target dependent

I have no problem with that.
>
>or
>
>b) it involves issues which are not within reach of the semantic framework
>of the RM. In other words, if some of the IA paragraphs were made normative
>requirements, they would be semantically vacuous and there fore useless.

Sorry, Robert. That's a bit grand for me. If you could quote some
specific examples, I might understand, but from looking at a few, I
conclude that they simply seem to be sensible (and useful) ways of doing
things. Still, anyone who relies on a particular IA being followed or
else not followed is treading in the area of non-portability. But that's
a problem they should recognise.

>
>We allow ourselves much more freedom in specifying IA than requirements.
>
>Take the Size issue at hand, obviously the normative text cannot prohibit
>the size clause from rearranging internal layouts, because it would be
>quite valid to determine the internal layout by tossing a coin, or 
>consulting astrological charts. So this is only advice, but it is good
>advice, and useful for a programmer.

Unless, it would seem, that programmer wants portability, in which case
the programmer should rely on something which is normative, and not on
something which is just Implementation Advice.

We agree that Implementation Advice is for things which cannot be
normative. Relying on things which are not normative is taking a risk,
even though it may be a calculated risk.

>
>(finally some GNAT relevance)
>
>THat's why in GNAT, with very rare exceptions, which we document along
>with the reasons for the discrepancies, we consider IA to be as governing
>as normative requirements, and other vendors generally take the same
>attitude in the Ada 95 world.

That should be good news for everyone.

>
>And now I think followups definitely SHOULD go to CLA :-)

and it was so.
-- 
Michael Pickett
Ada@norvu.demon.co.uk

Re: Enhancement needed (was strange record size ?)

[John McCabe]

Michael Pickett <MPickett@norvu.demon.co.uk> wrote:

<..snip..>

>...Robert may have misunderstood my intentions...

Given my experience of Robert's interpretations, I think that your
hypothesis is likely to be entirely correct!

>* Implementation Advice is a useful mechanism for persuading an
>implementor to adopt (or avoid) a particular approach where it would be
>inappropriate to introduce a normative clause. (Unfortunately, the
>Standard does not provide any background on what qualifies a clause to
>be a recommendation rather than a requirement.)

I may be missing the point here, but I believe IA are guidelines as to
the way a compiler would be expected to do things, but none of these
are requirements. The RM however does identify Implementation
Requirements sections.


Best Regards
John McCabe <john@assen.demon.co.uk>

Re: Enhancement needed

[Nick Roberts]

I'd be grateful if you would mention what it was that you actually wanted
your compiler to do, so I can make mine do the same. I'm always eager to
please. People seem to think that compiler writers have to be legally
coerced into doing anything; some of us will actually respond to a little
courtesy. ;-)

Personally, I find the Implementation Advice sections to be daft, from a
certain point of view (along the lines of "we recommend you design the boat
to be water resistant"). However, from another point of view, they're
wonderful, since they go some way towards telling me what my compiler should
do. It's (almost) always great to be told this, it eases the throbbing in my
poor (12-neurone) brain no end.

I think the IAs can be understood by understanding the RM95 in two lights:
(a) the political viewpoint; (b) the technical viewpoint. The IAs fall
in-between the two, where you can't _tell_ them to do something (that would
be impolitic, the people who sell boats that sink would complain), but you
can _recommend_ that they do it.

Finally, compilers are _always_ irritating. It's their role in life.
Compiler writers quite deliberately write their compilers to be as
irritating as possible. Of course they do. Sensible and useful ways of doing
things? Pah!

--
Nick Roberts
http://www.AdaOS.org

PS: For anyone asking "When's the compiler gonna be ready, Nick?", the
answer is the same old "Maybe 10 years". Sorry.

Re: Enhancement needed

[Robert A Duff]

"Nick Roberts" <nickroberts@callnetuk.com> writes:

> I think the IAs can be understood by understanding the RM95 in two lights:
> (a) the political viewpoint; (b) the technical viewpoint. The IAs fall
> in-between the two, where you can't _tell_ them to do something (that would
> be impolitic, the people who sell boats that sink would complain), but you
> can _recommend_ that they do it.

Nonsense.  (How's that for "impolitic"? ;-))  The reason the IA isn't
*required* is usually because the IA is not well defined from a formal
point of view.  It uses terms that are not defined in the RM, or talks
about things from an implementation point of view rather than a language
definition point of view.  It has nothing to do with being impolitic --
after all, we weren't shy about putting in all the other thousands of
hard requirements.

- Bob

Re: Enhancement needed (was strange record size ?)

[Michael Pickett]

In article <39beb5c7.17576629@news.demon.co.uk>, John McCabe <john@assen
.demon.co.uk.nospam> writes
>Michael Pickett <MPickett@norvu.demon.co.uk> wrote:
>
><..snip..>
>
>>...Robert may have misunderstood my intentions...
>
>Given my experience of Robert's interpretations, I think that your
>hypothesis is likely to be entirely correct!

One has to take the rough with the smooth. :-)

>
>>* Implementation Advice is a useful mechanism for persuading an
>>implementor to adopt (or avoid) a particular approach where it would be
>>inappropriate to introduce a normative clause. (Unfortunately, the
>>Standard does not provide any background on what qualifies a clause to
>>be a recommendation rather than a requirement.)
>
>I may be missing the point here, but I believe IA are guidelines as to
>the way a compiler would be expected to do things, but none of these
>are requirements. The RM however does identify Implementation
>Requirements sections.

I am inclined to share your beliefs. The point is, I think, that code
that relies on Implementation Requirements is portable, at least to the
extent that that is practical, but code that relies on Implementation
Advice is only portable to the extent that all compilers under
consideration follow that advice. Relying on Implementation Advice being
followed is a calculated risk. Relying on Implementation Advice NOT
being followed, as appeared to be the case at the start of this
exchange, is an even greater risk, even though there may be compilers in
this category. My concern in following up this posting was that there
may be examples of where only by assuming that Implementation Advice has
been taken (and so by taking a calculated risk) is some particular
useful effect achievable. I don't know that there are any such examples,
- I hope there aren't any - but if there are, I hope someone will bring
them forward rather than simply live with the risk.


-- 
--Michael--

Re: Enhancement needed

[Samuel T. Harris]

Michael Pickett wrote:
> 
> In article <8pol3q$dnqb3$1@ID-25716.news.cis.dfn.de>, Nick Roberts
> <nickroberts@callnetuk.com> writes
> >I'd be grateful if you would mention what it was that you actually wanted
> >your compiler to do, so I can make mine do the same. I'm always eager to
> >please. People seem to think that compiler writers have to be legally
> >coerced into doing anything; some of us will actually respond to a little
> >courtesy. ;-)
> 
> I wasn't the original poster, and I didn't retain the earlier postings,
> but as far as I recall, the expectation and previous experience was that
> setting the Size attribute for a record type should result in the
> compiler adjusting, if necessary, the internal layout of the record from
> the default layout.

I find that expectation dubious, from whereever it comes.

Consider the following problem.

A memory mapped device provides a collection of data at a specific
memory address. I use an Ada record to overlay that address.
I need a rather explicit representation clause to exactly
place each field in the appropriate location. I need an address
clause to place the record object at the appropriate place
in memory. I use a size clause as an extra check to ensure
my record layout indeed fits the size of the memory area.
I definately don't want the size clause changing the layout
at all. I expect a warning is the size is too large for the
record and an error if it is too small.

Consider another problem.

I'm interfacing to a C API. I used to use rep clauses on the
records to make them fit, but I now have pragma Convention
in Ada 95 which eliminates all that drudgery. I still use
a size clause to confirm the record will fit into the size
I want. Pragma Convention defines the layout, I don't want
the size clause changing it.

If all I'm after is a packed version of the record with no
padding or extra bits, then I expect pragma pack to do the
job.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Enhancement needed

[Ted Dennison]

"Samuel T. Harris" wrote:

> Michael Pickett wrote:
> >
> > but as far as I recall, the expectation and previous experience was that
> > setting the Size attribute for a record type should result in the
> > compiler adjusting, if necessary, the internal layout of the record from
> > the default layout.
>
> Consider the following problem.
>
> A memory mapped device provides a collection of data at a specific
> memory address. I use an Ada record to overlay that address.
> I need a rather explicit representation clause to exactly

I believe the entire issue was what the compiler can do in the *absence* of a
rep clause. Its pretty clear that it needs to honor any record rep clause, or
die trying. But it was suprising to some that in *absense* of a rep clause,
compilers still aren't supposed to rearrange record fields to make a size clause
attainable.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Enhancement needed

[Samuel T. Harris]

Ted Dennison wrote:
> 
> "Samuel T. Harris" wrote:
> 
> > Michael Pickett wrote:
> > >
> > > but as far as I recall, the expectation and previous experience was that
> > > setting the Size attribute for a record type should result in the
> > > compiler adjusting, if necessary, the internal layout of the record from
> > > the default layout.
> >
> > Consider the following problem.
> >
> > A memory mapped device provides a collection of data at a specific
> > memory address. I use an Ada record to overlay that address.
> > I need a rather explicit representation clause to exactly
> 
> I believe the entire issue was what the compiler can do in the *absence* of a
> rep clause. Its pretty clear that it needs to honor any record rep clause, or
> die trying. But it was suprising to some that in *absense* of a rep clause,
> compilers still aren't supposed to rearrange record fields to make a size clause
> attainable.
> 

I believe I covered this case in my last paragraph (quoted below) ...

> If all I'm after is a packed version of the record with no
> padding or extra bits, then I expect pragma pack to do the
> job.
> 

... and I also believe we are in agreement. I still expect a size clause
to produce a warning if it is too large and an error if it is too
small but I never expect it to change the layout. That is the purpose
of pragma pack.

-- 
Samuel T. Harris, Principal Engineer
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Re: Enhancement needed

[Robert Dewar]

In article <39C564E4.C976F096@telepath.com>,
  Ted Dennison <dennison@telepath.com> wrote:
> I believe the entire issue was what the compiler can do in the
> *absence* of a rep clause. Its pretty clear that it needs to
> honor any record rep clause, or die trying. But it was
> suprising to some that in *absense* of a rep clause,
> compilers still aren't supposed to rearrange record fields to
> make a size clause attainable.

Well the RM is a good antidote to suprise here. Once again,
the relevant section of the RM is 13.3(53):

53   A Size clause on a composite subtype should not affect the
internal layout of components.

This is implementation advice, since there is no easy way to
formalize this as a formal semantic requirement, because the
formal semantics have nothing to say about default data
representation (for example a compiler that rearranged record
fields only in leap years is a conforming, though silly,
compiler -- IA is basically about preventing silliness :-)

In this case, the IA is well taken, because if size could
affect the internal layout of components, this could result
in expensive implicit conversions.

At the very least, compilers that follow implementation advice
in the RM should not surprise you by following this advice :-)




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