HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
http://tinyurl.com/3zfo5dp

Keith Cayemberg wrote:
> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
> http://tinyurl.com/3zfo5dp


I didn't expect to see an article mention VMS  !!!

I am disaspointed that HP is still ruling out porting VMS to the 8086.
It would end up costing customer much less to move to 8086-VMS and keep
Oracle than to have to move from VMS to Linux or AIX or Solaris in order
to keep Oracle.

If Poulson will only double the performance, then it is not very
imporessive since this is just achieved by doubling the number of cores.
Computing PI to infinity will still take the same amount of time if a
single core runs at the same speed. :-)


Before HP can convince Oracle to return to that IA64 thing, it needs to
provide some public strategy on its real intenstions with IA64. This is
something Apotheker failed to do in his strategy document of earlier
this year and gave Oracle the ammunition to pull the plug.

It is time for HP to come out clean with unambiguous and credible
statement on its intentions with IA64.

The costs of porting the 3 OS to the 8086 are probably less than the
cost of continued payments to Intel to support continued development of
that IA64 thing.

In article <4e837900$0$2216$c3e8da3$460562f1@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Keith Cayemberg wrote:
>> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
>> http://tinyurl.com/3zfo5dp
>
>
>I didn't expect to see an article mention VMS  !!!
>
>I am disaspointed that HP is still ruling out porting VMS to the 8086.
>It would end up costing customer much less to move to 8086-VMS and keep
>Oracle than to have to move from VMS to Linux or AIX or Solaris in order
>to keep Oracle.

First off, I think that there are some real architecture impediments in
X86 for the porting of VMS to it.  

Secondly, the ports to Alpha and Itanium had a compiler group that was
instrumental in creating the Macro-32 and Bliss compilers for these two
architectures.  Until those compilers exist, forget about porting.  I'm
still not convinced the protections afforded by supervisor and executive
modes can be easily/readily overcome if moved to X86.

You're also assuming that Ellison will support Oracle on *anything* that
VMS runs upon.  He's trying to force people reliant on Oracle to buy his
SPARCy boxes that he's now acquired.  To me, Oracle's antics seem just as
anti-trust as when Micro$hit used its dominance of the desktop to force
its will on the masses.



>If Poulson will only double the performance, then it is not very
>imporessive since this is just achieved by doubling the number of cores.
>Computing PI to infinity will still take the same amount of time if a
>single core runs at the same speed. :-)
>
>
>Before HP can convince Oracle to return to that IA64 thing, it needs to
>provide some public strategy on its real intenstions with IA64. This is
>something Apotheker failed to do in his strategy document of earlier
>this year and gave Oracle the ammunition to pull the plug.
>
>It is time for HP to come out clean with unambiguous and credible
>statement on its intentions with IA64.

You missed bootcamp!



>The costs of porting the 3 OS to the 8086 are probably less than the
>cost of continued payments to Intel to support continued development of
>that IA64 thing.

You missed bootcamp!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

On 9/28/2011 3:43 PM, JF Mezei wrote:
> Keith Cayemberg wrote:
>> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
>> http://tinyurl.com/3zfo5dp
>
>
> I didn't expect to see an article mention VMS  !!!
>
> I am disapointed that HP is still ruling out porting VMS to the 8086.
> It would end up costing customer much less to move to 8086-VMS and keep
> Oracle than to have to move from VMS to Linux or AIX or Solaris in order
> to keep Oracle.
>
> If Poulson will only double the performance, then it is not very
> impressive since this is just achieved by doubling the number of cores.
> Computing PI to infinity will still take the same amount of time if a
> single core runs at the same speed. :-)
>
>
> Before HP can convince Oracle to return to that IA64 thing, it needs to
> provide some public strategy on its real intensions with IA64. This is
> something Apotheker failed to do in his strategy document of earlier
> this year and gave Oracle the ammunition to pull the plug.
>
> It is time for HP to come out clean with unambiguous and credible
> statement on its intentions with IA64.
>
> The costs of porting the 3 OS to the 8086 are probably less than the
> cost of continued payments to Intel to support continued development of
> that IA64 thing.

If it were possible to port VMS to the X86 platform, I think somebody 
would have done it long ago!  Both VMS-VAX and VMS-Alpha have hardware 
dependencies that the X86 platforms cannot satisfy easily, or at all!

There is actually an X86 program called "PCVMS" that gives you a 
VMS-like environment.  I haven't heard any mention of it for a long time.



The VAX and its software were developed together.  There was much 
discussion about what should be done in hardware and what in software.
This was before the RISC architectures evolved.

On Wed, 2011-09-28 at 20:29 +0000, VAXman-@SendSpamHere.ORG wrote:
> First off, I think that there are some real architecture impediments
> in
> X86 for the porting of VMS to it. =20
>=20
> Secondly, the ports to Alpha and Itanium had a compiler group that was
> instrumental in creating the Macro-32 and Bliss compilers for these
> two architectures.  Until those compilers exist, forget about porting.
> I'm still not convinced the protections afforded by supervisor and
> executive modes can be easily/readily overcome if moved to X86.=20

There is the ring 0 - 3 security model on x86 and also DEC did write a
BLISS compiler for the x86 many moons ago.=20
--=20
Tactical Nuclear Kittens

Keith Cayemberg schrieb:
> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
> http://tinyurl.com/3zfo5dp

 > Everyone I've spoken with is optimistic that with Meg's experience 
and > proven communications skills, we can change this direction," Buik 
said > in an interview with eWEEK.

Did she speak with Mr. Ellison too?
Apparently she didn't even speak with Mrs. Whitman,
so where does that optimism come from?

 > ... begin making a migration to a new hardware platform�most likely a 
 > Unix platform from either HP or IBM ...

but HP-UX is dead as well as far as Oracle DB is concerned?

On Sep 28, 9:29=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> In article <4e837900$0$2216$c3e8da3$46056...@news.astraweb.com>, JF Mezei=
 <jfmezei.spam...@vaxination.ca> writes:
>
> >Keith Cayemberg wrote:
> >> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
> >>http://tinyurl.com/3zfo5dp
>
> >I didn't expect to see an article mention VMS =A0!!!
>
> >I am disaspointed that HP is still ruling out porting VMS to the 8086.
> >It would end up costing customer much less to move to 8086-VMS and keep
> >Oracle than to have to move from VMS to Linux or AIX or Solaris in order
> >to keep Oracle.
>
> First off, I think that there are some real architecture impediments in
> X86 for the porting of VMS to it. =A0
>

Can you name any specific examples of architectural impediments, other
than the ones below?

AMD64 and its Intel clone running in native AMD64 mode isn't really
x86 as folks may have historically known it.

> Secondly, the ports to Alpha and Itanium had a compiler group that was
> instrumental in creating the Macro-32 and Bliss compilers for these two
> architectures. =A0Until those compilers exist, forget about porting.

Does sound like a bit of a snag. Do Intel have any decent compilers or
compiler people, or is there just Steve (Lionel) these days? Other
options (e.g. hyper-trendy virtualisation, or what used to be called
emulation) dismissed because?

> I'm
> still not convinced the protections afforded by supervisor and executive
> modes can be easily/readily overcome if moved to X86.

How many modes did Alpha have in underlying hardware (you and I know
the answer to that one)? How many modes has IA64 got (I can't remember
that one)? How many modes did x86 Classic have (Intel call them
"rings"), and how about AMD64 and its Intel clone?

What's the "big issue" here ?

AMD64 has a No Execute bit in the actual memory management hardware
which might be a rather handy feature.

> You're also assuming that Ellison will support Oracle on *anything* that
> VMS runs upon. =A0He's trying to force people reliant on Oracle to buy hi=
s
> SPARCy boxes that he's now acquired. =A0To me, Oracle's antics seem just =
as
> anti-trust as when Micro$hit used its dominance of the desktop to force
> its will on the masses.
>
> >If Poulson will only double the performance, then it is not very
> >imporessive since this is just achieved by doubling the number of cores.
> >Computing PI to infinity will still take the same amount of time if a
> >single core runs at the same speed. :-)
>
> >Before HP can convince Oracle to return to that IA64 thing, it needs to
> >provide some public strategy on its real intenstions with IA64. This is
> >something Apotheker failed to do in his strategy document of earlier
> >this year and gave Oracle the ammunition to pull the plug.
>
> >It is time for HP to come out clean with unambiguous and credible
> >statement on its intentions with IA64.
>
> You missed bootcamp!
>

There were lots of statements of intention re Alpha, with or without
NDA, right up until the day it was canned.

AMD64 and its Intel clone isn't going away any time soon.

If Proliant goes away, lots of people will be very surprised, though
HP do seem to be doing their best to drive away lots of customers,
Proliant ones presumably included.

> >The costs of porting the 3 OS to the 8086 are probably less than the
> >cost of continued payments to Intel to support continued development of
> >that IA64 thing.
>
> You missed bootcamp!
>

Presumably whatever you're referring to was disclosed at bootcamp
under NDA and cannot be repeated elsewhere, where (potential)
customers with limited travel budgets or limited interest in Homeland
Security theatrics can read it?

> --
> VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0VAXman(at)TMESIS(=
dot)ORG
>
> All your spirit rack abuses, come to haunt you back by day.
> All your Byzantine excuses, given time, given you away.

In article <a2184fb6-88ae-467f-ae69-d79889e1b26b@k15g2000yqd.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
>{...snip...}
>AMD64 and its Intel clone isn't going away any time soon.

There was one slide in Pauline Nist's presentation about CPU volume.
According to both Pauline and her slide, there's more volume in IA64
than in AMD!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

On 2011-09-28, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> There is actually an X86 program called "PCVMS" that gives you a 
> VMS-like environment.  I haven't heard any mention of it for a long time.

PCVMS was a toy.
-- 
roger ivie
rivie@ridgenet.net

In article <slrnj87g34.aem.rivie@stench.no.domain>, Roger Ivie <rivie@ridgenet.net> writes:
>On 2011-09-28, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>> There is actually an X86 program called "PCVMS" that gives you a 
>> VMS-like environment.  I haven't heard any mention of it for a long time.
>
>PCVMS was a toy.

Exactly.  However, for those interested:

http://decuslib.com/miscellaneous/PCVMS.contents.txt
http://decuslib.com/miscellaneous/pcvms.zip

It's a far far cry from VMS!  Even VMS V1.0.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

Richard B. Gilbert wrote:

