[Info-vax] Updated VMS Roadmap

[John Reagan]

"JF Mezei" <jfmezei.spamnot at vaxination.ca> wrote in message 
news:00c32138$0$26791$c3e8da3 at news.astraweb.com...
> John Reagan wrote:
>
>> *COULD* do is expose a latent bug in the compilers.  For instance, the
>> compilers today could generate code that says "these 15 instructions 
>> could
>> be done in parallel".
>
> Ah, I would have thought that the compilers would have optimised code
> with knowledge of how many could be done in parralel as opposed to
> making as many parralel operations as logically possible even if the CPU
> can't handle that many.
>
> So, if each iteration of IA64 since McKinley didn't make architectural
> changes visible to compilers, then the introduction of the 8.3 version
> to cater to the new IA64 systems (and blades) at that time wouldn't have
> created any need to recompile applications.
>
> So the "hardware" patches would have been related more to the systems
> than to the chip itself ?
>
>

Hardware releases almost always deal with platform specifics like buses, new 
hardware interfaces (USB controllers, NIC cards, et al.), etc. as well as 
bug fixes/performance changes (ie, -1H1 has some XFC changes that made my 
systems go faster when doing compiler testing).

The Itanium chip in a blade isn't any different than the same chip in a 
Superdome.

As for finding parallel operations, why should the compiler care?  The 
architecture provides a way for a compiler to denote "these instructions can 
be done in parallel".  There is no architected limit for the length of any 
instruction group (ie, the distance between stop bits).  We find as many as 
we can within the limits of what we know how to do.  Could GEM find more? 
Probably.  Is it worth the effort?  Harder question given the observation 
that the actual chips can only do so many.  Even if we found a 30 
instruction sequence (at the cost of longer compilations, more memory 
consumed by the compiler, etc.), no chip today (or tomorrow) can do it.

John