Related articles |
---|
Another Issue in Compiler Generated Assembly Code forrest@nobozo.CS.Berkeley.EDU (1993-02-23) |
Re: Another Issue in Compiler Generated Assembly Code toddpw@cco.caltech.edu (1993-02-24) |
Newsgroups: | comp.compilers |
From: | forrest@nobozo.CS.Berkeley.EDU (Jon Forrest) |
Keywords: | assembler, comment |
Organization: | University of California, Berkeley |
Date: | Tue, 23 Feb 1993 18:27:01 GMT |
Another issue for compiler writers to keep in mind is that if their
compiler produces assembly code, then it should 1) produce assembly code
that the assembler can actually assemble, and 2) produce assembly code
that, when assembled, is the same as the object code produced by the
compiler.
I used to work at one of the major database vendors in the VMS development
group. We found that the VMS C compiler didn't do either. #1 is obvious
since the compiler puts all kinds of listing information and other cruft
in the assembler output. But, by clever use of awk filters on Unix we were
able to get around this. What was worse was #2. The compiler would
generate floating point constants in the assembler that used the wrong
syntax so that the end result was different code than that produced by the
compiler.
To top it off, what was even worse than either of these was the admittedly
unofficial reaction of the C compiler engineers I described this to at a
DECUS meeting. They said that since the compiler obviously didn't produce
assembler code to be compiled that they didn't think that #2 was a bug or
even worth thinking about.
--
Jon Forrest WB6EDM forrest@cs.berkeley.edu 510-643-6764
[It's quite typical for compiler listings of assembler output not to be
legal assembler input. Compiler authors are rarely sympathetic to the
thought that you might massage their assembler and assemble the result --
after all, if it were possible to make the assembler output better, they
would already have done so. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.