> If it were possible to port VMS to the X86 platform, I think somebody 
> would have done it long ago!  Both VMS-VAX and VMS-Alpha have hardware 
> dependencies that the X86 platforms cannot satisfy easily, or at all!

From what I had been told, current 64 bit x86s have what it takes.

Remember that IA64 was not designed with VMS in mind (whereas both Alpha
and VAX were). Yet, the real VMS engineers managed to port VMS to it.

With regards to bootcamp: if you guys learned something under NDA, it is
worthless. The goal of communications is to reach customers and
potential customers: MAKE IT PUBLIC.

If HP is unwilling to make a piece of information public, then it is
worthless.


And guess what, if x86 does lack something needed by enterprise OS, then
HP has the clout to get Intel or Arm to add it to their products. (the
other will follow).

Intel
AMD
ARM
SPARC

On Sep 28, 2011, at 8:20 PM, "JF Mezei" <jfmezei.spamnot@vaxination.ca> wro=
te:

> Richard B. Gilbert wrote:
>=20
>> If it were possible to port VMS to the X86 platform, I think somebody=20
>> would have done it long ago!  Both VMS-VAX and VMS-Alpha have hardware=20
>> dependencies that the X86 platforms cannot satisfy easily, or at all!
>=20
> From what I had been told, current 64 bit x86s have what it takes.
>=20
> Remember that IA64 was not designed with VMS in mind (whereas both Alpha
> and VAX were). Yet, the real VMS engineers managed to port VMS to it.
>=20
> With regards to bootcamp: if you guys learned something under NDA, it is
> worthless. The goal of communications is to reach customers and
> potential customers: MAKE IT PUBLIC.
>=20
> If HP is unwilling to make a piece of information public, then it is
> worthless.
>=20
>=20
> And guess what, if x86 does lack something needed by enterprise OS, then
> HP has the clout to get Intel or Arm to add it to their products. (the
> other will follow).
> _______________________________________________
> Info-vax mailing list
> Info-vax@rbnsn.com
> http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com

On 9/28/2011 9:31 PM, Forster, Michael wrote:
> Intel
> AMD
> ARM
> SPARC
>
> On Sep 28, 2011, at 8:20 PM, "JF Mezei"<jfmezei.spamnot@vaxination.ca>  wrote:
>
>> Richard B. Gilbert wrote:
>>
>>> If it were possible to port VMS to the X86 platform, I think somebody
>>> would have done it long ago!  Both VMS-VAX and VMS-Alpha have hardware
>>> dependencies that the X86 platforms cannot satisfy easily, or at all!
>>
>>  From what I had been told, current 64 bit x86s have what it takes.
>>
>> Remember that IA64 was not designed with VMS in mind (whereas both Alpha
>> and VAX were). Yet, the real VMS engineers managed to port VMS to it.
>>
>> With regards to bootcamp: if you guys learned something under NDA, it is
>> worthless. The goal of communications is to reach customers and
>> potential customers: MAKE IT PUBLIC.
>>

H-P and other companies make advance announcements to customers
under a Non Disclosure Agreement in order allow customers to plan their 
System purchases.  If you bought a "WizBang 4000", with a 4GHz clock and
three weeks later, the "WizBang 5000" with an 8 GHz clock hits the 
market, you would be seriously pissed, and who would blame you.
So they tell you under NDA that they expect to release the "WizBang 
5000" sometime within the next 45 days.  And they caution you that first 
ship MAY be delayed due to unforeseen circumstances. . . .

So, maybe you can wait seven weeks or maybe not.  But you feel good 
because you are "in the know"! Or maybe you'll be able to get the 
Whizbang 4000 at a steep discount!

There is SOME method to this madness.  I recall attending an NDA
ten-twelve years ago.  ISTR that was the announcement the availability
of 10K RPM disks.

As I recall we bought five or six of these marvels of modern 
technologies only to have to replace most of them six weeks later. It 
seems that the technology was not quite ready for prime time!

"John Wallace" <johnwallace4@yahoo.co.uk> wrote in message 
news:a2184fb6-88ae-467f-ae69-d79889e1b26b@k15g2000yqd.googlegroups.com...
>Does sound like a bit of a snag. Do Intel have any decent compilers or
>compiler people, or is there just Steve (Lionel) these days? Other
>options (e.g. hyper-trendy virtualisation, or what used to be called
>emulation) dismissed because?

Steve Lionel went to Intel long ago when Compaq sold Digital Fortran and 
most of the GEM group to Intel.

John

"John Wallace" <johnwallace4@yahoo.co.uk> wrote in message 
news:a2184fb6-88ae-467f-ae69-d79889e1b26b@k15g2000yqd.googlegroups.com...

>Can you name any specific examples of architectural impediments, other
>than the ones below?

The whole 2-mode vs 4-mode is a red herring.  Current x86 machines are 
sufficient.  Plus Burns Fisher told me that he could do it all on a 2-mode 
piece of hardware anyway.  (but Burns isn't on OpenVMS anymore...)


The big problem is the Macro-32/BLISS register linkages. There is lots of 
Macro-32 code (RMS relies heavily on those global register definitions) that 
passes parameters in registers between Macro-32 and BLISS (and C as well). 
Look at the x86 register set.  Even in full 64-bit mode, there are only 16 
64-bit wide registers.  How do you expect the Macro-32 compiler to take 
existing code (which has references to registers higher than 16) and map it 
to the x86 register set?  It was funky enough on Itanium (just look at the 
Itanium register mapping algorithm and mouse pad) but it gets much harder 
(if not simply impossible) on x86.

If the Macro-32 code didn't exist and all those register linkages were 
normal call sequences, we wouldn't be having this conversation.

Some Macro-32 can be recoded into BLISS or C simply enough, but there are 
some Macro-32 files that can't easily be converted.  There is Macro-32 code 
that jumps between routines, enters via one routine's prologue but exits via 
another routine's epilogues, etc.  Such code can't easily be representable 
in C or BLISS.  That code needs more than just mechanical conversion.

John

On Wednesday, September 28, 2011 5:48:20 PM UTC-4, John Wallace wrote:
> On Sep 28, 9:29=A0pm, VAXman-  @SendSpamHere.ORG wrote:
> > In article <4e837900$0$2216$c3e8da3$4605...@news.astraweb.com>, JF Meze=
i <jfmezei...@vaxination.ca> writes:
> >
> > >Keith Cayemberg wrote:
> > >> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decision
> > >>http://tinyurl.com/3zfo5dp
> >
> > >I didn't expect to see an article mention VMS =A0!!!
> >

The folks at Connect worked hard to get press exposure for the Boot Camp th=
is year.

> > >If Poulson will only double the performance, then it is not very
> > >imporessive since this is just achieved by doubling the number of core=
s.
> > >Computing PI to infinity will still take the same amount of time if a
> > >single core runs at the same speed. :-)
> >

Well, actually, you do not get double the performance for the double the co=
res.  There is overhead of running the cores and communicating between them=
.. If Poulson was not actually more effective than double the performance th=
e system would not end up with an actual doubling.

> > >Before HP can convince Oracle to return to that IA64 thing, it needs t=
o
> > >provide some public strategy on its real intenstions with IA64. This i=
s
> > >something Apotheker failed to do in his strategy document of earlier
> > >this year and gave Oracle the ammunition to pull the plug.
> >
> > >It is time for HP to come out clean with unambiguous and credible
> > >statement on its intentions with IA64.
> >
> > You missed bootcamp!
> >
> There were lots of statements of intention re Alpha, with or without
> NDA, right up until the day it was canned.
>=20

NONE of the OpenVMS Boot Camp presentations were presented under either Con=
fidential Data Agreements nor Non-Disclosure Agreements.  The attendees are=
 free to share the presentations with anyone.

But I must agree with Brian that "You should have been at the Boot Camp!".

Bill.

John Reagan wrote:

> The big problem is the Macro-32/BLISS register linkages. There is lots of 
> Macro-32 code (RMS relies heavily on those global register definitions) that 
> passes parameters in registers between Macro-32 and BLISS (and C as well). 
> Look at the x86 register set.  Even in full 64-bit mode, there are only 16 
> 64-bit wide registers.  How do you expect the Macro-32 compiler to take 
> existing code (which has references to registers higher than 16) and map it 
> to the x86 register set?  It was funky enough on Itanium (just look at the 
> Itanium register mapping algorithm and mouse pad) but it gets much harder 
> (if not simply impossible) on x86.
> 
> If the Macro-32 code didn't exist and all those register linkages were 
> normal call sequences, we wouldn't be having this conversation.
> 
> Some Macro-32 can be recoded into BLISS or C simply enough, but there are 
> some Macro-32 files that can't easily be converted.  There is Macro-32 code 
> that jumps between routines, enters via one routine's prologue but exits via 
> another routine's epilogues, etc.  Such code can't easily be representable 
> in C or BLISS.  That code needs more than just mechanical conversion.
> 
> John
> 
> 

You might be able to get around that by using a very thin layer virtual 
machine, which
would then leave the layers above unchanged. I'm sure much more 
experienced minds
have looked at this in depth already though...

Regards,

Chris

On Sep 29, 5:01=A0am, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "John Wallace" <johnwalla...@yahoo.co.uk> wrote in message
>
> news:a2184fb6-88ae-467f-ae69-d79889e1b26b@k15g2000yqd.googlegroups.com...
>
> >Can you name any specific examples of architectural impediments, other
> >than the ones below?
>
> The whole 2-mode vs 4-mode is a red herring. =A0Current x86 machines are
> sufficient.

Current x86 machines only have 2 levels of protection at the MMU
level.

