Date: Tue, 22 Jun 1999 12:04:12 -0400 (EDT) From: Aaron Grosky <agrosky@wgate.com> To: Richard Cownie <tich@ma.ikos.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP, 4GB RAM, 4x CPU Message-ID: <Pine.BSF.3.96.990622114742.24956X-100000@dadu.eng.tvol.net> In-Reply-To: <99062211111300.27479@par28.ma.ikos.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Jun 1999, Richard Cownie wrote: > On Mon, 21 Jun 1999, Terry Lambert wrote: > > DEC (used to; haven't checked lately) have instruction scheduling > > code up for download on gatekeeper.dec.com. From memory, running > > it as an assembler preprocessor was pretty trivial. Of course, > > DEC may have advanced the technology without posting new code, so > > YMMV... > > To expose enough parallelism to get a good instruction schedule, > you probably need to do a lot of stuff earlier in the compilation, > e.g. loop unrolling, traversing the expression tree in a different > order for code-generation/register-allocation. In particular, > once the register allocation is cast in stone you don't have very > much freedom to re-order instructions. So I doubt that the > assembler pre-processor makes a big difference - if you want > good performance from the Alpha (and why else would you want > an Alpha ?) the DEC compiler is probably the only game in town. > > Unless anyone's tried the assembler scheduler and has figures to > suggest otherwise ? > > I notice that egcs (soon to be gcc-2.95) has a bunch of new > instruction-scheduling stuff, maybe this will do better than the > old gcc. '70s and early '80s vintage C compilers used an assembler optimizer step (input was ASCII assembly language, output was ASCII assembly language). This optimizer was able to reassign registers and rearrange code to achieve better use of registers and remove redundant memory accesses. Such an optimizer could be used to optimize RISC code (and ever *86 code), or analysis of this sort could even be build into the assembler (though then it would no longer be an assembler). In saying this, I do not disagree with Richard that doing the analysis earlier cannot achieve better optimization. I only point out that assigning the registers does not prevent major code movement nor register reassignment. Aaron Grosky agrosky@wgate.com WorldGate Communications "Internet TV Over Cable" 3220 Tillman Drive 215-633-5125 Bensalem, PA 19020 215-633-9590 (FAX) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990622114742.24956X-100000>