🚀 go-pugleaf

In article <13050@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes:
> In article <1629@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> ...[numerous "why don't HLLs let me say..." flames omitted]...
> >What does your HLL have to say about these?
> 
> What HLL?  What does this have to do with VLIW techniques?  Dr.  Rubin is
> complaining about languages -- but we are talking about VLIW compiler
> analysis and program transformation technology, not language design.

If the language the compiler compiles does not have the operations to be used
in my program, I cannot use them.  I have seen NO language designed for 
the efficient use of hardware operations.  The choice of the algorithm 
depends on the hardware, and there can be lots of different algorithms.

An example: most of the efficient ways of generating non-uniform random 
variables are acceptance-rejection.  This is only partly vectorizable on
CRAYs, and is especially difficult on the CRAY 1.  This is due to the
non-existence of some hardware instructions.  It would be necessary to
try out a number of computationally less efficient methods to find the
ones which are best on the machine.  I would not consider any of them on
the CYBER 205, as they are obviously worse.

> I hope that this confusion is not common.  Perhaps a lot of compilers do
> blindly spit-out the "obvious" code for badly-designed language constructs,
> but that certainly isn't the state of the art.  I would think that a person
> who has spent some time counting T-states would really appreciate the VLIW
> work that Ellis presents in his award-winning PhD thesis...  I know I do.
> 
> >... Are you so dead sure that
> >I cannot manage such structures better than the compiler?  The most complicated
> >instruction set I have seen is MUCH simpler than HLLs.  ...
> 
> VLIW technology is complex because of its use of parallelism -- it has very
> little to do with instruction set complexity issues.  Generating good code
> for a VLIW is most like microcode scheduling/compaction for a huge,
> asymmetric, microcoded machine.  You really don't even want to try it by
> hand...  well, I know I don't.  And why bother?  VLIW compiler techniques
> come very close to optimal schedules every time.  I can't match it, let
> alone beat it.

What you are saying is that an instruction scheduler can do better thqn a
human.  This is mostly true.  It is necessary to allow human override, as
the scheduler only takes into account what its designers thought was 
of value.

But this does not answer my complaint.  I need to know these instructions
to make use of them.  I certainly can use information about their timing
and overlap to select those algorithms which will run faster.  I do not
insist that an assembler carry out the instructions in the order I present
them, as long as the program logic is maintained.  This is what an 
optimizer does, and I do not oppose this.

I do not even object to the optimizer-compiler-scheduler even suggesting
alternates which are more efficient, but which it cannot be sure will work.
One of our programmers asked me whether some transfers could be deleted
from code.  It was possible by essentially duplicating some code, and
making inessential changes in the program.  I doubt a compiler could
figure this out.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)