> =A0Plus Burns Fisher told me that he could do it all on a 2-mode
> piece of hardware anyway. =A0(but Burns isn't on OpenVMS anymore...)

I would be interested in the details!  But I can believe that (not
enough VMS expert to tell).

> The big problem is the Macro-32/BLISS register linkages. There is lots of
> Macro-32 code (RMS relies heavily on those global register definitions) t=
hat
> passes parameters in registers between Macro-32 and BLISS (and C as well)=
..
> Look at the x86 register set. =A0Even in full 64-bit mode, there are only=
 16
> 64-bit wide registers. =A0How do you expect the Macro-32 compiler to take
> existing code (which has references to registers higher than 16) and map =
it
> to the x86 register set? =A0It was funky enough on Itanium (just look at =
the
> Itanium register mapping algorithm and mouse pad) but it gets much harder
> (if not simply impossible) on x86.

Ehh, VAX has only 16 registers, right ?

JD.

"ChrisQ" <meru@devnull.com> wrote in message 
news:K1Xgq.18$Wy4.15@newsfe05.ams2...
> John Reagan wrote:
>
>> The big problem is the Macro-32/BLISS register linkages. There is lots of 
>> Macro-32 code (RMS relies heavily on those global register definitions) 
>> that passes parameters in registers between Macro-32 and BLISS (and C as 
>> well). Look at the x86 register set.  Even in full 64-bit mode, there are 
>> only 16 64-bit wide registers.  How do you expect the Macro-32 compiler 
>> to take existing code (which has references to registers higher than 16) 
>> and map it to the x86 register set?  It was funky enough on Itanium (just 
>> look at the Itanium register mapping algorithm and mouse pad) but it gets 
>> much harder (if not simply impossible) on x86.
>>
>> If the Macro-32 code didn't exist and all those register linkages were 
>> normal call sequences, we wouldn't be having this conversation.
>>
>> Some Macro-32 can be recoded into BLISS or C simply enough, but there are 
>> some Macro-32 files that can't easily be converted.  There is Macro-32 
>> code that jumps between routines, enters via one routine's prologue but 
>> exits via another routine's epilogues, etc.  Such code can't easily be 
>> representable in C or BLISS.  That code needs more than just mechanical 
>> conversion.
>>
>> John
>>
>>
>
> You might be able to get around that by using a very thin layer virtual 
> machine, which
> would then leave the layers above unchanged. I'm sure much more 
> experienced minds
> have looked at this in depth already though...
>

Exception handling, interrupts, and register state all get involved.

John 

"john Doef" <doefjohn@gmail.com> wrote in message 
news:cf3969fa-cf78-4a13-aa50-4e7dc8a44174@dk6g2000vbb.googlegroups.com...

>Ehh, VAX has only 16 registers, right ?

But the source base for OpenVMS Alpha and OpenVMS Itanium has long since 
split from the 16-register 32-bit wide VAX source base.  If you want all the 
64-bit support, etc. then you need to start with the common source used for 
Alpha/Itanium.  That is full of registers references between 16-31 and all 
the EVAX_ and IA64_ builtins used for 64-bit data access.

John 

On 2011-09-29 13.27, John Reagan wrote:
> "john Doef"<doefjohn@gmail.com>  wrote in message
> news:cf3969fa-cf78-4a13-aa50-4e7dc8a44174@dk6g2000vbb.googlegroups.com...
>
>> Ehh, VAX has only 16 registers, right ?
>
> But the source base for OpenVMS Alpha and OpenVMS Itanium has long since
> split from the 16-register 32-bit wide VAX source base.  If you want all the
> 64-bit support, etc. then you need to start with the common source used for
> Alpha/Itanium.  That is full of registers references between 16-31 and all
> the EVAX_ and IA64_ builtins used for 64-bit data access.

I doubt any of the Macro-32 code really tries to use more than 16 
registers...
As for Bliss code, it should be even less dependant upon register details.

However, I suspect a big hurdle to get VMS on x86 is the fact that they 
would need to actually port some of those tools to a new platform. From 
the sound of things, HP might not actually have the people capable of 
doing this anymore.

	Johnny

On 2011-09-28 23.17, Richard B. Gilbert wrote:
> On 9/28/2011 3:43 PM, JF Mezei wrote:
>> It is time for HP to come out clean with unambiguous and credible
>> statement on its intentions with IA64.
>>
>> The costs of porting the 3 OS to the 8086 are probably less than the
>> cost of continued payments to Intel to support continued development of
>> that IA64 thing.
>
> If it were possible to port VMS to the X86 platform, I think somebody
> would have done it long ago! Both VMS-VAX and VMS-Alpha have hardware
> dependencies that the X86 platforms cannot satisfy easily, or at all!

The only one who could do it is DEC/Compaq/HP. And they have not until 
recently had any incentive at all to do it.
First it was Alpha. When HP took over, it was Itanium.  Until the x86-64 
came along, there was no point at all in a port. And now it's sheer 
stubbornness to just stick with Itanium to squeeze the money out of VMS, 
while not ploughing any major money into it, which would be required for 
the port.

So no, even though it is possible, it have not really made any sense for 
the owners to do it.

	Johnny

In article <0lfcl8-n91.ln1@nntp.local.net>, Single Stage to Orbit <alex.buell@munted.org.uk> writes:
> On Wed, 2011-09-28 at 20:29 +0000, VAXman-@SendSpamHere.ORG wrote:
>> First off, I think that there are some real architecture impediments
>> in
>> X86 for the porting of VMS to it. =20
>>=20
>> Secondly, the ports to Alpha and Itanium had a compiler group that was
>> instrumental in creating the Macro-32 and Bliss compilers for these
>> two architectures.  Until those compilers exist, forget about porting.
>> I'm still not convinced the protections afforded by supervisor and
>> executive modes can be easily/readily overcome if moved to X86.=20
> 
> There is the ring 0 - 3 security model on x86 and also DEC did write a
> BLISS compiler for the x86 many moons ago.=20
> --=20
> Tactical Nuclear Kittens

   And there is (was?) a group writing a portable bliss compiler.

   But converting complex VAX instructions to one or more simple
   instructions for Alpha or IA64 is a lot easier than converting
   them to complex x86 instructions for IA32 or IA32-64.  So I'm not
   holding my breath for a Macro-32 compiler for x86.

In article <Vbednf_vfPPpQh7TnZ2dnUVZ_tOdnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:

> How do you expect the Macro-32 compiler to take 
> existing code (which has references to registers higher than 16) and map it 
> to the x86 register set? 

   What register higher than 16?  VAXen have 16 registers and all my
   Macro-32 code uses only them.  Do you expect there's a lot of references
   to R17 from instruction formats that only use 4 bits to encode the
   register number?

In article <cq-dnfoliO6zyxnTnZ2dnUVZ_radnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
> 
> But the source base for OpenVMS Alpha and OpenVMS Itanium has long since 
> split from the 16-register 32-bit wide VAX source base.  If you want all the 
> 64-bit support, etc. then you need to start with the common source used for 
> Alpha/Itanium.  That is full of registers references between 16-31 and all 
> the EVAX_ and IA64_ builtins used for 64-bit data access.

   So you think there's a lot of Macro-32 code in VMS that was kept, but
   modified to use non-VAX features?  I find that hard to believe. 
   Perhaps you could convince me with a line count?

"Bob Koehler" <koehler@eisner.nospam.encompasserve.org> wrote in message 
news:aaai1o5rNGwL@eisner.encompasserve.org...
> In article <cq-dnfoliO6zyxnTnZ2dnUVZ_radnZ2d@earthlink.com>, "John Reagan" 
> <johnrreagan@earthlink.net> writes:
>>
>> But the source base for OpenVMS Alpha and OpenVMS Itanium has long since
>> split from the 16-register 32-bit wide VAX source base.  If you want all 
>> the
>> 64-bit support, etc. then you need to start with the common source used 
>> for
>> Alpha/Itanium.  That is full of registers references between 16-31 and 
>> all
>> the EVAX_ and IA64_ builtins used for 64-bit data access.
>
>   So you think there's a lot of Macro-32 code in VMS that was kept, but
>   modified to use non-VAX features?  I find that hard to believe.
>   Perhaps you could convince me with a line count?
>

Probably not. 

In article <soPvVu6dpPym@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <Vbednf_vfPPpQh7TnZ2dnUVZ_tOdnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
>> How do you expect the Macro-32 compiler to take 
>> existing code (which has references to registers higher than 16) and map it 
>> to the x86 register set? 
>
>   What register higher than 16?  VAXen have 16 registers and all my
>   Macro-32 code uses only them.

If you elide the PC, FP and SP (and in some cases, the AP) you have
only 12 registers.

>  Do you expect there's a lot of references
>   to R17 from instruction formats that only use 4 bits to encode the
>   register number?

The calling standard on Alpha uses registers to pass arguments.  Thus,
to maintain some mapping to the VAX register base, these registers are
your sacred 16.

There are "macros" (especially some used by system code) which use one
or more of the non-hallowed 16 to perform feats.  
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

In article <aaai1o5rNGwL@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <cq-dnfoliO6zyxnTnZ2dnUVZ_radnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>> 
>> But the source base for OpenVMS Alpha and OpenVMS Itanium has long since 
>> split from the 16-register 32-bit wide VAX source base.  If you want all the 
>> 64-bit support, etc. then you need to start with the common source used for 
>> Alpha/Itanium.  That is full of registers references between 16-31 and all 
>> the EVAX_ and IA64_ builtins used for 64-bit data access.
>
>   So you think there's a lot of Macro-32 code in VMS that was kept, but
>   modified to use non-VAX features?  I find that hard to believe. 
>   Perhaps you could convince me with a line count?

OK.  I just SEARCHed/STATISITCS SYS for EVAX_.

Files searched:               470       Buffered I/O count:     19872
Records searched:         2303166       Direct I/O count:        2134
Characters searched:    111805774       Page faults:               28
Records matched:            17855       Elapsed CPU time:  0 00:00:20.25
Lines printed:              18459       Elapsed time:      0 00:00:31.75

I'd love to give you a percentage of lines of code modified but that would
require me to devise some method to elide the machine listing portion from
the source portion in the listing files.  Anyway, in just SYS, there are
close to 18K EVAX_ references according to my search.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:

>In article <Vbednf_vfPPpQh7TnZ2dnUVZ_tOdnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:

>> How do you expect the Macro-32 compiler to take 
>> existing code (which has references to registers higher than 16) and map it 
>> to the x86 register set? 

>   What register higher than 16?  VAXen have 16 registers and all my
>   Macro-32 code uses only them.  Do you expect there's a lot of references
>   to R17 from instruction formats that only use 4 bits to encode the
>   register number?

The registers above 16 on Alpha are mostly special usage.  R16-21 are
procedure argument parameters [x(AP) on VAX], R25 is also argument related 
although I don't recall how it's used (it may be little more than
0(AP) on VAX). R29 is the frame pointer, R30 stack pointer and R31
a hardwired zero/sink.  R22-24 are scratch (R28 "volatile" scratch).
I forget how R26/R27 are used other than procedure calls.

I don't see too much macro code (other than very specific Alpha boot-type
code) using these.  Compilers use these and of course would need to
avoid them.

