kurt@fluke.UUCP (Kurt Guntheroth) (05/21/85)
Doug Pardee must be a user. As a potential compiler writer I must make some
comment.
Of course the reason computers exist is to run programs. Dumb point.
Of course it doesn't matter at the application level if the machine is
orthogonal or not. Right? Wrong Doug.
Doug, do you like it when the compiler produces slow or buggy code? Of
course you don't. Even a 'user' should understand the utility of fast
reliable code. And this is what makes CPU orthogonality so important.
If a company has X man-months to spend developing a compiler, they can
spend it in a variety of ways. They can spend their time screwing with
a braindamaged machine language trying to generate any code at all, or
they can go on to silly little things like optimization and testing if
the instruction set does not get in the way. Or, they can just double
or triple the design time and charge it to 'users'.
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtchuqui@nsc.UUCP (Chuq Von Rospach) (05/23/85)
In article <639@vax2.fluke.UUCP> kurt@fluke.UUCP (Kurt Guntheroth) writes: >Of course the reason computers exist is to run programs. Dumb point. Suprisingly, sometimes people forget this thought. Everyone who has ported Un*x to a new piece of hardware without thinking about what it was going to be used for when it was done, please raise their hands. Using the new hardware as a porting vehicle for a new piece of hardware doesn't count. (You could call that a pyramid scheme, but certain hardware manufacturers might get upset... *grin*) >If a company has X man-months to spend developing a compiler, they can >spend it in a variety of ways. They can spend their time screwing with >a braindamaged machine language trying to generate any code at all, or >they can go on to silly little things like optimization and testing if >the instruction set does not get in the way. Or, they can just double >or triple the design time and charge it to 'users'. The case can be even worse than this. The more complex the chip, the more silicon you have. The more microcode you have. The more decoding logic you have. It takes longer to get to market, harder to get right, and slower to get things processed. If you have a nice orthogonal architecture, the compiler writer can use these wonderful whizbang instructions and get amazing performance and code densities. If they aren't done right, the compiler writer has two choices -- they spend months writing special case code to use the instructions or they (almost invariably) subset the chip and use the simpler instructions that they CAN write a decent compiler for. The only people who get the advantage of the full instruction set is the assembler programmer. Subsetting the chip has a number of hidden costs. If we created the chip using only the instructions the compiler needed, we could use less logic. We could decode the instructions faster because the microcode is simpler (more ooomph per MHz), production is simpler, yield is higher, speeds are faster, and everyone is happy except the assembler programmer. To some degree, everyone ends up paying for the bells and whistles of the assembly language unless the compiler is good enough to take advantage of them. Most of them I've seen aren't, unfortunately, because the assembly language isn't clean enough to make it worthwhile. This is the concept behind the RISC architecture, in case you hadn't caught on. The realizations that (1) most compilers subset and (2) very little code is now done in assembler bring forward the thought that if you built the chip with only what the compiler needs, you can make a really fast chip and you can do it a lot easier than a more complex chip. People who really, truly, honestly need assembler can still do things in a RISC environment, but they can't be quite as elegant (which actually might improve the code quality of a lot of assembler I've seen... *grin*). It'll be interesting to see if the RISC work proves out its potentials... -- :From the offices of Pagans for Cthulhu: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Who shall forgive the unrepentant?