Date: Tue, 22 Jun 1999 19:00:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: agrosky@wgate.com Cc: tich@ma.ikos.com, freebsd-smp@FreeBSD.ORG Subject: Re: SMP, 4GB RAM, 4x CPU Message-ID: <199906221900.MAA26496@usr05.primenet.com> In-Reply-To: <Pine.BSF.3.96.990622114742.24956X-100000@dadu.eng.tvol.net> from "Aaron Grosky" at Jun 22, 99 12:04:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> '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). This is the stuff that was (is?) downloadable from gatekeeper. > 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. Definitely agreed. It's better to have the stuff in the compiler itself. However, the compiler needs knowledge of the architecture on which the code will run (task architexture, not processor) for this to be a real win at all. One thing that makes the assembler preprocessor stuff really dangerous these days is the default assumption of non-volatile for external references and register promotions. I think you would need a very, very large peephole in order to not break some of the ANSI C optimization assumptions. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199906221900.MAA26496>