[Info-vax] Updated VMS Roadmap

[John Reagan]

"JF Mezei" <jfmezei.spamnot at vaxination.ca> wrote in message 
news:017f7635$0$11366$c3e8da3 at news.astraweb.com...
> Guy Peleg wrote:
>
>> The migration from 8.3 to 8.3-1H1 is straightforward. Simple VMS
>> upgrade.
>
> Out of curiosity, if one has an IA64 box that requires 8.3-1H1 , would
> running applications *compiled* for 8.3 result in the application not
> making most efficient use of new features in the CPU ?
>
> Or is EPIC, instruction ordering and instruction set pretty much stable
> on IA64, not requiring compilers be updated to make use of new features ?

What new CPU?  Guy just said that V8.3-1H1 is more efficient on the same box 
as compared to V8.3.

As for compiling, the basic machine model for all the recent chips 
(McKinley, Madison, Monticito, Montvale, etc.) are all pretty much the same 
to the compiler.  The speed and cache sizes are different but the underlying 
CPU features (ie, number of adders, etc.) is about the same.  Plus the 
architecture itself requires the compilers to do the right thing.  So 
existing images will work just fine across all the chips I mentioned.

Future chips may have a different CPU model (like more functional units 
which will let them actually do more instructions in parallel).  What that 
*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".  In reality on today's chips without 15 adders or 
memory units, etc. will still do those 15 in chunks.  Consider a future chip 
with more adders that actually tries to do more per cycle.  What if the 
compiler was wrong and those 15 instructions actually had a dependency? 
That said, the compilers did lots of testing and validation to prevent such 
things from occuring.

Also future chips might have new instructions of interest to the compilers. 
So far, between McKinley and today, the only sorta interesting instructions 
are the ld16/st16/cmp8xchg16 instructions.  GEM doesn't know how to generate 
those.  Their performance benefits are somewhat suspect in that the 16-byte 
load/stores are not double-register pairs but the single register specified 
in the instruction and the AR.CSD register.  That makes the AR.CSD a real 
bottleneck as you have to constantly move data between a regular integer 
register and the AR.CSD application register.  We decided it wasn't worth 
the effort.  The cmp8xchg16 would have a little more use as a builtin since 
the 16-byte store would be atomic.

If future chips have even more instructions added (like to help with integer 
multiply or division), then I suspect GEM would be extended (along with a 
new keyword for /ARCH) to enable such new instructions.  I have no idea what 
the new instructions would do on older chips.  Depends on where in the 
opcode map they were created.  They might use encodings that would trap on 
older chips or encodings that just are nop's on older chips.

John