Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!amdahl!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: The VAX Always Uses Fewer Instructions [really: optimizing asms] Message-ID: <2468@winchester.mips.COM> Date: 26 Jun 88 16:16:34 GMT References: <6921@cit-vax.Caltech.Edu> <28200161@urbsdc> <10595@sol.ARPA> <270@laic.UUCP> <20424@beta.lanl.gov> <810@garth.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 54 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. This opinion runs contrary to a considerable body of experience that supports the use of assemblers that perform certain classes of optimizations. 1) The AT&T assemblers (and others) have done span-dependent branch optimizations for years. I don't remember the numbers; I do remember most people thought they were useful. 2) Many code-selection issues (such as multiply by constant) are conveniently left for the assembler: a) The facility is available to humans, as well as compilers. b) The compilers are slightly simplified. c) Sometimes, less data need be transmitted from compiler->assembler. These are not major things, and if they caused structural problems, I'd argue the other way, but as it happens, the partioning "feels good" and works well to handle certain problems in the assembler. 3) In any case, any assembler that does things to the code needs directives to turn them off; if for nothing else than design verification tests. >What is preferable is separate layer to do the optimisation. The problem with >an assembler is that it knows very little. Consider an assembler which replaces >a long branch with a different short branch. What if it occurs in a switch? > goto next + index > goto a > ... > goto z If the compiler actually generates switch code this way (depending on architecture, it might or might not), then the assembler needs the directive that turns sdi optimization off and on around this >Also, to properly schedule requires moving code past loads and stores. How >can an assembler safely and generally determine what the target of memory >reference is? 1) an assembler can know a fair amount without any help: a) Any two static variables have different addresses. b) Static varaibles and stack-relative variables have different addresses. c) Pointer-relative variables that have different offsets ( 4(r2), 8(r2)) are different. d) and perhaps others, depending on the system. 2) Some things are only known by the compilers, and they can well have directives to pass that information along. One can argue exactly what the best partitioning is here. -- -john mashey DISCLAIMER:UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086