Re: Object code optimization - really slow compiler

>[My understanding of the PL.8 compiler from IBM is that first it compiles
>into an extremely low-level intermediate code, second it does machine
>independent optimizations such as common subexpression and loop invariant
>removal, and then it does register assignment and instruction selection.
>The intermediate code has an infinite number of registers and very simple
>operations, so that real machine instructions usually subsume several
>intermediate instructions. I don't know how they deal with giving hints to
>the intermediate code generator so that it can use fancy real machine
>instructions, but this was part of the 801 RISC project which had a machine
>with very few "clever" instructions. They get superb code, but the
>compiler is so slow that I gather nothing less than a 370/168 will do.
>-John]


My understanding is that a 370/168 is only about 2.5 MIPS (370, not 801),
and that the major performance problem with the PL.8 compiler was its
profligate use of virtual memory, i.e. it thrashes with less than 8-12Mbyte
all to itself (or some such silly number)...anyway, we have 3090's now...


Oh, yeah, the same compiler generated 370 code...maybe even BXLE's
(probably no EDMK however :-)


Disclaimer: I haven't anything to do with the 801 folk here, indeed my
group could be construed to be anti-801, we work on making 370's fast,
but keeping them 370's. And of course IBM hasn't authorized me to say
anyth mmph..mmph...


Josh Knight, IBM T.J. Watson Research
        josh at YKTVMH on BITNET, josh.@ibm-sj.arpa
        ...!philabs!polaris!josh
--
John Levine, Javelin Software, Cambridge MA +1 617 494 1400
{ decvax | harvard | think | ihnp4 | cbosgd }!ima!johnl, Levine@YALE.ARPA


The opinions above are solely those of a 12 year old hacker who has broken
into my account, and not those of my employer or any other organization.

Return to the comp.compilers page.
Search the comp.compilers archives again.