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: | toddpw@cco.caltech.edu (Todd P. Whitesel) |
Keywords: | assembler |
Organization: | California Institute of Technology, Pasadena |
References: | 93-02-128 |
Date: | Wed, 24 Feb 1993 09:31:22 GMT |
forrest@nobozo.CS.Berkeley.EDU (Jon Forrest) writes:
>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 quite agree with #1, because one fast way to get a new compiler up and
running is to have it push off a lot of tasks onto the assembler;
naturally you have to output assembly that will be accepted if this is
going to work.
However, #2 is a bit unreasonable for third party compiler writers. It
would require the very last stage of the compiler to duplicate the second
half of the local assembler; this is wasteful enough, but what really
gives it problems is trying to support multiple assemblers that accept
essentially the same syntax but have quite different ideas of how to
organize things. Sure, it would be nice, but it has a tendency to be
impractical in a multiplatform environment.
Todd Whitesel
toddpw @ cco.caltech.edu
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.