* Re: Protected Types and Address Clauses [not found] <4fqe6h$t0e@theopolis.orl.mmc.com> @ 1996-02-19 0:00 ` Robert I. Eachus 1996-02-20 0:00 ` Norman H. Cohen 1996-02-21 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 9+ messages in thread From: Robert I. Eachus @ 1996-02-19 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-19 0:00 ` Protected Types and Address Clauses Robert I. Eachus @ 1996-02-20 0:00 ` Norman H. Cohen 1996-02-21 0:00 ` Keith Thompson 1996-02-21 0:00 ` Robert Dewar 1996-02-21 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 9+ messages in thread From: Norman H. Cohen @ 1996-02-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-20 0:00 ` Norman H. Cohen @ 1996-02-21 0:00 ` Keith Thompson 1996-02-21 0:00 ` Robert Dewar 1 sibling, 0 replies; 9+ messages in thread From: Keith Thompson @ 1996-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-20 0:00 ` Norman H. Cohen 1996-02-21 0:00 ` Keith Thompson @ 1996-02-21 0:00 ` Robert Dewar 1996-02-22 0:00 ` Keith Thompson 1 sibling, 1 reply; 9+ messages in thread From: Robert Dewar @ 1996-02-21 0:00 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-21 0:00 ` Robert Dewar @ 1996-02-22 0:00 ` Keith Thompson 1996-02-22 0:00 ` Mark A Biggar 0 siblings, 1 reply; 9+ messages in thread From: Keith Thompson @ 1996-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-22 0:00 ` Keith Thompson @ 1996-02-22 0:00 ` Mark A Biggar 1996-02-23 0:00 ` Robert A Duff 0 siblings, 1 reply; 9+ messages in thread From: Mark A Biggar @ 1996-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-22 0:00 ` Mark A Biggar @ 1996-02-23 0:00 ` Robert A Duff 0 siblings, 0 replies; 9+ messages in thread From: Robert A Duff @ 1996-02-23 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Protected Types and Address Clauses 1996-02-19 0:00 ` Protected Types and Address Clauses Robert I. Eachus 1996-02-20 0:00 ` Norman H. Cohen @ 1996-02-21 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 9+ messages in thread From: Robert I. Eachus @ 1996-02-21 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <DMrJAC.788@thomsoft.com>]
* Re: Protected Types and Address Clauses [not found] <DMrJAC.788@thomsoft.com> @ 1996-02-21 0:00 ` Bob Gilbert 0 siblings, 0 replies; 9+ messages in thread From: Bob Gilbert @ 1996-02-21 0:00 UTC (permalink / raw) 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 # ################################################################## ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~1996-02-23 0:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <4fqe6h$t0e@theopolis.orl.mmc.com> 1996-02-19 0:00 ` Protected Types and Address Clauses Robert I. Eachus 1996-02-20 0:00 ` Norman H. Cohen 1996-02-21 0:00 ` Keith Thompson 1996-02-21 0:00 ` Robert Dewar 1996-02-22 0:00 ` Keith Thompson 1996-02-22 0:00 ` Mark A Biggar 1996-02-23 0:00 ` Robert A Duff 1996-02-21 0:00 ` Robert I. Eachus [not found] <DMrJAC.788@thomsoft.com> 1996-02-21 0:00 ` Bob Gilbert
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox