PDA

View Full Version : Interesting read about upcoming K9 processors


Yousuf Khan
July 26th 04, 05:19 AM
http://www.digitimes.com/news/a20040726PR202.html

This interview with Tyan president Symon Chang provided the following
quotes:

"Around 2006, when the market moves to AMD's next generation of chips, you
will be able to go over 8-way. What I mean is that with eight sockets, and
dual cores, you then have sixteen processors, but with K9, you'll see it go
over that. I think we'll see a significant increase in the amount of
crossbar switches in the CPU. I'm not up on all the minute details, but you'
ll be able to go over 60 processors without adding any external crossbar
chips. We can do all that within the structure that is being currently
created. The crossbar bar chip is the standard in the mainframe business
whether it is for the Xeon, Opteron or other processors. There are a couple
of versions of the crossbar chip today, but I don't think that anyone is
currently using them for anything in the generic market; these solutions are
really only for the mainframe market. Today's mainframe market with
computers from IBM or Sparc will be using up to and over 128 processors,
with chips such as IBM's 390 microprocessor. These machines are starting
around US$1 million."

That's right over 60 processors without any kind of a special chipset
support!!!

Also he had some opinions about Windows XP64:

"Q: Do you think Microsoft's 64-bit OS will come out on time?

Chang: I hope so. There are delays, but I believe it will. Interestingly
enough, a couple of significant things have happened this year; for example,
Intel's Xeon processor with 64-bit extensions is a reaction to the
unexpected popularity of AMD's Opteron, which put Intel under pressure to
provide a similar solution for the OEM market. If Intel had not reacted, it
would have lost out. Their response was to come out with a 64-bit CPU that
is not optimal, but at least they have it, and I would compare that with
what Microsoft is doing now in the realm of the 64-bit operating system."

Doesn't sound like Chang believes that Microsoft is trying all that hard to
build a 64-bit OS. It's getting something out to show that it isn't behind
the times.

Yousuf Khan

--
Humans: contact me at ykhan at rogers dot com
Spambots: just reply to this email address ;-)

Dean Kent
July 26th 04, 05:47 AM
"Yousuf Khan" > wrote in message
t.cable.rogers.com...
>
> "Q: Do you think Microsoft's 64-bit OS will come out on time?
>

Are we still supposed to be excited about a 64-bit desktop OS from MS after
all these years? I heard once it was going to be a slam dunk. Guess
not... :-)

Regards,
Dean

George Macdonald
July 26th 04, 07:10 AM
On Mon, 26 Jul 2004 04:19:18 GMT, "Yousuf Khan" > wrote:

>http://www.digitimes.com/news/a20040726PR202.html
>
>This interview with Tyan president Symon Chang provided the following
>quotes:
>
>"Around 2006, when the market moves to AMD's next generation of chips, you
>will be able to go over 8-way. What I mean is that with eight sockets, and
>dual cores, you then have sixteen processors, but with K9, you'll see it go
>over that. I think we'll see a significant increase in the amount of
>crossbar switches in the CPU. I'm not up on all the minute details, but you'
>ll be able to go over 60 processors without adding any external crossbar
>chips. We can do all that within the structure that is being currently
>created. The crossbar bar chip is the standard in the mainframe business
>whether it is for the Xeon, Opteron or other processors. There are a couple
>of versions of the crossbar chip today, but I don't think that anyone is
>currently using them for anything in the generic market; these solutions are
>really only for the mainframe market. Today's mainframe market with
>computers from IBM or Sparc will be using up to and over 128 processors,
>with chips such as IBM's 390 microprocessor. These machines are starting
>around US$1 million."
>
>That's right over 60 processors without any kind of a special chipset
>support!!!
>
>Also he had some opinions about Windows XP64:
>
>"Q: Do you think Microsoft's 64-bit OS will come out on time?
>
>Chang: I hope so. There are delays, but I believe it will. Interestingly
>enough, a couple of significant things have happened this year; for example,
>Intel's Xeon processor with 64-bit extensions is a reaction to the
>unexpected popularity of AMD's Opteron, which put Intel under pressure to
>provide a similar solution for the OEM market. If Intel had not reacted, it
>would have lost out. Their response was to come out with a 64-bit CPU that
>is not optimal, but at least they have it, and I would compare that with
>what Microsoft is doing now in the realm of the 64-bit operating system."

Hmmm, "not optimal"?? How much can we read into that on top of the
deafening EM64T silence on WWW? As for "unexpected popularity of AMD's
Opteron"... must be a riddle... too difficult for me.:-)

>Doesn't sound like Chang believes that Microsoft is trying all that hard to
>build a 64-bit OS. It's getting something out to show that it isn't behind
>the times.

.... or that we'll get it when Intel is good and ready for us to have it.:-(

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Joe Seigh
July 26th 04, 12:06 PM
Yousuf Khan wrote:
>
> Doesn't sound like Chang believes that Microsoft is trying all that hard to
> build a 64-bit OS. It's getting something out to show that it isn't behind
> the times.
>

Going to 64 bits will be trivial compared to going to 64 way for Microsoft.

Joe Seigh

Rupert Pigott
July 26th 04, 12:14 PM
George Macdonald wrote:
> On Mon, 26 Jul 2004 04:19:18 GMT, "Yousuf Khan" > wrote:

[SNIP]

>>Doesn't sound like Chang believes that Microsoft is trying all that hard to
>>build a 64-bit OS. It's getting something out to show that it isn't behind
>>the times.
>
>
> ... or that we'll get it when Intel is good and ready for us to have it.:-(

That just means MS loses market & mindshare to other more capable
operating systems.

It also weakens their "Enterprise Class" claims. 64bit Windows has
very few production machine hours compared to Linux (for example).

64 bit Windows is hardly what I would call "Enterprise Ready", but
there are plenty of alternatives that are.

Cheers,
Rupert

Pleasant Thrip
July 26th 04, 01:40 PM
In comp.arch Joe Seigh > wrote:


> Yousuf Khan wrote:
> >
> > Doesn't sound like Chang believes that Microsoft is trying all that hard to
> > build a 64-bit OS. It's getting something out to show that it isn't behind
> > the times.
> >

> Going to 64 bits will be trivial compared to going to 64 way for Microsoft.

> Joe Seigh

why do you say that? Maybe there will be particular issues for
applications to make use of all those CPUs but I don't see why it would
be such a big deal for the OS kernel scheduler.

IMHO, 64-bits is much harder considering the Win32 API.

Nick Maclaren
July 26th 04, 01:51 PM
In article >,
Pleasant Thrip > writes:
|>
|> why do you say that? Maybe there will be particular issues for
|> applications to make use of all those CPUs but I don't see why it would
|> be such a big deal for the OS kernel scheduler.

Hmm. Do you manage any large CPU-count SMP systems?

|> IMHO, 64-bits is much harder considering the Win32 API.

No, Joe Seigh is right.


Regards,
Nick Maclaren.

Joe Seigh
July 26th 04, 01:55 PM
Pleasant Thrip wrote:
>
> In comp.arch Joe Seigh > wrote:
>
> > Yousuf Khan wrote:
> > >
> > > Doesn't sound like Chang believes that Microsoft is trying all that hard to
> > > build a 64-bit OS. It's getting something out to show that it isn't behind
> > > the times.
> > >
>
> > Going to 64 bits will be trivial compared to going to 64 way for Microsoft.
>
> > Joe Seigh
>
> why do you say that? Maybe there will be particular issues for
> applications to make use of all those CPUs but I don't see why it would
> be such a big deal for the OS kernel scheduler.
>
> IMHO, 64-bits is much harder considering the Win32 API.

Scalability primarily judging from the experience of the other OS vendors.

Joe Seigh

Judd
July 26th 04, 02:34 PM
As always, AMD is good and Intel is bad. Same old spiel. YAWN!


"Yousuf Khan" > wrote in message
t.cable.rogers.com...
> http://www.digitimes.com/news/a20040726PR202.html
>
> This interview with Tyan president Symon Chang provided the following
> quotes:
>
> "Around 2006, when the market moves to AMD's next generation of chips, you
> will be able to go over 8-way. What I mean is that with eight sockets, and
> dual cores, you then have sixteen processors, but with K9, you'll see it
go
> over that. I think we'll see a significant increase in the amount of
> crossbar switches in the CPU. I'm not up on all the minute details, but
you'
> ll be able to go over 60 processors without adding any external crossbar
> chips. We can do all that within the structure that is being currently
> created. The crossbar bar chip is the standard in the mainframe business
> whether it is for the Xeon, Opteron or other processors. There are a
couple
> of versions of the crossbar chip today, but I don't think that anyone is
> currently using them for anything in the generic market; these solutions
are
> really only for the mainframe market. Today's mainframe market with
> computers from IBM or Sparc will be using up to and over 128 processors,
> with chips such as IBM's 390 microprocessor. These machines are starting
> around US$1 million."
>
> That's right over 60 processors without any kind of a special chipset
> support!!!
>
> Also he had some opinions about Windows XP64:
>
> "Q: Do you think Microsoft's 64-bit OS will come out on time?
>
> Chang: I hope so. There are delays, but I believe it will. Interestingly
> enough, a couple of significant things have happened this year; for
example,
> Intel's Xeon processor with 64-bit extensions is a reaction to the
> unexpected popularity of AMD's Opteron, which put Intel under pressure to
> provide a similar solution for the OEM market. If Intel had not reacted,
it
> would have lost out. Their response was to come out with a 64-bit CPU that
> is not optimal, but at least they have it, and I would compare that with
> what Microsoft is doing now in the realm of the 64-bit operating system."
>
> Doesn't sound like Chang believes that Microsoft is trying all that hard
to
> build a 64-bit OS. It's getting something out to show that it isn't behind
> the times.
>
> Yousuf Khan
>
> --
> Humans: contact me at ykhan at rogers dot com
> Spambots: just reply to this email address ;-)
>
>

Yousuf Khan
July 26th 04, 07:01 PM
Rupert Pigott wrote:
> That just means MS loses market & mindshare to other more capable
> operating systems.
>
> It also weakens their "Enterprise Class" claims. 64bit Windows has
> very few production machine hours compared to Linux (for example).
>
> 64 bit Windows is hardly what I would call "Enterprise Ready", but
> there are plenty of alternatives that are.

Microsoft should have just released Windows 64, despite not having enough
optimized drivers for it. There's nothing like a shipping product to drive
driver development.

Yousuf Khan

Yousuf Khan
July 26th 04, 07:26 PM
Pleasant Thrip wrote:
>> Going to 64 bits will be trivial compared to going to 64 way for
>> Microsoft.
>
>> Joe Seigh
>
> why do you say that? Maybe there will be particular issues for
> applications to make use of all those CPUs but I don't see why it
> would be such a big deal for the OS kernel scheduler.

The scheduler would have to be quite non-trivial for such a large-scale
machine. The scheduler would have to not only take into account the number
of processors involved (that's the easy part), but it will have to take into
account metrics like how much latency there is between processors talking to
each other, how much latency there is in processors talking to various
sections of memory, etc.

For example with the processor-processor latencies, Hypertransport itself
creates a NUMA architecture, a relatively quick NUMA architecture that can
almost be treated as SMP, but NUMA nonetheless. Then if it goes above 4 or 8
processors, a second level of interconnect will need to be introduced which
might make things even slower. So certain groups of processors could talk to
each other at the highest speed, through Hypertransport, those groups would
likely be located on the same system boards. Then processors within each
group would have to talk to processors in other groups through a different
interconnect. So you have at least two levels of NUMA to take into account,
and get the timings right, etc.

Yousuf Khan

Yousuf Khan
July 26th 04, 07:26 PM
Judd wrote:
> As always, AMD is good and Intel is bad. Same old spiel. YAWN!

Well, it's good that you recognize it, Judd. :-)

Yousuf Khan

Bill Todd
July 26th 04, 08:02 PM
"Pleasant Thrip" > wrote in message
...
> In comp.arch Joe Seigh > wrote:
>
>
> > Yousuf Khan wrote:
> > >
> > > Doesn't sound like Chang believes that Microsoft is trying all that
hard to
> > > build a 64-bit OS. It's getting something out to show that it isn't
behind
> > > the times.
> > >
>
> > Going to 64 bits will be trivial compared to going to 64 way for
Microsoft.
>
> > Joe Seigh
>
> why do you say that?

Er, NUMA. Processor affinity in order to leverage local cache contents.
Synchronization mechanisms that scale easily to 4 - 8 processors but fall
flat on their face at 64. Just for a start.

Maybe there will be particular issues for
> applications to make use of all those CPUs but I don't see why it would
> be such a big deal for the OS kernel scheduler.
>
> IMHO, 64-bits is much harder considering the Win32 API.

Considering that they had a beta 64-bit version out in the field on Alpha 5
years ago, I'd suspect that they had that pretty well under control by now.

- bill

Yousuf Khan
July 26th 04, 08:31 PM
Bill Todd wrote:
>> IMHO, 64-bits is much harder considering the Win32 API.
>
> Considering that they had a beta 64-bit version out in the field on
> Alpha 5 years ago, I'd suspect that they had that pretty well under
> control by now.

They may have had an OS in 64-bit for Alpha 5 years ago, but did they have
any applications or drivers? That seems to be where they're stumbling right
now: on a bit of application support issues, and a lot of driver support
issues.

Yousuf Khan

Alex Johnson
July 26th 04, 08:37 PM
>>IMHO, 64-bits is much harder considering the Win32 API.
>
>
> Considering that they had a beta 64-bit version out in the field on Alpha 5
> years ago, I'd suspect that they had that pretty well under control by now.
>
> - bill

Did they? I thought WinNT on Alpha was really and truly 32 bit, even
though it was on a 64b processor. Besides, they threw all that code out
and made so many thousands of changes since then that there probably
isn't any legacy of Alpha's NT left in XP.

Alex
--
My words are my own. They represent no other; they belong to no other.
Don't read anything into them or you may be required to compensate me
for violation of copyright. (I do not speak for my employer.)

Bill Todd
July 26th 04, 09:40 PM
"Alex Johnson" > wrote in message
...
> >>IMHO, 64-bits is much harder considering the Win32 API.
> >
> >
> > Considering that they had a beta 64-bit version out in the field on
Alpha 5
> > years ago, I'd suspect that they had that pretty well under control by
now.
> >
> > - bill
>
> Did they?

Yes.

I thought WinNT on Alpha was really and truly 32 bit, even
> though it was on a 64b processor.

The versions that actually shipped were. The field-test version in 1999
that I referred to (being tested concurrently with its 32-bit Alpha
counterpart, until both were canned in August of that year courtesy of Curly
Capellas, bless his incompetent shiny head) was 64 bits.

> Besides, they threw all that code out

Well, not exactly: rumor has it that it's *still* running on Alphas inside
Microsoft (Dave Cutler reportedly isn't a great Itanic fan), and has even
been kept moderately up to date in the interim.

> and made so many thousands of changes since then that there probably
> isn't any legacy of Alpha's NT left in XP.

That would be stupid even for Microsoft: it was the first 64-bit Windows
version they had working, and they continued to use it for 64-bit Windows
development not only until they were able to get usable Itanic systems
(i.e., McKinleys) but significantly thereafter. To suggest that at some
point they then scrapped it and started over is, well, ridiculous.

Since Windows XP code is largely Win2K code underneath, and since 64-bit
Win2K was developed on Alpha, a large percentage of the 64-bit code in
current 64-bit Windows products almost certainly originated with the 64-bit
Alpha version.

- bill

Bill Todd
July 26th 04, 09:43 PM
"Yousuf Khan" > wrote in message
. rogers.com...
> Bill Todd wrote:
> >> IMHO, 64-bits is much harder considering the Win32 API.
> >
> > Considering that they had a beta 64-bit version out in the field on
> > Alpha 5 years ago, I'd suspect that they had that pretty well under
> > control by now.
>
> They may have had an OS in 64-bit for Alpha 5 years ago, but did they have
> any applications or drivers?

Who cares (at least in the current discussion context)? The point was that
they had the API worked out sufficiently back in 1999 to give it to outside
developers.

- bill

Ed Light
July 26th 04, 10:24 PM
"Yousuf Khan" > wrote in message
. rogers.com...
> Judd wrote:
> > As always, AMD is good and Intel is bad. Same old spiel. YAWN!

How can you doubt it? ;-)


--
Ed Light

Smiley :-/
MS Smiley :-\

Send spam to the FTC at

Thanks, robots.

George Macdonald
July 27th 04, 01:16 AM
On Mon, 26 Jul 2004 12:14:25 +0100, Rupert Pigott
> wrote:

>George Macdonald wrote:
>> On Mon, 26 Jul 2004 04:19:18 GMT, "Yousuf Khan" > wrote:
>
>[SNIP]
>
>>>Doesn't sound like Chang believes that Microsoft is trying all that hard to
>>>build a 64-bit OS. It's getting something out to show that it isn't behind
>>>the times.
>>
>>
>> ... or that we'll get it when Intel is good and ready for us to have it.:-(
>
>That just means MS loses market & mindshare to other more capable
>operating systems.

True but those people are among the most arrogant on the planet. They
think they can get away with it and maybe they can. There are signs that
AMD64 supply is tightening up and prices are staying relatively high. It's
probable that the bottom line is that M$ figures AMD64 volume can never
reach what they call "volume".

>It also weakens their "Enterprise Class" claims. 64bit Windows has
>very few production machine hours compared to Linux (for example).
>
>64 bit Windows is hardly what I would call "Enterprise Ready", but
>there are plenty of alternatives that are.

Just a couple of months ago, Oracle and IBM announced availability of
Oracle and DB2 x86-64 for Linux - as in you can buy it. As part of the
same announcement, they offered a "development version" for Windows
Server... development because the OS is err, late and itself in
"development"... Beta I suppose. That seems like a pretty strong prod to
me and yet, still, M$ just dawdles along.<shrug>

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Yousuf Khan
July 27th 04, 06:36 AM
Bill Todd > wrote:
> "Yousuf Khan" > wrote in message
> . rogers.com...
>> Bill Todd wrote:
>>>> IMHO, 64-bits is much harder considering the Win32 API.
>>>
>>> Considering that they had a beta 64-bit version out in the field on
>>> Alpha 5 years ago, I'd suspect that they had that pretty well under
>>> control by now.
>>
>> They may have had an OS in 64-bit for Alpha 5 years ago, but did
>> they have any applications or drivers?
>
> Who cares (at least in the current discussion context)? The point
> was that they had the API worked out sufficiently back in 1999 to
> give it to outside developers.

I thought the point was getting a working 64-bit Microsoft system? That
would mean not just the OS, but also the apps and drivers. If it's just the
OS, then Microsoft is already done, the OS is already ready for Opteron. But
Microsoft has said that the only thing holding them back from releasing the
OS is the drivers, and a few apps which might do things and get away with in
the 32-bit OS which they won't be allowed to get away with in 64-bit.

Yousuf Khan

Judd
July 27th 04, 03:32 PM
"Yousuf Khan" > wrote in message
et.cable.rogers.com...
> Bill Todd > wrote:
> > "Yousuf Khan" > wrote in message
> > . rogers.com...
>
> I thought the point was getting a working 64-bit Microsoft system? That
> would mean not just the OS, but also the apps and drivers. If it's just
the
> OS, then Microsoft is already done, the OS is already ready for Opteron.
But
> Microsoft has said that the only thing holding them back from releasing
the
> OS is the drivers, and a few apps which might do things and get away with
in
> the 32-bit OS which they won't be allowed to get away with in 64-bit.

Doesn't Advanced Server 2003 do 64-bit? As in Itanium?

Dean Kent
July 27th 04, 03:56 PM
"Judd" > wrote in message
...
>
> Doesn't Advanced Server 2003 do 64-bit? As in Itanium?
>

Of course. But, it isn't a 'desktop OS' and many people don't count
anything Itanium as being real... that gives it two strikes. Since it
doesn't run on Opteron, that makes three. ;-).

Regards,
Dean

>

Bill Todd
July 27th 04, 04:36 PM
"Yousuf Khan" > wrote in message
et.cable.rogers.com...
> Bill Todd > wrote:
> > "Yousuf Khan" > wrote in message
> > . rogers.com...
> >> Bill Todd wrote:
> >>>> IMHO, 64-bits is much harder considering the Win32 API.
> >>>
> >>> Considering that they had a beta 64-bit version out in the field on
> >>> Alpha 5 years ago, I'd suspect that they had that pretty well under
> >>> control by now.
> >>
> >> They may have had an OS in 64-bit for Alpha 5 years ago, but did
> >> they have any applications or drivers?
> >
> > Who cares (at least in the current discussion context)? The point
> > was that they had the API worked out sufficiently back in 1999 to
> > give it to outside developers.
>
> I thought the point was getting a working 64-bit Microsoft system?

Then you failed to pay attention to the context you were responding to.

- bill

Yousuf Khan
July 27th 04, 05:00 PM
Ed wrote:
> Hey, is Windows "Longhorn" gonna be for x86-64 CPU?
> Ed

Current rumours are that, that's all it's going to be for. You won't be able
to run it on anything less than a 64-bit machine.

Yousuf Khan

Yousuf Khan
July 27th 04, 05:00 PM
Judd wrote:
> Doesn't Advanced Server 2003 do 64-bit? As in Itanium?

The number of apps and the number of drivers supported on Opteron is
supposed to be much higher than on Itanium.

Yousuf Khan

David Gay
July 27th 04, 05:44 PM
"Bill Todd" > writes:
> Since Windows XP code is largely Win2K code underneath, and since 64-bit
> Win2K was developed on Alpha, a large percentage of the 64-bit code in
> current 64-bit Windows products almost certainly originated with the 64-bit
> Alpha version.

One would in fact presume that the 32 and 64-bit code bases are now
essentially identical.

--
David Gay

Bill Todd
July 27th 04, 06:28 PM
"David Gay" > wrote in message
...
>
> "Bill Todd" > writes:
> > Since Windows XP code is largely Win2K code underneath, and since 64-bit
> > Win2K was developed on Alpha, a large percentage of the 64-bit code in
> > current 64-bit Windows products almost certainly originated with the
64-bit
> > Alpha version.
>
> One would in fact presume that the 32 and 64-bit code bases are now
> essentially identical.

IIRC that was significantly the case (and definitely the goal) back in 1999.
Yet another reason to doubt that very much code was changed in the
transition to Itanic.

- bill

AD.
July 27th 04, 11:00 PM
On Tue, 27 Jul 2004 08:32:22 -0600, Judd wrote:

> Doesn't Advanced Server 2003 do 64-bit? As in Itanium?

There's also an IA64 version of XP Pro.

Cheers
Anton

Carlo Razzeto
July 27th 04, 11:15 PM
"George Macdonald" > wrote in message
...
> On Mon, 26 Jul 2004 12:14:25 +0100, Rupert Pigott
> > wrote:
>
> >George Macdonald wrote:
> >> On Mon, 26 Jul 2004 04:19:18 GMT, "Yousuf Khan" >
wrote:
> >
> >[SNIP]
> >
>
> True but those people are among the most arrogant on the planet. They
> think they can get away with it and maybe they can. There are signs that
> AMD64 supply is tightening up and prices are staying relatively high.
It's
> probable that the bottom line is that M$ figures AMD64 volume can never
> reach what they call "volume".
>

Interesting, because I was just reading an article from yesterday saying AMD
just dropped the price of the A64 by up to 30% (depending on the model).

http://www.theregister.co.uk/2004/07/26/amd_prices/

Judd
July 28th 04, 12:25 AM
"Yousuf Khan" > wrote in message
ers.com...
> Judd wrote:
> > Doesn't Advanced Server 2003 do 64-bit? As in Itanium?
>
> The number of apps and the number of drivers supported on Opteron is
> supposed to be much higher than on Itanium.
>

Huh? If Windows Server 2003 is running and selling for Itanium, then it
probably has the drivers for the architecture and applications as well. If
you mean 3rd party, then that's a different issue altogether but I'm sure
3rd party high end server vendors do have the drivers. Intel site has a
long list of apps that run on Itanium. Itanium also runs 32-bit software,
but only like a mid level P4.

Judd
July 28th 04, 12:26 AM
"Dean Kent" > wrote in message
m...
> "Judd" > wrote in message
> ...
> >
> > Doesn't Advanced Server 2003 do 64-bit? As in Itanium?
> >
>
> Of course. But, it isn't a 'desktop OS' and many people don't count
> anything Itanium as being real... that gives it two strikes. Since it
> doesn't run on Opteron, that makes three. ;-).
>

LOL, I suppose!

Yousuf Khan
July 28th 04, 02:59 AM
Judd wrote:
> "Yousuf Khan" > wrote in message
> ers.com...
>> Judd wrote:
>>> Doesn't Advanced Server 2003 do 64-bit? As in Itanium?
>>
>> The number of apps and the number of drivers supported on Opteron is
>> supposed to be much higher than on Itanium.
>>
>
> Huh? If Windows Server 2003 is running and selling for Itanium, then
> it probably has the drivers for the architecture and applications as
> well. If you mean 3rd party, then that's a different issue
> altogether but I'm sure 3rd party high end server vendors do have the
> drivers. Intel site has a long list of apps that run on Itanium.
> Itanium also runs 32-bit software, but only like a mid level P4.

Yeah, it's the 3rd party stuff I'm talking about. Opterons are supposed to
run with a wider range of 3rd party devices than Itaniums. Because they are
aimed at such a cost-sensitive sector of the market, you got to expect that
people will try to put their own devices into these systems rather than pay
the exhorbitant vendor prices. Of course when they do that, they also miss
out on all of the vendor pre-testing that goes along with it.

Yousuf Khan

Keith
July 28th 04, 03:22 AM
On Mon, 26 Jul 2004 07:34:34 -0600, Judd wrote:

> As always, AMD is good and Intel is bad. Same old spiel. YAWN!

Sure, when Intel tries to twist the market (i.e. consumer) to their
benefit and there is an alternative with a consumer-friendly alternative,
you bet Intel is *BAD*! To think otherwise is simply stupid. Unless of
"Course"...

BTW, top-posters suck!

--
Keith

Keith
July 28th 04, 03:28 AM
On Mon, 26 Jul 2004 04:47:58 +0000, Dean Kent wrote:

> "Yousuf Khan" > wrote in message
> t.cable.rogers.com...
>>
>> "Q: Do you think Microsoft's 64-bit OS will come out on time?
>>
>
> Are we still supposed to be excited about a 64-bit desktop OS from MS after
> all these years? I heard once it was going to be a slam dunk. Guess
> not... :-)

A 64bit OS is a slam dunk, though perhaps not from Micro$hit.
Perhaps politics is involved here? Nah Dean, couldn't be!

BTW, 64bit Linux works fine here! It seems Sun is found the light too.
OTOH, Itanic well never see the light, no matter how hard the pundits push.

--
Keith

Dean Kent
July 28th 04, 04:18 AM
"Keith" > wrote in message
...
> On Mon, 26 Jul 2004 04:47:58 +0000, Dean Kent wrote:
>
>
> A 64bit OS is a slam dunk, though perhaps not from Micro$hit.
> Perhaps politics is involved here? Nah Dean, couldn't be!

I don't think so. More likely Windows is a nightmare to code/modify. Some
people like conspiracy theories, however. :-).

>
> BTW, 64bit Linux works fine here! It seems Sun is found the light too.

Linux isn't Windows, and therefore is a completely different argument. Sun
found religion for the same reason most others do... impending death! <g>.

> OTOH, Itanic well never see the light, no matter how hard the pundits
push.

Unlike Power, which will dominate everywhere, right? No politics here!!!
;-).

Regards,
Dean

>
> --
> Keith

Yousuf Khan
July 28th 04, 04:40 AM
Keith wrote:
> BTW, 64bit Linux works fine here! It seems Sun is found the light
> too. OTOH, Itanic well never see the light, no matter how hard the
> pundits push.

It would be supremely embarrassing to Microsoft if Sun gets Solaris for
Opteron out before Windows.

Yousuf Khan

Dean Kent
July 28th 04, 04:46 AM
"Yousuf Khan" > wrote in message
ers.com...
>
> It would be supremely embarrassing to Microsoft if Sun gets Solaris for
> Opteron out before Windows.

My money is on embarassement...

Regards,
Dean

>
> Yousuf Khan
>
>

Bill Davidsen
July 28th 04, 05:51 AM
Joe Seigh wrote:
>
> Yousuf Khan wrote:
>
>>Doesn't sound like Chang believes that Microsoft is trying all that hard to
>>build a 64-bit OS. It's getting something out to show that it isn't behind
>>the times.
>>
>
>
> Going to 64 bits will be trivial compared to going to 64 way for Microsoft.

Yes, since Linux is already NUMA capable 64 CPU is a configuration
option. Still, finding the bandwidth to feed those CPUs is easier if
they have some dedicated RAM (read as: Opteron).

--
bill davidsen )
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com

Bill Davidsen
July 28th 04, 05:54 AM
Pleasant Thrip wrote:
> In comp.arch Joe Seigh > wrote:
>
>
>
>>Yousuf Khan wrote:
>>
>>>Doesn't sound like Chang believes that Microsoft is trying all that hard to
>>>build a 64-bit OS. It's getting something out to show that it isn't behind
>>>the times.
>>>
>
>
>>Going to 64 bits will be trivial compared to going to 64 way for Microsoft.
>
>
>>Joe Seigh
>
>
> why do you say that? Maybe there will be particular issues for
> applications to make use of all those CPUs but I don't see why it would
> be such a big deal for the OS kernel scheduler.

You don't understand the problem... the o/s needs to make all sorts of
decisions about moving a process to another processor to load balance
vs. cost of moving, etc. It is a nasty problem!
>
> IMHO, 64-bits is much harder considering the Win32 API.


--
bill davidsen )
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com

Bill Davidsen
July 28th 04, 05:57 AM
Yousuf Khan wrote:
> Bill Todd > wrote:
>
>>"Yousuf Khan" > wrote in message
. rogers.com...
>>
>>>Bill Todd wrote:
>>>
>>>>>IMHO, 64-bits is much harder considering the Win32 API.
>>>>
>>>>Considering that they had a beta 64-bit version out in the field on
>>>>Alpha 5 years ago, I'd suspect that they had that pretty well under
>>>>control by now.
>>>
>>>They may have had an OS in 64-bit for Alpha 5 years ago, but did
>>>they have any applications or drivers?
>>
>>Who cares (at least in the current discussion context)? The point
>>was that they had the API worked out sufficiently back in 1999 to
>>give it to outside developers.
>
>
> I thought the point was getting a working 64-bit Microsoft system? That
> would mean not just the OS, but also the apps and drivers. If it's just the
> OS, then Microsoft is already done, the OS is already ready for Opteron. But
> Microsoft has said that the only thing holding them back from releasing the
> OS is the drivers, and a few apps which might do things and get away with in
> the 32-bit OS which they won't be allowed to get away with in 64-bit.

I've been waiting since Windows 3.1 for a working 32-bit version, don't
ya know?

--
bill davidsen )
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com

Ketil Malde
July 28th 04, 08:10 AM
"Dean Kent" > writes:

>> It would be supremely embarrassing to Microsoft if Sun gets Solaris for
>> Opteron out before Windows.

> My money is on embarassement...

I guess it's somewhat embarrassing if Sun ships Opteron servers, and
can't offer Solaris to go with them. Microsoft can still afford to
wait, the vast majority of their market is still Intel and 32 bits.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

Rob Stow
July 28th 04, 09:20 AM
Yousuf Khan wrote:

> Keith wrote:
>
>>BTW, 64bit Linux works fine here! It seems Sun is found the light
>>too. OTOH, Itanic well never see the light, no matter how hard the
>>pundits push.
>
>
> It would be supremely embarrassing to Microsoft if Sun gets Solaris for
> Opteron out before Windows.
>
> Yousuf Khan
>
>

It is apparently ready to ship on their 1,2,and 4-way
Opty servers and W/S that were announced on Monday.
I wonder if Sun had the hardware ready to go for a while
but were waiting on Solaris ?

Rob Stow
July 28th 04, 09:23 AM
Ketil Malde wrote:

> "Dean Kent" > writes:
>
>
>>>It would be supremely embarrassing to Microsoft if Sun gets Solaris for
>>>Opteron out before Windows.
>
>
>>My money is on embarassement...
>
>
> I guess it's somewhat embarrassing if Sun ships Opteron servers, and
> can't offer Solaris to go with them. Microsoft can still afford to
> wait, the vast majority of their market is still Intel and 32 bits.
>

I just found a link I'd been looking for:
http://www.sun.com/desktop/workstation/w2100z/
which says that this system ships with Solaris, with
a 64 bit Solaris available "soon".

Pleasant Thrip
July 28th 04, 10:46 AM
In comp.arch Bill Davidsen > wrote:
> Pleasant Thrip wrote:
> > why do you say that? Maybe there will be particular issues for
> > applications to make use of all those CPUs but I don't see why it would
> > be such a big deal for the OS kernel scheduler.

> You don't understand the problem... the o/s needs to make all sorts of
> decisions about moving a process to another processor to load balance
> vs. cost of moving, etc. It is a nasty problem!

Sure it is a nasty problem and I do understand that. But, I'm talking
about the total amount of work for Microsoft here.

How many people do you think would need to be working on the kernel
development for this particular problem as opposed to migrating the
entire Win32 API and attendant APIs such as DirectX to 64-bit? That was
my point. The real world is more than some academic abstraction that
"NUMA is hard" and so on. The real world is about delivering a complete
shrink-wrapped 64-bit Windows XP I can buy.

For those that think the issue was solved with the Itanium/Alpha ports
you obviously aren't Windows programmers nor conversant with the various
APIs.

And if anybody wants to further this discussion, please stick OT. We're
talking _Windows_ here, much as some of you might not like.

> >
> > IMHO, 64-bits is much harder considering the Win32 API.

Yousuf Khan
July 28th 04, 11:45 AM
Rob Stow wrote:
>> It would be supremely embarrassing to Microsoft if Sun gets Solaris
>> for Opteron out before Windows.
>>
>> Yousuf Khan
>
> It is apparently ready to ship on their 1,2,and 4-way
> Opty servers and W/S that were announced on Monday.
> I wonder if Sun had the hardware ready to go for a while
> but were waiting on Solaris ?

I think it's just the 32-bit Solaris that is shipping right now. I was
referring to the upcoming 64-bit Solaris.

Yousuf Khan

chrisv
July 28th 04, 01:45 PM
"Dean Kent" > wrote:

>"Keith" > wrote in message
...
>> On Mon, 26 Jul 2004 04:47:58 +0000, Dean Kent wrote:
>>
>>
>> A 64bit OS is a slam dunk, though perhaps not from Micro$hit.
>> Perhaps politics is involved here? Nah Dean, couldn't be!
>
>I don't think so. More likely Windows is a nightmare to code/modify. Some
>people like conspiracy theories, however. :-).
>
>>
>> BTW, 64bit Linux works fine here! It seems Sun is found the light too.
>
>Linux isn't Windows, and therefore is a completely different argument.

Are you being sarcastic? I'd be amazed if Win32 was not 64-bit clean
from day one. The industry was a lot more mature at that point, and
hopefully learned from the migration of 16- to 32-bit...

Ken Hagan
July 28th 04, 02:57 PM
chrisv wrote:
>
> Are you being sarcastic? I'd be amazed if Win32 was not 64-bit clean
> from day one. The industry was a lot more mature at that point, and
> hopefully learned from the migration of 16- to 32-bit...

Surely if Win32 were 64-bit clean, MS wouldn't have had to ship separate
Win64 headers, which they did, to the general horror of everyone who
expected a 64-bit "long".

Furthermore, at the time of its inception, it was far more important for
Win32 code to be Win16 clean, and I doubt if MS could produce headers
that are clean for all three sizes simultaneously.

Russell Wallace
July 28th 04, 03:03 PM
On Wed, 28 Jul 2004 07:45:16 -0500, chrisv >
wrote:

>"Dean Kent" > wrote:
>
>>Linux isn't Windows, and therefore is a completely different argument.

>Are you being sarcastic?

I don't know whether he's being sarcastic...

>I'd be amazed if Win32 was not 64-bit clean
>from day one. The industry was a lot more mature at that point, and
>hopefully learned from the migration of 16- to 32-bit...

....but I hope you are! :P

--
"Sore wa himitsu desu."
To reply by email, remove
the small snack from address.

Sander Vesik
July 28th 04, 04:11 PM
In comp.arch Bill Davidsen > wrote:
> Joe Seigh wrote:
> >
> > Yousuf Khan wrote:
> >
> >>Doesn't sound like Chang believes that Microsoft is trying all that hard to
> >>build a 64-bit OS. It's getting something out to show that it isn't behind
> >>the times.
> >>
> >
> >
> > Going to 64 bits will be trivial compared to going to 64 way for Microsoft.
>
> Yes, since Linux is already NUMA capable 64 CPU is a configuration
> option. Still, finding the bandwidth to feed those CPUs is easier if
> they have some dedicated RAM (read as: Opteron).
>

The problem is that if Windows claimed 64 bit compat the same way linux did,
everybody would simply laugh and tell them to make up a better joke...

--
Sander

+++ Out of cheese error +++

Sander Vesik
July 28th 04, 04:12 PM
In comp.arch Bill Davidsen > wrote:
>
> I've been waiting since Windows 3.1 for a working 32-bit version, don't
> ya know?
>

So you are a loser who bashes MS without knowing any actual details about
teh OS?

--
Sander

+++ Out of cheese error +++

Tony Hill
July 28th 04, 04:21 PM
On Wed, 28 Jul 2004 03:40:59 GMT, "Yousuf Khan" >
wrote:
>Keith wrote:
>> BTW, 64bit Linux works fine here! It seems Sun is found the light
>> too. OTOH, Itanic well never see the light, no matter how hard the
>> pundits push.
>
>It would be supremely embarrassing to Microsoft if Sun gets Solaris for
>Opteron out before Windows.

Sun currently has 64-bit Solaris for Opteron scheduled for Dec. of
this year. Word so far is that they are pretty much right on schedule
and that the OS is up and running in their labs.

FWIW I don't think the MS delay is simply an issue of drivers.
They've also delayed Win2003 SP1 for apparently the same reason as
their delay of WinXP 64-bit. All of this actually seems to tie back
in to WinXP (32-bit) SP2, which is continuously being pushed back.
All the future OSes are going to be built off the SP2 code-base and
Microsoft seems to be having no end of problems getting this update
out.

For those that aren't familiar with WinXP SP2, it is a pretty
significant change to WinXP (many have referred to it more as "WinXP
Second Edition" rather than just a service pack). Lots of positive
changes with regards to the basic security concept of the system, but
MS seems to be having HUGE problems making it work. Reports from the
recently released "Release Candidate 2" suggest that this is still
definitely beta software (certainly not an actual candidate to be
released). I suspect that until MS gets these sorted out they aren't
going to try to push the other new OSes and service packs out.

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

Rob Stow
July 28th 04, 04:58 PM
Sander Vesik wrote:
> In comp.arch Bill Davidsen > wrote:
>
>>I've been waiting since Windows 3.1 for a working 32-bit version, don't
>>ya know?
>>
>
>
> So you are a loser who bashes MS without knowing any actual details about
> teh OS?
>

No, he sounds like someone who has tried them all
and doesn't feel they are good enough to be labelled
as "working".

For crapware like Win 3.x, Win9x, and WinMe he's got a
point, but I would disagree with him on NT4 and W2K.

Rupert Pigott
July 28th 04, 06:45 PM
Rob Stow wrote:
> Sander Vesik wrote:
>
>> In comp.arch Bill Davidsen > wrote:
>>
>>> I've been waiting since Windows 3.1 for a working 32-bit version,
>>> don't ya know?
>>>
>>
>>
>> So you are a loser who bashes MS without knowing any actual details about
>> teh OS?
>>
>
> No, he sounds like someone who has tried them all
> and doesn't feel they are good enough to be labelled
> as "working".
>
> For crapware like Win 3.x, Win9x, and WinMe he's got a
> point, but I would disagree with him on NT4 and W2K.

I have to agree with him on NT4, specifically file shares across long
and unreliable links. Bad idea to do, but it sucks that you have to
reboot the --ing file server to make it drop the stale locks when the
connection breaks. For some reason I never saw NT 3.51 have that same
problem... Did they ever fix that little doozey ? I lived with that
bug for 4 years all told at various PPOEs. I particular resented the
one where I lost a ton of sleep fixing batches that blew up because
the dipsticks in Hong Kong lacked the "expertise" to set up a FTP
server.

"Enterprise Ready", my arse.

Cheers,
Rupert

Sander Vesik
July 28th 04, 06:48 PM
In comp.arch Ketil Malde > wrote:
> "Dean Kent" > writes:
>
> >> It would be supremely embarrassing to Microsoft if Sun gets Solaris for
> >> Opteron out before Windows.
>
> > My money is on embarassement...
>
> I guess it's somewhat embarrassing if Sun ships Opteron servers, and
> can't offer Solaris to go with them. Microsoft can still afford to
> wait, the vast majority of their market is still Intel and 32 bits.

I though Solaris 9 something was an option on the Opterons?

>
> -kzm

--
Sander

+++ Out of cheese error +++

Sander Vesik
July 28th 04, 08:20 PM
In comp.arch Pleasant Thrip > wrote:
>
> How many people do you think would need to be working on the kernel
> development for this particular problem as opposed to migrating the
> entire Win32 API and attendant APIs such as DirectX to 64-bit? That was
> my point. The real world is more than some academic abstraction that
> "NUMA is hard" and so on. The real world is about delivering a complete
> shrink-wrapped 64-bit Windows XP I can buy.
>

Well... I would imaghine it depends a lot on how throughout work they want
to make of it. With teh IL32P64 model they are using, almost no extra work
might be needed for an initial api and lilbrary conversion.

--
Sander

+++ Out of cheese error +++

Sander Vesik
July 28th 04, 08:22 PM
In comp.arch Rob Stow > wrote:
> Sander Vesik wrote:
> > In comp.arch Bill Davidsen > wrote:
> >
> >>I've been waiting since Windows 3.1 for a working 32-bit version, don't
> >>ya know?
> >>
> >
> >
> > So you are a loser who bashes MS without knowing any actual details about
> > teh OS?
> >
>
> No, he sounds like someone who has tried them all
> and doesn't feel they are good enough to be labelled
> as "working".
>
> For crapware like Win 3.x, Win9x, and WinMe he's got a
> point, but I would disagree with him on NT4 and W2K.

Precicely - and now with WinMe being dead and essentialy superceded
with WinXP Home, his "I have been waiting for 32bit os since win 3.1"
simply makes no sense.

--
Sander

+++ Out of cheese error +++

Hank Oredson
July 28th 04, 08:34 PM
"Tony Hill" > wrote in message
...
> On Wed, 28 Jul 2004 03:40:59 GMT, "Yousuf Khan" >
> wrote:
>>Keith wrote:
>>> BTW, 64bit Linux works fine here! It seems Sun is found the light
>>> too. OTOH, Itanic well never see the light, no matter how hard the
>>> pundits push.
>>
>>It would be supremely embarrassing to Microsoft if Sun gets Solaris for
>>Opteron out before Windows.
>
> Sun currently has 64-bit Solaris for Opteron scheduled for Dec. of
> this year. Word so far is that they are pretty much right on schedule
> and that the OS is up and running in their labs.
>
> FWIW I don't think the MS delay is simply an issue of drivers.
> They've also delayed Win2003 SP1 for apparently the same reason as
> their delay of WinXP 64-bit. All of this actually seems to tie back
> in to WinXP (32-bit) SP2, which is continuously being pushed back.
> All the future OSes are going to be built off the SP2 code-base and
> Microsoft seems to be having no end of problems getting this update
> out.
>
> For those that aren't familiar with WinXP SP2, it is a pretty
> significant change to WinXP (many have referred to it more as "WinXP
> Second Edition" rather than just a service pack). Lots of positive
> changes with regards to the basic security concept of the system, but
> MS seems to be having HUGE problems making it work. Reports from the
> recently released "Release Candidate 2" suggest that this is still
> definitely beta software (certainly not an actual candidate to be
> released). I suspect that until MS gets these sorted out they aren't
> going to try to push the other new OSes and service packs out.


Kinda curious where you found the reports on SP2 RC2.
Have three systems running it, with zero problems.

I'd like to read the reports so I can tell what problems
to look for and test.

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net

George Macdonald
July 28th 04, 09:30 PM
On Tue, 27 Jul 2004 18:15:24 -0400, "Carlo Razzeto" >
wrote:

>
>"George Macdonald" > wrote in message
...
>> On Mon, 26 Jul 2004 12:14:25 +0100, Rupert Pigott
>> > wrote:
>>
>> >George Macdonald wrote:
>> >> On Mon, 26 Jul 2004 04:19:18 GMT, "Yousuf Khan" >
>wrote:
>> >
>> >[SNIP]
>> >
>>
>> True but those people are among the most arrogant on the planet. They
>> think they can get away with it and maybe they can. There are signs that
>> AMD64 supply is tightening up and prices are staying relatively high.
>It's
>> probable that the bottom line is that M$ figures AMD64 volume can never
>> reach what they call "volume".
>>
>
>Interesting, because I was just reading an article from yesterday saying AMD
>just dropped the price of the A64 by up to 30% (depending on the model).
>
>http://www.theregister.co.uk/2004/07/26/amd_prices/

That readjustment, which also included raised prices for a cpuple of
models, was on Monday and I'm going by prices paid for recent "shopping".
The price *has* been holding quite well for AMD64 CPUs compared with their
historical curves and even Intel's - even at the old higher prices, they
were definitely in quite tight supply.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

AD.
July 28th 04, 11:51 PM
On Wed, 28 Jul 2004 19:34:59 +0000, Hank Oredson wrote:

> Kinda curious where you found the reports on SP2 RC2. Have three systems
> running it, with zero problems.

I think he meant the problems MS have making it work - wider issues than
most people will come across. If there weren't any problems it would've
been released many months ago.

Cheers
Anton

Yousuf Khan
July 29th 04, 12:22 AM
Tony Hill > wrote:
> Sun currently has 64-bit Solaris for Opteron scheduled for Dec. of
> this year. Word so far is that they are pretty much right on schedule
> and that the OS is up and running in their labs.

I'd never heard of that until now. Doing a Yahoo search only revealed a few
articles from 2003 (too old now to be really useful), and some Sun articles
being suitably vague ("real soon now"). You got something to link to?

> FWIW I don't think the MS delay is simply an issue of drivers.
> They've also delayed Win2003 SP1 for apparently the same reason as
> their delay of WinXP 64-bit. All of this actually seems to tie back
> in to WinXP (32-bit) SP2, which is continuously being pushed back.
> All the future OSes are going to be built off the SP2 code-base and
> Microsoft seems to be having no end of problems getting this update
> out.
>
> For those that aren't familiar with WinXP SP2, it is a pretty
> significant change to WinXP (many have referred to it more as "WinXP
> Second Edition" rather than just a service pack). Lots of positive
> changes with regards to the basic security concept of the system, but
> MS seems to be having HUGE problems making it work. Reports from the
> recently released "Release Candidate 2" suggest that this is still
> definitely beta software (certainly not an actual candidate to be
> released). I suspect that until MS gets these sorted out they aren't
> going to try to push the other new OSes and service packs out.

It's possible that the NX protected pages are breaking more apps than
initially thought.

Yousuf Khan

Andrew Reilly
July 29th 04, 12:44 AM
Sander Vesik wrote:

> In comp.arch Pleasant Thrip > wrote:
> Well... I would imaghine it depends a lot on how throughout work they want
> to make of it. With teh IL32P64 model they are using, almost no extra work
> might be needed for an initial api and lilbrary conversion.

That model is surely going to make the famous trick of using xor
to build doubly-linked lists more interesting. (Unless they used
a typedef to mean "an integer that can hold a pointer". They
certainly wouldn't have been using "long long" for that purpose in
the 16- or 32-bit days.)

Weren't we just discussing "issues with C and pointers" :-)

--
Andrew

Seongbae Park
July 29th 04, 12:48 AM
Yousuf Khan > wrote:
> Tony Hill > wrote:
>> Sun currently has 64-bit Solaris for Opteron scheduled for Dec. of
>> this year. Word so far is that they are pretty much right on schedule
>> and that the OS is up and running in their labs.
>
> I'd never heard of that until now. Doing a Yahoo search only revealed a few
> articles from 2003 (too old now to be really useful), and some Sun articles
> being suitably vague ("real soon now"). You got something to link to?

http://www.theregister.co.uk/2004/07/15/sun_solarislives_opteron/

And I can say that there's been a lot more progress than
what's reported in this article.

Seongbae

Keith
July 29th 04, 02:55 AM
On Wed, 28 Jul 2004 03:18:40 +0000, Dean Kent wrote:

> "Keith" > wrote in message
> ...
>> On Mon, 26 Jul 2004 04:47:58 +0000, Dean Kent wrote:
>>
>>
>> A 64bit OS is a slam dunk, though perhaps not from Micro$hit.
>> Perhaps politics is involved here? Nah Dean, couldn't be!
>
> I don't think so. More likely Windows is a nightmare to code/modify. Some
> people like conspiracy theories, however. :-).

Moi? Come on. Either M$ is incompetent or they're holding back. You
choose!

>> BTW, 64bit Linux works fine here! It seems Sun is found the light too.
>
> Linux isn't Windows,

No (micro)$hit! Linux doesn't have the corporate skulldugery impeeding
its progress. There is a market, it will fill it. ...kinda like AMD
these days.

> and therefore is a completely different argument.
> Sun found religion for the same reason most others do... impending
> death! <g>.

Perhaps not impending.

>> OTOH, Itanic well never see the light, no matter how hard the pundits
>> push.
>
> Unlike Power, which will dominate everywhere, right?

Well, there is no longer a "Power" architecture (you really should
know by now that that is a silly marketeer's term). If you're
alluding to "PowerPC", well it seems to be invading from top to bottom;
IBM's Power(TM) and blades, Apple G5 and XServe, Nintendo,
PlayStation3, X-Box2, and a ton of embedded stuff.


Yeah, it seems to be doing a tad better than Itanic! ;-)


> No politics here!!! ;-).

Who me? o;-)

BTW, Dean a decent newsreader is in order. Lookout sucks.

Dean Kent
July 29th 04, 04:42 AM
"Keith" > wrote in message
...
>
> Moi? Come on. Either M$ is incompetent or they're holding back. You
> choose!

How many Windows programmers does it take to change a lightbulb? ;-).

>
> No (micro)$hit! Linux doesn't have the corporate skulldugery impeeding
> its progress. There is a market, it will fill it. ...kinda like AMD
> these days.

Far too early to tell for AMD, unfortunately. 15% marketshare is a bit less
than their best. Server segment share is not too shabby, but still a long
way to go to be compared to Linux.

>
> > and therefore is a completely different argument.
> > Sun found religion for the same reason most others do... impending
> > death! <g>.
>
> Perhaps not impending.

Hell, they're not only porting Solaris to x86-64, but are considering
PowerWhatever/IPF as well. Sun sees the light, and it is coming from
somewhere else. ;-).

>
> Well, there is no longer a "Power" architecture (you really should
> know by now that that is a silly marketeer's term). If you're
> alluding to "PowerPC", well it seems to be invading from top to bottom;
> IBM's Power(TM) and blades, Apple G5 and XServe, Nintendo,
> PlayStation3, X-Box2, and a ton of embedded stuff.
>
>
> Yeah, it seems to be doing a tad better than Itanic! ;-)

It has impressive numbers, for sure. What happened to SPEC int, though?

>
>
> > No politics here!!! ;-).
>
> Who me? o;-)
>
> BTW, Dean a decent newsreader is in order. Lookout sucks.

So I've heard. I haven't made the investment (timewise) to put Linux on,
and don't have the funds to upgrade my K7 box to a K8 yet. I figure to do
that all at the same time - will you stop your whining then? :-) Besides,
I keep hoping IBM will let me play with a Thinkpad with FLEX-ES and z/OS on
it (or they approve z/OS to run on Hercules along with an affordable
single-user license) so I can pretend I am on a *real* computer while at
home... <g>.

Regards,
Dean

Bill Davidsen
July 29th 04, 05:00 AM
Pleasant Thrip wrote:
> In comp.arch Bill Davidsen > wrote:
>
>>Pleasant Thrip wrote:
>>
>>>why do you say that? Maybe there will be particular issues for
>>>applications to make use of all those CPUs but I don't see why it would
>>>be such a big deal for the OS kernel scheduler.
>
>
>>You don't understand the problem... the o/s needs to make all sorts of
>>decisions about moving a process to another processor to load balance
>>vs. cost of moving, etc. It is a nasty problem!
>
>
> Sure it is a nasty problem and I do understand that. But, I'm talking
> about the total amount of work for Microsoft here.

I think this is a serial problem, time to solution is at least the time
to solution for the most dificult problem, or more depending on how many
things can be done in parallel.
>
> How many people do you think would need to be working on the kernel
> development for this particular problem as opposed to migrating the
> entire Win32 API and attendant APIs such as DirectX to 64-bit? That was
> my point. The real world is more than some academic abstraction that
> "NUMA is hard" and so on. The real world is about delivering a complete
> shrink-wrapped 64-bit Windows XP I can buy.

People are still doing graduate thesis on NUMA, it's not clear that more
people will mean shorter time to solution. The first cut may settle for
being stable and running well where Ntask <= Ncpu. Getting it wrong
means bigtime bad throughput, which is probably an issue, since there
are more mature Linux and Solaris (I'm told) models as competition.

I think the rest of the steps are pretty well understood and can be
solved in reasonable time. Or course things like keeping the CPU number
in a byte will need work ;-)
>
> For those that think the issue was solved with the Itanium/Alpha ports
> you obviously aren't Windows programmers nor conversant with the various
> APIs.
>
> And if anybody wants to further this discussion, please stick OT. We're
> talking _Windows_ here, much as some of you might not like.
>
>
>>>IMHO, 64-bits is much harder considering the Win32 API.
>

--
bill davidsen )
SBC/Prodigy Yorktown Heights NY data center
Project Leader, USENET news
http://newsgroups.news.prodigy.com

chrisv
July 29th 04, 02:28 PM
"Dean Kent" > wrote:

>It has impressive numbers, for sure. What happened to SPEC int, though?

Does anyone care about integer performance anymore? 8)

Keith R. Williams
July 29th 04, 03:39 PM
In article >,
says...
> "Keith" > wrote in message
> ...
> >
> > Moi? Come on. Either M$ is incompetent or they're holding back. You
> > choose!
>
> How many Windows programmers does it take to change a lightbulb? ;-).

That's easy; none. But that certainly doesn't answer the question
(quite the opposite, in fact). ;-)

> > No (micro)$hit! Linux doesn't have the corporate skulldugery impeeding
> > its progress. There is a market, it will fill it. ...kinda like AMD
> > these days.
>
> Far too early to tell for AMD, unfortunately. 15% marketshare is a bit less
> than their best. Server segment share is not too shabby, but still a long
> way to go to be compared to Linux.

Linux has 15%? The server segment is not too shabby, but...

> > > and therefore is a completely different argument.
> > > Sun found religion for the same reason most others do... impending
> > > death! <g>.
> >
> > Perhaps not impending.
>
> Hell, they're not only porting Solaris to x86-64, but are considering
> PowerWhatever/IPF as well. Sun sees the light, and it is coming from
> somewhere else. ;-).

When one has so many lamps to choose from, why would one keep lamp-
designers on payroll?

> > Well, there is no longer a "Power" architecture (you really should
> > know by now that that is a silly marketeer's term). If you're
> > alluding to "PowerPC", well it seems to be invading from top to bottom;
> > IBM's Power(TM) and blades, Apple G5 and XServe, Nintendo,
> > PlayStation3, X-Box2, and a ton of embedded stuff.
> >
> >
> > Yeah, it seems to be doing a tad better than Itanic! ;-)
>
> It has impressive numbers, for sure. What happened to SPEC int, though?

Don't look at me! I didn't take it! ...which SPEC Int were you
referring to?

> > > No politics here!!! ;-).
> >
> > Who me? o;-)
> >
> > BTW, Dean a decent newsreader is in order. Lookout sucks.
>
> So I've heard. I haven't made the investment (timewise) to put Linux on,
> and don't have the funds to upgrade my K7 box to a K8 yet. I figure to do
> that all at the same time - will you stop your whining then? :-)

Linux isn't needed to get a decent reader. Agent works fine under Win,
though I prefer Gravity. There are many choices, most *free*, and all
better than outhouse. It doesn't take a lot of time to switch. It took
me an hour or so to switch from Win/Gravity to Linux/PAN.

> Besides,
> I keep hoping IBM will let me play with a Thinkpad with FLEX-ES and z/OS on
> it (or they approve z/OS to run on Hercules along with an affordable
> single-user license) so I can pretend I am on a *real* computer while at
> home... <g>.

I can't remember the last time I logged onto a 'Z' system. Must be
close to five years for VM (I've long forgotten my password) and
fifteen for MVS.

--
Keith

Hellmark
July 29th 04, 04:50 PM
Dean Kent's last words before the Sword of Azrial plunged through his body
were:
> "Keith" > wrote in message
> ...
>> BTW, Dean a decent newsreader is in order. Lookout sucks.
> So I've heard. I haven't made the investment (timewise) to put Linux on,
> and don't have the funds to upgrade my K7 box to a K8 yet. I figure to do
> that all at the same time - will you stop your whining then? :-) Besides,
> I keep hoping IBM will let me play with a Thinkpad with FLEX-ES and z/OS on
> it (or they approve z/OS to run on Hercules along with an affordable
> single-user license) so I can pretend I am on a *real* computer while at
> home... <g>.

You can get different email and news readers for windows too, ya know

Tony Hill
July 29th 04, 07:31 PM
On Wed, 28 Jul 2004 17:48:05 +0000 (UTC), Sander Vesik
> wrote:
>In comp.arch Ketil Malde > wrote:
>> "Dean Kent" > writes:
>>
>> >> It would be supremely embarrassing to Microsoft if Sun gets Solaris for
>> >> Opteron out before Windows.
>>
>> > My money is on embarassement...
>>
>> I guess it's somewhat embarrassing if Sun ships Opteron servers, and
>> can't offer Solaris to go with them. Microsoft can still afford to
>> wait, the vast majority of their market is still Intel and 32 bits.
>
>I though Solaris 9 something was an option on the Opterons?

The 32-bit version of Solaris 9 is indeed an option on the Opterons,
but that's not really what we're interested in here. It's the 64-bit
version of Solaris 10 that people are waiting for.

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

Tony Hill
July 29th 04, 07:40 PM
On Wed, 28 Jul 2004 19:34:59 GMT, "Hank Oredson" >
wrote:
>"Tony Hill" > wrote in message
...
>> For those that aren't familiar with WinXP SP2, it is a pretty
>> significant change to WinXP (many have referred to it more as "WinXP
>> Second Edition" rather than just a service pack). Lots of positive
>> changes with regards to the basic security concept of the system, but
>> MS seems to be having HUGE problems making it work. Reports from the
>> recently released "Release Candidate 2" suggest that this is still
>> definitely beta software (certainly not an actual candidate to be
>> released). I suspect that until MS gets these sorted out they aren't
>> going to try to push the other new OSes and service packs out.
>
>
>Kinda curious where you found the reports on SP2 RC2.
>Have three systems running it, with zero problems.
>
>I'd like to read the reports so I can tell what problems
>to look for and test.

The biggest issue I've been hearing about (admittedly mostly
second-hand) seems to be with actually getting the service pack
installed. A lot of people seem to have had all sorts of problems,
ranging from changing settings and breaking things right up to making
the machines blue-screen and not boot.

Once installed I have heard of a few application compatibilities,
particularly with software that does kind of funky things with
hardware (some CD burning applications, virtual drives, etc.). Some
of these problems are probably almost by design, ie they tie in to the
new security features of SP2, but in the process break compatibility
with some odd-ball software. This isn't entirely a bad thing, MS
really NEEDED to break compatibility with some software in order to
improve their security, but there do still seem to be a few rough
edges to be worked out.

Of course, that being said, "release candidates" are never really
actual candidates for release, so I shouldn't really be directing too
much blame at MS for this one. They're really just late-beta releases
that are going through their final testing and bug-fixing before an
actual release candidate can be created. In this regards RC2 seems
fine. Hopefully MS will get the rough edges smoothed out and get SP2
out by the end of the year (only about a year late) so that all the
other new operating systems can get here.

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

Yousuf Khan
July 29th 04, 07:54 PM
Bill Davidsen > wrote:
> People are still doing graduate thesis on NUMA, it's not clear that
> more people will mean shorter time to solution. The first cut may
> settle for being stable and running well where Ntask <= Ncpu. Getting
> it wrong means bigtime bad throughput, which is probably an issue,
> since there are more mature Linux and Solaris (I'm told) models as
> competition.
>
> I think the rest of the steps are pretty well understood and can be
> solved in reasonable time. Or course things like keeping the CPU
> number in a byte will need work ;-)


I just remembered that pretty soon there will be dual-core Opterons too, so
that in itself will add another level of NUMA to take into account. Internal
chip-connect vs. Hypertransport connect vs. customized board-to-board
connect.

Yousuf Khan

Stephen Sprunk
July 30th 04, 01:14 AM
"Russell Wallace" > wrote in message
...
> On Wed, 28 Jul 2004 07:45:16 -0500, chrisv >
> wrote:
> >"Dean Kent" > wrote:
> >>Linux isn't Windows, and therefore is a completely different argument.
> >
> >Are you being sarcastic?
>
> I don't know whether he's being sarcastic...
>
> >I'd be amazed if Win32 was not 64-bit clean
> >from day one. The industry was a lot more mature at that point, and
> >hopefully learned from the migration of 16- to 32-bit...
>
> ...but I hope you are! :P

NT was 64-bit clean, since the Alpha and MIPS ports seemed to make that a
requirement, as does the upcoming PPC port for Xbox2.

The biggest problems are getting all those 32-bit drivers converted to
64-bit, and getting 32-bit apps to work under a 64-bit OS, neither of which
was a problem for the prior ports (since they were 64-bit only).

Some "apps" like .NET were gratuitously dependent on the register size, and
those will need serious reworking, but the OS core was ported to AMD64 over
a year ago.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Stephen Sprunk
July 30th 04, 01:15 AM
"Dean Kent" > wrote in message
m...
> "Yousuf Khan" > wrote in message
> ers.com...
> >
> > It would be supremely embarrassing to Microsoft if Sun gets Solaris for
> > Opteron out before Windows.
>
> My money is on embarassement...

Given MS just announced all AMD64 platforms have slipped to 1Q05,
embarrassment is pretty much a given -- not to mention Linux has been
shipping for AMD64 for over a year.

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Keith
July 30th 04, 03:42 AM
On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:

> "Russell Wallace" > wrote in message
> ...

>> >I'd be amazed if Win32 was not 64-bit clean
>> >from day one. The industry was a lot more mature at that point, and
>> >hopefully learned from the migration of 16- to 32-bit...
>>
>> ...but I hope you are! :P
>
> NT was 64-bit clean, since the Alpha and MIPS ports seemed to make that a
> requirement, as does the upcoming PPC port for Xbox2.

I don't know how you could come to any of these conclusions, given the
public information anyway.

> The biggest problems are getting all those 32-bit drivers converted to
> 64-bit, and getting 32-bit apps to work under a 64-bit OS, neither of
> which was a problem for the prior ports (since they were 64-bit only).

I agree with the others here. Force the issue by eliminating those who
won't convert. It seems Linux has done a reasonable job of supporting
AMD64 *without* all the resources M$ can bring to bare.

> Some "apps" like .NET were gratuitously dependent on the register size,
> and those will need serious reworking, but the OS core was ported to
> AMD64 over a year ago.

Ah, so we have another conspiracy theory. So you're on the "incompetence"
side?

--
Keith

Dean Kent
July 30th 04, 06:23 AM
"Keith" > wrote in message
...
>
> Ah, so we have another conspiracy theory. So you're on the "incompetence"
> side?

Some things are designed to be easily portable (such as DB2, perhaps?),
while others are not. The incompetence does not have to be with today's
coders, but could be due to yesterday's designers...

Regards,
Dean

>
> --
> Keith

Tim Shoppa
July 30th 04, 12:50 PM
"Ken Hagan" > wrote in message >...
> chrisv wrote:
> >
> > Are you being sarcastic? I'd be amazed if Win32 was not 64-bit clean
> > from day one. The industry was a lot more mature at that point, and
> > hopefully learned from the migration of 16- to 32-bit...
>
> Surely if Win32 were 64-bit clean, MS wouldn't have had to ship separate
> Win64 headers, which they did, to the general horror of everyone who
> expected a 64-bit "long".

Many of us have been working with 64-bit desktop CPU's, OS's, and C
compilers for over a decade now. Yeah, there are decisions to be made.
This was hardly the first time this particular decision was made that way.

