Ada question.
Bob Wells #402
> First, the use of "for use at" in the situation you describe, where an
> address comes in from an external source, is perfectly valid. In fact
> it is *what this construction is for*. What is erroneous is overlaying
> two Ada variables this way.
Does not the LRM specifically say
"Address clauses should not be used to achieve overlays of objects or
overlays of program units. Nor should a given interrupt be linked to more
than one entry. Any program using address clauses to achieve such effects
is erroneous." -LRM 13.5.8
and
AI-00395/00 expands upon this and goes on to say specifically that this is
disallowed.
@ --------
@ //// - ( G'day! )
@ (o o) --------
@ ----oOO--(_)--OOo--------------------------------------------------------
Bob Wells "You can measure a programmer's perspective by noting
his attitude on the continuing viability of FORTRAN."
-- Alan Perlis
@ INTERNET: w...@eurocontrol.de CompuServe: 100272,3004
Robert Dewar
What is allowed is getting the address of an external object, e.g. one
defined by C, and then using the address clause to allow the Ada program
to reference this external ovbject directly.
This isn't just allowed, it's what the feature is *for*
Typical uses are to reference objects defined by the hardware, e.g. a frame
buffer or other memory mapped device, and to link to external objects. It is
true that 9X has a nicer way of doing the latter, but there is nothing wrong
in using it for the purpose for which it was intended in Ada 8x
Chris Warack <sys mgr>
|> Robert Dewar writes
|>
|> > First, the use of "for use at" in the situation you describe, where an
|> > address comes in from an external source, is perfectly valid. In fact
|> > it is *what this construction is for*. What is erroneous is overlaying
|> > two Ada variables this way.
|>
|> Does not the LRM specifically say
|>
|> "Address clauses should not be used to achieve overlays of objects or
|> overlays of program units. Nor should a given interrupt be linked to more
|> than one entry. Any program using address clauses to achieve such effects
|> is erroneous." -LRM 13.5.8
Yup... Dr Dewar says to use the address clause on an object from an external
source. The LRM says don't overlay two >>>Ada<<< objects. You're both right.
The address clause allows you to overlay an Ada construct on an external object.
It is erroneous to overlay an Ada object on another Ada object ( at least within
the same program :-).
|> and
|>
|> AI-00395/00 expands upon this and goes on to say specifically that this is
|> disallowed.
|>
|> @ --------
|> @ //// - ( G'day! )
|> @ (o o) --------
|> @ ----oOO--(_)--OOo--------------------------------------------------------
|> Bob Wells "You can measure a programmer's perspective by noting
|> his attitude on the continuing viability of FORTRAN."
|> -- Alan Perlis
|> @ INTERNET: w...@eurocontrol.de CompuServe: 100272,3004
--
Christopher A. Warack, Capt, USAF
Computer Science Department, US Air Force Academy
Bob Wells #402
Does anyone know the reasons behind the disallowing of the overlaying of two
Ada objects?
Overlaying had to be used when interfacing to a MILBUS MIL-STD 1553 on a
helicopter. The data stream came off the MILBUS as 32 16-bit words and packed
into this stream was all sorts of float values, integer values, enumeration
types and boolean values. The quickest way, requiring the minumum code, was to
take the address of the incoming buffer and then lay the data record structure,
defined with a record rep. clause, over this. According to the LRM this is
illegal.
Any feedback about the reasoning would be greatly appreciated.
@ --------
@ //// - ( G'day! )
@ (o o) --------
@ ----oOO--(_)--OOo--------------------------------------------------------
Bob Wells "Zatt iss not my dog!"
lmi...@indyvax.iupui.edu
>> What is not allowed is overlaying two Ada objects
>>
>> What is allowed is getting the address of an external object, e.g. one
>> defined by C, and then using the address clause to allow the Ada program
>> to reference this external ovbject directly.
>>
>> This isn't just allowed, it's what the feature is *for*
>>
>> Typical uses are to reference objects defined by the hardware, e.g. a frame
>> buffer or other memory mapped device, and to link to external objects. It is
>> true that 9X has a nicer way of doing the latter, but there is nothing wrong
>> in using it for the purpose for which it was intended in Ada 8x
>>
>
> Does anyone know the reasons behind the disallowing of the overlaying of two
> Ada objects?
>
> Overlaying had to be used when interfacing to a MILBUS MIL-STD 1553 on a
> helicopter. The data stream came off the MILBUS as 32 16-bit words and packed
> into this stream was all sorts of float values, integer values, enumeration
> types and boolean values. The quickest way, requiring the minumum code, was to
> take the address of the incoming buffer and then lay the data record structure,
> defined with a record rep. clause, over this. According to the LRM this is
> illegal.
>
> Any feedback about the reasoning would be greatly appreciated.
If I had a nickle for every overlay bug I have chased...
Some people maintain that "overlays" are not necessary to solve any problem,
they are error prone and there are more "understandable" methods to use.
I once implemented a 1553b interface by using addres representation clauses to
place constrained arrays of words (1553 messages are arrays of words) I then
used unchecked conversion to "flip" these into the actual data representation
(usually a varrient record). This does two things at once, it does not force
me to map the 1553 memory into application specific datatypes and objects and
does the copy into "application" memory during the unchecked conversion. The
constraint checks executed during the evaluation of the record help trap
corrupted messages. This allows me to reuse the 1553 package and the
unchecked_conversion shows that the overlay is occuring. Sometimes it is not
immediately clear that an overlay is being used.
I wish I had a better reason for no overlays but I honestly can't think of a
good reason to use one with the available alternatives.
Todd A Sorensen
> It is erroneous to overlay an Ada object on another Ada object ( at least within
> the same program :-).
>
I have problems with this rule. Why make it erroneus? If I have two
distinctly different pieces of data arriving at the same address, why
can't I manage the interpretation of the data and overlay the two objects
at the same address?
This happens frequently when the same 1553 subaddress has to be used for
more than one type of message. I have lots of different types of messages,
and they have to use the same subaddress (which means the same memory
locations).
This is an instance (we have to do a lot of this) where using overlays
would be most helpful.
I get around this by using an assembly routine that moves data to one of
the objects and then I check the type of message to determine what it
really is, if it isn't what I want, then I move the data to the other
object and test it there. I would like to test the data once (at it's
initial address) and then procede from there. This would be more
efficient in both time and space, but the Language definition won't let me
do it, and hence the compiler either.
--
------------------------------------------------------------------------------
Todd A Sorensen Honeywell Defense Avionics Systems Division
505-828-5611 internet: tsor...@dasd.honeywell.com
internet: t...@dasd.honeywell.com
------------------------------------------------------------------------------
John Goodenough
In article <1993Nov10...@dasd.honeywell.com>, tsor...@dasd.honeywell.com (Todd A Sorensen) writes:
> In article <2bmgd1$k...@usafa2.usafa.af.mil>, cwa...@kirk.usafa.af.mil
> (Chris Warack <sys mgr>) writes:
> > It is erroneous to overlay an Ada object on another Ada object ( at least
> within the same program :-).
>
> I have problems with this rule. Why make it erroneus? If I have two
> distinctly different pieces of data arriving at the same address, why
> can't I manage the interpretation of the data and overlay the two objects
> at the same address?
>
> This happens frequently when the same 1553 subaddress has to be used for
> more than one type of message. I have lots of different types of messages,
> and they have to use the same subaddress (which means the same memory
> locations).
>
> This is an instance (we have to do a lot of this) where using overlays
> would be most helpful.
>
> I get around this by using an assembly routine that moves data to one of
> the objects and then I check the type of message to determine what it
> really is, if it isn't what I want, then I move the data to the other
> object and test it there. I would like to test the data once (at it's
> initial address) and then procede from there. This would be more
> efficient in both time and space, but the Language definition won't let me
> do it, and hence the compiler either.
I'm curious to know why Unchecked_Conversion doesn't work for you in this
situation. For example,
if UC(object).type_determiner = First_Message_Type then
Do_Something(UC_to_First_Message_Type(object).Desired_Component);
Do_Something_Else(UC_to_First_Message_Type(object).Another_Component);
end if;
where the procedure calls are replaced with appropriate code operating on
components of the message. Of course, this is more wordy (even if you use
more concise unchecked conversion names), but it does make explicit what you
are doing, whereas overlays leave things implicit for the reader. Maybe you
need to provide some sample code to show more explicitly why you need to write
an assembly language routine that moves data around.
As to your question of why overlays were defined to be erroneous, there are
several reasons (in no particular order): 1) unchecked conversion was defined
to provide functionality that was thought to be functionally equivalent; 2)
the spirit of the Ada design is to make things explicitly type-safe, and
overlays are not consistent with this objective (unchecked conversion *is*
consistent because the conversion is explicit in the code); and 3) the
possibility of overlays can make correct optimization more difficult or else
can impair the quality of optimization; neither possibility was considered
acceptable given the presence of unchecked conversion.
John B. Goodenough Goode...@sei.cmu.edu
Software Engineering Institute 412-268-6391
Michael Feldman
Todd A Sorensen <tsor...@dasd.honeywell.com> wrote:
>In article <2bmgd1$k...@usafa2.usafa.af.mil>, cwa...@kirk.usafa.af.mil (Chris Warack <sys mgr>) writes:
>> It is erroneous to overlay an Ada object on another Ada object ( at least within
>> the same program :-).
>>
>
>I have problems with this rule. Why make it erroneus? If I have two
>distinctly different pieces of data arriving at the same address, why
>can't I manage the interpretation of the data and overlay the two objects
>at the same address?
>
NOT mean "not permitted"; it does NOT mean "wrong"; it does NOT mean
"sinful". The LRM says (sect. 1.6, paragraph (c)):
"Erroneous execution:
The languages rules specify certain rules to be obeyed by Ada programs,
although there is no requirement on Ada compilers to provide either a
compilation-time or a run-time detection of the violation of such rules.
The errors of this category are indicated byt he use of the word
"erroneous" to qualify the execution of the corresponding constructs.
The effect of erroneous execution is unpredictable."
In plain English: there are areas where the LRM must cop out on trying
to predict behavior. An unchecked type conversion is one of these - how
can the standard predict what will happen if certain "integer bits"
are simply re-interpreted as "float bits"?
Overlaying variables to get the effect of an unchecked conversion is
equally _unpredictable_, hence _erroneous_. Nowhere in the LRM do I see
a statement that this is WRONG. It simply means that certain constructs
are _risky_ - you are walking a tightrope without a net, as it were.
But you knew that already.
If you can see no other plausible way to do what you have to do, then
do what you must. It's not a sin.
I think the definition of "erroneous" ought to be an FAQ. On the other
hand, Ada9X is changing the terms a bit, by adding the term "bounded
errors" - certain erroneous cases can nevertheless be bounded as to
the possible effects, others cannot.
Bottom line: "erroneous" is a defined technical term, not a judgemental one.
Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman - chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University - Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-0227 (fax) - mfel...@seas.gwu.edu (Internet)
"We just changed our CONFIG.SYS, then pressed CTRL-ALT-DEL. It was easy."
-- Alexandre Giglavyi, director Lyceum of Information Technologies, Moscow.
------------------------------------------------------------------------
Alex Blakemore
> As to ... why overlays were defined to be erroneous, there are
> several reasons (in no particular order):
> 1) unchecked conversion was defined
> to provide functionality that was thought to be functionally equivalent;
but its not exactly equivalent.
unchecked_conversion defines a _function_, so it cant of course be
used as an actual parameter when the formal is of type out or in out.
an overlaid variable could be used as an actual parameter in this case.
consider (again)
type your_string is array (positive range <>) of your_character;
type my_string is array(postive range <>) of my_character;
subtype your_buffer is your_string (1 .. really_big_number);
procedure fill_buffer (x : out your_buffer);
pragma interface (some_inferior_language, fill_buffer);
procedure my_fill_buffer (x : out my_buffer);
your job is to use fill_buffer to write
this forces you to first call fill_buffer, and then
make a copy of the actual parameter using unchecked conversion to
change it to type my_buffer.
that's not an unreasonable cost in many cases, but when the object
in question is a large buffer, then repeatedly making an extra copy
just to avoid a offending the compiler would be unacceptable.
of course, if you are free to redesign the procedure in question
or define all the types involved, then you should be able to find
a better solution than overlays.
I for one am glad the Ada83 designers did not forbid using rep clauses
for overlays, but only warn that it may not be portable.
seems fair enough.
--
Alex Blakemore
al...@cs.umd.edu NeXT mail accepted
Alex Blakemore
I wrote
> your job is to use fill_buffer to write
I meant
> your job is to use fill_buffer to write my_fill_buffer
Robert Dewar
perception that it would significantly damage optimization to allow
this. It is certainly true that it would damage optimization. It's
always hard to get good quantititaive data in such situations, but
it sure seems like it could be significant to my mind!
One interesting thought would be to say that in Ada 9X, it is OK to
overlay aliased volatile variables. That's almost sure to work, so
we might as well require it to work.
Robert Dewar
of erroneous. His definition suggests that it is essentially equivalent to
"implementation defined". I think that's erroneous (ha ha :-) The idea of
using the term erroneous is clearly to send a message that the program is
wrong. Programs that use erroneous constructs are extremely dubious!
Charles H. Sampson
>
>I for one am glad the Ada83 designers did not forbid using rep clauses
>for overlays, but only warn that it may not be portable.
>seems fair enough.
In 13.5(8), the LRM says: Address clauses should not be used to
achieve overlays of objects... Any program using address clauses to
achieve such effects is erroneous.
From 1.6(7): The language rules specify certain rules to be obeyed by
Ada programs, although there is no requirement on Ada compilers to provide
either a compilation-time or a run-time detection of the violation of such
rules. The errors of this category are indicated by the use of the word
_erroneous_ to qualify the execution of the corresponding constructs. The
effect of erroneous execution is unpredictable.
When it is specified that certain rules are to be obeyed, that sounds
pretty much like forbidding the breaking of those rules. Furthermore,
notice that there is no mention of portability. What 1.6(7) says is that
you can't expect your program to work the way you want it to.
The issue is even one step removed from portability. It could be that
you write an erroneous program and it executes the way you want serendipi-
tously. The compiler writers hadn't addressed the issue and their compiler
just happens to generate the code you want. In a later version they might
change something, perhaps in a far-removed part of the compiler, and what
the compiler just happens to generate afterwards is different and not what
you want.
Charlie
Robert Dewar
programs are incorrect (this is a non-technical term). They do not obey
the rules of the standard. However, compilers are not required to catch
these errors (although they are allowed to do so), and thus these
incorrect programs may execute correctly. The status of such a program
is similar, for instance, to a FORTRAN program which assumes that parameters
are passed by reference.
The fact that a program works does not mean it is correct, and conversely
there is no guarantee that incorrect programs will not work, but that does
not stop them from being incorrect.
MILLS,JOHN M.
[other correspondent's text elided ...]
> In 13.5(8), the LRM says: Address clauses should not be used to
>achieve overlays of objects... Any program using address clauses to
>achieve such effects is erroneous.
We have used representation clauses (USE .. AT) to overlay fields of structured
variables. Specifically, we had a field of data words (in memory space on a
FORCE ISIO-2 serial I/O board), and wanted to pass these words as packed
arrays of characters to our Ada program in a 68030. We defined the two spaces
to overlay and then used UNCHECKED CONVERSION between bytes and character
arrays. The compiler (Telesoft's old TeleGen2) complained until we got the
variables' sizes to match, which I thought was appropriate; once the Ada
storage was compatible, there were no more warnings.
I think this is a common embedded-systems problem: a semi-independent I/O
channel provides data upon which the Ada program must impose structure. It
isn't portable, but it reflects the specific hardware configuration of the
processor environment.
Can anyone suggest a cleaner way to do this? (If the case doesn't make
sense, I can dig out a segment of our code.)
> The issue is even one step removed from portability. It could be that
>you write an erroneous program and it executes the way you want serendipi-
>tously. The compiler writers hadn't addressed the issue and their compiler
>just happens to generate the code you want. In a later version they might
>change something, perhaps in a far-removed part of the compiler, and what
>the compiler just happens to generate afterwards is different and not what
>you want.
If you use these constructs to write bad code, all bets are off, but if you
_must_ translate between data representations used by different compilers
or processors (such as byte/word order from Intel to Motorola), portability
isn't a very realistic goal: that kind of portability would have to start
at the processor or compiler level, and requiring the compiler to iron
out basic processor differences would have a serious performance penalty
vs. producing code to run well on a given target.
I think this is a useful thread. I don't trust the dogmatic solutions
here. These _are_ the types of system for which Ada was ostensibly designed,
Ada _does_ provide the constructs, and the programmer _does_ occasionally
need to use them.
Regards --jmm--
--
John M. Mills, SRE; Georgia Tech/GTRI/CCRF/SDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: john.m...@gtri.gatech.edu
Rebel without a clue ..
Robert Dewar
address clauses, or unchecked conversion, to achieve the effect of an
overlay. The use of unchecked conversion is of course entirely appropriate,
and not subject to any of our discussion about what is or what is not
erroneous.
To restate once more: the clearly erroneous case is to declare a normal
variable X, which has no address clause, and then use an address clause
(of the form "for Y use at X'Address") to overlay variable Y on top of X.