AMD/Linux vs Intel/Microsoft

Hello

You can't help to notice the significant change in hardware and software at
the moment. A somewhat interesting scenerio is playing out.

AMD has its x86-64 architecture, which can run 32-bit applications rather
well, and promises to be able to run 64 bit applications, when they come
out, even better. They have forced Intel to play there hand, and now Intel
must follow AMD's lead.

Although Intel currently has there own IA-64 architecture, this is aimed at
the server market, and from what I have read, if Intel wants to go 64 bit,
Microsoft wants Intel to get a license to implement AMD x86-64
architecture. But Intel also has Hyperthreading in there Xeon and Pentium 4
lines, and will have a more improved version in the Prescott
core, which may help in multitasking. But like AMD's 64 bit solution, don't
individual applications need to be written and compiled with the new
optimizations in mind, in order to gain any benefit?

This is where it gets interesting. Why doesn't Microsoft have an x86-64
version ready of Windows XP? Will Linux companies pick up the slack, and
ban together with AMD to take some of the Windows and Intel market share?
There are already 64-bit Linux distributions ready. Will open source
applications be optimized for AMD x86-64? Will proprietary vendors of
multimedia and photo editing software, optimize there applications for AMD
x86-64 and port them to Linux? We can only hope.

E

E wrote in message ...
This is where it gets interesting. Why doesn't Microsoft have an x86-64
version ready of Windows XP?

Set your wayback machine to the early-mid-90's and remember that Microsoft
sold Windows NT for a 64-bit platform (Alpha) before. Rumors have it that
other RISC platforms were targets back then too. Clearly they have (or
had) some internal experience with multiple target platforms, even though
it's not nearly as extensive as the Linux experience.

Back then the big gotcha was binary-only driver distributions that weren't
cross-compatible. Microsoft invested a lot of time and money into some
mitigation schemes, some of which were clever or stupid depending who you
ask (virtualized 386 on an Alpha handling driver stuff!) but all that
may have to be re-done... AGAIN. Linux doesn't suffer nearly so much
from this stupidity (but it does, to some extent, as many manufacturers
distribute binary-only drivers for Linux. That's not the fault of Linux,
although many regard binary-only drivers as pure evil.)

Tim.

In article ,
(Tim Shoppa) writes:
| E wrote in message ...
|
| This is where it gets interesting. Why doesn't Microsoft have an x86-64
| version ready of Windows XP?
|
| Set your wayback machine to the early-mid-90's and remember that Microsoft
| sold Windows NT for a 64-bit platform (Alpha) before. Rumors have it that
| other RISC platforms were targets back then too. Clearly they have (or
| had) some internal experience with multiple target platforms, even though
| it's not nearly as extensive as the Linux experience.

Rumours also have it that most of the porting was done by DEC people,
that little of the coding has been preserved, that none of the other
projects got off the drawing board (within Microsoft) and that most of
the Microsoft people who did work on the Alpha have left.

The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.
I have not heard any reliable rumours either way.


Regards,
Nick Maclaren.

(Nick Maclaren) wrote in message ...
The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.

Historically Microsoft *seems* to have always chosen to "spawn off
an incompatible branch". All their products have to have a unique
set of features, the concept of having identical functionality across
different platforms is always broken. (They do seem to have
some grasp of "core" vs "extra" functionality.)

