[Info-vax] Poulson info from Dave Cantor

[John Wallace]

On Nov 18, 9:56 am, Michael Kraemer <M.Krae... at gsi.de> wrote:
> John Wallace schrieb:
>
> > Instead, look at the basic financial logic. Intel continue to have to
> > pay for parallel (overlapping, competing, duplicating) x86-64  and
> > IA64 development teams for the CPU core even though they now have
> > massive overlap in the market they address. Those costs are doubtless
> > passed on to the sole significant IA64 customer, HPQ, who also
> > continue to have to pay for parallel Proliant and Integrity server
> > development teams even though again there is substantial hardware
> > overlap between Integrity and mid/high-end Proliant.
>
> These "parallisms" are in fact in favour of Itanic.
> With intel being a dedicated chip maker, development
> and production certainly can share resources with
> their mainstream x86 product. I guess a year's volume
> of Itanic chips can be made in the lunch break
> of some x86 fab.
> This is in stark contrast to the Alpha.
> DEC had to create and maintain everything from scratch,
> and costs for that could not be shared with a mainstream
> product.
> So the economic reasoning for ditching Alpha in favour of
> Itanic was and is still valid.

Some of the design parallelism *might* be in favour of Itanic if the
engineering and support organisations took advantage of it.

The resurrection of Proliants with IA64s inside would be serious
evidence the costs are being shared for the benefit of IA64. The
disappearance of Windows for IA64, and the disappearance of various
Linux distros for IA64, would indicate the market in general isn't
that interested in IA64 in general, but the market in general *is*
clearly interested in AMD64.

Got any other evidence that your vision of cost sharing to preserve
IA64 has any chance of happening?

As for fabrication costs: when your volumes are relatively small, your
per-chip fabrication costs aren't that relevant, what's relevant is
the per-chip share of the non-recurring development costs. Bear in
mind also that at any given time IA64 has tended to be one or two
process generations behind the current mainstream Intel process. So
even if producing IA64s on a fab configured for x86-64 was technically
possible (is it?), the saving isn't going to massively affect the
total cost per chip.

"I just tried an ancient "edt" built in 1991 for POWER1, still runs on
POWER7, unmodified. "

And based on that test we are expected to be convinced that the modern
system will correctly run arbitrarily chosen examples of other ancient
real-world code ? I think not. Proper engineering "qualification"
tests would need a little more thought (and investment).

John Reagan has already mentioned SRM_CHECK. Certain earlier Alpha
chips/compilers which *appeared* to work with pretty much every code
sequence known to man weren't actually following the architecturally
defined rules. Once EV6 hardware came along, the new chip combined
with the early compiler's failure to enforce the rules *could* in the
right circumstances lead to visible weirdness [1]. Nobody would care
about these weirdnesses in a Windows environment, they'd just blame
Windows and reboot or reinstall in the traditional way. If it happens
again, so be it. However, in a  VMS or NonStop enviroment (and
presumably HP/UX too) you don't expect crashes or data corruption of
any kind, and if/when it happens repeatably and reproducibly you
expect to be told why it's happened, and how it's going to be fixed.

[1] http://h71000.www7.hp.com/doc/84final/6677/6677pro_ev6.html