cik@l.cc.purdue.edu (Herman Rubin) (02/25/89)
In article <730@microsoft.UUCP>, w-colinp@microsoft.UUCP (Colin Plumb) writes: > csimmons@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@l.cc.purdue.edu (Internet, bitnet, UUCP)