aglew%mycroft@gswd-vms.arpa (04/02/87)
>>[bcase @ AMD]: >> One of the reasons that simple architectures are better for compilers is >> that (nearly) all instructions take the same amount of time and space. >> Thus, code generation and optimization are *much* easier. Also, this >> relationship of one time unit/one space unit per instruction is unlikely >> to change as a function of CPU version. >[scott preece @ Gould]: >There's no great advantage to simplifying your compiler's job if all >that means is that it produces equivalently bad performance on all the >machines in your product line. Bullshit! There's such a thing as dependable performance. With a variety of complicated machines in the same family, you really have no idea of how good the compiler is. If the machines are simple, you can come much closer to an absolute measure of compiler quality. Andy "Krazy" Glew. Gould CSD-Urbana. USEnet: ihnp4!uiucdcs!ccvaxa!aglew 1101 E. University, Urbana, IL 61801 ARPAnet: aglew@gswd-vms.arpa
preece%mycroft@gswd-vms.arpa (04/03/87)
aglew%mycroft@gswd-vms: > >[scott preece @ Gould]: > >There's no great advantage to simplifying your compiler's job if all > >that means is that it produces equivalently bad performance on all the > >machines in your product line. > > Bullshit! There's such a thing as dependable performance. With a > variety of complicated machines in the same family, you really have no > idea of how good the compiler is. If the machines are simple, you can > come much closer to an absolute measure of compiler quality. > ---------- Relatively few customers are in the business of comparative compiler evaluation. Many customers are in the business of executing code as quickly as possible. If simplifying your architecture means that some important function inherently takes longer, you lose. Regardless of the efficiency or effectiveness of your compiler. Making life easier for compiler writers is not the ultimate goal of the computer industry, even though it may have some benefits. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms
prakash@clunker.UUCP (04/03/87)
In article <6667@brl-adm.ARPA> aglew%mycroft@gswd-vms.arpa (Andy Glew) writes: >>>[bcase @ AMD]: >>> One of the reasons that simple architectures are better for compilers is >>> that (nearly) all instructions take the same amount of time and space. >>> Thus, code generation and optimization are *much* easier. Also, this >>> relationship of one time unit/one space unit per instruction is unlikely >>> to change as a function of CPU version. > >>[scott preece @ Gould]: >>There's no great advantage to simplifying your compiler's job if all >>that means is that it produces equivalently bad performance on all the >>machines in your product line. > >Bullshit! There's such a thing as dependable performance. With a >variety of complicated machines in the same family, you really have no >idea of how good the compiler is. If the machines are simple, you can >come much closer to an absolute measure of compiler quality. Such Language!! I think the most relevant way to deal with the disagreement is to come to some common agreement as to the purpose of an architecture. To my mind Andy has missed the head of the nail completely and Scott has struck a barely glancing blow: Is the purpose of an architecture to simplify the design and speed up the operation of compilers??? Or perhaps it should speed up (and maybe simplify) application programs? The purpose of a compiler is to produce executable code which acts as described in the higher level language it compiles. One purpose of a Code-improver or code-improving (so-called optimizing) compiler is to take advantage of quirks in the architecture to somehow improve the code. For The Record: I think the architecture should be designed primarily with the goal of improving the performance of APPLICATIONS. Oh I'm sorry my compiler doesn't work well -- it's the hardware. -- "Once on a road through distant lands, |David Zink - I met a flower with only three names; | Bunker Ramo/Olivetti, Though I never saw her again, | Shelton, CT - (203)337-1622 I think often of her tender blossoms. | uucp address: ...{decvax,philabs,yale}!bunker!zink
preece%mycroft@gswd-vms.arpa (04/05/87)
prakash@clunker.u: > Such Language!! I think the most relevant way to deal with the > disagreement is to come to some common agreement as to the purpose of an > architecture. To my mind Andy has missed the head of the nail > completely and Scott has struck a barely glancing blow: > Is the purpose of an architecture to simplify the design and speed > up the operation of compilers??? Or perhaps it should speed up (and maybe > simplify) application programs? ---------- Well, I think that was what I was trying to say. On the other hand, the notion that simplifying compiler writing is a way to improve system performance is not all that silly, either. Andy (who is about as much more reasonable than he likes to appear as I am less reasonable than I like to appear, and whose desk is about sixteen feet from mine, if you can walk through walls) believes that the way to improve applications performance is to make it easier for tools to squeeze every ounce out of the architecture and to make hardware that does what it does as fast as possible, by avoiding design compromises favoring special instructions. I tend to think that complex instructions can, if sufficiently well designed in advance and sufficiently well used by the compiler, buy enough extra performance to make the extra compiler writing effort and the waste in sometimes NOT being able to automatically get out the last drop worthwhile. I think each of us can postulate applications that demonstrate our beliefs and I think that each of us would accept the statement that compiler technology is not yet strong enough to prove either. If there were a clear answer, the debate wouldn't be fun. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms