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