Tim.

Stephen Sprunk
July 30th 04, 02:51 PM
"Yousuf Khan" > wrote in message
gers.com...
> I just remembered that pretty soon there will be dual-core Opterons too,
so
> that in itself will add another level of NUMA to take into account.
Internal
> chip-connect vs. Hypertransport connect vs. customized board-to-board
> connect.

Does an OS really need to be aware of the difference between two cores on
the same chip?

Linux has a concept of a NUMA "node", where all of the processors in a node
are considered equivalent. It'll still try to schedule threads on the same
CPU they last ran on, but next it will try other CPUs in the same node
before giving up and sending it to any available node.

IIRC, the code already understands two-CPU nodes, because that is how
Intel's SMT chips are handled. Treating K8 CMP the same way sounds correct,
once AMD releases specs on how to recognize dual-core chips.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Stephen Sprunk
July 30th 04, 03:09 PM
"Keith" > wrote in message
...
> On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:
> > NT was 64-bit clean, since the Alpha and MIPS ports seemed to make that
a
> > requirement, as does the upcoming PPC port for Xbox2.

Oops, forgot to mention the Itanic port as well.

> I don't know how you could come to any of these conclusions, given the
> public information anyway.

Assuming MS is at least marginally competent, maintaining source that is
cleanly portable between 32-bit and 64-bit systems is required when they
have versions shipping for both sizes, and have (on and off) ever since NT
was created.

> > The biggest problems are getting all those 32-bit drivers converted to
> > 64-bit, and getting 32-bit apps to work under a 64-bit OS, neither of
> > which was a problem for the prior ports (since they were 64-bit only).
>
> I agree with the others here. Force the issue by eliminating those who
> won't convert. It seems Linux has done a reasonable job of supporting
> AMD64 *without* all the resources M$ can bring to bare.

AMD64 is just another platform, and the third (or higher) platform supported
is of marginal cost compared to the second. The free software world has had
to contend with dozens of platforms for over two decades, and so the fact
Linux (and all the common apps) ported over cleanly is hardly surprising.

MS is in another boat; the NT kernel might be portable, but all the other OS
"stuff" and sundry apps may not be, and MS has never had more than one
platform with significant revenue that has forced them to adopt clean coding
practices.

> > Some "apps" like .NET were gratuitously dependent on the register size,
> > and those will need serious reworking, but the OS core was ported to
> > AMD64 over a year ago.
>
> Ah, so we have another conspiracy theory. So you're on the "incompetence"
> side?

I am a firm believer in Hanlon's Razor: never attribute to malice what can
be adequately explained by stupidity.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Yousuf Khan
July 30th 04, 03:52 PM
Stephen Sprunk wrote:
> Does an OS really need to be aware of the difference between two
> cores on the same chip?
>
> Linux has a concept of a NUMA "node", where all of the processors in
> a node are considered equivalent. It'll still try to schedule
> threads on the same CPU they last ran on, but next it will try other
> CPUs in the same node before giving up and sending it to any
> available node.
>
> IIRC, the code already understands two-CPU nodes, because that is how
> Intel's SMT chips are handled. Treating K8 CMP the same way sounds
> correct, once AMD releases specs on how to recognize dual-core chips.

I'm sure as a first cut, not treating them specially is the right way to go.
But eventually everybody tries to optimize down to the bone. AMD is even
suggesting not treating Hypertransport as NUMA but as simple SMP is quite
acceptable, and this suggestion is likely to hold for dual-cores too
(probably even more so).

Yousuf Khan

Ken Hagan
July 30th 04, 04:03 PM
Regarding Microsoft's decision to keep "long" at 32-bits for Win64...


Tim Shoppa wrote:
>
> Many of us have been working with 64-bit desktop CPU's, OS's, and C
> compilers for over a decade now. Yeah, there are decisions to be
> made.
> This was hardly the first time this particular decision was made that
> way.

Ah, then I've just benefitted from the venerable maxim that the fastest
way to learn anything is to post wrong information to Usenet. I was
under the impression that everyone else had jumped the other way on this
one.

I am also under the impression that sticking to 32 bits hasn't actually
helped MS achieve their aims of source portability, since the rules on
MSDN suggest *very* strongly to me that all client code has to be
re-written to use their silly typedefs (like INT_PTR and LONG_PTR) in
any case. Therefore, the only consequence of the 32-bit long has been to
make it impossible to write C89 or C++98 code for that platform.

Doubtless you or someone else will now disabuse me of that opinion as
well.

Tim Shoppa
July 31st 04, 02:06 AM
"Ken Hagan" > wrote in message >...
> Regarding Microsoft's decision to keep "long" at 32-bits for Win64...
>
>
> Tim Shoppa wrote:
> >
> > Many of us have been working with 64-bit desktop CPU's, OS's, and C
> > compilers for over a decade now. Yeah, there are decisions to be
> > made.
> > This was hardly the first time this particular decision was made that
> > way.
>
> Ah, then I've just benefitted from the venerable maxim that the fastest
> way to learn anything is to post wrong information to Usenet. I was
> under the impression that everyone else had jumped the other way on this
> one.

Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
(and 64-bit long longs).

Some will interpret Microsoft's decision to use 32-bit longs as evidence
that DEC/Cutler's influence in Alpha NT still lingers. But there are other
valid reasons to choose it (many of them related to portability under
an established set of coding rules).

> I am also under the impression that sticking to 32 bits hasn't actually
> helped MS achieve their aims of source portability, since the rules on
> MSDN suggest *very* strongly to me that all client code has to be
> re-written to use their silly typedefs (like INT_PTR and LONG_PTR) in
> any case.

C has always been a basket case with respect to integer sizes. Until
recently you had to choose someone's silly typedefs or choose to
chart your own course. The new standards do help... but only if you use
them.

Tim.

glen herrmannsfeldt
July 31st 04, 03:25 AM
Tim Shoppa wrote:

(snip)

> Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
> (and 64-bit long longs).

I thought it was 32 bit int and 64 bit long. It broke a lot of
programs expecting 32 bit longs. I presume you mean OSF1.
There was (and is) also Alpha/VMS which may have had 32 bit long,
but I don't remember that long long even existed at the time.

> Some will interpret Microsoft's decision to use 32-bit longs as evidence
> that DEC/Cutler's influence in Alpha NT still lingers. But there are other
> valid reasons to choose it (many of them related to portability under
> an established set of coding rules).

-- glen

Nick Maclaren
July 31st 04, 11:37 AM
In article >,
Tim Shoppa > wrote:
>
>Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
>(and 64-bit long longs).

Are you SURE? I am pretty sure that I investigated that, and found
it to be an urban myth. Yes, there is such a mode, but the normal
one is I32LP64, just like any sane system.

>Some will interpret Microsoft's decision to use 32-bit longs as evidence
>that DEC/Cutler's influence in Alpha NT still lingers. But there are other
>valid reasons to choose it (many of them related to portability under
>an established set of coding rules).

The first statement is doubtful. When it was claimed, a lot of people
provided evidence that it was an aberrant decision, and that Microsoft
compilers more often used I32LP64 than IL32LLP64.

The second statement is wrong. I am the person who investigated that,
and all of the actual evidence is that the portability problems caused
by IL32LLP64 are FAR greater than those caused by I32LP64. While I did
not investigate Microsoft's code, I did inspect the relevant coding
standards, and the problems my investigation detected would have arisen
as much in that as in the programs I did look at.

>> I am also under the impression that sticking to 32 bits hasn't actually
>> helped MS achieve their aims of source portability, since the rules on
>> MSDN suggest *very* strongly to me that all client code has to be
>> re-written to use their silly typedefs (like INT_PTR and LONG_PTR) in
>> any case.
>
>C has always been a basket case with respect to integer sizes. Until
>recently you had to choose someone's silly typedefs or choose to
>chart your own course. The new standards do help... but only if you use
>them.

They do help - but only if you are not interested in serious (i.e.
long-term and widespread) portability! If you are, C99 is a disaster,
where C90 was merely a basket case.

The point is that, for such portability, you need to choose sizes by
PROPERTY not bit count. I.e. "The smallest signed integer type that
can address the largest allocatable object" or "the smallest integer
type that can hold A_INT_T_MAX*A_INT_T_MAX".

Now, making <float.h> usable by the preprocessor and the new symbols
for the limits DOES help, but the ghastly bit-count sizes are quite
useless. Despite repeated claims, nobody has ever produced evidence
that they help competent programmers - though I do agree that they
do help bozos.

The claim that they help with networking and other interfaces is
completely bogus, as they don't specify endianness (or some other
critical properties in some cases). Nor do structures specify
padding and alignment. So portable programs STILL have to do their
own packing.


Regards,
Nick Maclaren.

Tim Shoppa
July 31st 04, 04:57 PM
(Nick Maclaren) wrote in message >...
> In article >,
> Tim Shoppa > wrote:
> >
> >Most had. But the 64-bit Alpha with the DEC C compiler, has 32-bit longs
> >(and 64-bit long longs).
>
> Are you SURE? I am pretty sure that I investigated that, and found
> it to be an urban myth. Yes, there is such a mode, but the normal
> one is I32LP64, just like any sane system.

DEC C V6.0-001 (which was rather current as of late 1998) under Alpha VMS 7.2:

$ type junk.c
#include <stdio.h>
main () {
int x;
long y;
long long z;
printf("int is %d bytes,long is %d bytes, long long is %d bytes\n",
sizeof(x),sizeof(y),sizeof(z));
}
$ cc junk.c
$ link junk
$ run junk
int is 4 bytes,long is 4 bytes, long long is 8 bytes

The compiler has a whole array of switches for changing default sizes,
not just of various int and float types, but also of the pointers.

> >Some will interpret Microsoft's decision to use 32-bit longs as evidence
> >that DEC/Cutler's influence in Alpha NT still lingers. But there are other
> >valid reasons to choose it (many of them related to portability under
> >an established set of coding rules).
>
> The first statement is doubtful. When it was claimed, a lot of people
> provided evidence that it was an aberrant decision, and that Microsoft
> compilers more often used I32LP64 than IL32LLP64.
>
> The second statement is wrong. I am the person who investigated that,
> and all of the actual evidence is that the portability problems caused
> by IL32LLP64 are FAR greater than those caused by I32LP64. While I did
> not investigate Microsoft's code, I did inspect the relevant coding
> standards, and the problems my investigation detected would have arisen
> as much in that as in the programs I did look at.

I'm not really trying to defend those choices. Just pointing out that
similar choices were made over a decade ago. And that I kinda understand
why those choices were made (I was porting hundreds of thousands of lines
of C code written in the "all the world's a VAX" mode, and the defaults
made sense to *me*!) But I agree that they are not the most natural
choices if you know the whole world's moving (or in my case, has moved)
to 64 bit CPU's and OS's.

Keep in mind that in Alpha assembler-talk, a "word" is 16 bits and a "longword"
is 32 bits. The "quadword" is 64 bits. Yes, the first two are
anachronisms from PDP-11 days. Again, I'm not defending those choices,
I'm just pointing out that they were made before and will be made again
despite how strongly we feel they are anachronisms.

Tim.

Derek Baker
July 31st 04, 05:16 PM
Yousuf Khan wrote:
> Ed wrote:
>> Hey, is Windows "Longhorn" gonna be for x86-64 CPU?
>> Ed
>
> Current rumours are that, that's all it's going to be for. You won't
> be able to run it on anything less than a 64-bit machine.
>
> Yousuf Khan

Links?

--
Derek

Carlo Razzeto
July 31st 04, 06:41 PM
"George Macdonald" > wrote in message
...
> On Tue, 27 Jul 2004 18:15:24 -0400, "Carlo Razzeto" >
> wrote:
>
> >
<SNIP>
> That readjustment, which also included raised prices for a cpuple of
> models, was on Monday and I'm going by prices paid for recent "shopping".
> The price *has* been holding quite well for AMD64 CPUs compared with their
> historical curves and even Intel's - even at the old higher prices, they
> were definitely in quite tight supply.
>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who,
me??

Yeah, but I think this still show that they are starting to ramp up. What
this price adjustment shows me is that they are ready to take A64 into the
main stream market (by this I mean the mid-range pc market of course). Prior
to this price adjustment even the "low end" A64's were considered to be
parts reserved for highend/enthusiest boxes... Now the prices are low enough
that just last friday I got around to buying an A64 3000+ and a fairly nice
Chaintech board to go with it.

Carlo

Keith
July 31st 04, 07:01 PM
On Fri, 30 Jul 2004 05:23:57 +0000, Dean Kent wrote:

> "Keith" > wrote in message
> ...
>>
>> Ah, so we have another conspiracy theory. So you're on the "incompetence"
>> side?
>
> Some things are designed to be easily portable (such as DB2, perhaps?),
> while others are not. The incompetence does not have to be with today's
> coders, but could be due to yesterday's designers...

I surely *hope* M$'s architects learned something from OS/2 days. NT was
a complete re-write and one would suspect that they learned a few lessons
along the way.

--
Keith

Nick Maclaren
July 31st 04, 07:06 PM
In article >,
Tim Shoppa > wrote:
>
>DEC C V6.0-001 (which was rather current as of late 1998) under Alpha VMS 7.2:

I remember now (and have just got a colleague to check). Yes, VMS
uses that model, but Tru64 uses the normal I32LP64 one. As far as I
know, the sum total of C compilers on systems that anyone normal has
ever heard of that use IL32LLP64 is two, and both of those are relics
(i.e. I believe that Microsoft's future direction is I32LP64).

>I'm not really trying to defend those choices. Just pointing out that
>similar choices were made over a decade ago. And that I kinda understand
>why those choices were made (I was porting hundreds of thousands of lines
>of C code written in the "all the world's a VAX" mode, and the defaults
>made sense to *me*!) But I agree that they are not the most natural
>choices if you know the whole world's moving (or in my case, has moved)
>to 64 bit CPU's and OS's.

Oh, I am not arguing with DEC's VMS choice - not at all - what I am
referring to is the decision to break all of the working C90 code
to support an essentially unused option. And the fact that the
claim that it was necessary to do so to avoid breaking existing
code was the CONVERSE of the truth.


Regards,
Nick Maclaren.

Carlo Razzeto
July 31st 04, 07:30 PM
"Keith" > wrote in message
...
> On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:
>
> > "Russell Wallace" > wrote in message
> > ...
>
> I agree with the others here. Force the issue by eliminating those who
> won't convert. It seems Linux has done a reasonable job of supporting
> AMD64 *without* all the resources M$ can bring to bare.
>
<SNIP>
> --
> Keith

Define "support"? Linux has the advantage that it is still not for the
average home user so they lose compaibility with old apps and old hardware
and not care because the people running 64big Linux on AMD64 won't care.
Windows on the other hand doesn't that advantage. If they don't have at
least 95% support for everything XP supports at launch it's a real issue for
Microsoft.

Carlo

Rupert Pigott
July 31st 04, 08:07 PM
Carlo Razzeto wrote:

[SNIP]

> Define "support"? Linux has the advantage that it is still not for the
> average home user so they lose compaibility with old apps and old hardware
> and not care because the people running 64big Linux on AMD64 won't care.

That is not true. Besides if it *were* true, Microsoft have done all
this and got the T-Shirt with IA-64 already, surely... Linux has too.

> Windows on the other hand doesn't that advantage. If they don't have at
> least 95% support for everything XP supports at launch it's a real issue for
> Microsoft.

MS has no excuse, they've had well over a decade to get this right
during which they have had considerable clout over the hardware vendors
and they have a *lot* more resource to throw at the problem that the
Linux bods ($$$ for specialist dev. platforms etc).


Cheers,
Rupert

glen herrmannsfeldt
July 31st 04, 08:47 PM
Nick Maclaren wrote:
> In article >,
> Tim Shoppa > wrote:

>>DEC C V6.0-001 (which was rather current as of late 1998) under Alpha VMS 7.2:

> I remember now (and have just got a colleague to check). Yes, VMS
> uses that model, but Tru64 uses the normal I32LP64 one. As far as I
> know, the sum total of C compilers on systems that anyone normal has
> ever heard of that use IL32LLP64 is two, and both of those are relics
> (i.e. I believe that Microsoft's future direction is I32LP64).

When was "long long" invented? It isn't part of C90, but
seems to have been implemented in many compilers. I don't
believe that it existed yet when Alpha came out, though.

It seems to me that as both 16 bit (early x86) and 32 bit
(Sun and VAX for example) machines got popular, and networking
software needed types for 16 bit and 32 bit data that short
and long were the popular standard types. (If int had been
32 bits from the beginning, that wouldn't have been a problem.)

>>I'm not really trying to defend those choices. Just pointing out that
>>similar choices were made over a decade ago. And that I kinda understand
>>why those choices were made (I was porting hundreds of thousands of lines
>>of C code written in the "all the world's a VAX" mode, and the defaults
>>made sense to *me*!) But I agree that they are not the most natural
>>choices if you know the whole world's moving (or in my case, has moved)
>>to 64 bit CPU's and OS's.

Alpha first came out around 1993 or so, and I don't believe that
long long existed yet. It seems to me, then, that there wasn't
much of a choice. Also, making long 64 bits reminds people that
it is a 64 bit architecture.

> Oh, I am not arguing with DEC's VMS choice - not at all - what I am
> referring to is the decision to break all of the working C90 code
> to support an essentially unused option. And the fact that the
> claim that it was necessary to do so to avoid breaking existing
> code was the CONVERSE of the truth.

-- glen

Dean Kent
August 1st 04, 02:45 AM
"Keith" > wrote in message
...
>
> I surely *hope* M$'s architects learned something from OS/2 days. NT was
> a complete re-write and one would suspect that they learned a few lessons
> along the way.

Hope springs eternal!

Then reality hits. <grin>

Regards,
Dean

>
> --
> Keith

Keith
August 1st 04, 03:22 AM
On Sat, 31 Jul 2004 14:30:18 -0400, Carlo Razzeto wrote:

> "Keith" > wrote in message
> ...
>> On Thu, 29 Jul 2004 19:14:06 -0500, Stephen Sprunk wrote:
>>
>> > "Russell Wallace" > wrote in message
>> > ...
>>
>> I agree with the others here. Force the issue by eliminating those who
>> won't convert. It seems Linux has done a reasonable job of supporting
>> AMD64 *without* all the resources M$ can bring to bare.
>>
> <SNIP>
>> --
>> Keith
>
> Define "support"? Linux has the advantage that it is still not for the
> average home user so they lose compaibility with old apps and old hardware
> and not care because the people running 64big Linux on AMD64 won't care.
> Windows on the other hand doesn't that advantage. If they don't have at
> least 95% support for everything XP supports at launch it's a real issue for
> Microsoft.

Ok, now define "Windows support". Hint; it doesn't exist. They off-load
any little "support" to their OEM's. Amazing, really!


--
Keith

Hellmark
August 1st 04, 03:35 AM
Carlo Razzeto's last words before the Sword of Azrial plunged through his
body were:
> Define "support"? Linux has the advantage that it is still not for the
> average home user so they lose compaibility with old apps and old hardware
> and not care because the people running 64big Linux on AMD64 won't care.

I dont know of any hardware not being supported in the newer 64bit stuff,
but one reason why they dont care is because the vast majority (99% of all
linux software) can be recompiled for running on 64bit systems. Debian's
pool has been already mostly ported over. Windows can't do that, because
damn near everything is closed source.

Keith
August 1st 04, 03:41 AM
On Sun, 01 Aug 2004 01:45:44 +0000, Dean Kent wrote:

> "Keith" > wrote in message
> ...
>>
>> I surely *hope* M$'s architects learned something from OS/2 days. NT was
>> a complete re-write and one would suspect that they learned a few lessons
>> along the way.
>
> Hope springs eternal!

Let's put it this way; one only get's so many chances at life.

> Then reality hits. <grin>

Are you saying that M$ ran out of chances? If so, I suggest you short
'em. There is much money to be made if you're right!

--
Keith

Carlo Razzeto
August 1st 04, 05:43 AM
"Keith" > wrote in message
...
> On Sat, 31 Jul 2004 14:30:18 -0400, Carlo Razzeto wrote:
> Ok, now define "Windows support". Hint; it doesn't exist. They off-load
> any little "support" to their OEM's. Amazing, really!
>
>
> --
> Keith

Customer service? If that's what you mean it sucks all around no matter what
you choose so who cares? My point is Linux doesn't have to worry about being
a functional desktop system because most people don't use it that way, and
those who do know enough to build a system that will meet their needs and
how to get everything they need working up and running. MS has to deal with
the average user.

Carlo

Carlo Razzeto
August 1st 04, 05:51 AM
"Hellmark" > wrote in message
news:[email protected]****SPA M.net...
> I dont know of any hardware not being supported in the newer 64bit stuff,
> but one reason why they dont care is because the vast majority (99% of all
> linux software) can be recompiled for running on 64bit systems. Debian's
> pool has been already mostly ported over. Windows can't do that, because
> damn near everything is closed source.

Eh... That's not really a hold up for Microsoft... Frankly I'm really not a
big believer that Open Source inherently provides any such advantage... It
doesn't really matter that MS doesn't know how Quicken implemented Quick
Books, all they need to know is how the 32bit Windows API works and make the
64bit WoW interface work like that. I do realize that in real life things
aren't that easy, but I'm not convinced that open source makes that aspect
of porting an operating system any easier... The same principle will applied
to Linux... Well written 32bit code that uses the standard system libraries
should work.

Carlo

Hellmark
August 1st 04, 07:26 AM
Carlo Razzeto's last words before the Sword of Azrial plunged through his
body were:
> "Hellmark" > wrote in message
> news:[email protected]****SPA M.net...
>> I dont know of any hardware not being supported in the newer 64bit stuff,
>> but one reason why they dont care is because the vast majority (99% of all
>> linux software) can be recompiled for running on 64bit systems. Debian's
>> pool has been already mostly ported over. Windows can't do that, because
>> damn near everything is closed source.
>
> Eh... That's not really a hold up for Microsoft... Frankly I'm really not a
> big believer that Open Source inherently provides any such advantage... It
> doesn't really matter that MS doesn't know how Quicken implemented Quick
> Books, all they need to know is how the 32bit Windows API works and make the
> 64bit WoW interface work like that. I do realize that in real life things
> aren't that easy, but I'm not convinced that open source makes that aspect
> of porting an operating system any easier... The same principle will applied
> to Linux... Well written 32bit code that uses the standard system libraries
> should work.

making it run another API, flawlessly, is a pain in the ass at times.
Linux did take the easy route, and just recompile everything. It's far
easier to recompile than it is to make a setup that runs both

George Macdonald
August 1st 04, 10:02 AM
On Sat, 31 Jul 2004 13:41:57 -0400, "Carlo Razzeto" >
wrote:

>"George Macdonald" > wrote in message
...
>> On Tue, 27 Jul 2004 18:15:24 -0400, "Carlo Razzeto" >
>> wrote:
>>
>> >
><SNIP>
>> That readjustment, which also included raised prices for a cpuple of
>> models, was on Monday and I'm going by prices paid for recent "shopping".
>> The price *has* been holding quite well for AMD64 CPUs compared with their
>> historical curves and even Intel's - even at the old higher prices, they
>> were definitely in quite tight supply.
>
>Yeah, but I think this still show that they are starting to ramp up. What
>this price adjustment shows me is that they are ready to take A64 into the
>main stream market (by this I mean the mid-range pc market of course). Prior
>to this price adjustment even the "low end" A64's were considered to be
>parts reserved for highend/enthusiest boxes... Now the prices are low enough
>that just last friday I got around to buying an A64 3000+ and a fairly nice
>Chaintech board to go with it.

I've built two A64/3200+ systems recently - different cores but the price
had not changed at all in 6 weeks or so... until last weekend... and very
little before that. Those are 754 systems and certainly in the affordable
bracket, not in the high-end or enthusiast by any means - I generally look
for a CPU which is <$300... "mid-range PC" to me. IMO those adjustments
were just the next phase in the segmentation of marketing according to
current production of mbrds and production/uptake of CPUs. Basically this
accomodates socket 939 which is what is ramping up - mbrds are just
starting to appear. IOW it's the changeover to dual channel mainstream
CPUs.

I'm not sure what AMD's fab arrangements are here but I think they are
going to get into a tight supply situation before Dresden II comes
on-stream... late 2005? It'll be interesting to see how much "mileage"
they get out of the Lance/TdF success - they certainly got quite a wide
exposure there to what I believe is an "informed" audience. Other than
being in a state of total disarray:-), I'm not sure what the hell Intel is
up to with their reticence on x86-64 but I'm sure they're hoping that the
tight supply on A64 will contain it until they are "ready".

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Keith
August 1st 04, 02:38 PM
On Sun, 01 Aug 2004 00:43:17 -0400, Carlo Razzeto wrote:

> "Keith" > wrote in message
> ...
>> On Sat, 31 Jul 2004 14:30:18 -0400, Carlo Razzeto wrote:
>> Ok, now define "Windows support". Hint; it doesn't exist. They off-load
>> any little "support" to their OEM's. Amazing, really!
>>
>>
>> --
>> Keith
>
> Customer service? If that's what you mean it sucks all around no matter what
> you choose so who cares? My point is Linux doesn't have to worry about being
> a functional desktop system because most people don't use it that way, and
> those who do know enough to build a system that will meet their needs and
> how to get everything they need working up and running. MS has to deal with
> the average user.

My point is that M$ *DOESN't* deal with the average user. OEM's are stuck
dealing with the average user.

--
Keith

Ketil Malde
August 1st 04, 06:59 PM
Keith > writes:

> Are you saying that M$ ran out of chances? If so, I suggest you short
> 'em. There is much money to be made if you're right!

Well, they don't seem to be so hot on the 64bit issue, and at this
time many people are seriously considering both 64bit and alternatives
to Windows. I'm a bit puzzled they don't have a 64bit OS out by now.

They're probably struggling to put together Longhorn first, and with
lots of new stuff in there, deadlines will be fragile.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

Dean Kent
August 1st 04, 07:10 PM
"Ketil Malde" > wrote in message
...
> Keith > writes:
>
> > Are you saying that M$ ran out of chances? If so, I suggest you short
> > 'em. There is much money to be made if you're right!
>
> Well, they don't seem to be so hot on the 64bit issue, and at this
> time many people are seriously considering both 64bit and alternatives
> to Windows. I'm a bit puzzled they don't have a 64bit OS out by now.
>
> They're probably struggling to put together Longhorn first, and with
> lots of new stuff in there, deadlines will be fragile.

Well, I think that the effect of 64-bit on the desktop is a bit overrated.
Consider that AMD today enjoys just over 15% of the overall market. When
you consider that they increased their server market share it makes the
desktop share look even more anemic. This is significantly less than what
they had at the peak of K7, and even K6, production. Unlike those, there
has been no mad rush to go with A64. One can always blame MS for that, but
it really begs the question of which comes first, the MPU or the OS... ;-).

It should have been pretty obvious one or two years ago that x86-64 was not
going to be a 'revolution' on the desktop. There are certainly a lot of
vocal supporters, but they obviously represent a relatively small number of
actual users. 64-bit makes a lot more sense in servers, and doesn't MS
already have a 64-bit Windows Server offering for Opteron? I haven't
followed that closely, so I may be mistaken there...

>
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants

Yousuf Khan
August 1st 04, 07:54 PM
Derek Baker > wrote:
>> Current rumours are that, that's all it's going to be for. You won't
>> be able to run it on anything less than a 64-bit machine.
>>
>> Yousuf Khan
>
> Links?

As I said -- rumours.

Yousuf Khan

Derek Baker
August 1st 04, 08:12 PM
Yousuf Khan wrote:
> Derek Baker > wrote:
>>> Current rumours are that, that's all it's going to be for. You won't
>>> be able to run it on anything less than a 64-bit machine.
>>>
>>> Yousuf Khan
>>
>> Links?
>
> As I said -- rumours.
>
> Yousuf Khan

Ones whispered in your ear, as opposed to posted on the net? :)

--
Derek

Yousuf Khan
August 1st 04, 08:42 PM
Dean Kent wrote:
> It should have been pretty obvious one or two years ago that x86-64
> was not going to be a 'revolution' on the desktop. There are
> certainly a lot of vocal supporters, but they obviously represent a
> relatively small number of actual users. 64-bit makes a lot more
> sense in servers, and doesn't MS already have a 64-bit Windows Server
> offering for Opteron? I haven't followed that closely, so I may be
> mistaken there...

Nope, that's been delayed along with 64-bit XP. Really, Windows Server 2003
is nothing more than XP slightly tweaked for server operations.

Yousuf Khan

Yousuf Khan
August 1st 04, 08:42 PM
Derek Baker wrote:
> Yousuf Khan wrote:
>> Derek Baker > wrote:
>>>> Current rumours are that, that's all it's going to be for. You
>>>> won't be able to run it on anything less than a 64-bit machine.
>>>>
>>>> Yousuf Khan
>>>
>>> Links?
>>
>> As I said -- rumours.
>>
>> Yousuf Khan
>
> Ones whispered in your ear, as opposed to posted on the net? :)

No, they were posted on the net, but I can't find them anymore, Google is
just too awash in too many of these rumours to be useful.

Yousuf Khan

Carlo Razzeto
August 1st 04, 09:17 PM
"Keith" > wrote in message
...
> On Sun, 01 Aug 2004 00:43:17 -0400, Carlo Razzeto wrote:
>
> My point is that M$ *DOESN't* deal with the average user. OEM's are stuck
> dealing with the average user.
>
> --
> Keith
>

Ok... Perhaps I didn't state what I meant very clearly... What I meant by
deal with the average user is create a system which will do all of the
things that the average user thinks it needs to do... If that means run a
badly written application perfectly then that is what Windows has to do.
Even if they aren't dealing with customer directly it's still their
problem....

Carlo

Keith
August 2nd 04, 02:26 AM
On Sun, 01 Aug 2004 16:17:14 -0400, Carlo Razzeto wrote:

>
> "Keith" > wrote in message
> ...
>> On Sun, 01 Aug 2004 00:43:17 -0400, Carlo Razzeto wrote:
>>
>> My point is that M$ *DOESN't* deal with the average user. OEM's are stuck
>> dealing with the average user.
>>
>> --
>> Keith
>>
>
> Ok... Perhaps I didn't state what I meant very clearly... What I meant by
> deal with the average user is create a system which will do all of the
> things that the average user thinks it needs to do...

....and if it doesn't, *tough ****!*. That is not servicing the customer.

> If that means run a
> badly written application perfectly then that is what Windows has to do.

Ok, but Win doesn't have to be designed to crash on a badly written
application.

> Even if they aren't dealing with customer directly it's still their
> problem....

No it isn't! That's the point. They wash their hands of *all* support.
M$ owns no support, but wants to own your data. It will too, if you keep
apologizing for them.

--
Keith

Alexander Grigoriev
August 2nd 04, 05:55 AM
Did you check WinServ2003's versioned file system? Keeps multiple version of
a file, allowing you to roll back, or fetch an old version.

"Yousuf Khan" > wrote in message
t.cable.rogers.com...
>
> Nope, that's been delayed along with 64-bit XP. Really, Windows Server
2003
> is nothing more than XP slightly tweaked for server operations.
>
> Yousuf Khan
>
>

Yousuf Khan
August 2nd 04, 06:50 AM
Alexander Grigoriev wrote:
> Did you check WinServ2003's versioned file system? Keeps multiple
> version of a file, allowing you to roll back, or fetch an old version.

Is that a feature of the 64-bit WinServ2003 only, or is it available even on
the 32-bit version?

Yousuf Khan

Tony Hill
August 2nd 04, 07:33 AM
On Sun, 1 Aug 2004 16:17:14 -0400, "Carlo Razzeto"
> wrote:
>"Keith" > wrote in message
...
>> On Sun, 01 Aug 2004 00:43:17 -0400, Carlo Razzeto wrote:
>>
>> My point is that M$ *DOESN't* deal with the average user. OEM's are stuck
>> dealing with the average user.
>>
>> --
>> Keith
>>
>
>Ok... Perhaps I didn't state what I meant very clearly... What I meant by
>deal with the average user is create a system which will do all of the
>things that the average user thinks it needs to do...

Windows *DEFINITELY* does not do this!

>If that means run a
>badly written application perfectly then that is what Windows has to do.
>Even if they aren't dealing with customer directly it's still their
>problem....

It's not really their problem and they don't really have a solution.
There are lots of old, badly written applications that just won't run
at all in WinXP... and MS doesn't really care.

And Microsoft's solution to this? "Call your OEM". Seriously. MS
support is essentially non-existent, and when you've got a monopoly
and don't have to worry about support, it doesn't much matter what you
do.

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

