NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/misc/3771

Internet Message Format | 1992-11-18 | 2.9 KB

Path: sparky!uunet!know!mips2!news.bbn.com!usc!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
From: [e-mail] (J. Giles)
Newsgroups: comp.lang.misc
Subject: Re: languages which allow the introduction of new operators
Message-ID: <[e-mail]>
Date: 18 Nov 92 22:43:54 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: Los Alamos National Laboratory
Lines: 44

In article <[e-mail]>, [e-mail] (Mark C. Carroll) writes:
|> [...]
|> Optimization is a _very_ difficult business. Any optimization has
|> interactions with other optimizations, in terribly complex (and not
|> necessarily well-understood) ways. Making any change to the
|> optimization process can have broad affects on the entire process.
|> [...]

Yes.  Consider, for example, the last three things done by the
compiler: 1) instruction selection; 2) register allocation; and
3) instruction scheduling.  On a CISC machine, this could be *very*
difficult.  For example, a memory/memory instruction doesn't
need any registers, but may alter the optimal instruction order,
which alters the optimal register allocation, which may mean that
you should now use a register/memory instruction instead.  Each
of these three parts of compilation feed-back into the other two
in compilicated ways.  (This is one of the reasons that CISC
machines are harder to write compilers for than RISC machines
are.)

|> Any optimization, particularly on modern architectures, has got to
|> consider its affect on pipeline fills, branch predictions, register
|> allocations, memory and cache uses, and dozens of other factors.  Do
|> you think that you're qualified to judge what affect your two-cycle
|> savings will have on the rest of your program? If so, you're in the
|> wrong field - you should be designing compilers.

To be fair to Dr. Rubin, he wants to be able to specify information
that the high-level language cannot directly represent.  In particular,
many high level languages don't have the capability to directly express
operations that modern machines can do.  In these instances, the machine's
assembly language is higher-level than the so-called high-level language
you're compiling from.  You need to be able to tell the compiler what to
do.  For example, on vector machines there are often vector merges based
on the vector mask - but C doesn't have a way to directly instruct that
a given integer be stored into (or read from) the vector mask!  Coding
around this in C would require that you rely on the compiler being able
to *infer* from some standard C construct that the vector mask is what
you're after.  Most compilers aren't up to it.  But, if you could just
say: "use the vector mask", the code would, very likely, run much
faster.

--
J. Giles