Re: OoO, VLIW, Are there different programming languages that are compiled to the same intermediate language?

From	gah4 <gah4@u.washington.edu>
Newsgroups	comp.compilers
Subject	Re: OoO, VLIW, Are there different programming languages that are compiled to the same intermediate language?
Date	2023-02-04 02:55 -0800
Organization	Compilers Central
Message-ID	<23-02-017@comp.compilers> (permalink)
References	(1 earlier) <23-01-078@comp.compilers> <23-02-001@comp.compilers> <23-02-007@comp.compilers> <23-02-011@comp.compilers> <23-02-015@comp.compilers>

Show all headers | View raw

On Friday, February 3, 2023 at 7:51:41 PM UTC-8, gah4 wrote:

(snip on Itanium and OoO execution)

> The 360/91 had some interesting problems. One is that it had 16 way
> interleaved memory with a cycle time of 13 processor cycles, and the
> goal of one instruction per clock cycle. That means it is dependent on
> memory address ordering, which is hard to know at compile time.

(snip)

> But the reason for bringing this up, is that if Intel had a defined
> intermediate code, and supplied the back end that used it,
> and even more, could update that back end later, that would have
> been very convenient for compiler writers.

(snip, our moderator wrote)
> [Multiflow found that VLIW compile-time instruction scheduling was
> swell for code with predictable memory access patterns, much less so
> for code with data-dependent access patterns. I doubt that has
> changed. And if the memory access is that predictable, you can
> likely use SIMD instructions instead. -John]

So, 50 years ago we had the 360/91, and some CDC competition.

About 45 years ago, we had the Cray-1 and successor vector processors.

So, yes, SIMD processors.

Then 30 years ago, Fortran added the FORALL statement, to make writing
vector code easier.  Except that it doesn't.

FORALL, and array assignment statements, always operate such that
the effect is as if the whole right-hand side is evaluated before the left
side is changed.  Unless the whole thing fits in a vector register,
the compiler is still stuck.

And just about that time, vector processor go out of style.

(There is now DO CONCURRENT, which might be better.)

Much matrix code goes sequentially through memory, and programmers
know that.  (Or they are supposed to know that.)

Early Fortran had the FREQUENCY statement, such that one could
help the compiler know the likely iteration count for DO loops, and
branch probability for branch instructions.  Those would help with
static branch predictors, but are long gone now.

It would seem, though, that a statement telling the compiler the
expected memory access pattern would help.

And the Cray-1, like the 360/91, has 16-way interleaved
memory, 64 bits wide.
[Legend says that in one of the early Fortran compilers, the FREQUENCY
statement was accidentally implemented backward and nobody noticed. We
have found over and over that programmers' intuitions about the way
their programs perform are quite poor and we're much better off saying
what we mean and letting the compiler figure out how to do low level
optimizations. -John]

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

csiph-web