Jan Vorbrüggen
August 2nd 04, 08:10 AM
>>Even if they aren't dealing with customer directly it's still their
>>problem....
> No it isn't! That's the point. They wash their hands of *all* support.

Have you watched Pat Gelsinger's talk at Standford? At one point he mentions
going to the developer of MS Flight Simulator and begging for a change in some
peculiarity of the VM implementation, because he wanted to change it in the
next chip, but some version of MS FS relied on it to work. He was immensely
relieved at being told that code relying on that feature was no longer in
current version of MS FS, so he could go ahead with making the change.

And this was for a non-architected detail of implementation.

Microsoft has a _HUGE_ backward-compatibility problem. Sometimes, they
can give reasons such as "security!" for breaking something.

Jan

Rob Warnock
August 2nd 04, 09:12 AM
glen herrmannsfeldt > wrote:
+---------------
| Nick Maclaren wrote:
| > Tim Shoppa > wrote:
| >>DEC C V6.0-001 (which was rather current as of late 1998)
| >>under Alpha VMS 7.2:
| > I remember now (and have just got a colleague to check). Yes, VMS
| > uses that model, but Tru64 uses the normal I32LP64 one. As far as I
| > know, the sum total of C compilers on systems that anyone normal has
| > ever heard of that use IL32LLP64 is two, and both of those are relics
| > (i.e. I believe that Microsoft's future direction is I32LP64).
|
| When was "long long" invented? It isn't part of C90, but
| seems to have been implemented in many compilers. I don't
| believe that it existed yet when Alpha came out, though.
+---------------

Well, the Amdahl mainframe C compiler supported "long long" at least
as early as 1985, since I used it to write an Ethernet device driver
for Amdahl's UTS-5 (running on an IBM 3081), and "unsigned long long"
was commonly used for CAWs & CCWs (Channel Address & Control Words).


-Rob

-----
Rob Warnock >
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Michael S
August 2nd 04, 09:43 AM
Seongbae Park > wrote in message >...
> Yousuf Khan > wrote:
> > Tony Hill > wrote:
> >> Sun currently has 64-bit Solaris for Opteron scheduled for Dec. of
> >> this year. Word so far is that they are pretty much right on schedule
> >> and that the OS is up and running in their labs.
> >
> > I'd never heard of that until now. Doing a Yahoo search only revealed a few
> > articles from 2003 (too old now to be really useful), and some Sun articles
> > being suitably vague ("real soon now"). You got something to link to?
>
> http://www.theregister.co.uk/2004/07/15/sun_solarislives_opteron/
>
> And I can say that there's been a lot more progress than
> what's reported in this article.
>
> Seongbae

Does Solaris-AMD64 run Solaris-386 apps?

Nick Maclaren
August 2nd 04, 11:39 AM
In article >,
Rob Warnock > wrote:
>glen herrmannsfeldt > wrote:
>|
>| When was "long long" invented? It isn't part of C90, but
>| seems to have been implemented in many compilers. I don't
>| believe that it existed yet when Alpha came out, though.
>
>Well, the Amdahl mainframe C compiler supported "long long" at least
>as early as 1985, since I used it to write an Ethernet device driver
>for Amdahl's UTS-5 (running on an IBM 3081), and "unsigned long long"
>was commonly used for CAWs & CCWs (Channel Address & Control Words).

Well, it was also in Algol 68 :-)

"long long" was widespread but very restricted in use before C99,
and was typically used ONLY for such esoteric purposes. K&R and C90
both required that "long" be the longest integer type which, inter
alia, meant that it had to be large enough to address the largest
allocatable object. There was a slight kludge on 16-bit systems,
where the extra size allowed for by unsignedness was used.

Neither required nor assumed that it could address all of memory
(i.e. map all pointers) nor address all files. Unix did assume
the latter, but the assumption had already broken down by 1990;
"long long" was sometimes (NOT often) used for file addressing.

This mess is related to the ISA one which puns integers and pointers.
There is no need for this, and it is not the case on the AS/400, nor
would it be on capability machines. It was not a major hardware
problem at the time it got established, but is a noticeable headache
now, when it is normal for the bits used in a register file to be
much less than the size of the file.

In both cases, the root cause is a failure to separate different
aspects of the architecture, and ending up constraining the design
to match a small number of misdesigned programs rather than the
(surprisingly) larger number of better ones.


Regards,
Nick Maclaren.

Jouni Osmala
August 2nd 04, 12:08 PM
What you mean by the "Unless of "course"..."?

BTW: are your sure ;)

-Jouni

> > As always, AMD is good and Intel is bad. Same old spiel. YAWN!
>
> Sure, when Intel tries to twist the market (i.e. consumer) to their
> benefit and there is an alternative with a consumer-friendly alternative,
> you bet Intel is *BAD*! To think otherwise is simply stupid. Unless of
> "Course"...
>
> BTW, top-posters suck!

Yousuf Khan
August 2nd 04, 02:50 PM
Michael S wrote:
> Does Solaris-AMD64 run Solaris-386 apps?

It should.

Yousuf Khan

Tim Shoppa
August 2nd 04, 04:56 PM
glen herrmannsfeldt > wrote in message news:<[email protected]_s02>...
> When was "long long" invented? It isn't part of C90, but
> seems to have been implemented in many compilers. I don't
> believe that it existed yet when Alpha came out, though.

In a 1985 "draft proposed C Standard" it was listed as a "common
extension". That said, I didn't encounter it until a couple of
years later in a spanking-new compiler for a rather bizarre 64-bit-data-wide
DSP built out of ECL and with a Harvard architecture (the C was
compiled to microcode, the instruction word was a hundred-and-something
bits wide...)

Tim.

Alexander Grigoriev
August 2nd 04, 10:20 PM
Available in the released 32 bit version.

"Yousuf Khan" > wrote in message
t.cable.rogers.com...
> Alexander Grigoriev wrote:
> > Did you check WinServ2003's versioned file system? Keeps multiple
> > version of a file, allowing you to roll back, or fetch an old version.
>
> Is that a feature of the 64-bit WinServ2003 only, or is it available even
on
> the 32-bit version?
>
> Yousuf Khan
>
>

AD.
August 3rd 04, 02:12 AM
On Mon, 02 Aug 2004 04:08:50 -0700, Jouni Osmala wrote:

> What you mean by the "Unless of "course"..."?

Would it have made more sense if he spelled it "Corse"?

It probably won't unless you were reading c.s.i.p.h.c a year or two ago.

Google for it if curious.

Cheers
Anton

Keith
August 3rd 04, 03:08 AM
On Tue, 03 Aug 2004 13:12:50 +1200, AD. wrote:

> On Mon, 02 Aug 2004 04:08:50 -0700, Jouni Osmala wrote:
>
>> What you mean by the "Unless of "course"..."?
>
> Would it have made more sense if he spelled it "Corse"?

It would have, but I forgot the spelling (Even a PAN spelling-checker
wouldn't have helped). The upper-case 'C' was a tip to the .chips folks.
>
> It probably won't unless you were reading c.s.i.p.h.c a year or two ago.

I didn't notice that it was cross-posted from
here to oblivion. Sorry folks. The story is too long...

--
Keith

Keith
August 3rd 04, 03:15 AM
On Mon, 02 Aug 2004 09:10:33 +0200, Jan Vorbrüggen wrote:

>>>Even if they aren't dealing with customer directly it's still their
>>>problem....
>> No it isn't! That's the point. They wash their hands of *all* support.
>
> Have you watched Pat Gelsinger's talk at Standford? At one point he mentions
> going to the developer of MS Flight Simulator and begging for a change in some
> peculiarity of the VM implementation, because he wanted to change it in the
> next chip, but some version of MS FS relied on it to work. He was immensely
> relieved at being told that code relying on that feature was no longer in
> current version of MS FS, so he could go ahead with making the change.

The only PG talks I've seen are at the IDF's (and I haven't been to one
since #4). That said, why is one relieved that one no longer needs to
support last years hot software? I have an MS simulator around here
somewhere that I would certainly become annoyed if it was broken by
hardware. ...though I'm not sure who I'd be most annoyed at. M$ for
using unarchitected "feechurs" or Intel for breaking (promised) backward
compatability.

....choices, choices... ;-)

>
> And this was for a non-architected detail of implementation.

Amazing. Didn't M$ buy FS from the dude at UIUC, some years back?
Perhaps it was som of his hardware tricks?

> Microsoft has a _HUGE_ backward-compatibility problem. Sometimes, they
> can give reasons such as "security!" for breaking something.

....like security? ;-) Face it, they don't care squat about security.

--
Keith

Keith
August 3rd 04, 03:25 AM
On Sun, 01 Aug 2004 19:59:57 +0200, Ketil Malde wrote:

> Keith > writes:
>
>> Are you saying that M$ ran out of chances? If so, I suggest you short
>> 'em. There is much money to be made if you're right!
>
> Well, they don't seem to be so hot on the 64bit issue, and at this
> time many people are seriously considering both 64bit and alternatives
> to Windows. I'm a bit puzzled they don't have a 64bit OS out by now.

Which is *exactly* my point. I'm running SuSE 9.1, though I never
intended to buy another M$ OS.
>
> They're probably struggling to put together Longhorn first, and with
> lots of new stuff in there, deadlines will be fragile.

Meanwhile Linux gets the (insider, at least) press? BTW, I think you're
right, I just cannot understand it. There is something wrapped in
yesterday's newspaper here.

--
Keith

Jan Vorbrüggen
August 3rd 04, 07:37 AM
> I have an MS simulator around here
> somewhere that I would certainly become annoyed if it was broken by
> hardware. ...though I'm not sure who I'd be most annoyed at. M$ for
> using unarchitected "feechurs" or Intel for breaking (promised) backward
> compatability.

That's the whole point: that backward compatibility wasn't promised by
Intel, but Microsoft's market position and the market's de facto demand
for backward compatibility at all costs was so strong that a minor
implementation detail of a new chip needed Microsoft's go-ahead.

> ....like security? ;-) Face it, they don't care squat about security.

If Microsoft is good at anything, it's marketing. And that's why they now
care about security.

Jan

Ketil Malde
August 3rd 04, 07:56 AM
Keith > writes:

>> They're probably struggling to put together Longhorn first, and with
>> lots of new stuff in there, deadlines will be fragile.

> Meanwhile Linux gets the (insider, at least) press? BTW, I think you're
> right, I just cannot understand it. There is something wrapped in
> yesterday's newspaper here.

I don't know. Intel seems to be surprisingly weak in marketing their
whatchamacallit 64bit extensions - are they still trying to push IA64
for the server market? And is MS part of that, by providing Windows
64 for IA64, but not AMD64?

What kind of stranglehold could Intel have over Microsoft anyway? Did
they promise to stop supporting Linux or something? I can't really
find a reasonable conspiracy theory here.

So I guess the explanation is the one given by Homer Simpson: "It's
because they're stupid, that's why. That's why everybody does everything."

-kzm

PS: Any recent figures for "datacenter" IA64 vs Opteron servers, and the
percentage running Windows 64?
--
If I haven't seen further, it is by standing in the footprints of giants

Tony Hill
August 3rd 04, 02:16 PM
On Tue, 03 Aug 2004 08:56:53 +0200, Ketil Malde >
wrote:
>Keith > writes:
>
>>> They're probably struggling to put together Longhorn first, and with
>>> lots of new stuff in there, deadlines will be fragile.
>
>> Meanwhile Linux gets the (insider, at least) press? BTW, I think you're
>> right, I just cannot understand it. There is something wrapped in
>> yesterday's newspaper here.
>
>I don't know. Intel seems to be surprisingly weak in marketing their
>whatchamacallit 64bit extensions - are they still trying to push IA64
>for the server market?

Definitely! At least publicly Intel is STRONGLY saying that IA64 is
the one true path for the future, customers be damned!

> And is MS part of that, by providing Windows
>64 for IA64, but not AMD64?

I doubt it. I think you hit on the correct answer a bit further
along...

>What kind of stranglehold could Intel have over Microsoft anyway? Did
>they promise to stop supporting Linux or something? I can't really
>find a reasonable conspiracy theory here.

I don't think any conspiracy theory is needed...

>So I guess the explanation is the one given by Homer Simpson: "It's
>because they're stupid, that's why. That's why everybody does everything."

Now you've got it!

Actually it all seems to tie back in to the fact that MS decided to
push all their future OSes back until they get WinXP SP2 out, and that
seems to be taking forever! Each time SP2 gets pushed back everything
else gets pushed back behind it.

>PS: Any recent figures for "datacenter" IA64 vs Opteron servers, and the
>percentage running Windows 64?

I suspect that the figures are probably measured in single-digit units
for both, so they probably aren't all that meaningful. IA64 seems to
be either small (1-4P servers) or big iron from HP (running HP-UX or
Linux) or SGI (running Linux). Opterons, on the other hand, are all
1-4P servers and therefore wouldn't really fall into the "datacenter"
category.. at least assuming you define "datacenter" in a similar way
to how MS defines it.

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

Nick Maclaren
August 3rd 04, 02:37 PM
In article >,
Tony Hill > writes:
|>
|> Definitely! At least publicly Intel is STRONGLY saying that IA64 is
|> the one true path for the future, customers be damned!

If Intel even let hint that they were having second thoughts, IA64
would be dead overnight except in HP and SGI "big iron". Somewhat
surprisingly, I think that SGI would weather that pretty well, but
HP would be in dead trouble.

My belief is that Intel are trying to deny the failure of IA64 until
they get their new range of designs onstream (planned for 2007).

|> >What kind of stranglehold could Intel have over Microsoft anyway? Did
|> >they promise to stop supporting Linux or something? I can't really
|> >find a reasonable conspiracy theory here.
|>
|> I don't think any conspiracy theory is needed...

It may not be needed, but there is enough evidence of conspiracies
to safely assume that there are several. Whether any of them have
anything to do with the matter in hand is another matter. Quite
likely not, as you say.

|> >PS: Any recent figures for "datacenter" IA64 vs Opteron servers, and the
|> >percentage running Windows 64?
|>
|> I suspect that the figures are probably measured in single-digit units
|> for both, so they probably aren't all that meaningful. IA64 seems to
|> be either small (1-4P servers) or big iron from HP (running HP-UX or
|> Linux) or SGI (running Linux). Opterons, on the other hand, are all
|> 1-4P servers and therefore wouldn't really fall into the "datacenter"
|> category.. at least assuming you define "datacenter" in a similar way
|> to how MS defines it.

With that definition, agreed. I believe that you can buy some in
Japan, but they are probably only being used for development and
testing at present.


Regards,
Nick Maclaren.

Rob Stow
August 3rd 04, 03:11 PM
Nick Maclaren wrote:

> In article >,
> Tony Hill > writes:
> |>
> |> Definitely! At least publicly Intel is STRONGLY saying that IA64 is
> |> the one true path for the future, customers be damned!
>
> If Intel even let hint that they were having second thoughts, IA64
> would be dead overnight except in HP and SGI "big iron". Somewhat
> surprisingly, I think that SGI would weather that pretty well, but
> HP would be in dead trouble.
>

I think Intel could cut off the flow of Itanics right now and
HP would hardly notice. HP has had a couple of years now to
recognize that Itanic is never going to be anything more than
a niche market. They are not all idiots over there - they
began dealing with the fact that they will never come remotely
close to recovering their Itanic investment a long time ago.

Nick Maclaren
August 3rd 04, 03:34 PM
In article >,
Rob Stow > wrote:
>>
>> If Intel even let hint that they were having second thoughts, IA64
>> would be dead overnight except in HP and SGI "big iron". Somewhat
>> surprisingly, I think that SGI would weather that pretty well, but
>> HP would be in dead trouble.
>
>I think Intel could cut off the flow of Itanics right now and
>HP would hardly notice. HP has had a couple of years now to
>recognize that Itanic is never going to be anything more than
>a niche market. They are not all idiots over there - they
>began dealing with the fact that they will never come remotely
>close to recovering their Itanic investment a long time ago.

I agree that the technical staff are not idiots, but I have heard
reports about the reaction of executives to proposals of backup
strategies. Take a look at their accounts, and remember that VMS
and NonStop (or whatever it is now) are secondary only to HP-UX
in their service provision.

And then think about how customers would react if told that the
ONLY future platforms for HP-UX, VMS and NonStop had just been
cancelled. Overjoyed isn't the word I would use ....


Regards,
Nick Maclaren.

Tony Hill
August 4th 04, 02:59 AM
On 3 Aug 2004 13:37:34 GMT, (Nick Maclaren) wrote:
>In article >,
>Tony Hill > writes:
>|>
>|> Definitely! At least publicly Intel is STRONGLY saying that IA64 is
>|> the one true path for the future, customers be damned!
>
>If Intel even let hint that they were having second thoughts, IA64
>would be dead overnight except in HP and SGI "big iron".

I'm not sure that would be very different from where they stand now.
From what I understand HP and SGI make up well over 90% of all Itanium
server revenues. Everyone else (IBM, Dell, Unisys, Bull and whoever
else) are mostly fighting for a few scraps.

> Somewhat
>surprisingly, I think that SGI would weather that pretty well, but
>HP would be in dead trouble.

I'd say that it's completely the opposite. SGI has absolutely nothing
else but Itanium going for it. Their old MIPS sales are all but dried
up and the revenue their getting from service contracts is *rapidly*
vanishing.

HP, on the other hand, could easily afford to just ditch their
Integrity group altogether and keep going with the rest of their
businesses. It might hurt a bit, but all their Itanium servers
combined only make up a relatively small portion of the companies
total market. Their Xeon-based Proliant servers still bring in a LOT
more revenue.

>My belief is that Intel are trying to deny the failure of IA64 until
>they get their new range of designs onstream (planned for 2007).

I doubt that they'll ever admit failure... did they ever admit that
the i860 never came remotely close to the lofty expectations for it?
What was supposed to revolutionize the entire processor industry ended
up as little more than a co-processor for storage and networking
devices?

Nahh, the Itanium will quietly be swept under the rug as a mainstream
chip and it will remain a niche product to power SGI and HP's
big-iron.

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

Keith
August 4th 04, 03:22 AM
On Tue, 03 Aug 2004 08:37:54 +0200, Jan Vorbrüggen wrote:

> > I have an MS simulator around here
>> somewhere that I would certainly become annoyed if it was broken by
>> hardware. ...though I'm not sure who I'd be most annoyed at. M$ for
>> using unarchitected "feechurs" or Intel for breaking (promised) backward
>> compatability.
>
> That's the whole point: that backward compatibility wasn't promised by
> Intel, but Microsoft's market position and the market's de facto demand
> for backward compatibility at all costs was so strong that a minor
> implementation detail of a new chip needed Microsoft's go-ahead.

Then Intel doesn't truely care about backwards compatability (which was
my point).

>> ....like security? ;-) Face it, they don't care squat about security.
>
> If Microsoft is good at anything, it's marketing. And that's why they
> now care about security.

Are you really buying that crap?

--
Keith

Dean Kent
August 4th 04, 03:30 AM
"Tony Hill" > wrote in message
...
> On Tue, 03 Aug 2004 08:56:53 +0200, Ketil Malde >
>
> Definitely! At least publicly Intel is STRONGLY saying that IA64 is
> the one true path for the future, customers be damned!

They have publicly stated that x86 is here for a long time. Show me one
public statement anywhere from Intel, anywhere, that says IA64 is the only
future processor, whether strong or weak.

OTOH, virtually all OEMs but one are offering IA64 systems, and that one is
'looking at it'. As far as dollars, I believe that IA64 systems accounted
for a significantly larger amount of system revenues than Opteron. That
may change, but to imply that customers don't want IA64 is disingenuous at
best...

>
> Now you've got it!
>
> Actually it all seems to tie back in to the fact that MS decided to
> push all their future OSes back until they get WinXP SP2 out, and that
> seems to be taking forever! Each time SP2 gets pushed back everything
> else gets pushed back behind it.

The explanation is most likely that the Windows OS is likely a huge pile of
spaghetti code that is a nightmare to maintain - including full 64-bit
operation. For those who have never worked on a commercial product of any
size, all it takes is a few customers complaining about a bug that 95% will
never encounter to extend a beta - and that 95% will scratch their heads and
claim that the product is *so* stable. Sure, you can get the 'core'
features to work fine, but the corner cases can be a major bitch... :-).

Regards,
Dean

Dean Kent
August 4th 04, 03:30 AM
"Rob Stow" > wrote in message
...
>
> I think Intel could cut off the flow of Itanics right now and
> HP would hardly notice. HP has had a couple of years now to
> recognize that Itanic is never going to be anything more than
> a niche market. They are not all idiots over there - they
> began dealing with the fact that they will never come remotely
> close to recovering their Itanic investment a long time ago.

For those in .chips, since the reference was already made - this sounds an
awful lot like a certain individual claiming "DDR is dead, Dead, DEAD".

Some people should look in the mirror more often. :-).

Regards,
Dean

Dean Kent
August 4th 04, 03:30 AM
"Tony Hill" > wrote in message
...
>
> I'm not sure that would be very different from where they stand now.
> From what I understand HP and SGI make up well over 90% of all Itanium
> server revenues. Everyone else (IBM, Dell, Unisys, Bull and whoever
> else) are mostly fighting for a few scraps.

That, by itself, is not an indication of the success or failure of Itanium.
First you have to provide the revenue numbers, and market percentage.
Otherwise you could state that because Intel gets almost 85% of all x86
revenues, that x86 is a failure...

Regards,
Dean

Dean Kent
August 4th 04, 03:39 AM
"Dean Kent" > wrote in message
.. .
> OTOH, virtually all OEMs but one are offering IA64 systems, and that one
is
> 'looking at it'. As far as dollars, I believe that IA64 systems
accounted
> for a significantly larger amount of system revenues than Opteron.

Now that I think about it, I believe Itanium may have outshipped Operton in
units for all of 2003 as well. Intel claimed over 100,000 units shipped
(most at the end of the year), but I don't think AMD disclosed the Opteron
numbers. If they had outshipped Intel, I would think that they would have
made a comment to that effect, since JSIII had all but guaranteed it at the
beginning of the year...

Regards,
Dean

Rob Stow
August 4th 04, 04:47 AM
Dean Kent wrote:

> "Rob Stow" > wrote in message
> ...
>
>>I think Intel could cut off the flow of Itanics right now and
>>HP would hardly notice. HP has had a couple of years now to
>>recognize that Itanic is never going to be anything more than
>>a niche market. They are not all idiots over there - they
>>began dealing with the fact that they will never come remotely
>>close to recovering their Itanic investment a long time ago.
>
>
> For those in .chips, since the reference was already made - this sounds an
> awful lot like a certain individual claiming "DDR is dead, Dead, DEAD".
>

I think the similarity is a *lot* stronger to the
"Rambus is dead, Dead, DEAD." that far more people
subscribed to.

Ketil Malde
August 4th 04, 06:50 AM
The first Google hit on "opteron shipments" is xbitlabs:

| A report over InformationWeek web-site cites analyst Dean McCarron for
| Mercury Research who claims that AMD supplied about 70 000 of AMD
| Opteron microprocessors in the first quarter this year. By contrast,
| the Sunnyvale, California-based microprocessor maker supplied about 65
| 000 of its server microprocessors in 2003. According to some other
| estimates, AMD only sold 40 000 of AMD Opteron products last year.

So if the 100000 units figure is correct for Itanium, you seem to be
right. What was the "end of year" thing, though? It was hardly
Christmas shoppers, was it?

While (of course) Intel never committed to terminating x86, it
is clear that they wanted IA64 to be vastly more mainstream than it
seems to be. That, or the press were victim of the greatest
mass-misunderstanding I've seen. Randomly Googling around brings me
to e.g. http://www.dqindia.com/content/top_stories/102041601.asp, with a
nice chart showing an estimated 1.5-2 million IPF server shipments in
2003 -- and the article is dated early 2002. FWIW, I don't think it's
likely that they will exceed IA32 servers in 2005 either, but we'll
see.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

Jan Vorbrüggen
August 4th 04, 07:55 AM
> Then Intel doesn't truely care about backwards compatability (which was
> my point).

Humbug. They don't want to be held back by _accidental_ backward
compatibility, which is a big difference.

> Are you really buying that crap?

MS's marketing? No. But I can read about the effects of their recent
patches, not only to the base operating system.

Jan

Jan Vorbrüggen
August 4th 04, 07:58 AM
> HP, on the other hand, could easily afford to just ditch their
> Integrity group altogether and keep going with the rest of their
> businesses. It might hurt a bit, but all their Itanium servers
> combined only make up a relatively small portion of the companies
> total market. Their Xeon-based Proliant servers still bring in a LOT
> more revenue.

Who cares about revenue? It's EBIT or one of its variations that's relevant,
and EBIT/revenue is perhaps even more important. I'd rather have a company
with a tenth of the revenue and solid earnings than a company with high
revenue and bleeding red ink, wouldn't you?

Jan

Dean Kent
August 4th 04, 08:23 AM
"Ketil Malde" > wrote in message
...
>
> The first Google hit on "opteron shipments" is xbitlabs:
>
> | A report over InformationWeek web-site cites analyst Dean McCarron for
> | Mercury Research who claims that AMD supplied about 70 000 of AMD
> | Opteron microprocessors in the first quarter this year. By contrast,
> | the Sunnyvale, California-based microprocessor maker supplied about 65
> | 000 of its server microprocessors in 2003. According to some other
> | estimates, AMD only sold 40 000 of AMD Opteron products last year.
>
> So if the 100000 units figure is correct for Itanium, you seem to be
> right. What was the "end of year" thing, though? It was hardly
> Christmas shoppers, was it?

No, just that Intel stated that the shipments were 'back end loaded',
meaning that most of the shipments had occurred at the end of the year (I
believe that came from the earnings conference call). I have absolutely no
idea what it means, but there had been much noise made earlier in the year
about how Opteron would outsell Itanium in Opteron's first year of sales
because the first couple of quarters were pretty dismal for Itanium.

>
> While (of course) Intel never committed to terminating x86, it
> is clear that they wanted IA64 to be vastly more mainstream than it
> seems to be. That, or the press were victim of the greatest
> mass-misunderstanding I've seen. Randomly Googling around brings me
> to e.g. http://www.dqindia.com/content/top_stories/102041601.asp, with a
> nice chart showing an estimated 1.5-2 million IPF server shipments in
> 2003 -- and the article is dated early 2002. FWIW, I don't think it's
> likely that they will exceed IA32 servers in 2005 either, but we'll
> see.

I believe that Itanium is far less ubiquitous than Intel desired, but the
evidence seems to indicate it is far less than the total disaster that some
wish to spin. In fact, as the technologies mature (both hardware and
software), it could be argued that the momentum is starting to build.

Now, I know that there are some who claim that Intel wanted IA64 to replace
x86 very early on, but...

1) The NY Times quoted Andy Grove in 1998: "I don't see Merced appearing on
a mainstream desktop inside of a decade." -ANDY GROVE, Ex-CEO, Intel (New
York Times, 5 April 98)

2) In 1997, the now infamous Bob Colwell was scheduled to give a talk at the
Microprocessor Forum about the IA32 enhancements "beyond the end of the
decade", so it was obviously not the intent at that time to replace IA32
anytime really soon:
http://www.intel.com/pressroom/archive/releases/sp100997.HTM

3) Gordon Moore, in late 1996/early 1997, in an interview with PC Magazine
stated: "GORDON MOORE: Oh yeah, sure, 64 bits means new instructions. But it
will still run the older software compatibly. You know, that's one thing we
have, is the idea of carrying a compatible family along--even if we have to
put two processors on the chip, one 32-bit and one 64-bit, it's going to run
that old software effectively."
http://www.pcmag.com/article2/0,1759,35750,00.asp

So, it would appear that even in 1996 the concept was not to eliminate x86
entirely, in 1997 it was publicly stated that IA32 would be around for some
time after Y2K, and in 1998 it was publicly stated that IA64 would not be on
the desktop for at least another 3.5 years from *today*. This despite the
recollections of a few who are certain that Intel had more nefarious plans
early on...

Regards,
Dean



> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants

Nick Maclaren
August 4th 04, 09:41 AM
In article >,
Tony Hill > writes:
|> On 3 Aug 2004 13:37:34 GMT, (Nick Maclaren) wrote:
|> >In article >,
|> >Tony Hill > writes:
|> >|>
|> >|> Definitely! At least publicly Intel is STRONGLY saying that IA64 is
|> >|> the one true path for the future, customers be damned!
|> >
|> >If Intel even let hint that they were having second thoughts, IA64
|> >would be dead overnight except in HP and SGI "big iron".
|>
|> I'm not sure that would be very different from where they stand now.
|> From what I understand HP and SGI make up well over 90% of all Itanium
|> server revenues. Everyone else (IBM, Dell, Unisys, Bull and whoever
|> else) are mostly fighting for a few scraps.

No. "Dead" as in Norwegian Blue parrots, not merely half-dead as
at present.

|> > Somewhat
|> >surprisingly, I think that SGI would weather that pretty well, but
|> >HP would be in dead trouble.
|>
|> I'd say that it's completely the opposite. SGI has absolutely nothing
|> else but Itanium going for it. Their old MIPS sales are all but dried
|> up and the revenue their getting from service contracts is *rapidly*
|> vanishing.

Er, no. Look at their financials and customers. The former are
now balanced, and the latter have retrenched to the 'technical'
marketplace. And we are a damn sight less worried about which
CPUs we use than the 'commercial' market, as we are accustomed to
rebuilding codes on a few year timescale. Provided that Intel
still produces IA64 systems and delivers boring enhancements
(shrinks, clock rate, caches etc.), SGI is OK for now.

|> HP, on the other hand, could easily afford to just ditch their
|> Integrity group altogether and keep going with the rest of their
|> businesses. It might hurt a bit, but all their Itanium servers
|> combined only make up a relatively small portion of the companies
|> total market. Their Xeon-based Proliant servers still bring in a LOT
|> more revenue.

Look at their margins. They are zilch in that division, and there
is little chance of a change. They are in printing and services,
and the latter will disappear if all of the SuperDome, VMS and
Integrity products do so. And all of those are currently dependent
on IA64.

|> >My belief is that Intel are trying to deny the failure of IA64 until
|> >they get their new range of designs onstream (planned for 2007).
|>
|> I doubt that they'll ever admit failure... did they ever admit that
|> the i860 never came remotely close to the lofty expectations for it?
|> What was supposed to revolutionize the entire processor industry ended
|> up as little more than a co-processor for storage and networking
|> devices?

Internally. I agree that they will never admit failure in public.


Regards,
Nick Maclaren.

Ketil Malde
August 4th 04, 12:21 PM
(Nick Maclaren) writes:

> In article >,
> Tony Hill > writes:
>> On 3 Aug 2004 13:37:34 GMT, (Nick Maclaren) wrote:

>>> If Intel even let hint that they were having second thoughts, IA64
>>> would be dead overnight except in HP and SGI "big iron".

>> I'm not sure that would be very different from where they stand now.
>> From what I understand HP and SGI make up well over 90% of all Itanium
>> server revenues. Everyone else (IBM, Dell, Unisys, Bull and whoever
>> else) are mostly fighting for a few scraps.

I wouldn't really call it fighting; more like having something
available, just in case anybody would want it. The numbers seem to
indicate few people do. If you want to compare market share, you
should compare HP IA64s to IBM Powers and Sun Sparcs.

>> I'd say that it's completely the opposite. SGI has absolutely nothing
>> else but Itanium going for it.

> Er, no. Look at their financials and customers. The former are
> now balanced, and the latter have retrenched to the 'technical'
> marketplace. And we are a damn sight less worried about which
> CPUs

I think most of HP's IA64 sales also are going to the scientific
computing segment. And while the commercial customers may be more
worried, it depends on what HP replaces IA64 with; I'm not sure people
would object strongly to Superdomes with Opterons or 64-bit Xeons, for
instance.

-k
--
If I haven't seen further, it is by standing in the footprints of giants

Nick Maclaren
August 4th 04, 12:30 PM
In article >,
Ketil Malde > writes:
|>
|> I think most of HP's IA64 sales also are going to the scientific
|> computing segment. And while the commercial customers may be more
|> worried, it depends on what HP replaces IA64 with; I'm not sure people
|> would object strongly to Superdomes with Opterons or 64-bit Xeons, for
|> instance.

If your first sentence is true, HP's IA64 lines are in worse trouble
than even I thought they were.

No, I don't think people would object, but that's not my point.
It is the time to revalidate and the loss of confidence - both are
more of an issue in the commercial arena.


