Re: Protected Types and Address Clauses

Re: Protected Types and Address Clauses

[Robert I. Eachus]

In article <4fqe6h$t0e@theopolis.orl.mmc.com> rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:

  >  protected Discretes is 
  >    procedure Write(Settings : in SETTING_LIST);
  >  private
  >    HW_Control : DISCRETE_HW_CONTROL;
  >    for HW_Control use at 16#4000_0001#;
  >  end Discretes;

  > Our compiler complains about the address clause, claiming that
  > HW_Control is not visible.  Looking at the language specification
  > I do see that address clauses are not included here.  What is
  > the rationale for this omission?

    Seems to work the way I read it.  The private part is a list of
protected_element_declarations.  A protected_element_declaration can
be a protected_operation_declaration.  A
protected_operation_declaration can be a representation_clause.  A
representation_clause can be an attribute definition_clause, which can
be FOR local_name'attribute USE expression.

    I think you are looking at a (not very surprising) compiler bug.
As a workaround you might try defining HW_Control inside Write and any
other operations you might add later.  Of course before reporting this
as a bug make sure you didn't misspell something.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Protected Types and Address Clauses

[Norman H. Cohen]

In article <4fqe6h$t0e@theopolis.orl.mmc.com>
rgilbert@unconfigured.xvnews.domain (Bob Gilbert) wrote: 

BG>  protected Discretes is
BG>    procedure Write(Settings : in SETTING_LIST);
BG>  private
BG>    HW_Control : DISCRETE_HW_CONTROL;
BG>    for HW_Control use at 16#4000_0001#;
BG>  end Discretes;
BG>
BG> Our compiler complains about the address clause, claiming that
BG> HW_Control is not visible.  Looking at the language specification
BG> I do see that address clauses are not included here.  What is
BG> the rationale for this omission?

In article <EACHUS.96Feb19154710@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) responded: 

RIE>     Seems to work the way I read it.  The private part is a list of
RIE> protected_element_declarations.  A protected_element_declaration can
RIE> be a protected_operation_declaration.  A
RIE> protected_operation_declaration can be a representation_clause.  A
RIE> representation_clause can be an attribute definition_clause, which can
RIE> be FOR local_name'attribute USE expression.

This just establishes that the syntax allows representation clauses in
the private part of a protected definition.  I agree with Robert's
conclusion that the RM appears (despite the intent of its authors) to
permit this address clause, but as the result of a more intricate
exegesis.  By J.7(2),

   for HW_Control use at 16#4000_0001#;

is equivalent to

   for HW_Control'Address use 16#4000_0001#;

13.3(10) says that this attribute is defined if HW_Control denotes an
object, program unit, or label.  In fact, HW_Control does denote an
object, because 3.3(12) states that a component of an object is an
object.  9.4(12) states, "The elaboration of a
single_protected_declaration also creates an object of an (anonymous)
protected type," so Discretes is an object, and we can infer from the
use of the syntactic term component_declaration, as well as from the
statement in 9.4(17) that a protected object includes component values,
that HW_Control is a component of that object.  (3.8(9) states that a
component_declaration in a record-type declaration declares a component
of the record type; 9.4 ought to have had an analogous explicit statement
that a component_declaration in a protected declaration declares a
component of a protected type.  However, despite the absence of an
explicit statement, nobody will seriously question that this is the
intent.)

Tucker Taft wrote in article <DMqJDp.BMH.0.-s@inmet.camb.inmet.com>: 

STT> Because you are declaring a "single protected object" rather than
STT> a protected *type* it would make sense to allow an address
STT> clause here.  However, single protected objects are considered
STT> just a short-hand for declaring a protected type, and then
STT> one instance thereof.  Because of that equivalence, address
STT> clauses aren't allowed for components of a protected type
STT> or object.  This would be equivalent to specifying the address
STT> of a component of a record type, which of course doesn't make
STT> sense presuming you will have multiple instances.

However, the language of the RM does not reflect Tuck's intent. 9.4(12)
states nothing about a single protected declaration being EQUIVALENT to a
protected type declaration for an anonymous type FOLLOWED BY a
declaration for an object of that type.  It states that elaboration of
the single protected declaration creates an anonymous type and "also
creates" an object of that type, apparently simultaneously.

