preece%mycroft@gswd-vms.arpa (04/02/87)
bcase@amdcad.uu: > This brings up one of my major beefs abouts complex archtiectures: an > optimizing compiler might have to do different things depending upon the > *version* of a CPU it is compiling for! An optimizing compiler that is > considered "a great compiler" for one version of a CPU might be "a > mediocre" compiler for the next version of the machine. The compiler > writer found out that some obvious sequences of code are not the best > for the current version of the machine, but then the implementors of the > next version "fake him out" by changing the relative timings of the > instructions (and take note of the fact that determining instruction > timings for some machines, e.g. VAXs, is near impossible since DEC just > won't tell you. This makes superior code generation a nightmare). ---------- This is only a reasonable complint if you have too naively accepted the promise of compatibility between versions. If you (sensibly) recognize that different machines are different machines, even if they are advertised as siblings, you allocate the cost of the compiler modifications as part of your development costs and you have your compiler writer find clever sequences for the new machine, just as she did for the old one. Conde generation techniques that are based on machine descriptions help, too; though it can be very difficult to describe architectural differences adequately for porting between families, compilers based on machine descriptions should be relatively well adjusted to changes in instruction costs. The problem with asking for instruction costs, though, is that they are very hard to present adequately as human-readable documents. The time to execute an instruction depends on whether the arguments are cached or not, whether the pipeline gets locked by a dependency, whether branches are predicted correctly, and many other factors. It is just not reasonable to ask that this be boiled down to one number that you can use in your compiler. > 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. ---------- 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. -- scott preece gould/csd - urbana uucp: ihnp4!uiucdcs!ccvaxa!preece arpa: preece@gswd-vms