🚀 go-pugleaf

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