Path: utzoo!mnetor!uunet!lll-winken!lll-tis!oodis01!uplherc!sp7040!obie!wes
From: wes@obie.UUCP (Barnacle Wes)
Newsgroups: comp.lang.c
Subject: Re: optimization (was Re: volatile)
Message-ID: <174@obie.UUCP>
Date: 24 Apr 88 20:50:21 GMT
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <20065@think.UUCP>
Organization: the Well of Souls
Lines: 34
Summary: Whoops, that one can bite you, too!

In article <20065@think.UUCP>, barmar@think.COM (Barry Margolin) writes:
> This is unreasonable, and probably rules out almost all optimizations
> but the simplest peephole optimizations, and even some of them.
> Consider the statements
> 
> 	a = b;
> 	a = b;
> 
> It doesn't take much of a flow analysis to determine that the second
> statement is redundant.  Most peephole optimizers will hack this.
> 
> But my main objection to your blanket statement above is that it
> requires code that ACCIDENTALLY works when unoptimized to continue
> working when optimized.

Aha!  But this code is not always redundant!  I have worked on a
system (admittedly a WEIRD system) that had a particular I/O device
with a 16-bit status register hung off an 8-bit bus.  You accessed the
register by two sucessive reads of the register address, getting the
high byte first and the low byte second.  Guess what?  We never used
any of the bits in the high byte!  So our code basically looked
something like:

	mdmstatus: byte @ address;
	status: word;

	status := word;		! discard first byte
	status := word;		! get second byte
	if (status AND H0020) .....

-- 
    /\              -  "Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!uplherc!
  /    \/ \/\/  \   -   Contend in Vain."   -   sp7040!obie!
 / U i n T e c h \  -       Schiller        -        wes