Re: How about VLIW used as RISC?

Sander Vesik wrote:


> In comp.arch glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>>Ricardo Bugalho wrote:
>>>On Wed, 28 Apr 2004 15:33:26 -0400, Ron wrote:
>>
>>>>So what is your opinion?
(snip)


>>Out of order execution is needed in case the compiler generated the
>>instructions in the wrong order (as needed by the processor).


> No. Out of order excution allows you to tackle cases where the best
> order is unknowable before runtime including cases where the best
> order chnages on everyloop iteration that simply cannot be addressed
> by a compiler. It also allows you to work around binary compatibility
> between processors and not being able to arbitrarily add new
> registers, more predicates and non-blocking loads / stores and have
> old software take advantage of such.


Binary compatibility I consider later. Assume that the compiler has
all the details of the target processor. Yes, it isn't convenient,
but I think it is necessary for this discussion.


>>On the other hand, the idea of an architecture independent of the
>>implementation only makes sense if you can compile without knowing the
>>specific implementation.


>>(Remember that machines IBM is building today will still execute
>>programs compiled or assembled 40 years ago for S/360.)


>>It seems that VLIW, even more than RISC, requires the compiler to know
>>too much about implementation details.


> RISC does not really expose any more implementation details than CISC,
> possibly less - exposure of branch delay slots is a mistake in some
> RISC implementations.


I don't think it is so much exposure of implementation details, as
sensitivity to them. More implementation details go into RISC
architectures than really should, and branch delay slots are an
example. One cycle per instruction is another, as the amount of
computation per cycle changes with time.


Trying to stay on topic for comp.compilers, consider compilers for
CISC machines. There are a variety of instruction combinations that
could be used when compiling a given statement, and the compiler must
choose one. It could choose one that uses relatively more complex
instructions, or more simple ones. As I understand it, one motivation
for RISC was that compilers tended to generate simpler instructions,
leaving more complex ones for assembly programmers.


Machine designers then work on speeding up the instruction sequences
actually used by compilers and, with some delay, compiler writers
adapt to the new machines.


RISC machines only supply relatively simple instructions, but as
the technology changes, so does the level of instruction that
is simple.


>>Otherwise, I don't believe that a VLIW compiler written today could be
>>expected to generate code to run on a machine built 40 years from now.


> But that severly limits where such a processor will get used.


Last time I suggested generating VLIW code from an intermediate
representation at program load time. That allows generating for the
exact characteristics of the processor in question, the binary
compatibility problem asked above. (I believe implementations similar
to this exist.)


Another possibility is to do it at program install time. Again, the
code can be generated for the exact processor, and still only one
object code distribution set is required. It would mean that the
installation would have to be done on each machine, instead of moving
disk drives, but that is most often done, anyway.


-- glen
[Still sounds a lot like the S/38 and AS/400. -John]

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