On Sep 29, 11:41=A0am, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:
> koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> >In article <Vbednf_vfPPpQh7TnZ2dnUVZ_tOdn...@earthlink.com>, "John Reaga=
n" <johnrrea...@earthlink.net> writes:
> >> How do you expect the Macro-32 compiler to take
> >> existing code (which has references to registers higher than 16) and m=
ap it
> >> to the x86 register set?
> > =A0 What register higher than 16? =A0VAXen have 16 registers and all my
> > =A0 Macro-32 code uses only them. =A0Do you expect there's a lot of ref=
erences
> > =A0 to R17 from instruction formats that only use 4 bits to encode the
> > =A0 register number?
>
> The registers above 16 on Alpha are mostly special usage. =A0R16-21 are
> procedure argument parameters [x(AP) on VAX], R25 is also argument relate=
d
> although I don't recall how it's used (it may be little more than
> 0(AP) on VAX). R29 is the frame pointer, R30 stack pointer and R31
> a hardwired zero/sink. =A0R22-24 are scratch (R28 "volatile" scratch).
> I forget how R26/R27 are used other than procedure calls.
>
> I don't see too much macro code (other than very specific Alpha boot-type
> code) using these. =A0Compilers use these and of course would need to
> avoid them.

R25 is the argument count on entry to a routine.

Dan

In article <de61d83c-10bb-428b-9cb5-bb9ab29f5787@m37g2000yqc.googlegroups.com>, abrsvc <dansabrservices@yahoo.com> writes:
>On Sep 29, 11:41=A0am, moro...@world.std.spaamtrap.com (Michael Moroney)
>wrote:
>> koeh...@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> >In article <Vbednf_vfPPpQh7TnZ2dnUVZ_tOdn...@earthlink.com>, "John Reaga=
>n" <johnrrea...@earthlink.net> writes:
>> >> How do you expect the Macro-32 compiler to take
>> >> existing code (which has references to registers higher than 16) and m=
>ap it
>> >> to the x86 register set?
>> > =A0 What register higher than 16? =A0VAXen have 16 registers and all my
>> > =A0 Macro-32 code uses only them. =A0Do you expect there's a lot of ref=
>erences
>> > =A0 to R17 from instruction formats that only use 4 bits to encode the
>> > =A0 register number?
>>
>> The registers above 16 on Alpha are mostly special usage. =A0R16-21 are
>> procedure argument parameters [x(AP) on VAX], R25 is also argument relate=
>d
>> although I don't recall how it's used (it may be little more than
>> 0(AP) on VAX). R29 is the frame pointer, R30 stack pointer and R31
>> a hardwired zero/sink. =A0R22-24 are scratch (R28 "volatile" scratch).
>> I forget how R26/R27 are used other than procedure calls.
>>
>> I don't see too much macro code (other than very specific Alpha boot-type
>> code) using these. =A0Compilers use these and of course would need to
>> avoid them.
>
>R25 is the argument count on entry to a routine.

It's a bit more than that.  It's the Argument Information register.  The
low byte is the count of arguments.  Above this is a bit vector field of
3*6 bits.  This vector comes into play when passing floating point data.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

BillPedersen wrote:
> 
> But I must agree with Brian that "You should have been at the Boot Camp!".


You don't get it. My decision to leave VMS is done. I am still curious
just in case HP were to get religion and decide to leverage VMS to its
fullest extent.


I would not return to VMS unless HP made a big media splash about it.
Making a private  announcement at a conference with the few remaining
customers will not attract new customers nor change my mind.

It has gotten to a point where 25-30 year olds have never heard of VMS
and they work in IT.

HP's publically stated policy is to support existing customers. That is
what Ann Livermore said and this was repeated a few times. And it was
even part of the original "welcome to HP" announcement of may 7th 2002
wit the infamous Stallard memo.

Until HP makes signs that it wants to grow VMS and acquire new
cutsomers, there is no point in my returning to VMS.

