quest for breakthroughs (long)

[Herman Rubin]

In article <730 at microsoft.UUCP>, w-colinp at microsoft.UUCP (Colin Plumb) writes:
> csimmons at oracle.UUCP (Charles Simmons) wrote:
> > [The desired code was]:
> > 
> > 	nor $temp, $a, $b
> > 	and $c, $c, $temp
> > 
> > The actual code generated [by the MIPS compiler] was:
> > 
> > 	or $temp, $a, $b
> > 	nor $temp, $temp, $0
> > 	and $c, $c, $temp
> > 
> > Since the 'nor' instruction doesn't directly map into the C language,
> > I didn't really expect the compiler to handle this minor special case.)
> 
> Really?  I do.  Since the sequence "or $c, $a, $b; not $c, $c" is
> exactly equivalent to "nor $c, $a, $b" and easily recognised by a
> peephole optimiser.  If the code generator frequently uses extra
> temporary registers (say the first sequence ends in "not $d, $c"),
> you have to complicate this by checking to see if $c is dead after
> this point, but I expect MIPS have already fixed this.

There is no question that in some cases a peephole optimizer can catch
things like this.  But this requires that someone has anticipated the
problem and built it into the optimizer.  And how big is the peephole?

This is a point that I have been bringing up for a long time.  The 
language gurus are not aware of the hardware, and the "natural hardware,"
instuctions that Charles and I want to use.  At least they do not seem
to be.  Now if I give you a complete list of such instructions today,
the list may not be complete tomorrow.  So you should provide a way
for me to add this to the language, and communicate the necessary infor-
mation to the compiler.

I remind you that I have no difficulty with machine instructions on a
wide variety of machines, and a new machine is, for me, easier than a
new language.  I have difficulty with the clumsy assembler languages;
I understand how they got to be that way, and the advantages FOR THE
ASSEMBLER to having them that way.  I understand and appreciate the
advantages of the HLLs, and their drawbacks.

Possibly part of the solution can be done by having the intermediate
code available to the programmer, and allowing the editing of it.  This
is generally not the case, and the intermediate code is rarely documented.
> Well, guys?  Have you? :-)
> -- 
> 	-Colin (uunet!microsoft!w-colinp)
> 
> "Don't listen to me.  I never do."


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (Internet, bitnet, UUCP)