🚀 go-pugleaf

In article <23868@winchester.mips.COM> mash@mips.COM (John Mashey) writes:

>How about publishing some data on the size and complexity of the
>peephole for the 68K and the code reorderer for the 88K?
>This would seem to be a useful data point, esp. if the rest of the
>compiler system is similar.  Also, estimates of staff-weeks to do this
>would be really nice, to help start building an element of quantitative
>data into this ongoing discussion.

Well, here's a data point, though for an IBM/RT.
In an experimental FORTRAN compiler,
I do instruction selection and choice of addressing modes
via peephole optimization (ala Fraser and Davidson).
The code is pretty simple and short, less than 250 lines of C.
For the integer portion of the machine, there are only about 70 patterns.
These give complete coverage of the (very limited) instruction set.
For the floating point portion, I have more than 200 patterns,
evenly split between single and double precision.
However, these cover only a fraction of the available addressing
mode combinations.

I do code scheduling  before and after register allocation,
using the scheme of Gibbons and Muchnik (Sigplan 86).
I found it significantly more difficult to program,
at least to achieve good space and time performance.
The code size is less than 450 lines of C.

Unfortunately, I can't give you good guesses about the
development time.  Less than two years of grad student labor though!

A version for the 68K would avoid the scheduling problems,
but the number of peephole patterns needed for complete
coverage of the instruction set would be prohibitive.
(millions).  Fraser and Davidson would either use a
table-driven interpreter to get complete coverage,
or use a large set of test programs and select a
useful subset of the available pattterns.
These schemes, seperately or together, would however
be more difficult to program.

Preston