On 9/28/2011 11:01 PM, John Reagan wrote:
> "John Wallace"<johnwallace4@yahoo.co.uk>  wrote in message
> news:a2184fb6-88ae-467f-ae69-d79889e1b26b@k15g2000yqd.googlegroups.com...
>
>> Can you name any specific examples of architectural impediments, other
>> than the ones below?
>
> The whole 2-mode vs 4-mode is a red herring.  Current x86 machines are
> sufficient.  Plus Burns Fisher told me that he could do it all on a 2-mode
> piece of hardware anyway.  (but Burns isn't on OpenVMS anymore...)
>
>
> The big problem is the Macro-32/BLISS register linkages. There is lots of
> Macro-32 code (RMS relies heavily on those global register definitions) that
> passes parameters in registers between Macro-32 and BLISS (and C as well).
> Look at the x86 register set.  Even in full 64-bit mode, there are only 16
> 64-bit wide registers.  How do you expect the Macro-32 compiler to take
> existing code (which has references to registers higher than 16) and map it
> to the x86 register set?  It was funky enough on Itanium (just look at the
> Itanium register mapping algorithm and mouse pad) but it gets much harder
> (if not simply impossible) on x86.
>
> If the Macro-32 code didn't exist and all those register linkages were
> normal call sequences, we wouldn't be having this conversation.
>
> Some Macro-32 can be recoded into BLISS or C simply enough, but there are
> some Macro-32 files that can't easily be converted.  There is Macro-32 code
> that jumps between routines, enters via one routine's prologue but exits via
> another routine's epilogues, etc.  Such code can't easily be representable
> in C or BLISS.  That code needs more than just mechanical conversion.
>

If I saw code like that, I'd be inclined to question both the sanity AND 
the programming skills of the person who wrote it.  What you seem to be 
describing is frequently called "spaghetti code".  It's usually 
somewhere between extremely difficult and impossible to maintain.

Frequently there are no comments or other documentation that might 
explain what the author was trying to accomplish. I saw quite a lot
of that sort of code in the early 1970s through the 1990s.

John Reagan wrote:
> "John Wallace" <johnwallace4@yahoo.co.uk> wrote in message 
> news:a2184fb6-88ae-467f-ae69-d79889e1b26b@k15g2000yqd.googlegroups.com...
> 
>> Can you name any specific examples of architectural impediments, other
>> than the ones below?
> 
> The whole 2-mode vs 4-mode is a red herring.  Current x86 machines are 
> sufficient.  Plus Burns Fisher told me that he could do it all on a 2-mode 
> piece of hardware anyway.  (but Burns isn't on OpenVMS anymore...)

Right.  From the VAX instruction set point of view, everything is two 
mode.  Privileged (interrupt, kernel) and unprivileged (exec, super, user).

Everything else is memory map.  And the X86 memory map can handle VMS.

There are certain VMS constructs that may not be efficient to implement 
on X86, but efficiency problems can be dealt with by a fast enough 
processor.

As far as a lack of registers is concerned, you can always have an X86 
register pointing to a block of memory containing the "VMS registers". 
It is not optimal, but it works.  (FWIW: I don't necessarily recommend 
this implementation, I'm just throwing it out there as an option.)

Actually, it is not as bad as it sounds as this is basically the X86 
programming model (registers pointing to blocks of memory) and the X86 
hardware dedicates a lot of transistors to making it work.  Essentially, 
the on chip cache becomes a large register block.

This should only affect Macro code anyway.  Native compilers would not 
need to use that model.

I haven't seen anything in the X86 architecture which would preclude 
porting VMS.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris@applied-synergy.com
   Fax: 817-237-3074

On 2011-09-29 16.06, Bob Koehler wrote:
> In article<0lfcl8-n91.ln1@nntp.local.net>, Single Stage to Orbit<alex.buell@munted.org.uk>  writes:
>> On Wed, 2011-09-28 at 20:29 +0000, VAXman-@SendSpamHere.ORG wrote:
>>> First off, I think that there are some real architecture impediments
>>> in
>>> X86 for the porting of VMS to it. =20
>>> =20
>>> Secondly, the ports to Alpha and Itanium had a compiler group that was
>>> instrumental in creating the Macro-32 and Bliss compilers for these
>>> two architectures.  Until those compilers exist, forget about porting.
>>> I'm still not convinced the protections afforded by supervisor and
>>> executive modes can be easily/readily overcome if moved to X86.=20
>>
>> There is the ring 0 - 3 security model on x86 and also DEC did write a
>> BLISS compiler for the x86 many moons ago.=20
>> --=20
>> Tactical Nuclear Kittens
>
>     And there is (was?) a group writing a portable bliss compiler.
>
>     But converting complex VAX instructions to one or more simple
>     instructions for Alpha or IA64 is a lot easier than converting
>     them to complex x86 instructions for IA32 or IA32-64.  So I'm not
>     holding my breath for a Macro-32 compiler for x86.

Why converting complex VAX instructions into complex x86 instructions? 
There is, as far as I know, no law that forces you to do this. Convert 
the complex VAX instruction into a series of simple x86 instructions 
instead. Easy. Besides, there is probably nothing hairier than 
converting anything into Itanium code...

There is nothing really technically challenging about porting VMS to 
x86-64. It just takes loads of resources, which is why it probably will 
not happen.

	Johnny

On 2011-09-29 17.21, VAXman- @SendSpamHere.ORG wrote:
> In article<soPvVu6dpPym@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article<Vbednf_vfPPpQh7TnZ2dnUVZ_tOdnZ2d@earthlink.com>, "John Reagan"<johnrreagan@earthlink.net>  writes:
>>
>>> How do you expect the Macro-32 compiler to take
>>> existing code (which has references to registers higher than 16) and map it
>>> to the x86 register set?
>>
>>    What register higher than 16?  VAXen have 16 registers and all my
>>    Macro-32 code uses only them.
>
> If you elide the PC, FP and SP (and in some cases, the AP) you have
> only 12 registers.

True. But then you are talking about registers for general use. There 
are 16 registers in the VAX. How they are used, and sometimes forced 
into use is not really relevant, is it?

>>   Do you expect there's a lot of references
>>    to R17 from instruction formats that only use 4 bits to encode the
>>    register number?
>
> The calling standard on Alpha uses registers to pass arguments.  Thus,
> to maintain some mapping to the VAX register base, these registers are
> your sacred 16.
>
> There are "macros" (especially some used by system code) which use one
> or more of the non-hallowed 16 to perform feats.

Not sure how the Alpha calling conventions comes into this. If you want 
to compile Macro-32 code on an x86, why would Alpha calling conventions 
be relevant? I would expect the Macro-32 compiler on x86 to instead use 
(generate code for) whatever calling conventions that are decided upon 
for the x86.

	Johnny

Single Stage to Orbit wrote 2011-09-28 23:19:
> On Wed, 2011-09-28 at 20:29 +0000, VAXman-@SendSpamHere.ORG wrote:
>> First off, I think that there are some real architecture impediments
>> in
>> X86 for the porting of VMS to it.
>>
>> Secondly, the ports to Alpha and Itanium had a compiler group that was
>> instrumental in creating the Macro-32 and Bliss compilers for these
>> two architectures.  Until those compilers exist,...

Wasn't there a Bliss compiler supporting the Rdb(8) for Windows port ?
Lack of support (that Oracle could trust on) canned that project.
But the compiler must have been there in some form.

On Sep 29, 5:12=A0am, BillPedersen <peder...@ccsscorp.com> wrote:
> On Wednesday, September 28, 2011 5:48:20 PM UTC-4, John Wallace wrote:
> > On Sep 28, 9:29=A0pm, VAXman- =A0@SendSpamHere.ORG wrote:
> > > In article <4e837900$0$2216$c3e8da3$4605...@news.astraweb.com>, JF Me=
zei <jfmezei...@vaxination.ca> writes:
>
> > > >Keith Cayemberg wrote:
> > > >> HP Users Hope Whitman Can Persuade Oracle to Change Itanium Decisi=
on
> > > >>http://tinyurl.com/3zfo5dp
>
> > > >I didn't expect to see an article mention VMS =A0!!!
>
> The folks at Connect worked hard to get press exposure for the Boot Camp =
this year.
>
> > > >If Poulson will only double the performance, then it is not very
> > > >imporessive since this is just achieved by doubling the number of co=
res.
> > > >Computing PI to infinity will still take the same amount of time if =
a
> > > >single core runs at the same speed. :-)
>
> Well, actually, you do not get double the performance for the double the =
cores. =A0There is overhead of running the cores and communicating between =
them. If Poulson was not actually more effective than double the performanc=
e the system would not end up with an actual doubling.
>
> > > >Before HP can convince Oracle to return to that IA64 thing, it needs=
 to
> > > >provide some public strategy on its real intenstions with IA64. This=
 is
> > > >something Apotheker failed to do in his strategy document of earlier
> > > >this year and gave Oracle the ammunition to pull the plug.
>
> > > >It is time for HP to come out clean with unambiguous and credible
> > > >statement on its intentions with IA64.
>
> > > You missed bootcamp!
>
> > There were lots of statements of intention re Alpha, with or without
> > NDA, right up until the day it was canned.
>
> NONE of the OpenVMS Boot Camp presentations were presented under either C=
onfidential Data Agreements nor Non-Disclosure Agreements. =A0The attendees=
 are free to share the presentations with anyone.
>
> But I must agree with Brian that "You should have been at the Boot Camp!"=
..
>
> Bill.

It's good to hear that none of the bootcamp stuff was under NDA (this
is a change from previous years, right?).

So whose permission is needed to post as much of the content as
possible, and once that is permission is obtained, who is going to
post it, or at least post a slightly more detailed summary than the
highlights we enjoyed last week?

On Sep 29, 9:01=A0pm, Johnny Billquist <b...@softjar.se> wrote:
> On 2011-09-29 17.21, VAXman- @SendSpamHere.ORG wrote:
>
> > In article<soPvVu6dp...@eisner.encompasserve.org>, koeh...@eisner.nospa=
m.encompasserve.org (Bob Koehler) writes:
> >> In article<Vbednf_vfPPpQh7TnZ2dnUVZ_tOdn...@earthlink.com>, "John Reag=
an"<johnrrea...@earthlink.net> =A0writes:
>
> >>> How do you expect the Macro-32 compiler to take
> >>> existing code (which has references to registers higher than 16) and =
map it
> >>> to the x86 register set?
>
> >> =A0 =A0What register higher than 16? =A0VAXen have 16 registers and al=
l my
> >> =A0 =A0Macro-32 code uses only them.
>
> > If you elide the PC, FP and SP (and in some cases, the AP) you have
> > only 12 registers.
>
> True. But then you are talking about registers for general use. There
> are 16 registers in the VAX. How they are used, and sometimes forced
> into use is not really relevant, is it?
>
> >> =A0 Do you expect there's a lot of references
> >> =A0 =A0to R17 from instruction formats that only use 4 bits to encode =
the
> >> =A0 =A0register number?
>
> > The calling standard on Alpha uses registers to pass arguments. =A0Thus=
,
> > to maintain some mapping to the VAX register base, these registers are
> > your sacred 16.
>
> > There are "macros" (especially some used by system code) which use one
> > or more of the non-hallowed 16 to perform feats.
>
> Not sure how the Alpha calling conventions comes into this. If you want
> to compile Macro-32 code on an x86, why would Alpha calling conventions
> be relevant? I would expect the Macro-32 compiler on x86 to instead use
> (generate code for) whatever calling conventions that are decided upon
> for the x86.
>
> =A0 =A0 =A0 =A0 Johnny

I suspect (but await confirmation) that the problem arises because of
the *mixture* of compiled code and "Macro-32" code, with different and
incompatible calling conventions which would need to interwork somehow
on x86-64, and would therefore need to be updated in a minimally
disruptive way as part of an x86-64 port. Either one on its own would
likely be fine, but that's not where the source code is today.

There's a premium for someone to pay at some stage, either to cover
the cost of the (relatively) low volume of IA64 vs x86-64, or to cover
the cost of getting a set of clean interfaces (or clean code) as part
of the x86-64 port.

"Chris Scheers" <chris@applied-synergy.com> wrote in message 
news:j62fd1$qse$1@dont-email.me...
>
> Actually, it is not as bad as it sounds as this is basically the X86 
> programming model (registers pointing to blocks of memory) and the X86 
> hardware dedicates a lot of transistors to making it work.  Essentially, 
> the on chip cache becomes a large register block.
>
> This should only affect Macro code anyway.  Native compilers would not 
> need to use that model.

There are very few Macro-32 only programs.  OpenVMS itself is a mixture of 
Macro-32, BLISS, and C.  There are extensive uses of register linkages that 
make it all blur together.

Plus where you do you put those memory locations?  Even ASTs get interesting 
to manage.  Plus interrupts, switching to kernel mode, etc. all makes it 
more interesting.  Personally, I'd invent some "fixed" locations in P1 space 
and have the OS double map that memory to someplace that it can manage 
properly.

I didn't say it was impossible.  I said that Macro-32, all the global 
register linkages, and the use (in some cases isolated, in some cases not) 
of registers beyond 15 make it a little more difficult.

John 

"Jan-Erik Soderholm" <jan-erik.soderholm@telia.com> wrote in message 
news:j62lej$g5h$1@news.albasani.net...
> Single Stage to Orbit wrote 2011-09-28 23:19:
>> On Wed, 2011-09-28 at 20:29 +0000, VAXman-@SendSpamHere.ORG wrote:
>>> First off, I think that there are some real architecture impediments
>>> in
>>> X86 for the porting of VMS to it.
>>>
>>> Secondly, the ports to Alpha and Itanium had a compiler group that was
>>> instrumental in creating the Macro-32 and Bliss compilers for these
>>> two architectures.  Until those compilers exist,...
>
> Wasn't there a Bliss compiler supporting the Rdb(8) for Windows port ?
> Lack of support (that Oracle could trust on) canned that project.
> But the compiler must have been there in some form.
>

Yes.  The BLISS compiler had sufficient functionality to built itself and 
RDB.  For instance GLOBAL REGISTERs were hacked to some static locations in 
a BLISS RTL.  Worked fine on Windows for what it was needed.  Wouldn't 
extend very well to OpenVMS with ASTs, unwinding, LIB$ calling standard 
routines, etc.

John 

Since Macro-32 has been a compiled language on Alpha and IA64, it would
also be compiled language on 64 bit 8086s.

Doesn't that make it easy for the compiler to virtualise registers not
present on the x86 and just make sure that other compilers that also
make use of those registers use the same virtualisation method ?

We're not talking about moving Alpha or IA64 assembly language to X86,
we're talking about porting what has become compiled code.

In article <00AB6222.6DE21894@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
> 
> The calling standard on Alpha uses registers to pass arguments.  Thus,
> to maintain some mapping to the VAX register base, these registers are
> your sacred 16.

   When I port Macro-32 to Alpha, I use the macros that push the
   arguments into RAM, VAX style.  If I had to make enough changes to
   Macro-32 code to pass the arguments via registers I think I'd really
   be tempted to recode.

   I don't have access to the current listings CD.  I can't say nobody
   in VMS Engineering used R17.  But for that kind of thing to be a
   big impediment to a port to x86, like in the message I was following
   up, seems like harping on the wrong issue.

In article <OHUNoLPgYAW5@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <00AB6222.6DE21894@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>> 
>> The calling standard on Alpha uses registers to pass arguments.  Thus,
>> to maintain some mapping to the VAX register base, these registers are
>> your sacred 16.
>
>   When I port Macro-32 to Alpha, I use the macros that push the
>   arguments into RAM, VAX style.  If I had to make enough changes to
>   Macro-32 code to pass the arguments via registers I think I'd really
>   be tempted to recode.

You used the .CALL_ENTRY HOME_ARGS=TRUE which copies the R16-R21 register
passed arguments to memory to feign a VMS style argument list.   You did
NOT pass those arguments VAX-style.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

In article <00AB6223.3905E802@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
> 
> OK.  I just SEARCHed/STATISITCS SYS for EVAX_.
> 
> Files searched:               470       Buffered I/O count:     19872
> Records searched:         2303166       Direct I/O count:        2134
> Characters searched:    111805774       Page faults:               28
> Records matched:            17855       Elapsed CPU time:  0 00:00:20.25
> Lines printed:              18459       Elapsed time:      0 00:00:31.75

   Thanks, that's the kind of thing I wanted to know.  But the OP was
   worried about R17 and higher number registers, I wonder how many
   references there are, and how many are argument registers.

   I suspect R17 et. al. are easier to deal with than some of the EVAX_
   macros.  In many cases R22 - R30 can simply be emulated in RAM.
 
> I'd love to give you a percentage of lines of code modified but that would
> require me to devise some method to elide the machine listing portion from
> the source portion in the listing files.  Anyway, in just SYS, there are
> close to 18K EVAX_ references according to my search.

   IIRC, there was a tool in the old SIG tapes to do that.  Probably
   still hanging around in the archives.  But 18K EVAX_ macros is a
   sufficient number.

In article <4e84bcd0$0$32735$c3e8da3$76491128@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> You don't get it. My decision to leave VMS is done. I am still curious
> just in case HP were to get religion and decide to leverage VMS to its
> fullest extent.

   Goodbye.

In article <GcudnSEWz7txIBnTnZ2dnUVZ_j2dnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> On 9/28/2011 11:01 PM, John Reagan wrote:

>> Some Macro-32 can be recoded into BLISS or C simply enough, but there are
>> some Macro-32 files that can't easily be converted.  There is Macro-32 code
>> that jumps between routines, enters via one routine's prologue but exits via
>> another routine's epilogues, etc.  Such code can't easily be representable
>> in C or BLISS.  That code needs more than just mechanical conversion.
>>
> 
> If I saw code like that, I'd be inclined to question both the sanity AND 
> the programming skills of the person who wrote it.  What you seem to be 
> describing is frequently called "spaghetti code".  It's usually 
> somewhere between extremely difficult and impossible to maintain.

   Having worked on device drivers, I don't consider that kind of
   code insane, and I know it takes a very good set of programming
   skills.

   But that kind of code doesn't port from VAX to Alpha trivially since
   their calling standards are so different.  Again, we can look at the
   changes made to device drivers as good examples of where the VMS
   kernel was already very much changed in the port to Alpha.

In article <j62fd1$qse$1@dont-email.me>, Chris Scheers <chris@applied-synergy.com> writes:
> 
> I haven't seen anything in the X86 architecture which would preclude 
> porting VMS.

   The last thing I saw was circa 386, where the IA32 used a segmented
   memory model and VAXen used a paged memory model.

   There are many virtual memory OS up and running on x86, and I'm 
   under the impression that current chips deal with a page model
   fairly well (page size being more of an MMU issue than a CPU
   issue), and segment registers can simply be set up for a flat
   address space.

In article <j62iha$rm3$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Why converting complex VAX instructions into complex x86 instructions? 

   Performance and other resource issues.

   Of course, someone will just say "Get a faster chip and buy more
   memory".

In article <j62iq8$rmr$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> Not sure how the Alpha calling conventions comes into this. If you want 
> to compile Macro-32 code on an x86, why would Alpha calling conventions 
> be relevant? I would expect the Macro-32 compiler on x86 to instead use 
> (generate code for) whatever calling conventions that are decided upon 
> for the x86.

   If you look at the guide to porting Macro-32 to Alpha, you will find
   it's not quite all handled by the compiler.

On 29-9-2011 20:45, JF Mezei wrote:
> I would not return to VMS unless HP made a big media splash about it.
> Making a private  announcement at a conference with the few remaining
> customers will not attract new customers nor change my mind.

Because popularity is the only important aspect of an operating
system.  How many people nowadays hear frequently about AIX, HP-UX,
NonStop, i5/OS or IBM i?


> It has gotten to a point where 25-30 year olds have never heard of VMS
> and they work in IT.

Would you like to guess my age?


> Until HP makes signs that it wants to grow VMS and acquire new
> cutsomers, there is no point in my returning to VMS.

Does that mean the amount of gossip on comp.os.vms will be cut back
drastically from now on?  That just breaks my heart.

  - MG

On 9/28/2011 5:17 PM, Richard B. Gilbert wrote:
> If it were possible to port VMS to the X86 platform, I think somebody
> would have done it long ago! Both VMS-VAX and VMS-Alpha have hardware
> dependencies that the X86 platforms cannot satisfy easily, or at all!

I think that is a myth.

If there was a will (to fund the effort) to do it, then it
could be done.

VMS has already been through 2 arch migrations.

If something is missing in x86-64 then the OS would need
to change to fill the gap.

Arne

In article <Rlb9Litw5GQv@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <00AB6223.3905E802@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
>> 
>> OK.  I just SEARCHed/STATISITCS SYS for EVAX_.
>> 
>> Files searched:               470       Buffered I/O count:     19872
>> Records searched:         2303166       Direct I/O count:        2134
>> Characters searched:    111805774       Page faults:               28
>> Records matched:            17855       Elapsed CPU time:  0 00:00:20.25
>> Lines printed:              18459       Elapsed time:      0 00:00:31.75
>
>   Thanks, that's the kind of thing I wanted to know.  But the OP was
>   worried about R17 and higher number registers, I wonder how many
>   references there are, and how many are argument registers.
>
>   I suspect R17 et. al. are easier to deal with than some of the EVAX_
>   macros.  In many cases R22 - R30 can simply be emulated in RAM.

Memory is slow.

 
>> I'd love to give you a percentage of lines of code modified but that would
>> require me to devise some method to elide the machine listing portion from
>> the source portion in the listing files.  Anyway, in just SYS, there are
>> close to 18K EVAX_ references according to my search.
>
>   IIRC, there was a tool in the old SIG tapes to do that.  Probably
>   still hanging around in the archives.  But 18K EVAX_ macros is a
>   sufficient number.

Yeah, I can probably run the SYS listings through that tool but that's
more effort than I wanted to do to answer your question.  I can, when
I am back home, see about counting the actual excess of R16 registers 
used.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

All your spirit rack abuses, come to haunt you back by day.
All your Byzantine excuses, given time, given you away.

On Oct 1, 2:37=A0am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> On 9/28/2011 5:17 PM, Richard B. Gilbert wrote:
>
> > If it were possible to port VMS to the X86 platform, I think somebody
> > would have done it long ago! Both VMS-VAX and VMS-Alpha have hardware
> > dependencies that the X86 platforms cannot satisfy easily, or at all!
>
> I think that is a myth.
>
> If there was a will (to fund the effort) to do it, then it
> could be done.
>
> VMS has already been through 2 arch migrations.
>
> If something is missing in x86-64 then the OS would need
> to change to fill the gap.
>
> Arne

"If something is missing in x86-64 then the OS would need to change to
fill the gap."

There is at least one other possibility to look at. x86-64 changes to
fill the gap.

Reasonably widely understood is the fact that today's x86-64 chips and
systems don't actually yet address the high end IA64 market - the
ultra-massive-memory, ultra-massive-SMP systems that presumably some
customers are paying good money for. Proliant still "only" goes up to
64 cores and 2TB of memory. Presumably that's not enough for some
people's apps in a quasi-general-purpose computer (ie not a specialist
supercomputer of some flavour).

