🚀 go-pugleaf

In article <1989Jul9.202858.27121@jarvis.csri.toronto.edu> norvell@csri.toronto.edu (Theodore Stevens Norvell) writes:
>
>But the choice of instructions is not the hard part of instruction selection
>(on a CISC).  There is also the choice of address modes.

Valid point but that's only one side of the coin. Indeed our 68K compiler has 
extra templates for recognizing the more complex trees (actually called 'shapes'
for you pcc2 fans) that some addressing modes require.  However, our 88K 
compiler template file has become just as large as that of the 68K compiler 
because it requires extra templates to catch several special cases of 3 
register operand possibilities that are missed with the simple classic stock 
templates one would create for a base 88K machine. We found it rather
fascinating that the template files for the two machines are almost the same 
size.

>compiling the C statement   i = *p ;  where i and p are both memory (not
>register) variables.  Do you:
>	(A) Emit a move using an indirect address mode.
>	(B) load p and do a memory to memory move
>	(C) load *p with an indirect address mode and store i
>	(D) load p, load *p and then store i
> [...]
>In other words, even in a simple assignment statement, there are phase ordering
>problems between instruction selection and, optimization, register allocation
>and scheduling.

You are correct. But then the 68K compiler doesn't have the massive headache
of trying to support data addressability segment registers because of the RISC
inability to directly access an item with a full 32-bit address. Both are
massive headaches, which gets back to my original point some postings ago
that I don't see one architecture having a big advantage over the other when
it comes to purely 'amount-of-work-to-build-a-compiler' issues.

>
>Mr. Trissel's group seem to have solved this phase ordering problem by
>putting some of the address mode selection into a peephole optimizer.  
>This seems reasonable, but it moves the complexity to the peephole optimizer.

Correct again.  But once you figure in the amount of work that a RISC compiler
(or it's assembler) requires for code reordering [and for some non-Motorola 
RISCs the pipeline interlock worries -> :-)] is RISC really ahead in the amount
of work required? 

>>>To make matters worse, instruction selection is context sensitive.
>>>This means that different code ordering during optimization could
>>>invalidate the instruction selection choice (or, at least make the
>>>selected instructions sub-optimal).
>>
>>True for both RISC and CISC. No difference.
>
>The difference is that if there is only one good way to select the
>instructions (as is more often true on a RISC than a CISC), then there
>is no phase ordering problem, You simply select the instructions first
>with no fear of picking a sequence that screws up the register allocation
>or scheduling.  Not because it won't, but because there probably wasn't
>another sequence that would have been better.

But it seems to me that once you take into consideration the requirement that
a RISC compiler has to support code reorder scheduling to produce decent
output then the code reorderer must be every bit as complex as a 68K peephole 
optimizer (for example.) A reorderer has to keep up with live/dead 
registers, operand use/defines, have the knowledge of what can be swapped 
around to where etc. which is even more complex in many respects than what 
my 68K peephole is required to do.

-- Dave Trissel   Motorola Austin