RIE>     I think you are looking at a (not very surprising) compiler bug.

Or an RM bug.  The ARG will have to decide whether or not this should be
allowed.  On the other hand, the content of the error message that Bob
Gilbert reported, that HW_Control is not visible, is definitely wrong.
The address clause occurs in the same declarative region as the
declaration of HW_Control--the declarative region associated with the
protected declaration--so it is directly visible there.

RIE> As a workaround you might try defining HW_Control inside Write and any
RIE> other operations you might add later.

Or, as Tuck suggested, in the body of a package enclosing the protected
declaration.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Protected Types and Address Clauses

[Robert Dewar]

"BG>  protected Discretes is
BG>    procedure Write(Settings : in SETTING_LIST);
BG>  private
BG>    HW_Control : DISCRETE_HW_CONTROL;
BG>    for HW_Control use at 16#4000_0001#;
BG>  end Discretes;
BG>
BG> Our compiler complains about the address clause, claiming that
BG> HW_Control is not visible.  Looking at the language specification
BG> I do see that address clauses are not included here.  What is
BG> the rationale for this omission?"

It is obvious that this address clause should not be allowed, since it is
plainly meaningless (address clauses cannot apply to components in a 
meaningful way). I don't think the RM permits it, but if it does, then
the RM is plainly wrong.

If you declare a single protected object, it is fine to have an address
clause for the object, but not for its individual components.

Re: Protected Types and Address Clauses

[Keith Thompson]

In <4gcppr$10f5@watnews1.watson.ibm.com> ncohen@watson.ibm.com (Norman H. Cohen) writes:
> In article <4fqe6h$t0e@theopolis.orl.mmc.com>
> rgilbert@unconfigured.xvnews.domain (Bob Gilbert) wrote: 
> BG>  protected Discretes is
> BG>    procedure Write(Settings : in SETTING_LIST);
> BG>  private
> BG>    HW_Control : DISCRETE_HW_CONTROL;
> BG>    for HW_Control use at 16#4000_0001#;
> BG>  end Discretes;
[...]
> This just establishes that the syntax allows representation clauses in
> the private part of a protected definition.  I agree with Robert's
> conclusion that the RM appears (despite the intent of its authors) to
> permit this address clause, but as the result of a more intricate
> exegesis.  By J.7(2),
> 
>    for HW_Control use at 16#4000_0001#;
> 
> is equivalent to
> 
>    for HW_Control'Address use 16#4000_0001#;
> 
> 13.3(10) says that this attribute is defined if HW_Control denotes an
> object, program unit, or label.  In fact, HW_Control does denote an
> object, because 3.3(12) states that a component of an object is an
> object.
[...]

Yes, the 'Address attribute is defined for HW_Control; in fact you can
refer to HW_Control'Address from within the body of Discretes.Write.
That doesn't mean an address *clause* for HW_Control is legal.
RM95-13.3(12) says that

    Address may be specified for stand-alone objects and for program
    units via an attribute_definition_clause.

Since HW_Control is not a stand-alone object, an address clause for it
is not legal, any more than an address clause is legal for a label or
an array element.

(Incidentally, RM95-13.7(37) that System.Address should be private;
for implementations that follow this advice, 16#4000_0001# is not a
legal address.)

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As God is my witness, I thought turkeys could fly." -- Arthur Carlson, WKRP

Re: Protected Types and Address Clauses

[Robert I. Eachus]

In article <Dn44po.8ys@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes:

  > Yes, the 'Address attribute is defined for HW_Control; in fact you can
  > refer to HW_Control'Address from within the body of Discretes.Write.
  > That doesn't mean an address *clause* for HW_Control is legal.
  > RM95-13.3(12) says that

  >     Address may be specified for stand-alone objects and for program
  >     units via an attribute_definition_clause.

  > Since HW_Control is not a stand-alone object, an address clause for it
  > is not legal, any more than an address clause is legal for a label or
  > an array element.

    Ah, but an address clause for Discretes should be legal, and in
fact it probably makes the most sense to put such an address clause
inside the protected object declaration.  (You could also put the same
declaration inside a protected type declaration, since at that
location the type name denotes the instance, but having more than one
object of that type at a time should always be erroneous.)

    However, locating the protected object may not be sufficient,
