mash@mips.COM (John Mashey) (06/26/88)
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: <generic disclaimer, I speak for me only, etc> 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
smryan@garth.UUCP (Steven Ryan) (06/28/88)
>This opinion runs contrary to a considerable body of experience that >supports the use of assemblers that perform certain classes of optimizations. Presumably, this body of experience is based on running code through a parser and then using an assembler to do the dirty bits. Other compilers do the entire translation from source program to binary object file. > the assembler needs the >directive that turns sdi optimization off and on around this >1) an assembler can know a fair amount without any help: > c) Pointer-relative variables that have different offsets > ( 4(r2), 8(r2)) are different. It is hard for an assembler to know if loads/stores off of different base registers interfere without knowing what region the base register points to (this is something the compiler knows). >2) Some things are only known by the compilers, and they can well have >directives to pass that information along. I suppose inside an optimising assembler is a small assembler struggling to get out. Once all these declarations (a directive by any other name) are added, it is still an assembler or just a very low level machine dependent language? There is a time and place for really stupid software. Somewhere somebody has to lookup opcodes and find a binary equivalent, and to translate symbolic addresses into real addresses. Why not call an optimiser an optimiser and assembler an assembler?