🚀 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

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.

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.