But I suspect if we wait a bit, x86-64 continues to grow upwards,
needing no significant/specific funding from HP. Whereas IA64 only has
one customer, and they have to fully fund everything.

On the other hand it is now clearer to me that there is a genuine
issue with the number of registers needed to support "legacy" (=3D"stuff
that works") VMS code on x86. x86-64 has quite a few general
registers, but many modern processors have more. In both cases, there
are probably more registers implemented than are visible to the
programmer; many of them are hidden by "register renaming" and such
and are there to support things like speculative execution and the
like. I wonder what it would take to make enough of them visible again
(vs the costs of code changes in VMS to support a 16-register world).
Making the registers visible is probably a silly idea, given that it
would likely need changes to instruction encodings etc, so let's
forget that.

So the medium term choices look like: HP (ie HP customers) pay to stay
with IA64 or HP pay to port the VMS code.

Any thoughts from anyone on posting (some or all of) the bootcamp
materials?

John Wallace wrote:

> Reasonably widely understood is the fact that today's x86-64 chips and
> systems don't actually yet address the high end IA64 market - the
> ultra-massive-memory, ultra-massive-SMP systems that presumably some
> customers are paying good money for. 


Considering that the 8086 shares the same memory subsystem as IA64, does
IA64 have any advantage over the 8086 ?

Just because HP has decided to not build "mainframe" class 8086s does
not mean that the current chips are not able to scale to that size. This
could be a business decision as opposed to a technical one.

On 1-10-2011 19:36, JF Mezei wrote:
> Considering that the 8086 shares the same memory subsystem as IA64, does
> IA64 have any advantage over the 8086 ?
>
> Just because HP has decided to not build "mainframe" class 8086s does
> not mean that the current chips are not able to scale to that size. This
> could be a business decision as opposed to a technical one.

The SGI, let alone under its current ownership (with a very favourable
attitude towards x86/-64), never made that "business decision".  Yet,
their IA-64 "Altix" line still scales way beyond the x86/-64 systems
that they're selling at the moment.  So, how do you explain that?

Let's compare SGI's current NUMAlink-based server annex supercomputer 
offerings:

	- SGI Altix 4700 (Itanium, i.e. 9000)
	Capable of scaling up to maximum of 512 processor sockets
	and 128 terabytes(!) of memory.

	- SGI Altix UV (Xeon, i.e. E7)
	Capable of scaling up to maximum of 256 processor sockets
	and 16 terabytes of memory.


Lastly, why are you so concerned?  Didn't you say you stopped using VMS
and see no point in using it?

  - MG

On 1-10-2011 19:36, JF Mezei wrote:
> Considering that the 8086 shares the same memory subsystem as IA64, does
> IA64 have any advantage over the 8086 ?
>
> Just because HP has decided to not build "mainframe" class 8086s does
> not mean that the current chips are not able to scale to that size. This
> could be a business decision as opposed to a technical one.

The SGI, let alone under its current ownership (with a very favourable
attitude towards x86/-64, to say the least), never made that "business
decision".  Yet, their IA-64 "Altix" line still scales way beyond the
x86/-64 systems that they're selling at the moment.  So, how do you
explain that?

Let's compare SGI's current NUMAlink-based server annex supercomputer
offerings:

     - SGI Altix 4700 (Itanium, i.e. 9000)
     Capable of scaling up to a maximum of 512 processor sockets
     and 128 terabytes(!) of memory.

     - SGI Altix UV (Xeon, i.e. E7)
     Capable of scaling up to a maximum of 256 processor sockets
     and 16 terabytes of memory.


Lastly, why are you so concerned?  Didn't you say you stopped using VMS
and see no point in using it?

  - MG

On Oct 1, 6:36=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> John Wallace wrote:
> > Reasonably widely understood is the fact that today's x86-64 chips and
> > systems don't actually yet address the high end IA64 market - the
> > ultra-massive-memory, ultra-massive-SMP systems that presumably some
> > customers are paying good money for.
>
> Considering that the 8086 shares the same memory subsystem as IA64, does
> IA64 have any advantage over the 8086 ?
>
> Just because HP has decided to not build "mainframe" class 8086s does
> not mean that the current chips are not able to scale to that size. This
> could be a business decision as opposed to a technical one.

Afaik there's no architectural reason why AMD64/x86-64 (please, do try
not to call it 8086, it has little in common other than the mass
market software it can run) could not quite quickly and quite cheaply
support as many cores and CPUs as IA64. Such a CPU chip (and the
corresponding support chips and system designs) would be relatively
low volume vs their mass market brethren (as is IA64 vs x86-64) but a
great deal of the design (and the software) would be common, assuming
we are talking general purpose Proliant-style boxes and not something
HPC-specific.