especially since there may be implementation specific data as part of
the object.  Does this mean you have to wrap the protected object in a
record and use a record representation clause?  Ugly, and still no
guarentee.  Best would be for implementations to either specify the
size of the implementation specific header, or to allocate the
implementation specific parts of a protected object after user
specified components.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Protected Types and Address Clauses

[Bob Gilbert]

A few days ago I posted a question on the above
subject and several others have since posted
responses.  However, many include parts of a 
response from Tucker Taft, of which the original
I have not seen. I even looked through the archives
of DejaNews and did not find it.  Could somebody
please be kind enough to repost or e-mail me 
Tucker's response.

Thanks,
   Bob Gilbert
##################################################################
#              Lockheed Martin Electronics & Missiles            #
#              Attn: Bob Gilbert, Mail Point 183                 #
#              5600 Sand Lake Rd                                 #
#              Orlando, FL  32819-8907                           #
#                                                                #
# phone:(407)356-1905        e-mail:rgilbert@polaris.orl.mmc.com #
##################################################################

Re: Protected Types and Address Clauses

[Mark A Biggar]

In article <Dn5Mq1.Ewz@thomsoft.com> kst@thomsoft.com (Keith Thompson) writes:
>In <dewar.824905563@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>[...]
>> If you declare a single protected object, it is fine to have an address
>> clause for the object, but not for its individual components.
>Such an address clause is unlikely to do you much good, though, unless
>you know exactly how the implementation lays out the components of a
>protected object.  I presume that many implementations will put the
>implementation-defined implicit components common to all protected
>types at the beginning of the object (for more efficient addressing),
>so user-declared components are likely to be at a substantial offset.
>If you need to have an object of a particular type at a specified
>address with the kind of protection offered by protected types, you'll
>probably need to use Tucker Taft's suggested work-around of moving the
>data declarations into the package body surrounding the protected body.

That's not a work around, it is the necessity and proper implementation
method in almost all cases.  Even if you could figure out the layout
of the protected object and could give it an address clause that put
the one special component at the proper address for the hardware memory
mapped register, it is highly unlikely that the surrounding addresses
are anything other then other memory mapped registers or other non-normal
memory.  Thus having the special component outside of the PO is the only
proper way to handle this situation.  Note that the special variable
doesn't have to be visible to the users of the protected object, it
only need to be visible to the body of the PO and so can be hidden in
the same place the PO body is hidden.

--
Mark Biggar
mab@wdl.loral.com

Re: Protected Types and Address Clauses

[Keith Thompson]

In <dewar.824905563@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
[...]
> If you declare a single protected object, it is fine to have an address
> clause for the object, but not for its individual components.

Such an address clause is unlikely to do you much good, though, unless
you know exactly how the implementation lays out the components of a
protected object.  I presume that many implementations will put the
implementation-defined implicit components common to all protected
types at the beginning of the object (for more efficient addressing),
so user-declared components are likely to be at a substantial offset.

If you need to have an object of a particular type at a specified
address with the kind of protection offered by protected types, you'll
probably need to use Tucker Taft's suggested work-around of moving the
data declarations into the package body surrounding the protected body.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
"As God is my witness, I thought turkeys could fly." -- Arthur Carlson, WKRP

Re: Protected Types and Address Clauses

[Robert A Duff]

In article <4gi71p$94s@wdl1.wdl.loral.com>,
Mark A Biggar <mab@dst17.wdl.loral.com> wrote:
>That's not a work around, it is the necessity and proper implementation
>method in almost all cases.

I agree it's not a workaround.  It's perfectly reasonable to use
protected objects to protect stuff that's not inside the protected
object.  This case (with the address clause) is one case where it
really can't be inside.  There are other cases.

I'm not sure what you mean by "in almost all cases".  I think it's
*usually* best to put the stuff being protected inside the protected
object.  I guess you mean, "in almost all cases where the thing being
protected needs to be located at a particular address".

One useful technique (probably not applicable in this case, but in
others) is to have a component of the protected object be a pointer to
the stuff being protected.  For example, the PO can have an access
discriminant:

    type Stuff is ...
    
    protected type P(S: access Stuff) is ...
    
    X: Stuff;
    
    PO1: P(S => X'Access); -- protect a pre-existing thing
    
    PO2: P(S => new Stuff'(...));

- Bob