Regards,
Nick Maclaren.

Ketil Malde
August 4th 04, 12:42 PM
(Nick Maclaren) writes:

> Ketil Malde > writes:

>> I think most of HP's IA64 sales also are going to the scientific
>> computing segment.

> If your first sentence is true, HP's IA64 lines are in worse trouble
> than even I thought they were.

I guess I should emphasize that I'm just guessing - I know about a few
Superdomes that do number crunching (which anyway is what IA64 is good
at). Are there any numbers; anywhere?

OTOH, I think the commercial segment generally chooses vendor first,
and architecture later. So the customers who used to buy HPPA boxes
now buy HP IA64 boxes, and will (happily?) buy HP x86_64 boxes, if
that's what it takes. They'll need some reassurance that the new
stuff is in some way better, but will tend to stick with the vendor as
long as they get the service they want. IMHO.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

Nick Maclaren
August 4th 04, 01:10 PM
In article >,
Ketil Malde > writes:
|>
|> >> I think most of HP's IA64 sales also are going to the scientific
|> >> computing segment.
|>
|> > If your first sentence is true, HP's IA64 lines are in worse trouble
|> > than even I thought they were.
|>
|> I guess I should emphasize that I'm just guessing - I know about a few
|> Superdomes that do number crunching (which anyway is what IA64 is good
|> at). Are there any numbers; anywhere?

Almost certainly, but HP are unlikely to disclose them :-)

HP effectively consigned the academic and technical marketplaces
to limbo over a decade ago, and are a bit player in HPC. The
number crunching SuperDomes I know of were special deals to try to
promote them in those areas. I have not heard of many 'normal'
sales.


Regards,
Nick Maclaren.

Tom Gardner
August 4th 04, 02:06 PM
(Nick Maclaren) wrote in news:ceq7fc$hq$1
@pegasus.csx.cam.ac.uk:

> Er, no. Look at [SGI's] financials and customers. The former are
> now balanced, and the latter have retrenched to the 'technical'
> marketplace. And we are a damn sight less worried about which
> CPUs we use than the 'commercial' market, as we are accustomed to
> rebuilding codes on a few year timescale. Provided that Intel
> still produces IA64 systems and delivers boring enhancements
> (shrinks, clock rate, caches etc.)

Interestingly, in the commercial arena there is a move to
commoditise the CPU as well. The core point is that much
*new* commercial development is being done in Java or .NET,
both of which have machine-independent "bytecode" plus
interpreters at their core. The choice is thus becoming
between Java or .NET, with the added twist of a choice
of application server.

It will, of course, be a long time before the *old* codes
can be consigned to the dustbin :)


--
Tom Gardner
Mobile Payments,
LogicaCMG Wireless Networks
_____________________________
LogicaCMG
2420 The Quadrant
Aztec West
Bristol BS32 4LD
United Kingdom

T: +44 (0) 117 901 7896 (direct)

chrisv
August 4th 04, 06:15 PM
Tony Hill > wrote:

>It's not really their problem and they don't really have a solution.
>There are lots of old, badly written applications that just won't run
>at all in WinXP... and MS doesn't really care.

Can't say I blame them for that. Sometimes it's just time to move on.
They seem to have made a very reasonable attempt at retaining
backwards compatibility (not that they had much choice)...

George Macdonald
August 4th 04, 09:33 PM
On Wed, 04 Aug 2004 07:23:40 GMT, "Dean Kent" >
wrote:

>So, it would appear that even in 1996 the concept was not to eliminate x86
>entirely, in 1997 it was publicly stated that IA32 would be around for some
>time after Y2K, and in 1998 it was publicly stated that IA64 would not be on
>the desktop for at least another 3.5 years from *today*. This despite the
>recollections of a few who are certain that Intel had more nefarious plans
>early on...

Uhh, it's called spin.:-) The fact you or I can't find the docs/pages to
confirm the "recollections" does not mean they did not exist. Nefarious is
your term but I did see a roadmap which showed x86 relegated to mostly STBs
by 2005... after a steady year by year decline in PCs.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Keith
August 5th 04, 03:32 AM
On Wed, 04 Aug 2004 08:55:56 +0200, Jan Vorbrüggen wrote:

>> Then Intel doesn't truely care about backwards compatability (which was
>> my point).
>
> Humbug. They don't want to be held back by _accidental_ backward
> compatibility, which is a big difference.

Ah so... If an application I bought yesterday doesn't work today, it's
*my* fault? I don't think IBM became a giant with that attitude.
>
>> Are you really buying that crap?
>
> MS's marketing? No. But I can read about the effects of their recent
> patches, not only to the base operating system.

You really believe they care? Why don't they patch Win2K without having
to sign up for a XPish license agreement? Come on! What's with the XP
license anyway? Yes, and next year you'll rent the OS. ...good plan
this "security" is.

--
Keith

Keith
August 5th 04, 03:41 AM
On Wed, 04 Aug 2004 16:33:24 -0400, George Macdonald wrote:

> On Wed, 04 Aug 2004 07:23:40 GMT, "Dean Kent" >
> wrote:
>
>>So, it would appear that even in 1996 the concept was not to eliminate x86
>>entirely, in 1997 it was publicly stated that IA32 would be around for some
>>time after Y2K, and in 1998 it was publicly stated that IA64 would not be on
>>the desktop for at least another 3.5 years from *today*. This despite the
>>recollections of a few who are certain that Intel had more nefarious plans
>>early on...
>
> Uhh, it's called spin.:-) The fact you or I can't find the docs/pages to
> confirm the "recollections" does not mean they did not exist. Nefarious is
> your term but I did see a roadmap which showed x86 relegated to mostly STBs
> by 2005... after a steady year by year decline in PCs.

The charts I saw were Itanic to exceed x86 sales by 2003 and by '05 x86
was relegated to the dust-bin of embedded losers. ...and that was in
1997ish. There was some discussion about this in AFC a few weeks ago (I'm
not the only one remembering such).

--
Keith

Robert Redelmeier
August 5th 04, 04:34 AM
In comp.sys.ibm.pc.hardware.chips Jan Vorbr?ggen > wrote:
> That's the whole point: that backward compatibility wasn't
> promised by Intel, but Microsoft's market position and the
> market's de facto demand for backward compatibility at all
> costs was so strong that a minor implementation detail of
> a new chip needed Microsoft's go-ahead.

Actually, not. Intel, AMD, etc can add whatever new they like to
their chips so long as it doesn't break any current software.
viz MMX, SSE[2], 3DNow, etc. That's how progress is made.
If they break current software, they'll probably not sell many.

You seem to have a bit of an odd view of backward compatibility.
Maybe a hazard of technophilia. The market doesn't know what
backward compatibility is, much less demand it _per se_.

The market buys machines to do work and solve problems. Always
has. Always will. The first step is application software --
what app will do what needs doing? Then what OS does that app
need, and what hardware is needed. Lotus 1-2-3 & WordStar sold
lots of original IMB PCs, XTs and ATs. DTP sold lots of Macs.
Many people have put up with inferior OSes and hardware to get
needed apps.

Backwards compatibility only comes into it since good apps
usually have been around a while and hence run on older hw.

> If Microsoft is good at anything, it's marketing. And that's
> why they now care about security.

They now _appear_ to care about security. More marketing,
I'm afraid. I haven't heard of them undertaking measures
like OpenBSD's line-by-line walkthrus.

-- Robert

Dean Kent
August 5th 04, 05:17 AM
"Keith" > wrote in message
...
> On Wed, 04 Aug 2004 08:55:56 +0200, Jan Vorbrüggen wrote:
>
> Ah so... If an application I bought yesterday doesn't work today, it's
> *my* fault? I don't think IBM became a giant with that attitude.

Well, that isn't the only reason IBM became a giant. There were a bunch of
salespeople, and some rather draconian contracts before the anti-trust
lawsuits. I can recall when I worked at ADP in 1978/79 that IBM threatened
to cancel the lease and yank the 370/155 if the 3203 printers were replaced
with a competitors. I left there in 1980, and when I went back they had
replaced the entire system with one from a company called Magnuson (or
something to that effect). Needless to say, they were *not* happy with IBM
tactics. I also recall some interesting interactions when Amdahl sold them
a half-meg memory upgrade. IBM refused to allow Amdahl to touch the box,
and IBM would not touch the Amdahl unit - so our system programmer had to
hook everything up.

Yeah, IBM has always been your friend. ;-).

>
> You really believe they care? Why don't they patch Win2K without having
> to sign up for a XPish license agreement? Come on! What's with the XP
> license anyway? Yes, and next year you'll rent the OS. ...good plan
> this "security" is.

Hmm. At my job we 'rent' the OS we run today from IBM - I think it is
called zOS. Perhaps that is why IBM became a giant, too? ;-).

Regards,
Dean

>
> --
> Keith
>
>

Dean Kent
August 5th 04, 05:22 AM
"Keith" > wrote in message
...
> On Wed, 04 Aug 2004 16:33:24 -0400, George Macdonald wrote:
>
> > On Wed, 04 Aug 2004 07:23:40 GMT, "Dean Kent" >
> > wrote:
> >
> >>So, it would appear that even in 1996 the concept was not to eliminate
x86
> >>entirely, in 1997 it was publicly stated that IA32 would be around for
some
> >>time after Y2K, and in 1998 it was publicly stated that IA64 would not
be on
> >>the desktop for at least another 3.5 years from *today*. This despite
the
> >>recollections of a few who are certain that Intel had more nefarious
plans
> >>early on...
> >
> > Uhh, it's called spin.:-) The fact you or I can't find the docs/pages
to
> > confirm the "recollections" does not mean they did not exist. Nefarious
is
> > your term but I did see a roadmap which showed x86 relegated to mostly
STBs
> > by 2005... after a steady year by year decline in PCs.
>
> The charts I saw were Itanic to exceed x86 sales by 2003 and by '05 x86
> was relegated to the dust-bin of embedded losers. ...and that was in
> 1997ish. There was some discussion about this in AFC a few weeks ago (I'm
> not the only one remembering such).

I saw charts in 1997 also - and none of them showed Itanium moving out of
the high end server segment. Though I was only given reseller roadmaps
directly, I was given OEM roadmaps from a motherboard maker associated with
a very, very large Asian OEM. I don't recall seeing any of those things -
and I still have those roadmaps. I wonder if anyone 'recalling' such things
does?

As for George's argument, as usual it is a fallacy. It is called
"argumentum ad ignorantium". Just because it cannot be proven to be false,
does not mean that it is true. The burden of proof is upon those trying to
make the claim. Public information says Intel did not intend to replace
x86 anytime soon, so it will take a bit more than 'recollections' to make
the case that they did. Sorry.

Regards,
Dean

>
> --
> Keith

Yousuf Khan
August 5th 04, 05:23 AM
Keith wrote:
> On Wed, 04 Aug 2004 16:33:24 -0400, George Macdonald wrote:
>> Uhh, it's called spin.:-) The fact you or I can't find the
>> docs/pages to confirm the "recollections" does not mean they did not
>> exist. Nefarious is your term but I did see a roadmap which showed
>> x86 relegated to mostly STBs by 2005... after a steady year by year
>> decline in PCs.
>
> The charts I saw were Itanic to exceed x86 sales by 2003 and by '05
> x86 was relegated to the dust-bin of embedded losers. ...and that was
> in 1997ish. There was some discussion about this in AFC a few weeks
> ago (I'm not the only one remembering such).

I think a lot of us can remember Intel's predictions about IA64 eventually
replacing IA32 by some point in time. You don't need some archival webpage
in order to prove it. Just the fact that so many of us who have been in this
business for so long can recall these statements is more than enough.

Yousuf Khan

Dean Kent
August 5th 04, 05:38 AM
"Yousuf Khan" > wrote in message
t.cable.rogers.com...
>
> I think a lot of us can remember Intel's predictions about IA64 eventually
> replacing IA32 by some point in time. You don't need some archival webpage
> in order to prove it. Just the fact that so many of us who have been in
this
> business for so long can recall these statements is more than enough.

Mass recollections of events is no guarantee of the accuracy of those
recollections. The repeated telling of events can 'shape' those memories,
though they may seem to be vivid and accurate. Human recollection is a
very unreliable determinant of actual events.
http://www.memory-key.com/ResearchReports/tversky2000.htm

What *is* reliable is factual evidence, which has yet to be presented.
While the lack of evidence is no proof that Intel did *not* intend to
replace x86 in the near future, it is most certainly a reason to doubt the
accuracy of the recollections of those who most vehemently dislike
Itanium...

And, as I said - I have official Intel roadmaps from 1996 thru 2000. On
paper and in electronic form. You have recollections. Excuse me if I
doubt your powers of recall unless and until some better evidence is
presented. Sorry.

Regards,
Dean

>
> Yousuf Khan
>
>

Yousuf Khan
August 5th 04, 05:53 AM
Dean Kent wrote:
> So, it would appear that even in 1996 the concept was not to
> eliminate x86 entirely, in 1997 it was publicly stated that IA32
> would be around for some time after Y2K, and in 1998 it was publicly
> stated that IA64 would not be on the desktop for at least another 3.5
> years from *today*. This despite the recollections of a few who are
> certain that Intel had more nefarious plans early on...
>
> Regards,
> Dean

Hey, I dug up an old Register article by Mike McGee from April 1999:

http://www.theregister.co.uk/1999/04/28/secrets_of_intels_ia64_roadmap/

<quote>
Secrets of Intel's IA-64 roadmap revealed
By Mike Magee
Published Wednesday 28th April 1999 11:48 GMT
Updated Reliable sources said yesterday that a future Intel IA-64 chip
called Northwood would hit 3000MHz at its release. At the same time, it
emerged that McKinley is likely to launch using P858 aluminium technology.
The source who requested anonymity, works at Intel's R&D centre in Israel.
He said that all generations of microprocessors following Deschutes are
developed in pairs: Katmai-Tanner, Coppermine-Cascades and
Willamette-Foster. Northwood, like Madison and Deerfield will be X60
compactions of the IA-64 but for the Willamette architecture. Northwood,
further, is missing a Xeon counterpart and that suggests that Merced,
McKinley and Madison are likely to replace IA-32 server chips. Deerfield is
likely to be the first IA-64 chip aimed at the consumer market with a launch
date in the 2003 timeframe. Meanwhile, the source said there is "practically
no way" that Willamette and Foster will use copper technology. According to
another source at Intel Germany, the Merced platform was originally laid out
for .35 micron technology...
</quote>

So it looks like at one time Northwood was supposed to be an IA-64 chip, but
it actually turned out to be an IA-32 Pentium 4. Now it also looks like they
were saying that Northwood would have "no Xeon counterparts", so it would
seem that Northwood was meant to be a desktop chip -- which it actually
turned out to be. Of course Northwood did actually end up having Xeon
counterparts (what were they? Gallatin, or something?), but still 32-bit
Xeons.

It's fun digging up archives. It's almost like being a paleontologist. :-)

Yousuf Khan

Dean Kent
August 5th 04, 06:06 AM
"Yousuf Khan" > wrote in message
t.cable.rogers.com...
>
> So it looks like at one time Northwood was supposed to be an IA-64 chip,
but
> it actually turned out to be an IA-32 Pentium 4. Now it also looks like
they
> were saying that Northwood would have "no Xeon counterparts", so it would
> seem that Northwood was meant to be a desktop chip -- which it actually
> turned out to be. Of course Northwood did actually end up having Xeon
> counterparts (what were they? Gallatin, or something?), but still 32-bit
> Xeons.
>
> It's fun digging up archives. It's almost like being a paleontologist. :-)

Is it possible that Mike was wrong, or perhaps his source? Isn't the Israel
lab the one that developed Banias? Would someone there have direct
knowledge of IA-64 plans, or would it most likely be rumors? I wonder if
there has been any other time Intel has re-used a codename for two different
processors? So, if the Northwood was being planned as IA64 in mid-1999, but
by early 2001 it was released as a P4, that seems like a very short amount
of time to do such a redesign. I'm no EE, but it seems that if Intel has
such release cycles it would be pretty difficult to just change them on the
fly like this.

Regards,
Dean



>
> Yousuf Khan
>
>
>

Dean Kent
August 5th 04, 06:11 AM
"Dean Kent" > wrote in message
.. .
>
> Is it possible that Mike was wrong, or perhaps his source?

Check this link to MDR. This is the 2nd half 2000 Intel forecast. That
means it was likely compiled in the first half, or perhaps even late 1999.
It shows Northwood as a P4 part, not IA-64. Can we presume that Mike or
his source were out in left field?

http://www.mdronline.com/publications/tl/intel_2h2000/toc2.html

Regards,
Dean

>
> Regards,
> Dean
>

Yousuf Khan
August 5th 04, 06:39 AM
Dean Kent wrote:
> "Yousuf Khan" > wrote in message
> t.cable.rogers.com...
>>
>> I think a lot of us can remember Intel's predictions about IA64
>> eventually replacing IA32 by some point in time. You don't need some
>> archival webpage in order to prove it. Just the fact that so many of
>> us who have been in this business for so long can recall these
>> statements is more than enough.
>
> Mass recollections of events is no guarantee of the accuracy of those
> recollections. The repeated telling of events can 'shape' those
> memories, though they may seem to be vivid and accurate. Human
> recollection is a very unreliable determinant of actual events.
> http://www.memory-key.com/ResearchReports/tversky2000.htm

Ah, I see, so we who have been in this business for so long are just
suffering from collective hallucinations?

> What *is* reliable is factual evidence, which has yet to be presented.
> While the lack of evidence is no proof that Intel did *not* intend to
> replace x86 in the near future, it is most certainly a reason to
> doubt the accuracy of the recollections of those who most vehemently
> dislike Itanium...
>
> And, as I said - I have official Intel roadmaps from 1996 thru 2000.
> On paper and in electronic form. You have recollections. Excuse
> me if I doubt your powers of recall unless and until some better
> evidence is presented. Sorry.

Thus you shall have it. If the only proof you shall accept is documentary
proof (which would include webpages), then we shall do Google searches on
your behalf to find those precious archival webpages.

This article from late 1998, it was thought that the IA-32 line of
processors would end in 2003 with the Foster, and from that point afterwards
IA-64 would take over starting with Deerfield. It's also interesting to note
that back then, Intel thought 64-bit for the masses would take off starting
in 2003. It turned out that they were absolutely right, but it just wasn't
one of their chips, it was the Athlon 64 and Opteron.

http://www.theregister.co.uk/1998/10/22/madison_and_deerfield_to_split/

http://www.theregister.co.uk/1998/10/15/intel_doctors_foster_to_extend/

Now, it's obvious that Intel's plans didn't actually live upto its original
roadmaps. That's not surprising or unexpected. However, it's also not
important, it was their intention that is being discussed here only. It was
obvious that in 1998, Intel was hinting at replacing IA-32 at least by 2003.

Yousuf Khan

Dean Kent
August 5th 04, 06:49 AM
"Dean Kent" > wrote in message
. ..
> "Dean Kent" > wrote in message
> .. .
> >
> > Is it possible that Mike was wrong, or perhaps his source?
>
> Check this link to MDR. This is the 2nd half 2000 Intel forecast. That
> means it was likely compiled in the first half, or perhaps even late 1999.
> It shows Northwood as a P4 part, not IA-64. Can we presume that Mike or
> his source were out in left field?
>
> http://www.mdronline.com/publications/tl/intel_2h2000/toc2.html
>

Just found this post on comp.sys.intel back in Jan 1996. It says that Intel
delayed Merced until late 1998, and that there would be a performance
discrepancy when running x86 code.

http://www.google.com/groups?q=IA-64++group:comp.*&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=12&as_minm=5&as_miny=1981&as_maxd=4&as_maxm=8&as_maxy=1996&selm=310C00DE.5014%40swcp.com&rnum=2

I am finding it harder and harder to believe that Intel said anything about
replacing x86 with IA-64 in the 1996 and beyond timeframe (might have said
something in 1994/95 about it - but searching Google Groups turns up nothing
from anyone about this - so I am doubting that anyone actually heard such a
thing or it probably would have been posted as a question, at least).
Official information indicates that they knew there would be performance
issues, and that x86 would not be easily replaced.

David Wang posted in Dec 1996, that MDR claimed IA-64 would likely be
'phased in' over a long period of time (he estimates 5 to 10 years), but
also states that he believed Intel would be developing x86 processors "well
into the 21st century".

http://www.google.com/groups?q=IA-64+replace+x86+group:comp.*&hl=en&lr=&ie=UTF-8&as_drrb=b&as_mind=12&as_minm=5&as_miny=1981&as_maxd=4&as_maxm=8&as_maxy=1997&selm=582kof%24ei7%40dailyplanet.wam.umd.edu&rnum=1

Searching Google Groups from 1981 thru 1997, I see nobody posting anything
about Intel claiming IA-64 would replace x86 in any official or unofficial
statement. I *do* see several people trying to make the argument that it
would, which picked up steam in 1997 (only a couple of posts in 1996). If
so many people saw charts and heard Intel statements, how come nobody posted
a single comment or question about it anywhere on Usenet?

I really am trying to find the evidence. It just seems so damned hard to
find that I must question whether it ever existed...

Regards,
Dean

Dean Kent
August 5th 04, 06:55 AM
"Yousuf Khan" > wrote in message
et.cable.rogers.com...
>
> Thus you shall have it. If the only proof you shall accept is documentary
> proof (which would include webpages), then we shall do Google searches on
> your behalf to find those precious archival webpages.
>
> This article from late 1998, it was thought that the IA-32 line of
> processors would end in 2003 with the Foster,

Foster, Cascades and Tanner are Xeon parts, not desktop x86. You are either
being intentionally disingenuous, or your shades are letting through only
what will support your argument. The article specifically states:

"Graylish meanwhile confirms that Intel doesn't want people to get too
excited about IA-64 too soon. As reported here earlier, Intel's plans for
the continuation of IA-32 make it clear that it anticipates this being the
volume platform for some time"

> and from that point afterwards
> IA-64 would take over starting with Deerfield. It's also interesting to
note
> that back then, Intel thought 64-bit for the masses would take off
starting
> in 2003. It turned out that they were absolutely right, but it just wasn't
> one of their chips, it was the Athlon 64 and Opteron.

Um. Exactly which 'masses' are you referring to? Opteron has 6-7% of the
market. A64 has even less.

>
> http://www.theregister.co.uk/1998/10/22/madison_and_deerfield_to_split/
>
> http://www.theregister.co.uk/1998/10/15/intel_doctors_foster_to_extend/
>
> Now, it's obvious that Intel's plans didn't actually live upto its
original
> roadmaps. That's not surprising or unexpected. However, it's also not
> important, it was their intention that is being discussed here only. It
was
> obvious that in 1998, Intel was hinting at replacing IA-32 at least by
2003.

Read it again. It did not say that. The entire article is discussing
server chips, and specifically states that IA-32 chips would be volume for a
long time after 2003...

Regards,
Dean

>
> Yousuf Khan
>
>

Ketil Malde
August 5th 04, 07:39 AM
"Dean Kent" > writes:

> Just found this post on comp.sys.intel back in Jan 1996. It says that Intel
> delayed Merced until late 1998, and that there would be a performance
> discrepancy when running x86 code.

Well, the fact that they spent an effort on x86 compatibility seems to
make it pretty clear that they wanted it to target at least some of
the same market. At least, it's hardly something HP would insist on
in a HPPA replacement.

> I am finding it harder and harder to believe that Intel said anything about
> replacing x86 with IA-64 in the 1996 and beyond timeframe (might have said

IA-64 was supposed to be the Next Thing, much faster and better than
x86, and backwards compatible. Even if Intel didn't explicitly
sentence x86 to death, the market perception was that it was going to
happen.

Analogously, I think one would be hard pressed to find an AMD
statement giving a timeframe for ending x86 in favor of x86-64, but I
think it's fair to say that this is the plan and likely outcome.

Given the ('fin de siecle'? :-) perception that IA64 would outperform
x86, have a 64bit address space, and perhaps most importantly: be
proprietary to Intel; why wouldn't Intel do all in their power to
terminate x86 as the CPU of choice? (Including newspeak about IA64
being "open", as opposed to "closed" architectures like SPARC, but I
digress.)

IMHO, they kept x86 available 'until IA64 could take over', and
only relatively recently (with the development of their own x86-64
line) changed to 'indefinitely'. Good for them they didn't terminate
x86 development early on (unlike some competing RISC chips).

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

Yousuf Khan
August 5th 04, 07:54 AM
Dean Kent wrote:
> "Yousuf Khan" > wrote in message
> et.cable.rogers.com...
>>
>> Thus you shall have it. If the only proof you shall accept is
>> documentary proof (which would include webpages), then we shall do
>> Google searches on your behalf to find those precious archival
>> webpages.
>>
>> This article from late 1998, it was thought that the IA-32 line of
>> processors would end in 2003 with the Foster,
>
> Foster, Cascades and Tanner are Xeon parts, not desktop x86. You are
> either being intentionally disingenuous, or your shades are letting
> through only what will support your argument. The article
> specifically states:

No one said anything about desktop or server x86, we were just talking about
x86 in general.

Actually, neither of these articles made any mention about these being Xeon
parts. Yes, Foster eventually did turn out to be a P4 Xeon, but at that time
it wasn't known what market it was aimed at. It was just a name on a
roadmap.

> "Graylish meanwhile confirms that Intel doesn't want people to get too
> excited about IA-64 too soon. As reported here earlier, Intel's plans
> for the continuation of IA-32 make it clear that it anticipates this
> being the volume platform for some time"

However, the 32-bit Intel roadmaps ended at Foster at that time, while at
the same time a lot of names appeared on the IA-64 roadmap well after
Foster. Why so little visibility on IA-32 roadmap when IA-64 was so visible?

>> and from that point afterwards
>> IA-64 would take over starting with Deerfield. It's also interesting
>> to note that back then, Intel thought 64-bit for the masses would
>> take off starting in 2003. It turned out that they were absolutely
>> right, but it just wasn't one of their chips, it was the Athlon 64
>> and Opteron.
>
> Um. Exactly which 'masses' are you referring to? Opteron has 6-7%
> of the market. A64 has even less.

What would you call them, boutique chips? Athlon 64 with a small marketshare
in the desktop space could still mean millions of chips in a year. And of
course, Opteron at 6-7% would still mean that it outsells all non-x86 server
chips. And of course none of this is static, as both of those processors
increasing their marketshare not decreasing.

Yousuf Khan

Tony Hill
August 5th 04, 08:20 AM
On Wed, 04 Aug 2004 02:30:58 GMT, "Dean Kent"
> wrote:
>"Tony Hill" > wrote in message
...
>>
>> I'm not sure that would be very different from where they stand now.
>> From what I understand HP and SGI make up well over 90% of all Itanium
>> server revenues. Everyone else (IBM, Dell, Unisys, Bull and whoever
>> else) are mostly fighting for a few scraps.
>
>That, by itself, is not an indication of the success or failure of Itanium.
>First you have to provide the revenue numbers, and market percentage.
>Otherwise you could state that because Intel gets almost 85% of all x86
>revenues, that x86 is a failure...

Not indicative of success vs. failure at all (nor was it at all
intended to be), simply indicative that Itanium is pretty much just an
HP and SGI chip. Sure, there are at least a half-dozen other
companies selling the chips, but the quantities that they sell are
small enough that they can pretty much be ignored.

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

Tony Hill
August 5th 04, 08:20 AM
On Wed, 04 Aug 2004 02:30:57 GMT, "Dean Kent"
> wrote:
>"Tony Hill" > wrote in message
...
>> Actually it all seems to tie back in to the fact that MS decided to
>> push all their future OSes back until they get WinXP SP2 out, and that
>> seems to be taking forever! Each time SP2 gets pushed back everything
>> else gets pushed back behind it.
>
>The explanation is most likely that the Windows OS is likely a huge pile of
>spaghetti code that is a nightmare to maintain - including full 64-bit
>operation.

That's probably got a lot to do with it, but it's definitely not just
64-bit code that's causing the holdup. MS announced that they were
delaying Win2K3 Server SP1 (32-bit version) at the same time and for
the same reason why they are delaying WinXP 64-bit and Win2K3 64-bit.
All seem to tie back in to getting all the changes and fixes for WinXP
SP2 implemented properly first and then streaming them into the other
products.

> For those who have never worked on a commercial product of any
>size, all it takes is a few customers complaining about a bug that 95% will
>never encounter to extend a beta - and that 95% will scratch their heads and
>claim that the product is *so* stable. Sure, you can get the 'core'
>features to work fine, but the corner cases can be a major bitch... :-).

Certainly! It's that classic 90/10 principal of project work (ie 10%
of the work takes 90% of the time to complete), although for computers
I think it's more like a 95/5% principal!

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

Yousuf Khan
August 5th 04, 08:23 AM
Dean Kent wrote:
> Is it possible that Mike was wrong, or perhaps his source? Isn't the
> Israel lab the one that developed Banias? Would someone there have
> direct knowledge of IA-64 plans, or would it most likely be rumors?

Or perhaps, it's possible that Intel is rather flexible with codenames
during the conceptual phase, and doesn't actually lock them down until the
design phase?

> I wonder if there has been any other time Intel has re-used a
> codename for two different processors?

I can think of at least one recent instance. Clackamas vs. Yamhill
technology, which eventually became EM64T technology. Just goes to show how
flexible Intel really is with its codenames.

> So, if the Northwood was
> being planned as IA64 in mid-1999, but by early 2001 it was released
> as a P4, that seems like a very short amount of time to do such a
> redesign. I'm no EE, but it seems that if Intel has such release
> cycles it would be pretty difficult to just change them on the fly
> like this.

And I'm no Intel manager, but isn't it entirely possible that these Intel
project codenames are actually attached to management cost centres rather
than to actual technology? First you get funding for a project, and then you
lay down the technology. So perhaps during the initial conceptual phase they
were toying with the idea of either making Northwood either IA-64 or IA-32,
and in 1999 it looked like a good bet that IA-64 was the way to go with it,
but by 2000 it was looking like IA-32 was the way to go.

Let's look at what the Northwood actually ended up becoming, shall we? It
was just a small evolution of the Williamette core: a die shrink, an L2
cache increase, and the enabling of the dormant Hyperthreading technology.
These evolutions were therefore paid for through the Northwood cost centre.
The Williamette itself was rushed out the door as soon as possible to do
battle against the Athlon which was starting to hurt Intel. Once Williamette
was out the door, incomplete as it was, it's likely that its cost centre was
closed, and thus further evolution had to be paid for through the next
available cost centre which was the Northwood project. Basically, just a big
management relay race, rather than showcases of technology.

Yousuf Khan

Yousuf Khan
August 5th 04, 08:23 AM
Dean Kent wrote:
> I really am trying to find the evidence. It just seems so damned
> hard to find that I must question whether it ever existed...

You go ahead and re-interpret history as much as you like. But you were the
one who wanted to know why so many of us have this memory of Intel wanting
to phase out x86 by now. Notwithstanding clauses notwithstanding, I think
the case has now been made for why so many of us have this memory of things
past.

Yousuf Khan

Yousuf Khan
August 5th 04, 08:36 AM
Yousuf Khan wrote:
>> I wonder if there has been any other time Intel has re-used a
>> codename for two different processors?
>
> I can think of at least one recent instance. Clackamas vs. Yamhill
> technology, which eventually became EM64T technology. Just goes to
> show how flexible Intel really is with its codenames.

Which in light of the previous cost centres discussion, can be
reinterpretted too. Yamhill was supposedly cancelled by Intel a long time
ago, because it threatened future IA-64 sales. So the Yamhill cost centre
was closed. However, none of the designs worked on are ever thrown away. So
if they ever want to revive a project, they have to open up a new cost
centre with a new name. Thus Yamhill was cancelled, and thus its name could
never be reopened.

Yousuf Khan

Patrick Schaaf
August 5th 04, 09:00 AM
"Yousuf Khan" > writes:

>lay down the technology. So perhaps during the initial conceptual phase they
>were toying with the idea of either making Northwood either IA-64 or IA-32,

Didn't some ex-Intel person comment on comp.arch, not so long ago,
that that was indeed the case, but the idea was later canned?

>Let's look at what the Northwood actually ended up becoming, shall we? It
>was just a small evolution of the Williamette core: a die shrink, an L2
>cache increase, and the enabling of the dormant Hyperthreading technology.

Would it be plausible that initially, Hyperthreading (two threads) was
invented so one IA-32 and one IA-64 process could share the processor
at the same time, different decoders feeding the same trace cache and
execution resources?

best regards
Patrick

Jan Vorbrüggen
August 5th 04, 09:08 AM
> Ah so... If an application I bought yesterday doesn't work today, it's
> *my* fault? I don't think IBM became a giant with that attitude.

If the reason it broke was some accidental feature of the previous chip,
it is the application programmer's/vendor's fault, yes. It is very similar
to writing a multi-threaded program with a race condition that just doesn't
happen to occur in one particular context - the one you have been using up
until now - but now occurs and makes WW III happen.

Jan

Jan Vorbrüggen
August 5th 04, 09:10 AM
> You seem to have a bit of an odd view of backward compatibility.

I do. Have you seen the talk in question, and understood the situation
Colwell described?

Jan

Niels Jřrgen Kruse
August 5th 04, 12:17 PM
I artiklen > , "Dean Kent"
> skrev:

> "Dean Kent" > wrote in message
> .. .
>>
>> Is it possible that Mike was wrong, or perhaps his source?
>
> Check this link to MDR. This is the 2nd half 2000 Intel forecast. That
> means it was likely compiled in the first half, or perhaps even late 1999.
> It shows Northwood as a P4 part, not IA-64. Can we presume that Mike or
> his source were out in left field?

64 bit uops did show up in Prescott and according to Andy Glew, IA-64
support was proposed for Tejas (but turned down). Even if rumors have a
basis in fact, it is common for planned features to creep a generation or
two upstream (versus reality). Makes for much better drama.

--
Mvh./Regards, Niels Jřrgen Kruse, Vanlřse, Denmark

George Macdonald
August 5th 04, 02:03 PM
On Thu, 05 Aug 2004 04:22:13 GMT, "Dean Kent" >
wrote:

>> The charts I saw were Itanic to exceed x86 sales by 2003 and by '05 x86
>> was relegated to the dust-bin of embedded losers. ...and that was in
>> 1997ish. There was some discussion about this in AFC a few weeks ago (I'm
>> not the only one remembering such).
>
>I saw charts in 1997 also - and none of them showed Itanium moving out of
>the high end server segment. Though I was only given reseller roadmaps
>directly, I was given OEM roadmaps from a motherboard maker associated with
>a very, very large Asian OEM. I don't recall seeing any of those things -
>and I still have those roadmaps. I wonder if anyone 'recalling' such things
>does?
>
>As for George's argument, as usual it is a fallacy. It is called
>"argumentum ad ignorantium". Just because it cannot be proven to be false,
>does not mean that it is true. The burden of proof is upon those trying to
>make the claim. Public information says Intel did not intend to replace
>x86 anytime soon, so it will take a bit more than 'recollections' to make
>the case that they did. Sorry.

As usual the Kentster's way of impolitely calling someone a liar... and not
only me. The roadmaps *did* exist! Were they official roadmaps like those
issued to the i-Stooges in your quixotic, privileged position?... nope!
Were they published in magazines and Web sites?... yup! The evidence has
vanished along with bubble memory cheers and i860 effervescence - seems
like you were not paying attention.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Annie Nonimus
August 5th 04, 02:37 PM
Yousuf Khan wrote:

>>http://www.memory-key.com/ResearchReports/tversky2000.htm
>
> This article from late 1998, it was thought that the IA-32 line of
> processors would end in 2003 with the Foster, and from that point afterwards
> IA-64 would take over starting with Deerfield. It's also interesting to note
> that back then, Intel thought 64-bit for the masses would take off starting
> in 2003. It turned out that they were absolutely right, but it just wasn't
> one of their chips, it was the Athlon 64 and Opteron.
>
> http://www.theregister.co.uk/1998/10/22/madison_and_deerfield_to_split/
>
> http://www.theregister.co.uk/1998/10/15/intel_doctors_foster_to_extend/
>
> Now, it's obvious that Intel's plans didn't actually live upto its original
> roadmaps. That's not surprising or unexpected. However, it's also not
> important, it was their intention that is being discussed here only. It was
> obvious that in 1998, Intel was hinting at replacing IA-32 at least by 2003.
>
> Yousuf Khan
>

For those of you who seem to enjoy beating a dead horse in you K9
thread, take a look at the links above!

Dean Kent
August 5th 04, 02:48 PM
"Yousuf Khan" > wrote in message
t.cable.rogers.com...
>
> No one said anything about desktop or server x86, we were just talking
about
> x86 in general.
>
> Actually, neither of these articles made any mention about these being
Xeon
> parts. Yes, Foster eventually did turn out to be a P4 Xeon, but at that
time
> it wasn't known what market it was aimed at. It was just a name on a
> roadmap.

Now you *are* being disingenuous. It was very well known that Foster was a
Xeon at the time. I *have* the roadmaps, and the roadmaps very clearly
segment the market. Foster was at the lower end of the server segment by
2003 (which was supposed to be why Deerfield would be the low-end
replacement).

>
> However, the 32-bit Intel roadmaps ended at Foster at that time, while at
> the same time a lot of names appeared on the IA-64 roadmap well after
> Foster. Why so little visibility on IA-32 roadmap when IA-64 was so
visible?

Yousef - this is a *SERVER* roadmap. Period. Not an IA-32 roadmap.

>
> What would you call them, boutique chips? Athlon 64 with a small
marketshare
> in the desktop space could still mean millions of chips in a year. And of
> course, Opteron at 6-7% would still mean that it outsells all non-x86
server
> chips. And of course none of this is static, as both of those processors
> increasing their marketshare not decreasing.

Itanium outsold Opteron last year (100K to about 70K, I believe). So, if
Opteron is a mass-market 64-bit CPU, what is Itanium? Your comments apply
to Itanium as well as Opteron, and yet you relegate Itanium to the scrap
heap? Disingenuous does not seem to describe properly the argument being
presented, it seems.

I believe that by this time the point should have been made, and recognized.
I doubt most care much about this particular point anymore, however.

Regards,
Dean

>
> Yousuf Khan
>
>

Hank Oredson
August 5th 04, 03:32 PM
"Yousuf Khan" > wrote in message
t.cable.rogers.com...
> Keith wrote:
>> On Wed, 04 Aug 2004 16:33:24 -0400, George Macdonald wrote:
>>> Uhh, it's called spin.:-) The fact you or I can't find the
>>> docs/pages to confirm the "recollections" does not mean they did not
>>> exist. Nefarious is your term but I did see a roadmap which showed
>>> x86 relegated to mostly STBs by 2005... after a steady year by year
>>> decline in PCs.
>>
>> The charts I saw were Itanic to exceed x86 sales by 2003 and by '05
>> x86 was relegated to the dust-bin of embedded losers. ...and that was
>> in 1997ish. There was some discussion about this in AFC a few weeks
>> ago (I'm not the only one remembering such).
>
> I think a lot of us can remember Intel's predictions about IA64 eventually
> replacing IA32 by some point in time. You don't need some archival webpage
> in order to prove it. Just the fact that so many of us who have been in
> this
> business for so long can recall these statements is more than enough.


I'm sure most or even all of us remember these things.

Some of the problem is in semantics: introduction, general
availability, wide use, replacement. I take "replacing" to
mean that IA32 is no longer available, and IA64 is used
in all cases including embeded devices.

My particular memory puts the date of IA64 replacing
IA32 well into the second decade of this century.

My memory puts the date of widespread use of
IA64 in the first decade of this century.

This is from an investment viewpoint: what I thought
Intel was saying about the evolution of the portions
of their product line that produced the most profit.

But the fact that I think these things is probably rather
uninteresting, since I cannot produce any actual
documents that say the specific things I think will be true ;-)

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net

Mark Hahn
August 5th 04, 03:40 PM
In comp.sys.intel Ketil Malde > wrote:
> (Nick Maclaren) writes:

>> Ketil Malde > writes:

>>> I think most of HP's IA64 sales also are going to the scientific
>>> computing segment.

I've wondered about this; if true, I think it's a combination of
several factors:
- the fact that SPEC is now an in-cache benchmark.
- 4 flops/cycle on linpack -> good scores for top500.
- before Xeon/Opteron shipped with 128b ddr, it2 had the only
6.4 GB/s memory system.
- big discounts from vendors.
- some people swallowing spin about the next-big-thing.

> I guess I should emphasize that I'm just guessing - I know about a few
> Superdomes that do number crunching (which anyway is what IA64 is good
> at). Are there any numbers; anywhere?

I've done some testing, and Superdomes are OK - comparable to Altix,
not surprisingly.

the ironic thing is that ia64 owes nearly all of its good performance to
running benchmarks in-cache. out of cache, it's dramatically less
impressive. I re-analyzed a batch of specFP results, by sorting the
individual components by score. you'll immediately notice that ia64
has some real outliers, which just happen to be the smallest (RSS) SPEC
components, that just happen to be in-cache on ia64, and not on most
other processors. iirc, if you drop the top 4, Opterons are actually
faster than ia64.

there are realistic codes which have small working sets. the real problem
is that these codes tend to run pretty well on a 3GHz Xeon, so why pay
incredible prices for a 1.3 GHz It2? for memory-intensive codes, the
standard is pretty much Opteron.

regards, mark hahn.
--
operator may differ from spokesperson.
http://hahn.mcmaster.ca/~hahn

Yousuf Khan
August 5th 04, 04:52 PM
Dean Kent wrote:
> Now you *are* being disingenuous. It was very well known that Foster
> was a Xeon at the time. I *have* the roadmaps, and the roadmaps very
> clearly segment the market. Foster was at the lower end of the
> server segment by 2003 (which was supposed to be why Deerfield would
> be the low-end replacement).

And as it has been said, it doesn't matter, we're just talking about x86 in
general. The x86 roadmap's visibility ended at Foster in one case, and
Northwood in another. I'm not going to get into a ****ing contest with you
Dean (I'll let Keith do that :-), but you asked for reasons why the beliefs
are so widespread, so now you know.

> Itanium outsold Opteron last year (100K to about 70K, I believe).
> So, if Opteron is a mass-market 64-bit CPU, what is Itanium? Your
> comments apply to Itanium as well as Opteron, and yet you relegate
> Itanium to the scrap heap? Disingenuous does not seem to describe
> properly the argument being presented, it seems.

Quite the accomplishment for Itanium too, that was. It beat the sales of a
chip that came out for the first time ever four months into the year. This
year Opteron is already slated to sell 100,000 in one quarter, let alone the
whole year. Quite the wide-selling boutique chip isn't it?

> I believe that by this time the point should have been made, and
> recognized. I doubt most care much about this particular point
> anymore, however.

Oh that point was already reached a long time ago, you were the only one
denying what the rest of us saw as quite obvious. This is just the education
of Dean Kent at this point.

Yousuf Khan

Yousuf Khan
August 5th 04, 05:19 PM
George Macdonald wrote:
> On Thu, 05 Aug 2004 04:22:13 GMT, "Dean Kent"
>> As for George's argument, as usual it is a fallacy. It is called
>> "argumentum ad ignorantium". Just because it cannot be proven to
>> be false, does not mean that it is true. The burden of proof is
>> upon those trying to make the claim. Public information says Intel
>> did not intend to replace x86 anytime soon, so it will take a bit
>> more than 'recollections' to make the case that they did. Sorry.
>
> As usual the Kentster's way of impolitely calling someone a liar...
> and not only me. The roadmaps *did* exist! Were they official
> roadmaps like those issued to the i-Stooges in your quixotic,
> privileged position?... nope!
> Were they published in magazines and Web sites?... yup! The evidence
> has vanished along with bubble memory cheers and i860 effervescence -
> seems
> like you were not paying attention.

We've now even dug up some old historical webpages (possibly written in
parchment or papyrus or something) from the early days of the commercial
Internet which states exactly why we thought Intel's plans were to go
towards IA-64. Yet, he still needs to argue. Some people are just beyond
quixotic!

Yousuf Khan

Yousuf Khan
August 5th 04, 05:19 PM
Patrick Schaaf wrote:
> Would it be plausible that initially, Hyperthreading (two threads) was
> invented so one IA-32 and one IA-64 process could share the processor
> at the same time, different decoders feeding the same trace cache and
> execution resources?

It's possible but we have no way of knowing that right now. Anyways, that
would sound more like dual-processing than Hyperthreading.

Yousuf Khan

Yousuf Khan
August 5th 04, 05:19 PM
Hank Oredson wrote:
> But the fact that I think these things is probably rather
> uninteresting, since I cannot produce any actual
> documents that say the specific things I think will be true ;-)

Well, now the historical documents have been produced.

Yousuf Khan

Hank Oredson
August 5th 04, 06:03 PM
"Yousuf Khan" > wrote in message
.rogers.com...
> Hank Oredson wrote:
>> But the fact that I think these things is probably rather
>> uninteresting, since I cannot produce any actual
>> documents that say the specific things I think will be true ;-)
>
> Well, now the historical documents have been produced.


Where are they?

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net

Wes Newell
August 5th 04, 07:16 PM
On Thu, 05 Aug 2004 05:49:44 +0000, Dean Kent wrote:

> I am finding it harder and harder to believe that Intel said anything about
> replacing x86 with IA-64 in the 1996 and beyond timeframe (might have said

For all.

Who really gives a ****.:-)

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://mysite.verizon.net/res0exft/cpu.htm

Annie Nonimus
August 5th 04, 07:29 PM
Wes Newell wrote:

> On Thu, 05 Aug 2004 05:49:44 +0000, Dean Kent wrote:
>
>
>>I am finding it harder and harder to believe that Intel said anything about
>>replacing x86 with IA-64 in the 1996 and beyond timeframe (might have said
>
>
> For all.
>
> Who really gives a ****.:-)
>

My sentiments exactly! This dead horse has been beat so much there's
nothing left to bury! Probably nothing the buzzards could subsist on
either!!

Yousuf Khan
August 5th 04, 07:39 PM
Hank Oredson wrote:
> "Yousuf Khan" > wrote in message
> .rogers.com...
>> Hank Oredson wrote:
>>> But the fact that I think these things is probably rather
>>> uninteresting, since I cannot produce any actual
>>> documents that say the specific things I think will be true ;-)
>>
>> Well, now the historical documents have been produced.
>
>
> Where are they?

Read the rest of the thread(s).

Yousuf Khan

August 5th 04, 09:00 PM
On Thu, 05 Aug 2004 18:16:23 GMT, Wes Newell
> wrote:

>On Thu, 05 Aug 2004 05:49:44 +0000, Dean Kent wrote:

>> I am finding it harder and harder to believe that Intel said anything about
>> replacing x86 with IA-64 in the 1996 and beyond timeframe (might have said

>For all.

>Who really gives a ****.:-)

Wondered Wes, whether you would ever jump in this thread lad. For over
a week or so I thought you would resist - but then bang in you go both
wellies filled to the top - good on you m8.

BoroLad

Nick Maclaren
August 5th 04, 09:09 PM
In article rs.com>,
Yousuf Khan > wrote:
>Patrick Schaaf wrote:
>> Would it be plausible that initially, Hyperthreading (two threads) was
>> invented so one IA-32 and one IA-64 process could share the processor
>> at the same time, different decoders feeding the same trace cache and
>> execution resources?
>
>It's possible but we have no way of knowing that right now. Anyways, that
>would sound more like dual-processing than Hyperthreading.

That is understating the case. No, that hypothesis is not plausible.

Hyperthreading is so intimate that it would be foul to implement for
two architectures as different as x86 and IA64. The sane approach
would be two separate CPUs with a shared Lx cache on the same die.
I have hypothesised that a FUTURE Intel design may be a Crusoe-like
one where two logical CPUs could be x86 and IA64, but even then I
suspect that it won't run both at once.


Regards,
Nick Maclaren.

Hank Oredson
August 5th 04, 10:10 PM
"Yousuf Khan" > wrote in message
rs.com...
> Hank Oredson wrote:
>> "Yousuf Khan" > wrote in message
>> .rogers.com...
>>> Hank Oredson wrote:
>>>> But the fact that I think these things is probably rather
>>>> uninteresting, since I cannot produce any actual
>>>> documents that say the specific things I think will be true ;-)
>>>
>>> Well, now the historical documents have been produced.
>>
>>
>> Where are they?
>
> Read the rest of the thread(s).


I found no documents, nor any URLs to documents.

If there are other threads, whast are they?

I only read one of the groups this troll was cross posted
to, so perhaps those documents were in some other group?

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net

The Chief
August 6th 04, 12:17 AM
You're not going to find any viable links in this thread because all
that are participating, or throwing their 2 cents worth in, are either
"armchair quarterbacks" or "**** house lawyers", or whatever you want to
call them, and none of them really know their ass from a hole in the
ground!!!

Keith
August 6th 04, 03:07 AM
On Thu, 05 Aug 2004 04:17:33 +0000, Dean Kent wrote:

> "Keith" > wrote in message
> ...
>> On Wed, 04 Aug 2004 08:55:56 +0200, Jan Vorbrüggen wrote:
>>
>> Ah so... If an application I bought yesterday doesn't work today, it's
>> *my* fault? I don't think IBM became a giant with that attitude.
>
> Well, that isn't the only reason IBM became a giant.

Actually, Dean, yes it is. SOftware that's lost its source decades ago
still runs. Software rules enterprise hardware, not the other way around.
I'm really surprised, given your background that you don't understand
simple reality. IBM's FS was still-born precisely because backwards
compatablility is far more important than hardware.



> There were a bunch of
> salespeople, and some rather draconian contracts before the anti-trust
> lawsuits.

Oh, Pkease Dean! This all stopped dead with the '56 consent decree.
Neither of us were in the business (I was almost ready for kindergarten
and I doubt you were alive_ when this was entered into.

> I can recall when I worked at ADP in 1978/79 that IBM threatened
> to cancel the lease and yank the 370/155 if the 3203 printers were
> replaced with a competitors.

There was obviously far more to it than that. The OEMI interface was a
standard long before (see above). Printers were not part of the system.
Yes, I'm calling you misinformed (benefit of the doubt given, reluctantly).

> I left there in 1980, and when I went back
> they had replaced the entire system with one from a company called
> Magnuson (or something to that effect). Needless to say, they were
> *not* happy with IBM tactics.

The allowable "tactics" were well laid out by the '56 consent decree.

> I also recall some interesting
> interactions when Amdahl sold them a half-meg memory upgrade. IBM
> refused to allow Amdahl to touch the box, and IBM would not touch the
> Amdahl unit - so our system programmer had to hook everything up.

My bet is that the box was leased. Otherwise you were free to have anyone
blow it up. Yes, there were *many* problems with add-on memory. Some
understood, some not so. In any case GM doesn't warrant a Ford engine in
thier cars. If you blow the tranny, too bad.


> Yeah, IBM has always been your friend. ;-).

Has always worked for me! ;-)

>> You really believe they care? Why don't they patch Win2K without
>> having to sign up for a XPish license agreement? Come on! What's with
>> the XP license anyway? Yes, and next year you'll rent the OS. ...good
>> plan this "security" is.
>
> Hmm. At my job we 'rent' the OS we run today from IBM - I think it is
> called zOS. Perhaps that is why IBM became a giant, too? ;-).

I know you dropped out of the groups for a while. Perhaps you were having
a lobotomy? IBM hasn't been able to force *anyone* to lease since the
'56 consent decree. If your management chooses to lease, then it's their
business decision. M$ will force everyone to "rent" their OS. Indeed
their data will no longer belong to them, if you believe the license
agreements. No, you're being "disingenuous" again Dean.

--
Keith

Yousuf Khan
August 6th 04, 03:31 AM
Hank Oredson wrote:
>>> Where are they?
>>
>> Read the rest of the thread(s).
>
>
> I found no documents, nor any URLs to documents.
>
> If there are other threads, whast are they?
>
> I only read one of the groups this troll was cross posted
> to, so perhaps those documents were in some other group?

You didn't read the these archival webpages from 98 and 99?

http://www.theregister.co.uk/1998/10/22/madison_and_deerfield_to_split/

http://www.theregister.co.uk/1998/10/15/intel_doctors_foster_to_extend/

http://www.theregister.co.uk/1999/04/28/secrets_of_intels_ia64_roadmap/

Basically, these are the examples of why the perception that Intel had said
that IA-64 would be replacing IA-32 sooner rather than later.

Yousuf Khan

Dean Kent
August 6th 04, 04:04 AM
"Wes Newell" > wrote in message
news:[email protected] .net...
> On Thu, 05 Aug 2004 05:49:44 +0000, Dean Kent wrote:
>
> > I am finding it harder and harder to believe that Intel said anything
about
> > replacing x86 with IA-64 in the 1996 and beyond timeframe (might have
said
>
> Hell, I saw it predicted in 1979, Now that I've removed the group I read
> from this crossposted rediculous thread, have at it.:-)

It is ridiculous, and it was cross posted, and you are a liar and a complete
idiot. Now that I have removed the group that *I* read, you can have at it
too. Enjoy your clueless life - particularly since you use POS Abit
products. The most obvious clue that you are an idiot. Enjoy.

Regards,
Dean

>
> --
> Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
> http://mysite.verizon.net/res0exft/cpu.htm

Hank Oredson
August 6th 04, 05:28 AM
"Yousuf Khan" > wrote in message
gers.com...
> Hank Oredson wrote:
>>>> Where are they?
>>>
>>> Read the rest of the thread(s).
>>
>>
>> I found no documents, nor any URLs to documents.
>>
>> If there are other threads, whast are they?
>>
>> I only read one of the groups this troll was cross posted
>> to, so perhaps those documents were in some other group?
>
> You didn't read the these archival webpages from 98 and 99?
>
> http://www.theregister.co.uk/1998/10/22/madison_and_deerfield_to_split/
>
> http://www.theregister.co.uk/1998/10/15/intel_doctors_foster_to_extend/
>
> http://www.theregister.co.uk/1999/04/28/secrets_of_intels_ia64_roadmap/
>
> Basically, these are the examples of why the perception that Intel had
> said
> that IA-64 would be replacing IA-32 sooner rather than later.


Oh, I'm all confused.
I thought you meant Intel documents.
Didn't understand you meant "Rumors and Raw Random Data."

--

... Hank

http://horedson.home.att.net
http://w0rli.home.att.net

Wes Newell
August 6th 04, 05:45 AM
On Fri, 06 Aug 2004 03:04:49 +0000, Dean Kent wrote:

> "Wes Newell" > wrote in message
> news:[email protected] .net...
>> On Thu, 05 Aug 2004 05:49:44 +0000, Dean Kent wrote:
>>
>> > I am finding it harder and harder to believe that Intel said anything
> about
>> > replacing x86 with IA-64 in the 1996 and beyond timeframe (might have
> said
>>
>> Hell, I saw it predicted in 1979, Now that I've removed the group I read
>> from this crossposted rediculous thread, have at it.:-)
>
> It is ridiculous, and it was cross posted, and you are a liar and a complete
> idiot. Now that I have removed the group that *I* read, you can have at it
> too. Enjoy your clueless life - particularly since you use POS Abit
> products. The most obvious clue that you are an idiot. Enjoy.
>
You mean you literally took what I said as if I believed it? And you call
me an idiot. Satire, look up the word. No need to reply. You know nothing
that I would be interested in. In fact you probably don't know anything
useful that I don't alreay know.:-)

--
Abit KT7-Raid (KT133) Tbred B core CPU @2400MHz (24x100FSB)
http://mysite.verizon.net/res0exft/cpu.htm

Ketil Malde
August 6th 04, 07:27 AM
"Hank Oredson" > writes:

> Oh, I'm all confused. I thought you meant Intel documents.
> Didn't understand you meant "Rumors and Raw Random Data."

Well, I know the Register may not be the most accurate of sources, but
if we're talking about public perception, I bet more people read the
Register (and similar sites) than official Intel documentation.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

Dean Kent
August 6th 04, 08:23 AM
"Ketil Malde" > wrote in message
...
> "Hank Oredson" > writes:
>
> > Oh, I'm all confused. I thought you meant Intel documents.
> > Didn't understand you meant "Rumors and Raw Random Data."
>
> Well, I know the Register may not be the most accurate of sources, but
> if we're talking about public perception, I bet more people read the
> Register (and similar sites) than official Intel documentation.

I'm not sure at what point the discussion turned, but my original question
was whether anyone had factual evidence that Intel had plans to 'replace'
x86 in the near future - not whether people believed it to be true. I've
already made my position clear, I think, about perception and flawed
recollections...

Regards,
Dean

>
> -kzm
> --
> If I haven't seen further, it is by standing in the footprints of giants

Stephen Sprunk
August 6th 04, 04:13 PM
"Keith" > wrote in message
...
> On Fri, 30 Jul 2004 05:23:57 +0000, Dean Kent wrote:
>
> > Some things are designed to be easily portable (such as DB2, perhaps?),
> > while others are not. The incompetence does not have to be with today's
> > coders, but could be due to yesterday's designers...

The near-monopoly Windows has enjoyed is damaging to Microsoft's coders'
skills. They haven't been required to maintain portable code all along,
just to develop for the latest platform and once or twice a decade do a
complete rewrite when the platform changes. OSS developers have to deal
with portability every day and the transition from i386 to amd64 has been
almost a non-event because of it.

The Win32 API and SDK was pretty well designed to handle the eventual
transition to Win64, but most coders didn't take advantage of those features
because a decade ago there was no obvious motivation. Based on how quickly
the _kernel_ was ported, at least some of MS' developers did it right, but
most did not -- nor did most ISVs.

> I surely *hope* M$'s architects learned something from OS/2 days. NT was
> a complete re-write and one would suspect that they learned a few lessons
> along the way.

M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
possible at the time they expected their code to be obsolete before 64-bit
systems took over -- 4GB is enough for anybody, right? I'm sure they didn't
expect their newly-ported 32-bit code to require porting again in less than
a decade, given 16-bit x86 code had been around for two decades. And, given
that most programmers don't stay in the same job for a decade, why would one
expect them to plan for the future (other than style)?

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Stephen Sprunk
August 6th 04, 04:17 PM
"Tony Hill" > wrote in message
...
> On Tue, 03 Aug 2004 08:56:53 +0200, Ketil Malde >
> wrote:
> >Keith > writes:
> >So I guess the explanation is the one given by Homer Simpson: "It's
> >because they're stupid, that's why. That's why everybody does
everything."
>
> Now you've got it!

Could that be considered a layman's version of Hanlon's Razor?

> Actually it all seems to tie back in to the fact that MS decided to
> push all their future OSes back until they get WinXP SP2 out, and that
> seems to be taking forever! Each time SP2 gets pushed back everything
> else gets pushed back behind it.

This makes a certain amount of sense; why should MS release XP64 in Q4 when
they'll be releasing SP2 (for all platforms) a couple months later? More
released versions means more support and distribution costs.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Ken Hagan
August 6th 04, 05:00 PM
Stephen Sprunk wrote:
>
> M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
> possible at the time they expected their code to be obsolete before
> 64-bit systems took over -- 4GB is enough for anybody, right? I'm
> sure they didn't expect their newly-ported 32-bit code to require
> porting again in less than a decade, given 16-bit x86 code had been
> around for two decades.

It's not *that* surprising that 64-bit systems are now arriving on
desktops. (But then again, by now it's been more than a decade.)

Back in, ooo, 1990 or thereabouts, I can remember plotting a graph of
memory size in the average bargain bucket PC versus date. OK, they were
my guesses and taken only over a decade, not proper data, but the graph
cut through the 4GB line around 2005. I predicted then that my OS would
be 64-bit, even if none of my applications were. (smug)

Annie Nonimus
August 6th 04, 05:11 PM
Ken Hagan wrote:

> Stephen Sprunk wrote:
>
>>M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
>>possible at the time they expected their code to be obsolete before
>>64-bit systems took over -- 4GB is enough for anybody, right? I'm
>>sure they didn't expect their newly-ported 32-bit code to require
>>porting again in less than a decade, given 16-bit x86 code had been
>>around for two decades.
>
>
> It's not *that* surprising that 64-bit systems are now arriving on
> desktops. (But then again, by now it's been more than a decade.)
>
> Back in, ooo, 1990 or thereabouts, I can remember plotting a graph of
> memory size in the average bargain bucket PC versus date. OK, they were
> my guesses and taken only over a decade, not proper data, but the graph
> cut through the 4GB line around 2005. I predicted then that my OS would
> be 64-bit, even if none of my applications were. (smug)
>
>
Sure hope you don't break your arm patting yourself on the back!

Stephen Sprunk
August 6th 04, 05:24 PM
"Yousuf Khan" > wrote in message
. rogers.com...
> Stephen Sprunk wrote:
> > Does an OS really need to be aware of the difference between two
> > cores on the same chip?
> >
> > Linux has a concept of a NUMA "node", where all of the processors in
> > a node are considered equivalent. It'll still try to schedule
> > threads on the same CPU they last ran on, but next it will try other
> > CPUs in the same node before giving up and sending it to any
> > available node.
> >
> > IIRC, the code already understands two-CPU nodes, because that is how
> > Intel's SMT chips are handled. Treating K8 CMP the same way sounds
> > correct, once AMD releases specs on how to recognize dual-core chips.
>
> I'm sure as a first cut, not treating them specially is the right way to
go.
> But eventually everybody tries to optimize down to the bone.

From a NUMA-aware scheduler's perspective, what's different between 2-way
SMT and 2-way CMP?

> AMD is even suggesting not treating Hypertransport as NUMA but as
> simple SMP is quite acceptable, and this suggestion is likely to hold for
> dual-cores too (probably even more so).

Once the bugs were worked out, Linux showed much better performance (for 2+
way Opeterons) when it was made NUMA-aware. Treating the system as simple
SMP is acceptable, but demonstrably not optimal.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Yousuf Khan
August 6th 04, 05:46 PM
Stephen Sprunk wrote:
> M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
> possible at the time they expected their code to be obsolete before
> 64-bit systems took over -- 4GB is enough for anybody, right? I'm
> sure they didn't expect their newly-ported 32-bit code to require
> porting again in less than a decade, given 16-bit x86 code had been
> around for two decades. And, given that most programmers don't stay
> in the same job for a decade, why would one expect them to plan for
> the future (other than style)?

The move from 16-bit to 32-bit Windows was doubly difficult, because of the
need to replace segment-based addressing with linear addressing. That is not
an issue with the 32-bit to 64-bit port. I think people are justifiably
disappointed in MS, because this one should've been smooth as silk. Their
kernel was ported quickly, but nothing else is being ported quickly.

I don't think it's entirely as a result of spaghetti code. I think it's also
as a result of some dufusy arbitrary decisions that MS made. For example,
they decided not support 16-bit protected mode apps in Win64, even though
the AMD64 architecture has no problems running either 16-bit or 32-bit
protected-mode apps in compatibility mode. They've also decided not to allow
the use of x87 FPU under 64-bit mode, relying solely on SSE, even though
AMD64 is perfectly fine with either or both; now I don't know if this is
actually going to be a problem to developers, but it does show that MS is
taking arbitrary decisions. Then it hasn't created a 32-bit to 64-bit device
driver thunking layer, which would've given device driver manufacturers an
additional amount of time to port full 64-bit drivers to Windows.

Yousuf Khan

Seongbae Park
August 6th 04, 06:38 PM
Yousuf Khan > wrote:
....
> I think it's also as a result of some dufusy arbitrary decisions that MS made.
> For example,
....
> They've also decided not to allow
> the use of x87 FPU under 64-bit mode, relying solely on SSE, even though
> AMD64 is perfectly fine with either or both; now I don't know if this is
> actually going to be a problem to developers, but it does show that MS is
> taking arbitrary decisions.
...

I think this particular decision is not without its merit,
so calling it arbitrary is too harsh.

It would make some people's life easier immediately
(e.g. compiler, math library, etc)
although I'll have to admit it is debatable how much easier.
In the longer term, they can drop the support in the ISA
to recover opcode space and avoid supporting cost in the chip.
It will take long time to be able to actually gain from this decision
but dropping them now when trasitioning to 64bit ABI
is much easier than trying to do it later.

For example, SPARC ABI should have outright *banned* the use of y register
(sdiv,udiv,rdy, etc) in the new 64bit (v9) or extended 32bit (v8plus),
but they just kept it for compatibility's sake.
They were declared "deprecated" but the new ABI didn't ban the use.
Since sdiv/udiv performed better than sdivx/udivx and was allowed in ABI,
compilers continue to use sdiv/udiv even in v8plus/v9.
And now it's much more difficult to remove.

All in all, I'm always in favor of dropping unnecessary instructions
from ABI - so that it can be dropped from the ISA later.
It's next to impossible to do this
without introducing major pain in the existing ABI,
so this 64bit transition of x86 is a good opportunity to drop
some mistakes of the past.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/"

Yousuf Khan
August 6th 04, 06:42 PM
Stephen Sprunk wrote:
> From a NUMA-aware scheduler's perspective, what's different between
> 2-way SMT and 2-way CMP?

It's not really the 2-ways that we're talking about here. We're talking
about the enterprise and datacentre classes, which would range from 4-way to
64-way or more. I think any old memory-organization model would do for 2-way
systems.

>> AMD is even suggesting not treating Hypertransport as NUMA but as
>> simple SMP is quite acceptable, and this suggestion is likely to
>> hold for dual-cores too (probably even more so).
>
> Once the bugs were worked out, Linux showed much better performance
> (for 2+ way Opeterons) when it was made NUMA-aware. Treating the
> system as simple SMP is acceptable, but demonstrably not optimal.

True, but Linux has been around right from the beginning, and they are well
beyond the first-cut stage of their kernel development. They are at the
optimize right down to the bone stage now.

Yousuf Khan

Paul Repacholi
August 6th 04, 07:05 PM
(Nick Maclaren) writes:

> And then think about how customers would react if told that the ONLY
> future platforms for HP-UX, VMS and NonStop had just been cancelled.
> Overjoyed isn't the word I would use ....

I supose they could drag out the dead and try to revive the Alpha, or
ask someone else to for VMS. Non-Stop has been advanced so as to
<flashingred>not require a lock-step CPU any more</flashingred>. PHUX
can crawl away and smell in a corner, it has nothing to offer over any
other unix. Less in many cases in fact.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

Nick Maclaren
August 6th 04, 09:20 PM
In article >,
Stephen Sprunk > wrote:
>
>From a NUMA-aware scheduler's perspective, what's different between 2-way
>SMT and 2-way CMP?

About ten times as much as the difference between two-way CMP and
dual CPUs on a board?

The point about CMP is that it is merely the latest stage in the
integration of multiple SMP CPUs. Many of us remember when each
such CPU was in a separate box and built out of multiple boards!
There is, however, little logical difference between them and two
CPUs on a die - the only question is the level at which they share
cache (including TLBs).

Eggers-style SMT is entirely different, and the two cores CAN'T be
scheduled as if they were separate CPUs. The timing issues are a
problem (think NTP), the Pentium 4 has the problem of a single set
of performance registers, but those pale into insignificance compared
with the problem of the mode of one CPU affecting another. I don't
know how serious this is for the Pentium 4, as the documents are not
trivially accessible, but there are a lot of place in the public
documents where I mentally raised a flag.

For example, consider the facility to switch between using both cores
and using a single double-speed one. This is not SOLELY decided by
the BIOS, and the first-level interrupt handler has to be aware of
the state and perhaps even control it. That, in turn, affects the
scheduler, because each core may generate an interrupt at any time.


Regards,
Nick Maclaren.

Nick Maclaren
August 6th 04, 09:22 PM
In article >,
Paul Repacholi > wrote:
(Nick Maclaren) writes:
>
>> And then think about how customers would react if told that the ONLY
>> future platforms for HP-UX, VMS and NonStop had just been cancelled.
>> Overjoyed isn't the word I would use ....
>
>I supose they could drag out the dead and try to revive the Alpha, or
>ask someone else to for VMS. Non-Stop has been advanced so as to
><flashingred>not require a lock-step CPU any more</flashingred>. PHUX
>can crawl away and smell in a corner, it has nothing to offer over any
>other unix. Less in many cases in fact.

Case (a): Quite.

Case (b): It would be interesting to know if any sacrifice of the
reliability was needed.

Case (c): If true, that is sad. I last used it with HP-UX 9, and
that was a very nice Unix.


Regards,
Nick Maclaren.

Andi Kleen
August 6th 04, 10:34 PM
"Stephen Sprunk" > writes:

> "Yousuf Khan" > wrote in message
> . rogers.com...
>> Stephen Sprunk wrote:
>> > Does an OS really need to be aware of the difference between two
>> > cores on the same chip?
>> >
>> > Linux has a concept of a NUMA "node", where all of the processors in
>> > a node are considered equivalent. It'll still try to schedule
>> > threads on the same CPU they last ran on, but next it will try other
>> > CPUs in the same node before giving up and sending it to any
>> > available node.
>> >
>> > IIRC, the code already understands two-CPU nodes, because that is how
>> > Intel's SMT chips are handled. Treating K8 CMP the same way sounds
>> > correct, once AMD releases specs on how to recognize dual-core chips.
>>
>> I'm sure as a first cut, not treating them specially is the right way to
> go.
>> But eventually everybody tries to optimize down to the bone.
>
> From a NUMA-aware scheduler's perspective, what's different between 2-way
> SMT and 2-way CMP?

The two cores in CMP are pretty independent. They have a shared
connection to the memory which causes some dependence, but that can be
ignored for scheduling because it is equivalent to the shared FSB in
most SMP systems and fair enough.

The threads in SMT slow each other down, which the scheduler may
want to take into account. Otherwise you get into situations where
low priority processes can slow down high priority processes.

Some SMT implementations like IBM's support setting priorities in
the hardware, but Intel's doesn't support that, so software has
to handle it.

>
>> AMD is even suggesting not treating Hypertransport as NUMA but as
>> simple SMP is quite acceptable, and this suggestion is likely to hold for
>> dual-cores too (probably even more so).
>
> Once the bugs were worked out, Linux showed much better performance (for 2+
> way Opeterons) when it was made NUMA-aware. Treating the system as simple
> SMP is acceptable, but demonstrably not optimal.

No, that's wrong. In fact we turned off the old NUMA scheduler support on
Opteron because it even made things worse. It was aimed at big NUMA
machines with slow interconnect, where low node balance rates
are good. But on a Opteron you want a fast NUMA balance rate,
it is best to treat it nearly like an SMP.

The new current Linux 2.6 kernel uses the new NUMA scheduler, but
it is still subject to more tuning and it may get turned off again.

-Andi

kal
August 7th 04, 12:28 AM
On Fri, 06 Aug 2004 16:46:51 GMT, "Yousuf Khan" >
wrote:

>as a result of some dufusy arbitrary decisions that MS made. For example,
>they decided not support 16-bit protected mode apps in Win64, even though
>the AMD64 architecture has no problems running either 16-bit or 32-bit
>protected-mode apps in compatibility mode.

I am not sure this is accurate. The issue with win16 is that some of
it still depends on the DOS (for file system etc.) so it needs the
virtual x86 mode too which is not supported in AMD64. So it is really
a technical issue which may also have been solved but that's another
topic.

George Macdonald
August 7th 04, 12:38 AM
On Thu, 05 Aug 2004 16:19:21 GMT, "Yousuf Khan" > wrote:

>George Macdonald wrote:
>> On Thu, 05 Aug 2004 04:22:13 GMT, "Dean Kent"
>>> As for George's argument, as usual it is a fallacy. It is called
>>> "argumentum ad ignorantium". Just because it cannot be proven to
>>> be false, does not mean that it is true. The burden of proof is
>>> upon those trying to make the claim. Public information says Intel
>>> did not intend to replace x86 anytime soon, so it will take a bit
>>> more than 'recollections' to make the case that they did. Sorry.
>>
>> As usual the Kentster's way of impolitely calling someone a liar...
>> and not only me. The roadmaps *did* exist! Were they official
>> roadmaps like those issued to the i-Stooges in your quixotic,
>> privileged position?... nope!
>> Were they published in magazines and Web sites?... yup! The evidence
>> has vanished along with bubble memory cheers and i860 effervescence -
>> seems
>> like you were not paying attention.
>
>We've now even dug up some old historical webpages (possibly written in
>parchment or papyrus or something) from the early days of the commercial
>Internet which states exactly why we thought Intel's plans were to go
>towards IA-64. Yet, he still needs to argue. Some people are just beyond
>quixotic!

I'd really like to find the original charts though -- multi-line graphs in
the typical Intel roadmap style -- which showed x86/IA32 petered out by
2005 in the PC space. They seem to be as extant as the success stories of
the notorious Intel i8089... though at least it did not have a coupla
billion $$ of "support" to prop it up.

Apparently he also thinks that insults in Latin phraseology cadged from his
favorite look-up table are somehow umm, dignified?... exempt from
contempt?:-)

At least I have had some success here... by having the extreme honor of
being killfiled and I suggest that the rest of you do your best to get
equal status from the err, Kentster!... before he skulks back off to his
UnReal World". Good luck with it... I can tell ya - it ain't easy.:-)

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

George Macdonald
August 7th 04, 12:38 AM
On Thu, 05 Aug 2004 14:32:25 GMT, "Hank Oredson" > wrote:

>"Yousuf Khan" > wrote in message
t.cable.rogers.com...
>> Keith wrote:
>>> On Wed, 04 Aug 2004 16:33:24 -0400, George Macdonald wrote:
>>>> Uhh, it's called spin.:-) The fact you or I can't find the
>>>> docs/pages to confirm the "recollections" does not mean they did not
>>>> exist. Nefarious is your term but I did see a roadmap which showed
>>>> x86 relegated to mostly STBs by 2005... after a steady year by year
>>>> decline in PCs.
>>>
>>> The charts I saw were Itanic to exceed x86 sales by 2003 and by '05
>>> x86 was relegated to the dust-bin of embedded losers. ...and that was
>>> in 1997ish. There was some discussion about this in AFC a few weeks
>>> ago (I'm not the only one remembering such).
>>
>> I think a lot of us can remember Intel's predictions about IA64 eventually
>> replacing IA32 by some point in time. You don't need some archival webpage
>> in order to prove it. Just the fact that so many of us who have been in
>> this
>> business for so long can recall these statements is more than enough.
>
>
>I'm sure most or even all of us remember these things.
>
>Some of the problem is in semantics: introduction, general
>availability, wide use, replacement. I take "replacing" to
>mean that IA32 is no longer available, and IA64 is used
>in all cases including embeded devices.

Nope and it's been stated umpteen times: the err, "semantics" are the
existence of x86 vs. IA64, in the *Intel* view circa 1998, of the 2005 *PC*
space, desktop in particular, included. The roadmaps I know I saw
specifically nominated x86 for the typical STB space in the mass market at
its PC EOL cycle... in 2005. Hell the 8085 is still a healthy technical
solution in its space.

>This is from an investment viewpoint: what I thought
>Intel was saying about the evolution of the portions
>of their product line that produced the most profit.
>
>But the fact that I think these things is probably rather
>uninteresting, since I cannot produce any actual
>documents that say the specific things I think will be true ;-)

"Ay, there's the rub".

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

Yousuf Khan
August 7th 04, 01:05 AM
kal wrote:
> On Fri, 06 Aug 2004 16:46:51 GMT, "Yousuf Khan" >
> wrote:
>
>> as a result of some dufusy arbitrary decisions that MS made. For
>> example, they decided not support 16-bit protected mode apps in
>> Win64, even though the AMD64 architecture has no problems running
>> either 16-bit or 32-bit protected-mode apps in compatibility mode.
>
> I am not sure this is accurate. The issue with win16 is that some of
> it still depends on the DOS (for file system etc.) so it needs the
> virtual x86 mode too which is not supported in AMD64. So it is really
> a technical issue which may also have been solved but that's another
> topic.

I don't think that's been the case since Windows 3.1. That's the version of
Windows that brought the "32-bit file system", which replaced all calls to
DOS and BIOS with protected mode Windows ones. Even if the app made a direct
call to DOS or BIOS, the 32-bit FS would handle the call.

Yousuf Khan

Yousuf Khan
August 7th 04, 03:56 AM
George Macdonald wrote:
> Apparently he also thinks that insults in Latin phraseology cadged
> from his favorite look-up table are somehow umm, dignified?... exempt
> from contempt?:-)
>
> At least I have had some success here... by having the extreme honor
> of being killfiled and I suggest that the rest of you do your best to
> get
> equal status from the err, Kentster!... before he skulks back off to
> his UnReal World". Good luck with it... I can tell ya - it ain't
> easy.:-)

It's too bad that his first act in coming back to the newsgroups is to try
to show that he's some kind of alpha male all over again, by picking fights.
And unfortunately he continuously picks fights over dead horses too.

Does it really matter if Intel didn't explicitly say that it was going to
kill x86? Of course, it's never going to say anything definitively about
something so far away, so there will always be plenty of wiggle room. Any
intelligent person can surmise that when the roadmap shows clear paths for
IA-64, but not so much for IA-32 that perhaps it was not expecting much to
happen beyond a certain point for that path. Intel's older roadmaps ended at
Foster and Northwood, but just kept going for Itanium. Saying, "we envision
we will continue making x86 processors into the future", is just a standard
"notwithstanding" clause.

Yousuf Khan

Casper H.S. Dik
August 7th 04, 03:18 PM
"Stephen Sprunk" > writes:

>AMD64 is just another platform, and the third (or higher) platform supported
>is of marginal cost compared to the second. The free software world has had
>to contend with dozens of platforms for over two decades, and so the fact
>Linux (and all the common apps) ported over cleanly is hardly surprising.


It's not really all that simple: while you can run a pure 64 bit OS on
AMD64, there are many Linux applications only available as "32-bit, IA32"
binaries. MS Windows for AMD64 has an even greater need to support all
those 32 bit app. Solaris for AMD64 will follow the same route as
Solaris for 64-bit SPARC: dual boot, and the ability to run unchanged 32
bit binaries in the 64 bit environment.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

Patrick Schaaf
August 7th 04, 03:24 PM
Casper H.S. Dik > writes:

>"Stephen Sprunk" > writes:

>>AMD64 is just another platform, and the third (or higher) platform supported
>>is of marginal cost compared to the second. The free software world has had
>>to contend with dozens of platforms for over two decades, and so the fact
>>Linux (and all the common apps) ported over cleanly is hardly surprising.

>It's not really all that simple: while you can run a pure 64 bit OS on
>AMD64, there are many Linux applications only available as "32-bit, IA32"
>binaries.

I don't see many of them on the ~1000 Linux systems I've got at work.
There are bound to be some commercial apps where that's the case,
but I'm sure Stephen was thinking about the ease for _open_source_software_
to be ported over.

Why worry about commercial apps? They are supposed to make money, let their
developing companies spend some on porting. If the open source developers
already could do it for free, where should the problem lie? :)

>Solaris for AMD64 will follow the same route as Solaris for 64-bit SPARC:
>dual boot, and the ability to run unchanged 32 bit binaries in the 64 bit
>environment.

Which is, of course, what Linux on AMD64 already and always provided,
decisions of _distributions_ wrt their development / library support
nonwithstanding.

best regards
Patrick

Andi Kleen
August 7th 04, 03:38 PM
Casper H.S. Dik > writes:

> "Stephen Sprunk" > writes:
>
>>AMD64 is just another platform, and the third (or higher) platform supported
>>is of marginal cost compared to the second. The free software world has had
>>to contend with dozens of platforms for over two decades, and so the fact
>>Linux (and all the common apps) ported over cleanly is hardly surprising.
>
>
> It's not really all that simple: while you can run a pure 64 bit OS on
> AMD64, there are many Linux applications only available as "32-bit, IA32"
> binaries. MS Windows for AMD64 has an even greater need to support all
> those 32 bit app. Solaris for AMD64 will follow the same route as
> Solaris for 64-bit SPARC: dual boot, and the ability to run unchanged 32
> bit binaries in the 64 bit environment.

Most Linux/x86-64 distributions support 32bit applications just
fine. The kernel certainly can run 32bit applications with very good
compatibility (I'm typing this on a Athlon64 running a 64bit kernel
with an old 32bit suse 8.1 userland). The 32bit emulation subsystem
is also very stable, because it is mostly shared now between many
other 64bit architectures, some of them using 32bit as their
primary user land.

There are unfortunately some more x86-64 linux distributions (let
unnamed) who chose to go the slightly easier route of not providing
32bit compatibility. This means they don't ship the 32bit libraries
and don't use the /lib64 <-> /lib separation to make it easy to
install 32bit programs into the 64bit system.

Of course even with them you can install a 32bit root into a chroot
and run your old programs in there, but it is not very nice solution
and makes administration more difficult.

I suppose the users will chose with their feet depending on if they
value 32bit compatibility or not.

-Andi

Douglas Siebert
August 7th 04, 11:35 PM
(Patrick Schaaf) writes:

>Casper H.S. Dik > writes:

>>"Stephen Sprunk" > writes:

>>>AMD64 is just another platform, and the third (or higher) platform supported
>>>is of marginal cost compared to the second. The free software world has had
>>>to contend with dozens of platforms for over two decades, and so the fact
>>>Linux (and all the common apps) ported over cleanly is hardly surprising.

>>It's not really all that simple: while you can run a pure 64 bit OS on
>>AMD64, there are many Linux applications only available as "32-bit, IA32"
>>binaries.

>I don't see many of them on the ~1000 Linux systems I've got at work.
>There are bound to be some commercial apps where that's the case,
>but I'm sure Stephen was thinking about the ease for _open_source_software_
>to be ported over.


Do the AMD64 versions of Redhat and SuSE recompile everything? It seems
kind to silly to have a 64 bit /bin/ls, for instance. They always left
most stuff for which performance didn't matter compiled as i386, and for
stuff where performance mattered (the kernel, openssl libraries, etc.)
there were i686 versions. I would assume it is the same way for AMD64
stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have
to do a lot more versions if they bugfix /bin/ls and have to compile a
64 bit version to go along with the i386 version!

--
Douglas Siebert

When hiring, avoid unlucky people, they are a risk to the firm. Do this by
randomly tossing out 90% of the resumes you receive without looking at them.

Andi Kleen
August 8th 04, 02:05 AM
Douglas Siebert > writes:
>
> Do the AMD64 versions of Redhat and SuSE recompile everything? It seems

Yes, they do.

(well mostly, the 32bit compat libraries are 32bit of course. And
there are a few programs left that are 32bit only, most noteable
of them is OpenOffice. Also usually only 32bit Java is available
because the 64bit version wasn't ready when the last releases were cut)

> kind to silly to have a 64 bit /bin/ls, for instance. They always left

One reason is that a 32bit /bin/ls uses a 32bit time_t and will return
bad dates after 2036.

And unlike on some other architecture 64bit AMD64 programs are not
significantly slower than their 32bit counterparts.

> most stuff for which performance didn't matter compiled as i386, and for
> stuff where performance mattered (the kernel, openssl libraries, etc.)
> there were i686 versions. I would assume it is the same way for AMD64
> stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have

You are wrong.

> to do a lot more versions if they bugfix /bin/ls and have to compile a
> 64 bit version to go along with the i386 version!

And a s390 version and a ia64 version and a ppc64 version and ...

Linux distributions already have the infrastructure in place to handle
multi architecture updates. Adding another architecture is only a very
small amount of additional work.

-Andi

Zalman Stern
August 8th 04, 05:56 AM
Douglas Siebert > wrote in message >...
> Do the AMD64 versions of Redhat and SuSE recompile everything?

The SuSE distro I last worked with (8.1 enterprise?) has 64-bit as the
default compilation environment. If you do a "make configure" you get
a 64-bit app. Thus the natural process of building a distro produces
all 64-bit commands.

(E.g. if one installs a 32-bit devel package RPM, it will not be found
for config purposes in the default 64-bit build environment.)

> It seems kind to silly to have a 64 bit /bin/ls, for instance.

"Silly" or "not necessary"? One would have to decide which commands
stay 32-bit on a command by command basis as some do benefit from the
better performance and increased address space. And having ls be
32-bit doesn't gain one much except allowing the same bits to be used
for the 64-bit and 32-bit versions. If one wants that, one can install
the 32-bit distro on top of the 64-bit kernel.

But if one values the executable bits being widely useable across
architectures, it seems silly to have native code for ls at all. All
the basic commands could be Java class files, .NET assemblies, dis
code, or Perl or Python scripts or whatever.

-Z-

Sander Vesik
August 17th 04, 07:20 AM
In comp.arch Yousuf Khan > wrote:
> Stephen Sprunk wrote:
> > M$ spent a lot of effort moving from 16-bit to 32-bit code, and it's
> > possible at the time they expected their code to be obsolete before
> > 64-bit systems took over -- 4GB is enough for anybody, right? I'm
> > sure they didn't expect their newly-ported 32-bit code to require
> > porting again in less than a decade, given 16-bit x86 code had been
> > around for two decades. And, given that most programmers don't stay
> > in the same job for a decade, why would one expect them to plan for
> > the future (other than style)?
>
> The move from 16-bit to 32-bit Windows was doubly difficult, because of the
> need to replace segment-based addressing with linear addressing. That is not
> an issue with the 32-bit to 64-bit port. I think people are justifiably
> disappointed in MS, because this one should've been smooth as silk. Their
> kernel was ported quickly, but nothing else is being ported quickly.

Umm... Note that WinNT was never 16 bit and that parts of code were
AFAICT always shared with Win9x.

>
> I don't think it's entirely as a result of spaghetti code. I think it's also
> as a result of some dufusy arbitrary decisions that MS made. For example,
> they decided not support 16-bit protected mode apps in Win64, even though
> the AMD64 architecture has no problems running either 16-bit or 32-bit
> protected-mode apps in compatibility mode. They've also decided not to allow
> the use of x87 FPU under 64-bit mode, relying solely on SSE, even though
> AMD64 is perfectly fine with either or both; now I don't know if this is
> actually going to be a problem to developers, but it does show that MS is
> taking arbitrary decisions. Then it hasn't created a 32-bit to 64-bit device
> driver thunking layer, which would've given device driver manufacturers an
> additional amount of time to port full 64-bit drivers to Windows.

Its not an *arbitrary* decision - once you look at the POV of "we are
doing a new ABI, hey compiler folks, whats the best thing?" doing it
this way makes sense.

>
> Yousuf Khan
>
>

--
Sander

+++ Out of cheese error +++

Sander Vesik
August 17th 04, 07:25 AM
In comp.arch Yousuf Khan > wrote:
> kal wrote:
> > On Fri, 06 Aug 2004 16:46:51 GMT, "Yousuf Khan" >
> > wrote:
> >
> >> as a result of some dufusy arbitrary decisions that MS made. For
> >> example, they decided not support 16-bit protected mode apps in
> >> Win64, even though the AMD64 architecture has no problems running
> >> either 16-bit or 32-bit protected-mode apps in compatibility mode.
> >
> > I am not sure this is accurate. The issue with win16 is that some of
> > it still depends on the DOS (for file system etc.) so it needs the
> > virtual x86 mode too which is not supported in AMD64. So it is really
> > a technical issue which may also have been solved but that's another
> > topic.
>
> I don't think that's been the case since Windows 3.1. That's the version of
> Windows that brought the "32-bit file system", which replaced all calls to
> DOS and BIOS with protected mode Windows ones. Even if the app made a direct
> call to DOS or BIOS, the 32-bit FS would handle the call.

It was slightly more complex given that you could have "16 bit disk drivers"
so the call might still make it back to some non-32bit gunk after the FS.

>
> Yousuf Khan
>
>

--
Sander

+++ Out of cheese error +++

Yousuf Khan
August 17th 04, 08:09 AM
"Sander Vesik" > wrote in message
...
> > I don't think that's been the case since Windows 3.1. That's the version
of
> > Windows that brought the "32-bit file system", which replaced all calls
to
> > DOS and BIOS with protected mode Windows ones. Even if the app made a
direct
> > call to DOS or BIOS, the 32-bit FS would handle the call.
>
> It was slightly more complex given that you could have "16 bit disk
drivers"
> so the call might still make it back to some non-32bit gunk after the FS.

I doubt that. Even if they were 16-bit disk drivers, they were *protected
mode* 16-bit disk drivers, so there was no need to transition through a
Virtual-8086 task gate.

The call to V86 was the real killer of performance. An OS call would result
in going to Ring 0 protected mode kernel and drivers, but then that driver
would really be a wrapper of a DOS or BIOS function, and that would result
in executing code in Ring 3 with continuous back and forth monitoring by the
Ring 0 code.

Yousuf Khan

Sander Vesik
August 17th 04, 12:59 PM
In comp.arch Douglas Siebert > wrote:
> (Patrick Schaaf) writes:
>
> >Casper H.S. Dik > writes:
>
> >>"Stephen Sprunk" > writes:
>
> >>>AMD64 is just another platform, and the third (or higher) platform supported
> >>>is of marginal cost compared to the second. The free software world has had
> >>>to contend with dozens of platforms for over two decades, and so the fact
> >>>Linux (and all the common apps) ported over cleanly is hardly surprising.
>
> >>It's not really all that simple: while you can run a pure 64 bit OS on
> >>AMD64, there are many Linux applications only available as "32-bit, IA32"
> >>binaries.
>
> >I don't see many of them on the ~1000 Linux systems I've got at work.
> >There are bound to be some commercial apps where that's the case,
> >but I'm sure Stephen was thinking about the ease for _open_source_software_
> >to be ported over.
>
>
> Do the AMD64 versions of Redhat and SuSE recompile everything? It seems
> kind to silly to have a 64 bit /bin/ls, for instance. They always left
> most stuff for which performance didn't matter compiled as i386, and for
> stuff where performance mattered (the kernel, openssl libraries, etc.)
> there were i686 versions. I would assume it is the same way for AMD64
> stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have
> to do a lot more versions if they bugfix /bin/ls and have to compile a
> 64 bit version to go along with the i386 version!
>

It really depends on if AMD64 is being treated as an extension of
x86 or no. decising that no, you are just going to treat it as a
64 pltaform where the native ABI is x86-64 and that is what userland
uses by default is a valid decision. Especially if you dont plan on
running anything legacy.

--
Sander

+++ Out of cheese error +++

Yousuf Khan
August 17th 04, 04:16 PM
Sander Vesik > wrote:
> In comp.arch Yousuf Khan > wrote:
>> The move from 16-bit to 32-bit Windows was doubly difficult, because
>> of the need to replace segment-based addressing with linear
>> addressing. That is not an issue with the 32-bit to 64-bit port. I
>> think people are justifiably disappointed in MS, because this one
>> should've been smooth as silk. Their kernel was ported quickly, but
>> nothing else is being ported quickly.
>
> Umm... Note that WinNT was never 16 bit and that parts of code were
> AFAICT always shared with Win9x.

The move from 16-bit to 32-bit Windows didn't happen with Windows NT, it
happened during the time of Windows 3.x. Windows 3.x was the bridge between
16-bit and 32-bit. The Windows 9X/ME series was a continuation of that
bridging system.

Windows NT was supposed to be what those operating systems bridged
themselves to. As it turned out, that is exactly what happened, but it
didn't happen right away. The bridging OSes survived for a long, long time,
and Windows NT evolved into Windows 2000 and finally XP, before the
transition was finally complete.

Yousuf Khan

Nick Roberts
August 18th 04, 02:54 PM
On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan > wrote:

> The move from 16-bit to 32-bit Windows didn't happen with Windows NT,
> it happened during the time of Windows 3.x. Windows 3.x was the
> bridge between 16-bit and 32-bit. The Windows 9X/ME series was a
> continuation of that bridging system.

I don't think that's strictly correct. My memory is that Windows 95
was itself the first Windows which supported 32-bit code, when it was
launched (in 1995 ;-) The immediately prior version of Windows was
3.11, which was 16-bit only (and ran on top of MS-DOS).

Microsoft was banking on most customers immediately switching to
Windows 95. However, a lot of people (including corporate customers)
did not do this, so demand for a way to run Win32 programs under
Windows 3.1x built, and Microsoft quite quickly brought out the
Win32s API (which thunks the 32-bit calls to 16-bit ones).

> Windows NT was supposed to be what those operating systems bridged
> themselves to. As it turned out, that is exactly what happened, but
> it didn't happen right away. The bridging OSes survived for a long,
> long time, and Windows NT evolved into Windows 2000 and finally XP,
> before the transition was finally complete.

I think that's about right, but greatly shortens a very long and
convoluted story. Apparently the NT project actually began in the
late 1980s, and the theme of the ensuing saga seems to be that
Microsoft were permanently struggling to find a place for NT in
their marketing strategies (and failing, until XP).

However, my comments are of a punter, and not vaguely authoritative.

--
Nick Roberts

Dean Kent
August 18th 04, 04:04 PM
"Nick Roberts" > wrote in message
news:[email protected]
> On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan > wrote:
>
> I don't think that's strictly correct. My memory is that Windows 95
> was itself the first Windows which supported 32-bit code, when it was
> launched (in 1995 ;-) The immediately prior version of Windows was
> 3.11, which was 16-bit only (and ran on top of MS-DOS).
>
> Microsoft was banking on most customers immediately switching to
> Windows 95. However, a lot of people (including corporate customers)
> did not do this, so demand for a way to run Win32 programs under
> Windows 3.1x built, and Microsoft quite quickly brought out the
> Win32s API (which thunks the 32-bit calls to 16-bit ones).

I seem to recall that Win32S was made available prior to Win95, but I may be
mistaken. It seemed to be a 'transition' tool so that developers could
start writing '32 bit' code that would run under Win95 when it arrived (and
perhaps WinNT).

>
> I think that's about right, but greatly shortens a very long and
> convoluted story. Apparently the NT project actually began in the
> late 1980s, and the theme of the ensuing saga seems to be that
> Microsoft were permanently struggling to find a place for NT in
> their marketing strategies (and failing, until XP).

I seem to recall that the WinNT effort followed the failed OS/2 partnership
with IBM. I think it was specifically meant to replace OS/2 1.1 (or 1.2,
whichever was the last MS release). This brings me back to my original
assertion - WinNT was not written to be portable, nor to be upgradable. It
was written to be 32-bit. I find it difficult to believe that in their
haste to come out with WinNT that the MS developers took into consideration
the chance that they might have to run on different platforms. If there
was one code base, I think there would not be the 'problem' of supporting
multiple platforms. Consider DB2, which *was* written with portability in
mind. It took several weeks (or perhaps several days) to port it to x86-64,
and it runs on virtually every platform imaginable specifically because of
this.

>
> However, my comments are of a punter, and not vaguely authoritative.

Ditto...

Regards,
Dean


>
> --
> Nick Roberts

Florian Laws
August 18th 04, 04:25 PM
Dean Kent > wrote:
>>
>> I think that's about right, but greatly shortens a very long and
>> convoluted story. Apparently the NT project actually began in the
>> late 1980s, and the theme of the ensuing saga seems to be that
>> Microsoft were permanently struggling to find a place for NT in
>> their marketing strategies (and failing, until XP).
>
>I seem to recall that the WinNT effort followed the failed OS/2 partnership
>with IBM. I think it was specifically meant to replace OS/2 1.1 (or 1.2,
>whichever was the last MS release). This brings me back to my original
>assertion - WinNT was not written to be portable, nor to be upgradable. It
>was written to be 32-bit. I find it difficult to believe that in their
>haste to come out with WinNT that the MS developers took into consideration
>the chance that they might have to run on different platforms.

WinNT did in fact run on four different Platforms:
i386, MIPS, PowerPC and Alpha. (all 32-bit little-endian, though)

Regards,

Florian

Rob Stow
August 18th 04, 05:13 PM
Dean Kent wrote:
> "Nick Roberts" > wrote in message
> news:[email protected]
>
>>On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan > wrote:
>>
>>I don't think that's strictly correct. My memory is that Windows 95
>>was itself the first Windows which supported 32-bit code, when it was
>>launched (in 1995 ;-) The immediately prior version of Windows was
>>3.11, which was 16-bit only (and ran on top of MS-DOS).
>>
>>Microsoft was banking on most customers immediately switching to
>>Windows 95. However, a lot of people (including corporate customers)
>>did not do this, so demand for a way to run Win32 programs under
>>Windows 3.1x built, and Microsoft quite quickly brought out the
>>Win32s API (which thunks the 32-bit calls to 16-bit ones).
>
>
> I seem to recall that Win32S was made available prior to Win95, but I may be
> mistaken. It seemed to be a 'transition' tool so that developers could
> start writing '32 bit' code that would run under Win95 when it arrived (and
> perhaps WinNT).

I have a slightly different recollection of Win32S.

When Win95 came out, MicroSoft told developers that if they
wanted to put the Windows logo on their packaging or to
call their software Windows compatible, then it had to be
able to run on all three platforms: 3.x, 95, and NT.
Win32S was more or less a thunking layer that let 32 bit
code made for 95 and NT run on the 16 bit Windows 3.x.

>>I think that's about right, but greatly shortens a very long and
>>convoluted story. Apparently the NT project actually began in the
>>late 1980s, and the theme of the ensuing saga seems to be that
>>Microsoft were permanently struggling to find a place for NT in
>>their marketing strategies (and failing, until XP).

Personally I thought W2K was a roaring success for MicroSoft.
>
>
> I seem to recall that the WinNT effort followed the failed OS/2 partnership
> with IBM.

In some ways it is the *cause* of that failed partnership.
MicroSoft made no secret of the fact that they were
*simultaneously* working on NT and OS/2 - which led to
a lot of acrimony between IBM and MS. IBM resented
that MS was diverting resources from the OS/2 project,
and IBM also did what they could to prevent MS from using
OS/2 ideas/techniques/code/etc in the development of NT.

Some of the many long delays for OS/2 were attributed to
the fact that the IBMers did not want to share any more
code than they had to with MS - for fear that MS would
abuse their relationship with IBM and use that code for
NT. This meant that often the MS developers working on
OS/2 were kept in the dark about things they needed to know.


As well, I have heard another side of the story about MS
"rushing" to beat OS/2. Seems that perhaps it was not
so much that MS was rushing, but that IBM was doing too
much foot dragging - which is one of the things that caused
MS to start their NT project. Apparently IBM was aiming
for cross-platform perfection while MS wanted to settle for
a "good enough" x86 version, put the OS on the market, and
start recovering some of those development costs. MicroSoft's
pockets weren't nearly as deep back then as they are today -
they were deeply in the hole over OS/2 and badly needed to start
seeing revenue from the investment they had made.

> I think it was specifically meant to replace OS/2 1.1 (or 1.2,
> whichever was the last MS release). This brings me back to my original
> assertion - WinNT was not written to be portable, nor to be upgradable. It
> was written to be 32-bit. I find it difficult to believe that in their
> haste to come out with WinNT that the MS developers took into consideration
> the chance that they might have to run on different platforms. If there
> was one code base, I think there would not be the 'problem' of supporting
> multiple platforms. Consider DB2, which *was* written with portability in
> mind. It took several weeks (or perhaps several days) to port it to x86-64,
> and it runs on virtually every platform imaginable specifically because of
> this.
>
>
>>However, my comments are of a punter, and not vaguely authoritative.

Mine aren't any more authorative. I was a programer back
in those days and IBM and MS were stabbing each other in
the back as they tried to lure programmers towards developing
for either OS/2 or NT. Each side spread a lot of nasty
rumours about the other side and it was pretty hard to find
a few nuggets of truth in all of that sh*t.

Yousuf Khan
August 18th 04, 05:57 PM
Nick Roberts wrote:
> On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan > wrote:
>
>> The move from 16-bit to 32-bit Windows didn't happen with Windows NT,
>> it happened during the time of Windows 3.x. Windows 3.x was the
>> bridge between 16-bit and 32-bit. The Windows 9X/ME series was a
>> continuation of that bridging system.
>
> I don't think that's strictly correct. My memory is that Windows 95
> was itself the first Windows which supported 32-bit code, when it was
> launched (in 1995 ;-) The immediately prior version of Windows was
> 3.11, which was 16-bit only (and ran on top of MS-DOS).
>
> Microsoft was banking on most customers immediately switching to
> Windows 95. However, a lot of people (including corporate customers)
> did not do this, so demand for a way to run Win32 programs under
> Windows 3.1x built, and Microsoft quite quickly brought out the
> Win32s API (which thunks the 32-bit calls to 16-bit ones).

No, Win32S was available long before Windows 95 ever came out (remember
Windows 95 itself was greatly delayed). It sort of served as a "preview" of
the functionality to come with Windows 95 and beyond. Not that Win32S was an
API greatly used to during its time, but it was there nonetheless. It
allowed programs to use more than 16MB of memory (i.e. the limit of 16-bit
286 Protected Mode).

Also even ignoring the Win32S API, Windows 3.1 and beyond itself had quite a
few 32-bit drivers, such as the filesystem and the disksystem. There was a
combination of 16-bit and 32-bit protected mode drivers running under
Windows 3.x already. Plus the Windows 3.x kernel itself was 32-bit in
Enhanced Mode (remember that Standard Mode vs. Enhanced Mode stuff that used
to exist back then?). In Enhanced mode, it was able make use of paging and
Virtual-8086 mode for multitasking DOS programs underneath it; both of these
Enhanced Mode features required that the OS be designed for the 386 or later
processors, it wouldn't work on earlier non-32-bit processors.

Yousuf Khan

Yousuf Khan
August 18th 04, 06:41 PM
Dean Kent wrote:
> I seem to recall that Win32S was made available prior to Win95, but I
> may be mistaken. It seemed to be a 'transition' tool so that
> developers could start writing '32 bit' code that would run under
> Win95 when it arrived (and perhaps WinNT).

Yup.

> I seem to recall that the WinNT effort followed the failed OS/2
> partnership with IBM. I think it was specifically meant to replace
> OS/2 1.1 (or 1.2, whichever was the last MS release). This brings me
> back to my original assertion - WinNT was not written to be portable,
> nor to be upgradable. It was written to be 32-bit. I find it
> difficult to believe that in their haste to come out with WinNT that
> the MS developers took into consideration the chance that they might
> have to run on different platforms.

Actually, I think it was meant to be the next generation of VMS. Remember it
was Dave Cutler who spearheaded this project after coming over from DEC to
Microsoft. At DEC he spearheaded VMS, and at Microsoft he wanted to do it
one better.

The "one better" in this case meant that he wanted NT to be more portable
than VMS was at the time (it was originally just a VAX OS, then at great
effort it was ported to become an Alpha OS, now it's been ported to
Itanium).

And yes, Microsoft's own goal was to make NT one better than OS/2 too. So
each conspirator (Cutler & Microsoft) had their own goal posts in mind.

Yousuf Khan

Paul Repacholi
August 18th 04, 08:59 PM
(Florian Laws) writes:

> Dean Kent > wrote:

>>> I think that's about right, but greatly shortens a very long and
>>> convoluted story. Apparently the NT project actually began in the
>>> late 1980s, and the theme of the ensuing saga seems to be that
>>> Microsoft were permanently struggling to find a place for NT in
>>> their marketing strategies (and failing, until XP).

>>I seem to recall that the WinNT effort followed the failed OS/2
>>partnership with IBM. I think it was specifically meant to replace
>>OS/2 1.1 (or 1.2, whichever was the last MS release). This brings
>>me back to my original assertion - WinNT was not written to be
>>portable, nor to be upgradable. It was written to be 32-bit. I
>>find it difficult to believe that in their haste to come out with
>>WinNT that the MS developers took into consideration the chance that
>>they might have to run on different platforms.

> WinNT did in fact run on four different Platforms: i386, MIPS,
> PowerPC and Alpha. (all 32-bit little-endian, though)

NT, aka MICA was 64 bit from day one. It was a VMS derivitive for
Prism, the Alpha predescessor. (An inside joke, AXP stands for Almost
eXactly Prism. Not totally far from the truth!)

Windows was DEFINED to be 32 bit. Except for the many 16 bit
leftovers! PPros showed them up very quickly. SO all of the Windows
defined APIs had to also be 32 bit, and still are.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

G
August 18th 04, 10:42 PM
"Nick Roberts" > wrote in message news:<[email protected]>...
> On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan > wrote:
>
> > The move from 16-bit to 32-bit Windows didn't happen with Windows NT,
> > it happened during the time of Windows 3.x. Windows 3.x was the
> > bridge between 16-bit and 32-bit. The Windows 9X/ME series was a
> > continuation of that bridging system.
>
> I don't think that's strictly correct. My memory is that Windows 95
> was itself the first Windows which supported 32-bit code, when it was
> launched (in 1995 ;-) The immediately prior version of Windows was
> 3.11, which was 16-bit only (and ran on top of MS-DOS).

That's pretty oversimplified. There were things running before Win95
that took advantage of the 386. EMM386.exe (and HiMem.sys ?) did some
funky things to give DOS apps more breathing room. Plus I seem to
recall that the actual implementation of the local/global heap code
was different on a 386. There was definitely a different version of
kernel.dll if you were on a 386.

But all that was hidden at the API level wich was strictly 16-bit.
Pointers to API calls were defined as DWORD I believe? I suppose that
you could argue from an academic perspective that "handles" were
bit-independent though.

> Microsoft was banking on most customers immediately switching to
> Windows 95. However, a lot of people (including corporate customers)
> did not do this, so demand for a way to run Win32 programs under
> Windows 3.1x built, and Microsoft quite quickly brought out the
> Win32s API (which thunks the 32-bit calls to 16-bit ones).

Actually I don't think there was any external demand for this.
Microsoft wanted to force everyone to upgrade to the new 32-bit
development environment, and end-of-life VC++ 1.52. They couldn't get
corporate developers who were working in a Win 3.x only shop to
abandon good old 1.52 without the ability to run what they built on
their users' machines. So you're correct that it was indirectly
related to the slow uptake of Win95, but not driven by market demand
as much as MS's own agenda to jump start 32 bit development. They new
only too well from OS/2 what happens when people don't write native
apps for your shiny new OS, but just use it as a more convenient way
to run older apps.

> > Windows NT was supposed to be what those operating systems bridged
> > themselves to. As it turned out, that is exactly what happened, but
> > it didn't happen right away. The bridging OSes survived for a long,
> > long time, and Windows NT evolved into Windows 2000 and finally XP,
> > before the transition was finally complete.
>
> I think that's about right, but greatly shortens a very long and
> convoluted story. Apparently the NT project actually began in the
> late 1980s, and the theme of the ensuing saga seems to be that
> Microsoft were permanently struggling to find a place for NT in
> their marketing strategies (and failing, until XP).

I think it also had to do with there being no "clean" cut-off point.
Alot of the crappier stuff in Win9x was there for the greatest
possible backward compatibility. Remember this was a time when there
was no DirectX, and games wrote directly to the hardware (and often
required "quiting" Windows entirely in order to run). Device drivers
stayed 16 bit for a LONG time. I bought a brand new HP scanner in 1998
that *still* used a 16 bit driver and wrote directly to the parallel
port.

Dean Kent
August 19th 04, 04:14 AM
"Florian Laws" > wrote in message
...

>
> WinNT did in fact run on four different Platforms:
> i386, MIPS, PowerPC and Alpha. (all 32-bit little-endian, though)

Yes, but were they written with a 'port' to 64 bit addressing in mind (seems
from your comment that the answer to the latter question would be no). I am
also curious as to whether all of these were entirely different code bases,
or if they shared a lot of code with some 'flags' to determine which
libraries/routines/includes/macros/whatever to compile with (not sure how it
works with C, as I am more familiar with COBOL or S/390 assembler).

Regards,
Dean

>
> Regards,
>
> Florian

Dean Kent
August 19th 04, 04:14 AM
"Paul Repacholi" > wrote in message
...
> (Florian Laws) writes:
>
>
> NT, aka MICA was 64 bit from day one. It was a VMS derivitive for
> Prism, the Alpha predescessor. (An inside joke, AXP stands for Almost
> eXactly Prism. Not totally far from the truth!)
>
> Windows was DEFINED to be 32 bit. Except for the many 16 bit
> leftovers! PPros showed them up very quickly. SO all of the Windows
> defined APIs had to also be 32 bit, and still are.

Apologies for being dense - but when you say "Windows was defined to be 32
bit" are you referring to Win95, or all flavors of Windows? If the latter,
how is that to be reconciled with your first statement?

Regards,
Dean

>
> --
> Paul Repacholi 1 Crescent Rd.,
> +61 (08) 9257-1001 Kalamunda.
> West Australia 6076
> comp.os.vms,- The Older, Grumpier Slashdot
> Raw, Cooked or Well-done, it's all half baked.
> EPIC, The Architecture of the future, always has been, always will be.

Ken Hagan
August 19th 04, 09:40 AM
Nick Roberts wrote:
>
> I don't think that's strictly correct. My memory is that Windows 95
> was itself the first Windows which supported 32-bit code, when it was
> launched (in 1995 ;-) The immediately prior version of Windows was
> 3.11, which was 16-bit only (and ran on top of MS-DOS).

The first version of NT (1991?) called itself Windows 3.1. It had its
faults, but it was 32-bit all the way through and more robust than
any DOS based Windows either before or after. On anything other than
minimum hardware it was faster too. Since any sane application ran
fine on it, I consider it a version of Windows.

Sadly, drivers were another matter. Every version of Windows 3x or
9x from that point on existed merely to support hardware that didn't
have an NT driver. (IIRC, for each of Win31, 95, 98 and ME, Microsoft
stated at the time of release that it would be the last such version.)

Microsoft designed Win31 (the DOS version) with some hooks in the
loader which allowed them to offer Win32s very soon after. Win32s
made it attractive for people like me to write 32-bit software even
though none of my customers had a 32-bit OS. As a result, Win95 had
an installed base of applications even before it was released and
OS/2 never had one, at all, ever. (Ducks for cover.)

All of which preceded Win95 by 2 or 3 years.

David Brown
August 19th 04, 01:22 PM
"Dean Kent" > wrote in message
...
> "Nick Roberts" > wrote in message
> news:[email protected]
> > On Tue, 17 Aug 2004 15:16:31 GMT, Yousuf Khan > wrote:
> >
> > I don't think that's strictly correct. My memory is that Windows 95
> > was itself the first Windows which supported 32-bit code, when it was
> > launched (in 1995 ;-) The immediately prior version of Windows was
> > 3.11, which was 16-bit only (and ran on top of MS-DOS).
> >
> > Microsoft was banking on most customers immediately switching to
> > Windows 95. However, a lot of people (including corporate customers)
> > did not do this, so demand for a way to run Win32 programs under
> > Windows 3.1x built, and Microsoft quite quickly brought out the
> > Win32s API (which thunks the 32-bit calls to 16-bit ones).
>
> I seem to recall that Win32S was made available prior to Win95, but I may
be
> mistaken. It seemed to be a 'transition' tool so that developers could
> start writing '32 bit' code that would run under Win95 when it arrived
(and
> perhaps WinNT).
>

Win32S was available before Win95, as was NT 3.51 (I believe NT 3.5 was the
first easily-availble version of NT - marketing's idea of persuading people
that it was a mature product). Win32s implemented some of the Win32 api
from NT - it allowed programs to use a full 32-bit address space, but did
not support multi-tasking. It was mainly used for "big" programs, like CAD,
or development tools, which could take advantage of the better memory
management. Back in the days when MS made at least a token attempt at
pretending they could co-operate with other people, the aim was that Win32s
would be a portable api for use on Win3.1, NT, and Win95 (which was due out
"real soon now"), along with other systems including OS/2 and unix systems.
Of course, after giving IBM a license to put win32s 1.25 into OS/2 Warp, MS
immediately upped the version number to 1.30 (the version number being the
only real change) so that new win32s programs would refuse to run on OS/2.

Incidently, the only win32s program MS ever made, AFAIK, was freecell.

> >
> > I think that's about right, but greatly shortens a very long and
> > convoluted story. Apparently the NT project actually began in the
> > late 1980s, and the theme of the ensuing saga seems to be that
> > Microsoft were permanently struggling to find a place for NT in
> > their marketing strategies (and failing, until XP).
>
> I seem to recall that the WinNT effort followed the failed OS/2
partnership

WinNT caused the failure - MS realised that they did not have full control
of OS/2, so they started the WinNT project behind IBM's back, with a fair
amount in common at the base (which they were legally allowed to do). NT
has far more in common with OS/2 in its guts than it does with VMS.

> with IBM. I think it was specifically meant to replace OS/2 1.1 (or 1.2,
> whichever was the last MS release). This brings me back to my original
> assertion - WinNT was not written to be portable, nor to be upgradable.
It
> was written to be 32-bit. I find it difficult to believe that in their

WinNT was written to be 32-bit - it followed mainly from OS/2 2.0 (the
original OS/2 1.x was 16-bit, in common with Win3.x). But it was written to
be portable, within certain restrictions - it required a 32-bit
little-endian cpu. It ran on PowerPCs, MIPs (this was in fact the main
platform for NT), Alpha, and x86. Even though all but the x86 had 64-bit
variants, and all ran best in big-endian rather than little-endian mode,
WinNT stuck to 32-bit little-endian.

> haste to come out with WinNT that the MS developers took into
consideration
> the chance that they might have to run on different platforms. If there
> was one code base, I think there would not be the 'problem' of supporting
> multiple platforms. Consider DB2, which *was* written with portability
in
> mind. It took several weeks (or perhaps several days) to port it to
x86-64,
> and it runs on virtually every platform imaginable specifically because of
> this.
>

Porting applications between architectures is not nearly as much work as
porting an OS. Original windows (Win3.x, then Win9x) has had lots of
architecture-specific code and assembly language scattered randomly about
the code base, making them a porting nightmare. Original NT 3.5 was nicely
modular, with the main code in C and only a few specific bits being
architecture-specific. This made it fairly easily portable. The same
applies to Linux, *bsd, etc. NT 4.0 onwards re-introduced the spagetti
organisation, as code (in particular, graphics code) was made
architecture-specific in the name of performance. Thus the NT platforms
died one after one as the maintainance costs sky-rocketed, and the cpu
manufacturers refused to pay MS' development costs.

Porting applications, on the other hand, is far easier. You have to
consider the effect of having 64-bit integers, and you might have to
consider endian issues, but mostly (if the original code is well-written)
its a matter of re-compiling and testing the new binary.


> >
> > However, my comments are of a punter, and not vaguely authoritative.
>
> Ditto...
>
> Regards,
> Dean
>
>
> >
> > --
> > Nick Roberts
>
>
>

Paul Repacholi
August 19th 04, 02:46 PM
"Dean Kent" > writes:

> "Paul Repacholi" > wrote in message
> ...

>> NT, aka MICA was 64 bit from day one. It was a VMS derivitive for
>> Prism, the Alpha predescessor. (An inside joke, AXP stands for
>> Almost eXactly Prism. Not totally far from the truth!)

>> Windows was DEFINED to be 32 bit. Except for the many 16 bit
>> leftovers! PPros showed them up very quickly. SO all of the Windows
>> defined APIs had to also be 32 bit, and still are.

> Apologies for being dense - but when you say "Windows was defined to
> be 32 bit" are you referring to Win95, or all flavors of Windows?
> If the latter, how is that to be reconciled with your first
> statement?

WindowsNT on, not the Windows 3.x or earlier, they where 16 bit
through out as far as I could see.

It was not a clean cut though, there was a lot of 16 bit code in
Windows from NT 3.5 and 3.51. NT 4.0 had lots less, but also NT and
Windows where now totally welded together. My memory of the times
was that NT was the future way, and all others where to go.

Win 95 was still a DOS based system, but with a curtin pulled over the
DOS parts. You have to dig to find it, but much of it is still there.
Don't know about ME, thank god!

2000 was ready to go to the Win64 interface on Alpha but was stopped
from proceding by M$.

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

Dean Kent
August 20th 04, 04:16 AM
"David Brown" > wrote in message
...
>
>
> Porting applications, on the other hand, is far easier. You have to
> consider the effect of having 64-bit integers, and you might have to
> consider endian issues, but mostly (if the original code is well-written)
> its a matter of re-compiling and testing the new binary.
>

Well, I am not an OS developer - but I do work on system level applications
(requiring hooks into the OS, use of low-level OS services, etc.). It
seems to me that the biggest problem for the OS is the compatibility with
existing applications. There will be control blocks (structures, whatever)
and APIs that include addresses to data areas, calls to communicate with
other programs, etc. You can't just change the size of the address areas
for two reasons - the offsets for following data areas would change
(requiring all applications using that structure/control block to be
recompiled), and you have no idea if the applications using it can actually
use the 'bigger' addresses. It also seems to me that you would have to
include a mechanism whereby the OS knows whether the application is running
32-bit or 64-bit to make sure it doesn't allocate memory where the
application can't access it - and it can't load the program in an address
range it can't handle. The calls to other modules would have to include a
mechanism whereby programs running in different addressing modes can still
pass parameters and data to each other without causing major problems and
crashes.

IOW, moving an OS to 64-bit would not only require changing integer sizes
and recompiling, but actually redefining the interfaces to work with both
32-bit and 64-bit programs (perhaps even mixed addressing modes). Making
sure all of this works would be a huge undertaking, and could create
situations where 95% of the code works fine, but a few critical apps have
major problems that delay the OS release.

Backwards compatibility matters, particularly in an environment where the OS
vendor has support issues to deal with and wants to control what is running
in the field. It may not be as big an issue with Linux (or may be), since
there are no support issues to deal with and there is no attempt to control
what is running in the field. "Want a 32-bit OS? Fine, run an older
kernel - or someone else's 64-bit kernel that has support for it."

At least, it works that way in the environment I am familiar with (not
Windows or Unix... :-).

Regards,
Dean

Dean Kent
August 20th 04, 04:20 AM
"Paul Repacholi" > wrote in message
...
>
> 2000 was ready to go to the Win64 interface on Alpha but was stopped
> from proceding by M$.

Is it your understanding that this is the basis for the current 64-bit
Windows implementation? Also, out of curiosity (as I don't work on
Windows), are there updated APIs for 64-bit applications that are backwards
compatibile with the 32-bit ones - or has MS somehow designed their
interfaces/control blocks/etc. so that this isn't a concern?

Regards
Dean

>
> --
> Paul Repacholi 1 Crescent Rd.,
> +61 (08) 9257-1001 Kalamunda.
> West Australia 6076
> comp.os.vms,- The Older, Grumpier Slashdot
> Raw, Cooked or Well-done, it's all half baked.
> EPIC, The Architecture of the future, always has been, always will be.

Thor Lancelot Simon
August 20th 04, 06:06 AM
In article >,
Ken Hagan > wrote:
>Nick Roberts wrote:
>>
>> I don't think that's strictly correct. My memory is that Windows 95
>> was itself the first Windows which supported 32-bit code, when it was
>> launched (in 1995 ;-) The immediately prior version of Windows was
>> 3.11, which was 16-bit only (and ran on top of MS-DOS).
>
>The first version of NT (1991?) called itself Windows 3.1. It had its

No.

--
Thor Lancelot Simon
But as he knew no bad language, he had called him all the names of common
objects that he could think of, and had screamed: "You lamp! You towel! You
plate!" and so on. --Sigmund Freud

Roger Binns
August 20th 04, 07:13 AM
Dean Kent wrote:
> Windows implementation? Also, out of curiosity (as I don't work on
> Windows), are there updated APIs for 64-bit applications that are
> backwards compatibile with the 32-bit ones - or has MS somehow
> designed their interfaces/control blocks/etc. so that this isn't a
> concern?

Short answer is yes. Long answer follows:

Microsoft of all companies is very proficient at word size changes,
backwards compatibility, and API design borne of necessity rather
than purist design.

These are the transitions they went through:

- 8 bit to 16 bit (early machines, Basics, cloning CP/M)
- 16 bits with slightly wider memory (DOS, extended memory, 286
and 386 flavours of early Windows 1/2)
- 16 to 32 bits (but mostly 16) in Windows 3
- 32 bits with lots of 16 (Windows 95)
- "Clean" design 32 (Windows NT)
- 32 bits with longer addresses (PAE, Alpha, MIPS)
- 64 bits (Itanic, AMD64)

In general a binary is marked for a particular subsystem/version
which implies sizes. When the underlying OS uses a different
size various thunking or stub mechanisms are used to translate
to the right sizes, as well as lots of backwards compatibility
shims.

Note that backwards compatibility doesn't just mean theoretically
pure. It also means bugs or other behaviour. For example Windows
95 specifically recognised the Windows 3 version of SimCity which
had a bug that used memory just after it had been freed. They
run the memory manager in a different mode that ensures no crash
happens.

I recommend reading the historical articles in Raymond Chen's blog.

http://weblogs.asp.net/oldnewthing/category/2282.aspx?Show=All

A selection:

Why 16-bit DOS and Windows are still with us
http://weblogs.asp.net/oldnewthing/archive/2004/03/01/82103.aspx

History of calling conventions:
http://weblogs.asp.net/oldnewthing/archive/2004/01/02/47184.aspx
http://weblogs.asp.net/oldnewthing/archive/2004/01/07/48303.aspx
http://weblogs.asp.net/oldnewthing/archive/2004/01/08/48616.aspx
http://weblogs.asp.net/oldnewthing/archive/2004/01/13/58199.aspx
http://weblogs.asp.net/oldnewthing/archive/2004/01/14/58579.aspx

Sometimes an app just wants to crash:
http://weblogs.asp.net/oldnewthing/archive/2003/12/19/44644.aspx

When programs grovel into undocumented structures:
http://weblogs.asp.net/oldnewthing/archive/2003/12/23/45481.aspx

Why not just block the apps that rely on undocumented behaviour:
http://weblogs.asp.net/oldnewthing/archive/2003/12/24/45779.aspx

Why are structure sizes checked strictly:
http://weblogs.asp.net/oldnewthing/archive/2003/12/12/56061.aspx

What do the letters W and L stand for in WPARAM and LPARAM?
http://weblogs.asp.net/oldnewthing/archive/2003/11/25/55850.aspx

What about BOZOSLIVEHERE and TABTHETEXTOUTFORWIMPS?
http://weblogs.asp.net/oldnewthing/archive/2003/10/15/55296.aspx

Why is address space allocation granularity 64K?
http://weblogs.asp.net/oldnewthing/archive/2003/10/08/55239.aspx

My all time favourite about why Win95 didn't use the HLT instruction:
http://weblogs.asp.net/oldnewthing/archive/2003/08/28/54719.aspx

Roger

David Brown
August 20th 04, 08:13 AM
"Dean Kent" > wrote in message
...
> "David Brown" > wrote in message
> ...
> >
> >
> > Porting applications, on the other hand, is far easier. You have to
> > consider the effect of having 64-bit integers, and you might have to
> > consider endian issues, but mostly (if the original code is
well-written)
> > its a matter of re-compiling and testing the new binary.
> >
>
> Well, I am not an OS developer - but I do work on system level
applications
> (requiring hooks into the OS, use of low-level OS services, etc.). It
> seems to me that the biggest problem for the OS is the compatibility with
> existing applications. There will be control blocks (structures,
whatever)
> and APIs that include addresses to data areas, calls to communicate with
> other programs, etc. You can't just change the size of the address areas
> for two reasons - the offsets for following data areas would change
> (requiring all applications using that structure/control block to be
> recompiled), and you have no idea if the applications using it can
actually
> use the 'bigger' addresses. It also seems to me that you would have to
> include a mechanism whereby the OS knows whether the application is
running
> 32-bit or 64-bit to make sure it doesn't allocate memory where the
> application can't access it - and it can't load the program in an address
> range it can't handle. The calls to other modules would have to include
a
> mechanism whereby programs running in different addressing modes can still
> pass parameters and data to each other without causing major problems and
> crashes.
>
> IOW, moving an OS to 64-bit would not only require changing integer sizes
> and recompiling, but actually redefining the interfaces to work with both
> 32-bit and 64-bit programs (perhaps even mixed addressing modes). Making
> sure all of this works would be a huge undertaking, and could create
> situations where 95% of the code works fine, but a few critical apps have
> major problems that delay the OS release.
>

That's all very true - that's more reasons to back up my "porting an
applicaiton is relatively easy, porting an OS is hard" post. The OS has to
sit between the hardware and the apps - I only mentioned that the low-level
stuff was hard to port, but you are correct that there are issues on the app
side to consider. Hence Win-on-win for 16-bit app support on 32-bit WinNT,
and 32-bit loaders and libraries as well as 64-bit versions on 64-bit linux
and Win64.

> Backwards compatibility matters, particularly in an environment where the
OS
> vendor has support issues to deal with and wants to control what is
running
> in the field. It may not be as big an issue with Linux (or may be),
since
> there are no support issues to deal with and there is no attempt to
control
> what is running in the field. "Want a 32-bit OS? Fine, run an older
> kernel - or someone else's 64-bit kernel that has support for it."
>

Most people get their linux from OS vendors - what else would you call
Mandrake, Suse (Novell), Red Hat, etc. ? Support and backwards
compatibility is a big issue - in the linux world, if something works then
people use it, they don't re-write it and expect people to pay for upgrades
just that it will run on the latest version of your OS. There are programs
in continuous use in linux systems (and any other *nix system) that haven't
been changed in years - decades, maybe - simply because they already do the
job they were meant to do. Most of these can, of course, be simply
re-compiled at 64-bit for a 64-bit linux, but there are certainly plenty of
occasions when you would want to run 32-bit binaries on 64-bit linux.

> At least, it works that way in the environment I am familiar with (not
> Windows or Unix... :-).
>
> Regards,
> Dean
>
>

Roger Binns
August 20th 04, 08:24 AM
Thor Lancelot Simon wrote:
> In article >,
> Ken Hagan > wrote:
>> Nick Roberts wrote:
>>>
>>> I don't think that's strictly correct. My memory is that Windows 95
>>> was itself the first Windows which supported 32-bit code, when it
>>> was launched (in 1995 ;-) The immediately prior version of Windows
>>> was
>>> 3.11, which was 16-bit only (and ran on top of MS-DOS).
>>
>> The first version of NT (1991?) called itself Windows 3.1. It had its
>
> No.

The first version of NT was released in 1993 and was called Windows NT 3.1.

http://www.microsoft.com/presspass/features/1998/winntfs.asp

Details and screenshots of all Windows releases are at
http://www.microsoft.com/windows/WinHistoryProGraphic.mspx
http://www.microsoft.com/windows/WinHistoryDesktop.mspx

Roger

Stephen Sprunk
August 23rd 04, 02:07 AM
"Douglas Siebert" > wrote in message
...
> (Patrick Schaaf) writes:
>
>>Casper H.S. Dik > writes:
>
>>>"Stephen Sprunk" > writes:
>>>>AMD64 is just another platform, and the third (or higher) platform
>>>>supported
>>>>is of marginal cost compared to the second. The free software world has
>>>>had
>>>>to contend with dozens of platforms for over two decades, and so the
>>>>fact
>>>>Linux (and all the common apps) ported over cleanly is hardly
>>>>surprising.
>
>>>It's not really all that simple: while you can run a pure 64 bit OS on
>>>AMD64, there are many Linux applications only available as "32-bit, IA32"
>>>binaries.

There are a few, yes, but most of the folks developing Linux couldn't care
less if they cause closed-source developers a little pain. I haven't heard
any complaints about problems running i386 binaries on amd64 kernels, so it
appears to be a non-issue -- unlike with WinXP64.

>>I don't see many of them on the ~1000 Linux systems I've got at work.
>>There are bound to be some commercial apps where that's the case,
>>but I'm sure Stephen was thinking about the ease for
>>_open_source_software_
>>to be ported over.

Actually, it applies to commercial software too. I worked at a company
where the main product (an embedded OS) was shipped on a dozen different CPU
types and once the cost of porting was paid (over a decade ago) for the
second arch, the cost of adding a new arch was nearly zero.

The key is making sure all new code is written portably, which so far has
not been necessary in the Windows world. Some ISVs may decide it's cheaper
to develop non-portable code over time; they'll pay dearly for porting once
a decade and usually drop support for the older arch (as happened in the
Win16-to-Win32 conversion).

> Do the AMD64 versions of Redhat and SuSE recompile everything? It seems
> kind to silly to have a 64 bit /bin/ls, for instance. They always left
> most stuff for which performance didn't matter compiled as i386, and for
> stuff where performance mattered (the kernel, openssl libraries, etc.)
> there were i686 versions. I would assume it is the same way for AMD64
> stuff, but perhaps I'm wrong. If I am, it sure seems like they'd have
> to do a lot more versions if they bugfix /bin/ls and have to compile a
> 64 bit version to go along with the i386 version!

If /bin/ls were patched, somebody has to recompile it for dozens of other
platforms, so what's the marginal cost in recompiling for amd64? It seems
to be less than the cost of deciding which binaries on an amd64 installation
should be kept as i386 and compiling your distribution appropriately.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

Nate Edel
August 23rd 04, 11:25 PM
In comp.sys.intel David Brown > wrote:
> Win32S was available before Win95, as was NT 3.51 (I believe NT 3.5 was the
> first easily-availble version of NT - marketing's idea of persuading people
> that it was a mature product).

NT 3.1 was the first version available, with the 3.1 selected to be in
parallel with the version of (non-NT) Windows available at the time.

> not support multi-tasking. It was mainly used for "big" programs, like CAD,
> or development tools, which could take advantage of the better memory
> management.

And for a lot of the Windows 3.x web browsers. I remember deploying a ton
of copies of Win32s so the lawyers I was supporting could use some
now-archaic version of netscape while the higher-ups in IT planned how to
transition to Win 95 (and then to WinNT 4, which was what we ended up moving
to, right around when I left.)

--
Nate Edel http://www.nkedel.com/

"I do have a cause though. It is obscenity. I'm for it." - Tom Lehrer