[Simh] Hardware fidelity in the VAX family simulators

[Timothe Litt]

On 08-Jul-15 19:55, Clem cole wrote:
>
> Sent from my handheld. More typos likely which is quite a thought. 
>
>> On Jul 8, 2015, at 6:17 PM, Timothe Litt <litt at ieee.org> wrote:
>>
>> Vectors?  What you add to an architecture just before you give up on it.  Rigel and the 9000 supported VAX  vectors.  Alpha had them on its roadmap for Ev8 before it died... CDC's ETA-10 implemented vectors, and died.  However, Cray and its clones had a good run.  And of course there were the bolt-on 'array processors' for various machines.
> Tim
>
> Point taken and a reasonable observation.  But to be fair most current architectures have them-they are pretty much deriger in the high end these days (along with lots of thread support). The key point is that the current compilers all generate code for them (thank you Mark, Dave, Kent, Rich et al who blazed the trail with Vax Fortran and then went on to 'reinject' that DNA into the current code base). 
>
> Funny I listened to a google guy give a talk about LLVM today and many of the questions and concerns from our crew was how to get it to be as good as GEM or intel particular wrt vectors and the usual Fortran stuff.  Fine for C but a long way to go for HPC.  
>
> Also I don't think the Intel*64 architecture is going to die any time soon (nor Power for that matter).   Fact is vectors are cute trick for fortran code and a good fortran implementation (particularly one that supported vectors and parallel execution) has paid many of our salaries over the years 😂
>
> Clem
I was mostly thinking of long vectors.  Current machines have SIMD
instruction sets with 8-16 vector registers ("short vectors") vs. the
64+ of the machines that pioneered vectors for HPC.   The SIMD
instructions started as graphics accelerators; it took a few iterations
before they became more generally useful.  And outside the high end, the
adoption rates were an issue due to the compatibility morass.

I agree that IA is the exception - certainly not on its technical
merits, but rather on its inertia.  Power seems to be hanging on.  And I
wasn't commenting on the merits of vectors, just when they appear in the
evolution of architectures. 

Not all the enabling work for vectors was in the compiler space.  The
VAX vector emulator actually has 2 variants; one that I did for the
FORTRAN/GEM team was designed to ensure that they obeyed the
architecture (not the implementations).  It had hooks that allowed
arbitrary rescheduling of instructions between the various sync points,
traces & other instrumentation.  Besides finding compiler bugs, it
caused one architecture ECO where the compiler folks said "hardware
would never do that, but the spec said OK".  I probably should have done
a paper on it, but I was too busy creating stuff to write papers...  The
production version was initially opposed by the compiler team, who felt
that it could never be fast enough to be useful.  I was unwilling to
break the strict binary compatibility precedents for VAX.  (vs. the IA
mess) I used quite a few coding tricks to end up beating the hurdle
(slowdown for emulation) that we agreed upon.  The emulator made it
possible to have vector support at FRS (First Revenue Ship) of
hardware.  I don't believe there were any cases where the emulator and
either hardware implementation diverged.  (Of course, the emulator was
also the reference model for the hardware simulators...)

But on the original topic, for the reasons you note the VAX vector
instruction set is historically interesting.  The primary point is that
absent OS emulation of vectors, SimH doesn't "cover the complete
history" of the VAX software stack.  I haven't looked at implementing
VAX vectors in SimH.  While one would expect to be able to build on the
scalar instruction emulations, condition codes and exceptions (math and
memory management) make it a project...even for the (simpler)
synchronous memory model variant.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150709/f68989be/attachment.bin>