Whether it would make commercial sense to do that is a different
decision, but it is hard to see how a relatively minor upgrade to an
existing chip + system + software ecosystem to add a bit more capacity
for a niche of a high volume market could possibly be any more
expensive than paying to keep an entire low volume ecosystem (chip +
system + software + dealer channels + tech support + ...) on life
support, which is what's happening with IA64 vs x86-64.

So, for any system where x86-64 is able to compete directly against
IA64, the fundamentals of costs vs volumes say that IA64 is more
expensive than the x86-64 competition. In the same way as those
fundamentals were used to justify the cancellation of Alpha. Outside
that sector (e.g. for ultra-massive-memory ultra-massive-SMP, be it
commercial or HPC or whatever), there are different considerations.

The question then becomes, how does the extra expense of keeping IA64
on life support (perhaps originally as a face-saving exercise for some
now-departed senior people?) compare against the cost of  yet another
port of an operating system and the associated costs (assuming it's
practical which again is a different question altogether).

That operating system would typically be VMS round here, but exactly
the same question could be asked for any other IA64 OS e.g. Windows
Server (deceased on IA64), or whatever runs on SGI Altix on IA64. The
answer to the question might be different depending on the arithmetic
of the market and the specifics of the OS, and indeed on the politics
of the market. HPC was IA64s last great white hope, so maybe there's
still some dealing going on behind the scenes, or maybe the HPC market
is just not big enough to justify the required investment in ultra-
massive memory ultra-massive-SMP chip and system designs based around
future AMD64 rather than today's IA64. Is the OS on Altix still Suse
Linux Enterprise Server? That's one of the last Linuxes with IA64
support. As always, low volumes generally make the economics less
favourable. I like Suse but I wouldn't want to bet my business on it
right now.

Intel haven't had a real commercial success outside the Wintel market
for a decade or more, though they're still doing fine with x86-64, and
x86-64 isn't going away for the foreseeable future.

IA64 certainly isn't that non-Wintel success. Before IA64, who
remembers iAPX432, or i960, or their I2O IO accelerator strategy (aka
"here's a way to shift those i960s again"), or WiMax, or any of the
various other non-Wintel products that were going to be "the next big
thing". All vanished, largely without trace.

Intel even made the wrong decision with StrongARM and family, despite
it being handed to them on a plate. OK IA64 does the advantage of
having eliminated one competitive technology and in the process having
acquired some of its designers expertise, and another potentially
competitive technology is in the hands of a company whose senior
management are behaving like they might have some "issues" to resolve.
But it'll take more than that.

Given that track record, it would be a brave person that would bet on
IA64 being around in new designs in five years. These days it's a bit
short sighted for a business to be focusing on the hardware rather
than the software; if it's VMS that's important, just make sure the IT
department don't have a Dell-only policy (like my current employers
do).

On Oct 1, 9:33=A0pm, MG <marcog...@SPAMxs4all.nl> wrote:
> On 1-10-2011 19:36, JF Mezei wrote:
>
> > Considering that the 8086 shares the same memory subsystem as IA64, doe=
s
> > IA64 have any advantage over the 8086 ?
>
> > Just because HP has decided to not build "mainframe" class 8086s does
> > not mean that the current chips are not able to scale to that size. Thi=
s
> > could be a business decision as opposed to a technical one.
>
> The SGI, let alone under its current ownership (with a very favourable
> attitude towards x86/-64), never made that "business decision". =A0Yet,
> their IA-64 "Altix" line still scales way beyond the x86/-64 systems
> that they're selling at the moment. =A0So, how do you explain that?
>
> Let's compare SGI's current NUMAlink-based server annex supercomputer
> offerings:
>
> =A0 =A0 =A0 =A0 - SGI Altix 4700 (Itanium, i.e. 9000)
> =A0 =A0 =A0 =A0 Capable of scaling up to maximum of 512 processor sockets
> =A0 =A0 =A0 =A0 and 128 terabytes(!) of memory.
>

In fact, 256 blades * 32GB/blade =3D 8 TB. 128 TB is an address space,
not the real memory you could plug into it.


> =A0 =A0 =A0 =A0 - SGI Altix UV (Xeon, i.e. E7)
> =A0 =A0 =A0 =A0 Capable of scaling up to maximum of 256 processor sockets
> =A0 =A0 =A0 =A0 and 16 terabytes of memory.
>

256 sockets, 16 TB  is a limitation for directly addressable memory in
a single system image.
256 sockets =3D 2560 cores, 2.5 times more than 1024 cores in SGI Altix
4700. And each core in UV is way faster than that of 4700.
SpecFp_rate(base):
Altix UV - 128 sockets/1280 cores - 20500, 16/core
Altix 4700 (bandwidth nodes) - 128 sockets/256 cores - 3420, 13.4/core
Altix 4700 (density nodes)  - 64 sockets/128 cores - 1460, 11.4/core
Now, take into account that 512 sockets in Altix 4700 are only
possible with density nodes. Bandwidth nodes are limited to 256
sockets.

It is possible to hook several Altix UV systems together with the same
NUMAlink interconnects that are used within a single system and have
up to 1 PB of non-cache coherent globally-addressable memory. I don't
understand that tech sufficiently well to say more.

Bottom line:
Altix 4700 is not just dead, it's starting to get cold in the grave.
If you don't believe me - ask SGI.

On 2-10-2011 14:44, Michael S wrote:
> Bottom line:
> Altix 4700 is not just dead, it's starting to get cold in the grave.
> If you don't believe me - ask SGI.

Explain: Why is it still being sold by SGI and on top of their product
offerings?

  - MG

On 2-10-2011 14:44, Michael S wrote:

I forgot to comment on this:

> In fact, 256 blades * 32GB/blade = 8 TB. 128 TB is an address space,
> not the real memory you could plug into it.
>
> 256 sockets, 16 TB  is a limitation for directly addressable memory in
> a single system image.
>
> 256 sockets = 2560 cores, 2.5 times more than 1024 cores in SGI Altix
> 4700. And each core in UV is way faster than that of 4700.
> SpecFp_rate(base):
>
> [...]

All nice and well, but I quoted those figures directly from SGI.  So,
perhaps you should contact them and tell them to 'get' their 'facts
straight'?


> I don't understand that tech sufficiently well to say more.

Maybe you should study it a bit more before saying anything at all?

  - MG

On Oct 2, 2:52=A0pm, MG <marcog...@SPAMxs4all.nl> wrote:
> On 2-10-2011 14:44, Michael S wrote:
>
> > Bottom line:
> > Altix 4700 is not just dead, it's starting to get cold in the grave.
> > If you don't believe me - ask SGI.
>
> Explain: Why is it still being sold by SGI and on top of their product
> offerings?
>
> =A0 - MG

Same reason HP sold Alpha-based systems up until 2007?
And "on top of their product offerings" is your interpretation. If you
look at their product page, it's pretty clear that UV is on top.

On Oct 1, 1:05=A0pm, John Wallace <johnwalla...@yahoo.co.uk> wrote:
> On Oct 1, 2:37=A0am, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
>
>
>
> > On 9/28/2011 5:17 PM, Richard B. Gilbert wrote:
>
> > > If it were possible to port VMS to the X86 platform, I think somebody
> > > would have done it long ago! Both VMS-VAX and VMS-Alpha have hardware
> > > dependencies that the X86 platforms cannot satisfy easily, or at all!
>
> > I think that is a myth.
>
> > If there was a will (to fund the effort) to do it, then it
> > could be done.
>
> > VMS has already been through 2 arch migrations.
>
> > If something is missing in x86-64 then the OS would need
> > to change to fill the gap.
>
> > Arne
>
> "If something is missing in x86-64 then the OS would need to change to
> fill the gap."
>
> There is at least one other possibility to look at. x86-64 changes to
> fill the gap.
>
> Reasonably widely understood is the fact that today's x86-64 chips and
> systems don't actually yet address the high end IA64 market - the
> ultra-massive-memory, ultra-massive-SMP systems that presumably some
> customers are paying good money for. Proliant still "only" goes up to
> 64 cores and 2TB of memory. Presumably that's not enough for some
> people's apps in a quasi-general-purpose computer (ie not a specialist
> supercomputer of some flavour).
>

In fact, Proliant goes up to 80 cores. Yes, that's 1.6 times than 128
cores in recently announced Tukwila-based Superdome2-32, but cores
themselves are measurably faster in Proliant. So it is not obvious
what is faster for running single big job - top Proliant or top
Superdome. I'd suspect that Proliant would win in OLTP while Superdome
would win in more memory bandwidth intensive workloads like, for
example, data mining.
Anywhere, in context of VMS Tukwila-based Superdomes are irrelevant
since they are HP-UX only.
The biggest Tukwila-based gear that natively supports VMS is pretty
small (2 sockets, 8 cores), certainly much smaller than most Proliant
servers. Hopefully, in the future they will support VMS in virtual box
under HP-UX on Superdome2, but VMS running on bare Superdome metal or
even owning the whole SD2-32 via virtual machine does not sound
likely.

On 2-10-2011 15:02, Michael S wrote:
> Same reason HP sold Alpha-based systems up until 2007?

Your point being?


> And "on top of their product offerings" is your interpretation. If you
> look at their product page, it's pretty clear that UV is on top.

Second in the top, happy now?

  - MG

Michael S wrote 2011-10-02 15:23:


> The biggest Tukwila-based gear that natively supports VMS is pretty
> small (2 sockets, 8 cores),

"or scale up to support Integrity eight-socket server blades
with 32 cores and 64 hyperthreads

 From : http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA1-6045ENW.pdf

See also :
http://h71000.www7.hp.com/openvms_v8.4_on_i2%20server_blades.pdf

On Oct 2, 3:45=A0pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:
> Michael S wrote 2011-10-02 15:23:
>
> > The biggest Tukwila-based gear that natively supports VMS is pretty
> > small (2 sockets, 8 cores),
>
> "or scale up to support Integrity eight-socket server blades
> with 32 cores and 64 hyperthreads
>
> =A0From :http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA1-6045ENW.pdf
>
> See also :http://h71000.www7.hp.com/openvms_v8.4_on_i2%20server_blades.pd=
f

