🚀 go-pugleaf

In article <B_WAUIB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>In article <3924@inews.intel.com> bhoughto@pima.intel.com (Blair P. Houghton) writes:
>> If the compiler's smart
>> enough to understand that the "side effect [of a ref. to a
>> volatile object] is not needed" and the value is not used,
>> then the evaluation can be elided.
>
>I'd hate to have to write a device driver with that compiler, mate.
>A compiler that sharp can cut you.

I'd _love_ to have a compiler that knows all about
my new, still-in-the-box devices' needs.

YADDPG: Yet Another Device Driver Program Generator.

It'd sure cut down on hand-packing arrays...

:-)

No, seriously, I doubt very much that accessing a
previously undefined location would be something this
whiffy-compiler could optimize out.

One common one, though, might be if a compiler
eliminated the setting of `a' and the call to free() in

    void foo()
    {
	volatile char *a;

	free(a=0);
	exit(0);
    }

Since you're setting `a' -- creating a side-effect -- the
implementation must arrange that the machinery not alter
`a' -- create another side-effect -- before the call to
free(); hence, free() is guaranteed to be called with
argument (char *)0, a null pointer, and thus is defined to
have no effect.

Here it's obvious that foo() is synonymous with `{volatile
char *a=0;exit();}' if the compiler believes it, the
the call to free() may, obviously, be removed.

If it can also determine that assigning 0 to `a' is
irrelevant to the machinery, the declaration and assignment
may also be removed.

exit() will never get removed, although the call to foo()
(in the calling routine) may be turned into a call to exit(0),
again if the implementation is on its toes and it doesn't
materially change the effect in the calling routine.

Any optimization you can do by hand can be done by a compiler.

>So you're volatile too?

Some call it "temperamental."

				--Blair
				  "Some call it 'viscous...'"