garry@ithaca.uucp (Garry Wiegand) (02/21/91)
Tom Ngo writes: >ARM 7.1.6: [proposed] > > A const object of a type that does not have a constructor or a > destructor might be placed in readonly memory. The const parts of > any object that does have a constructor might be placed in > DISCARDABLE [write-once] memory unless the class contains any > ~const member function. Discardable memory is virtual memory that > is paged to disk only the first time it is faulted out after > construction. Thereafter, the effect of any write operation to > any const part of any such object is undefined. ARM 7.1.6: (original) A const object of a type that does not have a constructor or a destructor may be placed in readonly memory. Why in the world does the ARM have to get involved in all these implementation details?? It seems like a bad policy to be describing machinery rather than describing the language. Would it not suffice, in language terms, to say: A const object may be set or changed only during construction. At other times const objects may be cast to non-const, but the actual writing of such an object is still prohibited. The enforcement of this prohibition is implementation-dependent. Ie, const memory may or may not be hardware-readonly and/or "discardable" after construction. As is explained and depicted in the immediately- preceding example section in the ARM. Rationale: Readonly implementations should be encouraged, not prohibited ("a type that does not have a constructor or destructor may be placed in readonly memory" reads to me as a prohibition in the normal "constructed" case.) Readonly memory, properly implemented, doesn't hurt anything and ought to be encouraged - it helps find bugs, and in some cases it improves efficiency. Argument: Margaret/Bjarne justify the policy by saying "...since in most practical machine architectures memory cannot be made 'readonly' during program execution". This ain't true. VMS machines, for example, are not rare and VMS implemented 'memory protection fixups' during image startup years ago. The startup sequence loads initial values in, and then makes the proper op sys call to change the page protections/paging mechanism on the relevant group of pages to 'readonly'. Exactly what you'd want at least for static const C++ objects. (Dynamic const objects would require a small amount of additional trickiness, for efficiency - I'm thinking of a separate 'readonly heap', plus a certain bit of Vax magic for quickly temporarily getting privileged write-access to the pages.) Note 1: Writeability is required only during construction by the first paragraph of 7.1.6. So I can't see what the rationale was for bothering with the words "or a deconstructor" in the original quoted section. Have I missed something? Note 2: If the casting to non-const weren't allowed *at all*, then "the enforcement of this prohibition" would no longer have to be "implementation-dependent" - the compiler could handle it completely. If I understand C++. Yes, I know declaring any kind of cast to be unreasonable wouldn't be "C-like". Garry Wiegand --- Ithaca Software, Alameda, California ...!uunet!ithaca!garry, garry%ithaca.uucp@uunet.uu.net
brucec@phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) (02/22/91)
In article <1991Feb20.220900.7523@ithaca.uucp> garry@ithaca.uucp (Garry Wiegand) writes: > Why in the world does the ARM have to get involved in all these > implementation details?? It seems like a bad policy to be describing > machinery rather than describing the language. > > Would it not suffice, in language terms, to say: > > A const object may be set or changed only during construction. At > other times const objects may be cast to non-const, but the actual > writing of such an object is still prohibited. The enforcement of > this prohibition is implementation-dependent. > > Ie, const memory may or may not be hardware-readonly and/or "discardable" > after construction. As is explained and depicted in the immediately- > preceding example section in the ARM. > > Rationale: > Readonly implementations should be encouraged, not prohibited ("a > type that does not have a constructor or destructor may be placed in > readonly memory" reads to me as a prohibition in the normal > "constructed" case.) Readonly memory, properly implemented, doesn't > hurt anything and ought to be encouraged - it helps find bugs, > and in some cases it improves efficiency. As a developer of software tools for a company which employs several hundred embedded systems programmers (somewhat fewer than a company like AT&T), I disagree with the implication that readonly memory is only a convenience. For us it's a fact of life. There are many places in a program where we must be able to *guarantee* that a particular object can be burned into ROM, or we have to change our design. Currently, all that sort of handwaving is done literally by hand :-), that is we have to write code in contorted ways, at higher-than-optimal development cost, to ensure that things can go in the right places. This contortion is why C is so popular in embedded software (1/2 :-)). In fact I support very strongly some sort of statement in the standard which guarantees me some conditions in which I can be sure I can ROM an object. Otherwise I have to negotiate that separately with each compiler writer, probably getting a different solution and a different set of conditions from each. -- ------------------------------------------------------------------------ Speaker-to-managers, aka Bruce Cohen, Computer Research Lab email: brucec@tekchips.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077
rfg@NCD.COM (Ron Guilmette) (03/03/91)
In article <BRUCEC.91Feb21132333@phoebus.labs.tek.com> brucec@phoebus.labs.tek.com (Bruce Cohen;;50-662;LP=A;) writes: > >As a developer of software tools for a company which employs several >hundred embedded systems programmers (somewhat fewer than a company like >AT&T), I disagree with the implication that readonly memory is only a >convenience. For us it's a fact of life... That seems to be true around here also. >...In fact I support very strongly some sort of statement in the standard >which guarantees me some conditions in which I can be sure I can ROM an >object. Otherwise I have to negotiate that separately with each compiler >writer, probably getting a different solution and a different set of >conditions from each. Hummm... I'll bet you would like to see the data object called `array' in the following example be able to go into ROM. Interestingly, I think that the semantics currently defined for the initialization of local static objects might effectively prohibit such treatment. void foobar () { static const char array[] = "Hello world.\n"; // ... } This is probably not the best example I could have cooked up, but if you read the bottom half of page 92 in the ARM, you may see the problem that I'm getting at. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.
jimad@microsoft.UUCP (Jim ADCOCK) (03/05/91)
In article <4200@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: |Hummm... I'll bet you would like to see the data object called `array' in |the following example be able to go into ROM. Interestingly, I think |that the semantics currently defined for the initialization of local |static objects might effectively prohibit such treatment. | | void foobar () | { | static const char array[] = "Hello world.\n"; | | // ... | } | |This is probably not the best example I could have cooked up, but if you |read the bottom half of page 92 in the ARM, you may see the problem that |I'm getting at. I'm not sure I do. I don't see any problems with you example. Perhaps you can clarify? You seem to be concerned about how ROM initialization can occur the first time through foobar if the contents of array[] are held in ROM? Answer: none of the programmer's business how the implementation "causes" this to happen, as long as there is no way for the programmer to legally tell the difference. In this case, there is no legal way for a programmer to detect the exact moment that array[] is initialized, nor how, so an implementation is free to do as it chooses, including taking the "sneaky" approach of initializing array[] at compile time. This is quite different from the example on page 92, which could indeed prove difficult to implement s in ROM.
rfg@NCD.COM (Ron Guilmette) (03/10/91)
In article <71044@microsoft.UUCP+ jimad@microsoft.UUCP (Jim ADCOCK) writes: +In article <4200@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: +|Hummm... I'll bet you would like to see the data object called `array' in +|the following example be able to go into ROM. Interestingly, I think +|that the semantics currently defined for the initialization of local +|static objects might effectively prohibit such treatment. +| +| void foobar () +| { +| static const char array[] = "Hello world.\n"; +| +| // ... +| } +| +|This is probably not the best example I could have cooked up, but if you +|read the bottom half of page 92 in the ARM, you may see the problem that +|I'm getting at. + +I'm not sure I do. I don't see any problems with you example. +Perhaps you can clarify?... Well, perhaps my idle theorizing about how to ROM-ize a C++ program is a bit half-baked, but here goes... One possible approach to ROM-izing a C++ program would be to actually *run* the program until just before it is about to enter main() and then freeze the image of all of the code and all of the initialized (and const) file-scope objects at that instant in time and then burn the PROMS based upon that image. That way, if you had some class C (which required construction) and some file-scope object declaration like: const C c_object (9.9, "hello world"); The "initial" values for these could go into ROM also. Unfortunately, this scheme leaves out the example from my previous posting (shown above). Try to imagine the declaration of `array' being something like this instead: static const C local_c_object (9.9 "hello"); This will not have been "elaborated" at the "image freeze time" so you won't be able to put this particular object into ROM. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // New motto: If it ain't broke, try using a bigger hammer.