You are correct, BL890c i2 now supports OpenVMS.
I think, that is relatively new development, so I didn't see it last
time I checked half a year or so ago.
So I have to change my statement above from:
"The biggest Tukwila-based gear that natively supports VMS is pretty
small (2 sockets, 8 cores), certainly much smaller than most Proliant
servers".
To more conservative:
"The biggest Tukwila-based gear that natively supports VMS is not very
big (8 sockets, 32 cores), certainly smaller than several top Proliant
servers, in particular DL580 (40 cores), DL585 (48 cores) and DL980
(80 cores)".

Thank you for correction.

On Oct 2, 2:57=A0pm, MG <marcog...@SPAMxs4all.nl> wrote:
> On 2-10-2011 14:44, Michael S wrote:
>
> I forgot to comment on this:
>
> > In fact, 256 blades * 32GB/blade =3D 8 TB. 128 TB is an address space,
> > not the real memory you could plug into it.
>
> > 256 sockets, 16 TB =A0is a limitation for directly addressable memory i=
n
> > a single system image.
>
> > 256 sockets =3D 2560 cores, 2.5 times more than 1024 cores in SGI Altix
> > 4700. And each core in UV is way faster than that of 4700.
> > SpecFp_rate(base):
>
> > [...]
>
> All nice and well, but I quoted those figures directly from SGI. =A0So,
> perhaps you should contact them and tell them to 'get' their 'facts
> straight'?

I am sufficiently certain about 32GB/blade limit in 4700. Less certain
about 256 blades per SSI domain. It is possible they can do a bit more
with processorless "memory" blades. But not much more and certainly
not 128 TB.

Look, for example, at spec of NASA Columbia supercomputer, which is
the biggest publicly known Altix 4700 installation. On average they
have less than 1 TB of memory per SSI node.

>
> > I don't understand that tech sufficiently well to say more.
>
> Maybe you should study it a bit more before saying anything at all?
>
> =A0 - MG

The info about 1 PB of non-CC globally-addressable memory supported by
Altix-UV came in forum post from SGI employee.
I tend to believe him.
http://www.realworldtech.com/forums/index.cfm?action=3Ddetail&id=3D105363&t=
hreadid=3D105281&roomid=3D2

On Oct 2, 3:29=A0pm, MG <marcog...@SPAMxs4all.nl> wrote:
> On 2-10-2011 15:02, Michael S wrote:
>
> > Same reason HP sold Alpha-based systems up until 2007?
>
> Your point being?
>

I guess, my point is that by now Itanium has to live and die as
"enterprise" CPU. It is completely out of High Performance Computing
picture and not expected to come back.

Michael S wrote 2011-10-02 16:45:
> On Oct 2, 3:45 pm, Jan-Erik Soderholm<jan-erik.soderh...@telia.com>
> wrote:
>> Michael S wrote 2011-10-02 15:23:
>>
>>> The biggest Tukwila-based gear that natively supports VMS is pretty
>>> small (2 sockets, 8 cores),
>>
>> "or scale up to support Integrity eight-socket server blades
>> with 32 cores and 64 hyperthreads
>>
>>   From :http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA1-6045ENW.pdf
>>
>> See also :http://h71000.www7.hp.com/openvms_v8.4_on_i2%20server_blades.pdf
>
> You are correct, BL890c i2 now supports OpenVMS.
> I think, that is relatively new development, so I didn't see it last
> time I checked half a year or so ago.
> So I have to change my statement above from:
> "The biggest Tukwila-based gear that natively supports VMS is pretty
> small (2 sockets, 8 cores), certainly much smaller than most Proliant
> servers".
> To more conservative:
> "The biggest Tukwila-based gear that natively supports VMS is not very
> big (8 sockets, 32 cores), certainly smaller than several top Proliant
> servers, in particular DL580 (40 cores), DL585 (48 cores) and DL980
> (80 cores)".
>
> Thank you for correction.
>

Now, we currently run a full factory production system on one
single CPU (1 core :-) ) 666 MHz Alpha server DS20e. So from
my point view, a 8 CPU, 32 core, 1,5 GHz system would probably
be way more than we need anyway. :-)

 From what I have understood from the OpenVMS presentations I been
to, the reason to not support VMS on larger then BL890c blades
comes from talks to customers. There simply isn't any need.

So the comparision with Proliants is not that interesting.

On Oct 2, 5:09=A0pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:
> Michael S wrote 2011-10-02 16:45:
> =A0From what I have understood from the OpenVMS presentations I been
> to, the reason to not support VMS on larger then BL890c blades
> comes from talks to customers. There simply isn't any need.
>

The explanation fits my personal understanding of VMS philosophy that
seem to favor clusters over big cache-coherent SMP.

On 2-10-2011 17:06, Michael S wrote:
> I guess, my point is that by now Itanium has to live and die as
> "enterprise" CPU. It is completely out of High Performance Computing
> picture and not expected to come back.

Since when is VMS in the HPC racket?

  - MG

On Oct 2, 6:19=A0pm, MG <marcog...@SPAMxs4all.nl> wrote:
> On 2-10-2011 17:06, Michael S wrote:
>
> > I guess, my point is that by now Itanium has to live and die as
> > "enterprise" CPU. It is completely out of High Performance Computing
> > picture and not expected to come back.
>
> Since when is VMS in the HPC racket?
>
> =A0 - MG

O.k. Let's go back to your original post.
You claim, absolutely correctly, that current Xeon-MP can't generate
physical address wider than 44 bits and that there is no such
limitation in current Itanium.
Since when 44 bits =3D 16 TB insufficient for anything but big bad
single system image HPC?
The answer is - may be it will become insufficient in 2-3 years
period, but by now it is sufficient. To prove it, let's look at
biggest IBM Power box, p795. It holds 8 TB max.
So, by now, for all enterprise class machines, not just for those
running VMS, Itaniums capability to address >50 bits (I don't remember
the exact number) of physical memory does not constitute advantage
over Xeon-MP's 44 bits.
Now, what would happen 3 years from now? Obviously, next Xeon-MP or
one after it, will support 46-bit physical address, may be, even 48
bit. And what would happen 10 years from now, when 48 bit (current
physical address limitation of AMD64 instruction set) runs out of gas?
Nothing dramatic, really. They will introduce new page table format.
Of course, old OS versions will be screwed, but new OS versions will
be adapted to new format with minimal difficulties.
Yes, for Itanium crossing of 256TB limit would be smoother (assuming
Itanium survives that long), but in great scheme of things the
difference hardly matters.

MG wrote:

> Since when is VMS in the HPC racket?

When LaCarly pulled support for IA64 workstations in 2004, HP started to
push IA64's niche as "HPC" (high performance computing). Remember that
IA64 has/had a floating point advantage over the 8086.

When that didn't quite pan ut, they started to use "RAS" to give IA64
something that 8086 didn't have.

Now that 8086 shares the same memory subsystem, RAS is no longer
something Ia64 has that 8086 doesn't have. And neither is scalability
since they share the same memory interfaces which is the determining
factor in how many cores/CPUs you can connect together.


So, why are there no x86 "mainframes" ?

- because there insufficient demand for more than 64 cores ?

- because companies like HP and IBM made a niche for IA64/Power and
don't want X86 to compete in that niche ?

- or because x86 truly has technical limitations that prevent its
scaling to large systems ?

On 2-10-2011 20:27, JF Mezei wrote:
> So, why are there no x86 "mainframes" ?
>
> - because there insufficient demand for more than 64 cores ?
>
> - because companies like HP and IBM made a niche for IA64/Power and
> don't want X86 to compete in that niche ?
>
> - or because x86 truly has technical limitations that prevent its
> scaling to large systems ?

Well, what do you think?

  - MG

MG wrote:

> Well, what do you think?

Dell has outsourced most of its systems designs to Asus. Asus wants mass
 market and has no expertise in "mainframes". And it likely uses the
Intel reference designs ofr x86 motherboards.

So, in terms of Dell not producing "mainframes", it is either because
the market isn't large enough for Dell's business model, or because Dell
lacks the engineers to design such systems.

The current superdomes are glorified blades with a Quickpath (CSI)
bridge between blades. Very smartly done. But this means that HP could
make equivalent X86 blades with the same blade interconnects to bridge
the memory and voila, you'd have x86 based Superdomes.

My guess is that superdomes are designed to run only HP-UX, in the same
way that NSK gets its own systems dedicated to running NSK. Hp might not
be interested in selling superdomes that run Linux since Linux doesn't
generate as much support revenus.

A rather negative (understatement) article about Whitman:

http://www.itworld.com/hardware/209825/whitmans-political-obsessions-spell-disaster-hp


Basically, it appears that Whitman is more of a political fundraiser for
her party than a CEO for HP and the article writer fears that she won't
spend the time to be CEO of HP since she'll be concentrating on the 2012
election.

It goes further is stating she only accepted the job to freshen her
resume and use her CEO office to help cultivate fundraising contacts.

OUCH !


This article is a bit scary. I have no idea whether this is footed in
reality or just a very biased editorial or both.

On 5-10-2011 4:10, JF Mezei wrote:
> A rather negative (understatement) article about Whitman:
>
> http://www.itworld.com/hardware/209825/whitmans-political-obsessions-spell-disaster-hp
>
>
> Basically, it appears that Whitman is more of a political fundraiser for
> her party than a CEO for HP and the article writer fears that she won't
> spend the time to be CEO of HP since she'll be concentrating on the 2012
> election.
>
> It goes further is stating she only accepted the job to freshen her
> resume and use her CEO office to help cultivate fundraising contacts.
>
> OUCH !
>
>
> This article is a bit scary. I have no idea whether this is footed in
> reality or just a very biased editorial or both.

Glad to see you're at least enjoying the show.  Maybe that's the right
attitude, after all.

  - MG

MG wrote:

> Glad to see you're at least enjoying the show.  Maybe that's the right
> attitude, after all.


I never cared about HP. But I care about Digital and to some extent
Tandem. Both had developped unique technologies that made significant
contributions to the IT world, especially Digital with its VAX and Alpha
chips that inspired others, as well as wth VMS with innovative features
such as all the clustering technologies and many other things.


Anc it is sad to see those die again when HP falters.  We had hopes that
Compaq would resurrect Digital. It faltered and ended up in HP's hands.
And now, the same thing is happening again. Except there is nobody left
to buy HP except perhaps an asian or indian company.