Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ivv1!hobbit!ge
From: ge@hobbit.sci.kun.nl (Ge' Weijers)
Newsgroups: comp.arch
Subject: Re: The VAX Always Uses Fewer Instructions
Summary: DON'T use a C-optimiser for assembly source
Message-ID: <292@hobbit.sci.kun.nl>
Date: 7 Jul 88 07:45:29 GMT
References: <6921@cit-vax.Caltech.Edu> <28200161@urbsdc> <10595@sol.ARPA> <140@vertical.oz>
Organization: University of Nijmegen, The Netherlands.
Lines: 24

In article <140@vertical.oz>, greg@vertical.oz (Greg Bond) writes:
) In article <810@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
) >>As you pointed out, there is a need for optimizing assemblers.
) >Strong disagreement--an assembler should be safe, simple, and dumb. If you
) >want an optimiser, use a compiler.
) >What is preferable is separate layer to do the optimisation. The problem with
) 
) In fact, use the "optimisation" pass from your favourite C compiler.
) This is tough to organise on most Unix boxes, but goes great on the
) 8086 X-compiler we have here.  The optimiser is a separate assembler-assembler
) processor.  I can't see where its orientation as a C optimiser would kill
) semantics of assembler code.  But then, it may not be a real clever
) optimiser either (for the general case).

Watch out for C optimisers. They usually assume things about their input
(register usage, Rx = frame pointer, etc) that are just NOT true for
hand-written assembly language. A case in point: see the manual of the
assembler for the Sun-4. It has an optimiser, but you are strongly advised
not to use it. 

Ge' Weijers, mcvax!kunivv1!hobbit!ge
-- 
Ge' Weijers, Informatics dept., Nijmegen University, the Netherlands
UUCP: {uunet!,}mcvax!kunivv1!hobbit!ge