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

gah4 <gah4@u.washington.edu>
Sat, 4 Feb 2023 02:55:01 -0800 (PST)

          From comp.compilers

Related articles
Are there different programming languages that are compiled to the same intermediate language? costello@mitre.org (Roger L Costello) (2023-01-29)
Re: Are there different programming languages that are compiled to the same intermediate language? gah4@u.washington.edu (gah4) (2023-01-31)
Re: Are there different programming languages that are compiled to the same intermediate language? gah4@u.washington.edu (gah4) (2023-02-02)
Re: Are there different programming languages that are compiled to the same intermediate language? anton@mips.complang.tuwien.ac.at (2023-02-03)
Re: OoO, VLIW, Are there different programming languages that are compiled to the same intermediate language? gah4@u.washington.edu (gah4) (2023-02-03)
Re: OoO, VLIW, Are there different programming languages that are compiled to the same intermediate language? gah4@u.washington.edu (gah4) (2023-02-04)
Re: OoO, VLIW, Are there different programming languages that are compiled to the same intermediate language? anton@mips.complang.tuwien.ac.at (2023-02-07)
Re: OoO, VLIW, Are there different programming languages that are compiled to the same intermediate language? gah4@u.washington.edu (gah4) (2023-02-08)
| List of all articles for this month |
From: gah4 <gah4@u.washington.edu>
Newsgroups: comp.compilers
Date: Sat, 4 Feb 2023 02:55:01 -0800 (PST)
Organization: Compilers Central
References: <Adkz+TvWa4zLl8W9Qd6ovtClKZpZrA==> 23-01-078 23-02-001 23-02-007 23-02-011 23-02-015
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="30143"; mail-complaints-to="abuse@iecc.com"
Keywords: architecture, history, comment
Posted-Date: 04 Feb 2023 11:55:17 EST
In-Reply-To: 23-02-015

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]


Post a followup to this message

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