Wayne writes:
> [log in to unmask] writes:
> > Except that these subsystems are written in languages for which
> > there is no IA-64 compiler.

> I am aware of that.  A FUNDAMENTAL requirement of moving to IA-64
> is having the compilers available.  I would suspect that the SPL/SPLASH
> compiler could be ported to IA-64 far easier than some attempt at
> re-writing all of the SPL-type code into some other language.

Probably, but emitting worthwhile IA-64 code is such rocket science that not
even HP and Intel have figured out how to do a really good job of it yet,
even though this was going to be one of HP's big advantages in the IA-64
world (that their compilers would be so much better than other people's).
Currently the HP compiler + HP-UX SPECfp benchmark numbers are about 7%
*slower* than the Intel compiler + Windows numbers.

So if you want native code, then the best option probably is something
like...

> On the other hand, there is the potential for a semi-automated
> "convert SPL to C" approach.  Requires more work on the utility
> software's source code but you end up with a more supportable
> base of source code.

You might not get maintainable C code, but you might be able to have the
compiler emit C that the native C compiler could turn into good code.

Of course it's questionable whether you would care whether VPLUS were
running in native IA-64 code or simply translated 32-bit PA-RISC code.
Large parts of MPE/XL remained in CM for years and nobody really cared, so
this might be perfectly fine for MPE on IA-64 as well.

For Image I personally think you would want to bite the bullet and
reimplement it from scratch in a language like C, updating the
implementation to take advantage of a modern 64-bit architecture, rather
than continuing to work with a design model that came from a small memory
16-bit stack architecture.  Of course 100% compatibility would be the
primary goal, something that the Image II project failed to achieve back in
the MPE/XL days.

I believe that CSY had an excellent plan for getting MPE onto IA-64, and
that it would have been every bit as good as the MPE/V to MPE/XL transition
was.  Unfortunately it all came down to the fact that it would just cost
them more money than they could justify based on the state of the market.
If you've got, oh, I don't know, say $25,000,000 laying around that you
don't know what to do with, maybe they could have their minds changed.

Assuming this is the magnitude of the cost to complete the IA-64 migration,
it would be interesting to have HP put an actual price on the project and
see if the remaining customers would be willing to cough up a few $1000 each
in order to avoid the transition that's been thrust upon them, or if a dozen
or so "large" customers might be able to come up with this amount between
them.  Hell, the large ISVs like Summit, Amisys, SGA, etc., might prefer to
fund this project rather than their own migrations.

> Gavin: You said "languages" not "language" - by that do you mean various
> dialects of SPL?

I think Image is currently written in P-SPL and if I recall correctly VPLUS
is SPL II,  neither of which are publicly released languages.  But this is a
relatively small issue among all of the things you would need to deal with
if you want a *good* MPE/iA.

G.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *