[Info-vax] Itanium support is back in GCC 15

[John Dallman]

In article <vpfoc7$2o5$1 at panix2.panix.com>, kludge at panix.com (Scott
Dorsey) wrote:

> The whole idea of the VLIW system is that the compiler will be able 
> to optimize the code to gain paralellism of units inside the single 
> processor. This is a very very ingenious idea but nobody has yet
> been able to make a compiler that could do it well enough for it to 
> be a real win.

Sadly, the job is *impossible*. 

The fundamental problem in optimisation for modern computers is the
slowness of main RAM, which isn't currently solvable at a reasonable cost.
We use caches to mitigate it. 

Out-of-order execution addresses this problem by tracking the data
dependencies on memory and registers in real time and executing
instructions when their data is available. This has worked pretty well
for almost thirty years for x86 and the other architectures that are
still competing on performance. 

Itanium/EPIC was an alternative to this. The management of data
dependencies wasn't to be done dynamically by hardware, but in advance by
the compiler. This requires the compiler to track what data is in cache
so that advance loads can be scheduled correctly to have data available
in time. Unfortunately, in a multi-core system with a multi-tasking
operating system, it's impossible to know in advance what data will be in
cache, because that depends on what else is running. 

Other flaws of Itanium include the bulky instruction set, which needs
more memory bandwidth and larger caches than other architectures, and an
architectural misfeature which means floating-point advance loads that
are outstanding across subroutine calls can fail silently. 

If anyone tries to re-use ideas from Itanium, they'd be well-advised to
keep quiet about where they got them. There is remaining prejudice
against it, which is well-justified. 

John