I happen to believe that these decisions are usually driven by marketing,
and not by any technical inability inside Microsoft, although I could be
wrong. Clearly the lack of uniformity has great costs inside Microsft's
development and support organizations; I can only assume that somehow
this is made up for in extra sales. Probably in the same way that
each toothpaste company now has twenty different variations ("shelf
space").

Tim.

"Nick Maclaren" wrote in message
...

In article ,
(Tim Shoppa) writes:
| E wrote in message
...
|
| This is where it gets interesting. Why doesn't Microsoft have an
x86-64
| version ready of Windows XP?
|
| Set your wayback machine to the early-mid-90's and remember that
Microsoft
| sold Windows NT for a 64-bit platform (Alpha) before. Rumors have it
that
| other RISC platforms were targets back then too. Clearly they have (or
| had) some internal experience with multiple target platforms, even
though
| it's not nearly as extensive as the Linux experience.

Rumours also have it that most of the porting was done by DEC people,
that little of the coding has been preserved, that none of the other
projects got off the drawing board (within Microsoft) and that most of
the Microsoft people who did work on the Alpha have left.


The porting was by DEC. DEC had to pay for the whole port. Trouble was, NT
couldn't compete against OpenVMS and TRU64 UNIX on the Alpha. Not enough
features and pretty rough around the edges. DEC dropped developement for
M$.
M$ let the other vendors do the port of NT to their perspective platforms.
When the vendors finally woke up, they dropped NT.

The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.
I have not heard any reliable rumours either way.



OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.
When M$ has ported XP to the Itanium2 isn't known here nor have I seen any
ads on M$ website about it.

"GreyCloud" wrote in message
...
The porting was by DEC. DEC had to pay for the whole port. Trouble
was, NT couldn't compete against OpenVMS and TRU64 UNIX on the
Alpha. Not enough features and pretty rough around the edges.
DEC dropped developement for M$. M$ let the other vendors do the
port of NT to their perspective platforms. When the vendors finally woke
up, they dropped NT.

Were there any platforms besides i386, Alpha, and MIPS?

OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.

I don't see why HP would continue supporting Tru64 if they've already got a
commitment to HP-UX on IA64. Also, HP appears to be putting some level of
support into Linux and GCC -- at least on IA64. How many different unix
flavors can a single vendor realistically ship and support?

When M$ has ported XP to the Itanium2 isn't known here nor have I
seen any ads on M$ website about it.

Windows Server 2003 has been ported to IA64. Whether XP was ported or not
is now moot.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

"Stephen Sprunk" wrote in message
.. .
"GreyCloud" wrote in message
...
The porting was by DEC. DEC had to pay for the whole port. Trouble
was, NT couldn't compete against OpenVMS and TRU64 UNIX on the
Alpha. Not enough features and pretty rough around the edges.
DEC dropped developement for M$. M$ let the other vendors do the
port of NT to their perspective platforms. When the vendors finally
woke
up, they dropped NT.

Were there any platforms besides i386, Alpha, and MIPS?


The RISC line that SGI line was using I think for a while. I do know that
SGI tried to push NT under their namebrand of X86 for a period, but it
brought them nothing but a bad name out of it.

OpenVMS has been ported successfully to the Itanium2 processor as well
as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.

I don't see why HP would continue supporting Tru64 if they've already got
a
commitment to HP-UX on IA64. Also, HP appears to be putting some level of
support into Linux and GCC -- at least on IA64. How many different unix
flavors can a single vendor realistically ship and support?


Good point and one that is good to take to the bank. I only see it being
supported under the current federal contracts... but after that I suspect
its the axe for tru64.

When M$ has ported XP to the Itanium2 isn't known here nor have I
seen any ads on M$ website about it.

Windows Server 2003 has been ported to IA64. Whether XP was ported or not
is now moot.

Most of the old DEC line uses Apache now anyway. If there is a mass
produced IA64 for public use, XP maybe only able to compete if the price is
real low. Other than that windows can't compete against OpenVMS on the
IA64.

In comp.arch Stephen Sprunk wrote:
"GreyCloud" wrote in message
...
The porting was by DEC. DEC had to pay for the whole port. Trouble
was, NT couldn't compete against OpenVMS and TRU64 UNIX on the
Alpha. Not enough features and pretty rough around the edges.
DEC dropped developement for M$. M$ let the other vendors do the
port of NT to their perspective platforms. When the vendors finally woke
up, they dropped NT.

Were there any platforms besides i386, Alpha, and MIPS?

PowerPC.


S


--
Sander

+++ Out of cheese error +++

On Thu, 08 Jan 2004 20:03:13 GMT, "GreyCloud"
wrote:
The real issue is whether the Itanium port has been done competently,
or by simply spawning off another completely unportable code stream.
I have not heard any reliable rumours either way.

OpenVMS has been ported successfully to the Itanium2 processor as well as
TRU-64 UNIX. Whether HP keeps tru-64 unix is another question tho.
When M$ has ported XP to the Itanium2 isn't known here nor have I seen any
ads on M$ website about it.

WinXP was ported to IA-64 long ago. Here's the webpage for WinXP
64-bit edition for IA-64:

http://www.microsoft.com/windowsxp/64bit/default.asp

I guess this wasn't really done for the Itanium2 since it predates
that chip, but it certainly will run with no troubles at all on it.
More recently MS released Win2003 Server for IA-64.

FWIW at least in theory WinNT was designed to be very portable. The
entire system was built with a hardware abstraction layer that was
supposed to minimize the amount of architecture-specific code. Now,
I'm not sure just how successful this attempt was, but the basis is
there. At various times NT was reported to have been running on
PowerPC and MIPS in addition to the Alpha, i386 and IA-64 instruction
sets that it was officially released for. Combined with the upcoming
AMD64 port that makes for a fairly impressive array of architectures,
though several of them were stillborn.

-------------
Tony Hill
hilla underscore 20 at yahoo dot ca

"Tony Hill" wrote in message
.com...

FWIW at least in theory WinNT was designed to be very portable. The
entire system was built with a hardware abstraction layer that was
supposed to minimize the amount of architecture-specific code. Now,
I'm not sure just how successful this attempt was, but the basis is
there. At various times NT was reported to have been running on
PowerPC and MIPS in addition to the Alpha, i386 and IA-64 instruction
sets that it was officially released for. Combined with the upcoming
AMD64 port that makes for a fairly impressive array of architectures,
though several of them were stillborn.



My first NT box was a MIPS based DEC 5000 (or some such thing) prior to
Alpha being done (I was investigating graphics support for Alpha/NT). A DEC
group in Seattle (DECWest) did the work as far as I remember. At the first
NT developers conference, I recall that they made a lot of noise about how
NT was designed to be portable across architectures. Much later on, in
connection with some console firmware research - I noted that OpenBoot had a
"thin veneer" implementation of the "BIOS" interfaces that allowed NT to
boot on Alpha which apaprently had been used for PowerPC (again IIRC froma
hazy memory).

The basic problem really is that the Windows market is a shrink wrap SW
market. Despite interesting things like FX!32, other architectures just had
no real advantage unless SW vendors (including Microsoft!) would provide
native implementations of their apps.