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