Sign in with
Sign up | Sign in
Your question

Is Itanium the first 64-bit casualty?

Last response: in CPUs
Share
Anonymous
a b à CPUs
June 26, 2004 7:54:02 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Interesting reading here, and very common-sense. Itanium may be the next
casualty in the 64-bit wars, when Itanium was the one that caused the 64-bit
wars to start in the first place.

http://www.infoworld.com/article/04/06/25/26enterwin_1....

Yousuf Khan

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

More about : itanium bit casualty

Anonymous
a b à CPUs
June 26, 2004 11:54:12 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

>Interesting reading here, and very common-sense.

Pretty much lacking on the factual side, and nothing new in the rest
of it.

Why'd you cross-post so widely?

Followups away from comp.arch.

-- greg
Anonymous
a b à CPUs
June 26, 2004 9:36:44 PM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sat, 26 Jun 2004 07:54:12 GMT, lindahl@pbm.com (Greg Lindahl) wrote:

>>Interesting reading here, and very common-sense.
>
>Pretty much lacking on the factual side, and nothing new in the rest
>of it.

Yes, I'm curious why he mentioned none of the known hard facts. I guess
the ones like this
http://www.ptc.com/partners/hardware/current/itanium_le... didn't want
to be held up as examples of the iNfidel.:-) "Decertification" sounds
kinda serious coming from a major workstation software vendor. I wonder
how long before customers umm, decertify 32-bit only x-86 systems.

>Why'd you cross-post so widely?
>
>Followups away from comp.arch.

RD&H?

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
Related resources
Anonymous
a b à CPUs
June 28, 2004 10:09:22 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@ezrs.com> wrote:
> Interesting reading here, and very common-sense. Itanium may be the next
> casualty in the 64-bit wars, when Itanium was the one that caused the 64-bit
> wars to start in the first place.

Errr... hype about Itanium may have brought the interest from the Unix world
to the destkop, but Dec and Sun both came closer to getting Alpha and
UltraSparc on the desktop than Intel's come to putting Itanic there.

The 64-bit war for the desktop is still a non-starter; right you can either
get software without consumer hardware (Windows for Itanic) or consumer
hardware without a mass-market OS (x86-64).

--
Nate Edel http://www.nkedel.com/

"Wanted: One .Sig-quote. Must work cheap."
Anonymous
a b à CPUs
June 29, 2004 12:02:39 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

bbbl67@ezrs.com (Yousuf Khan) wrote in
<ur6Dc.4$6sE1.1@news04.bloor.is.net.cable.rogers.com>:

>Interesting reading here, and very common-sense. Itanium may be the next
>casualty in the 64-bit wars, when Itanium was the one that caused the
>64-bit wars to start in the first place.
>
>http://www.infoworld.com/article/04/06/25/26enterwin_1....
>
> Yousuf Khan
>

Perhaps this is the first case of a processor acting as a catalyst: The
Itanium sparked the 64-bit-for-consumer trend, but isn't actually going to
take part in it ;-)

ws
--
Warren Spencer
Senior Software Engineer
The Associated Press
Anonymous
a b à CPUs
June 29, 2004 12:28:13 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <9516A4D51wspenceraporg@216.168.3.30>,
Warren Spencer <wspencer@ap.dontspamme.org> wrote:
>
>Perhaps this is the first case of a processor acting as a catalyst: The
>Itanium sparked the 64-bit-for-consumer trend, but isn't actually going to
>take part in it ;-)

Yer whaa?

It was INTENDED to do that - back in 1994, it was intended to replace
x86 in the consumer market by 2001 - but NO WAY did it have a significant
influence on it. The trend was due to the passage of time, involving
Moore's law and Gates's law (bloatware expands at 60% per annum), and
the main chips that started 64-bit use by consumers were the SPARC
and PowerPC. And they didn't have much influence on that market.


Regards,
Nick Maclaren.
Anonymous
a b à CPUs
June 29, 2004 1:34:17 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Nate Edel" <archmage@sfchat.org> wrote in message
news:23s6r1xcjn.ln2@mail.sfchat.org...
> In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@ezrs.com> wrote:
> > Interesting reading here, and very common-sense. Itanium may be the
next
> > casualty in the 64-bit wars, when Itanium was the one that caused
the 64-bit
> > wars to start in the first place.
>
> Errr... hype about Itanium may have brought the interest from the Unix
world
> to the destkop, but Dec and Sun both came closer to getting Alpha and
> UltraSparc on the desktop than Intel's come to putting Itanic there.
>
> The 64-bit war for the desktop is still a non-starter; right you can
either
> get software without consumer hardware (Windows for Itanic) or
consumer
> hardware without a mass-market OS (x86-64).
>
> --
Or you can get both, Apple G5. duh.

del cecchi
June 29, 2004 10:56:27 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

del cecchi wrote:

> "Nate Edel" <archmage@sfchat.org> wrote in message
> news:23s6r1xcjn.ln2@mail.sfchat.org...
>
>>In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@ezrs.com> wrote:
>>
>>>Interesting reading here, and very common-sense. Itanium may be the
>
> next
>
>>>casualty in the 64-bit wars, when Itanium was the one that caused
>
> the 64-bit
>
>>>wars to start in the first place.
>>
>>Errr... hype about Itanium may have brought the interest from the Unix
>
> world
>
>>to the destkop, but Dec and Sun both came closer to getting Alpha and
>>UltraSparc on the desktop than Intel's come to putting Itanic there.
>>
>>The 64-bit war for the desktop is still a non-starter; right you can
>
> either
>
>>get software without consumer hardware (Windows for Itanic) or
>
> consumer
>
>>hardware without a mass-market OS (x86-64).
>>
>>--
>
> Or you can get both, Apple G5. duh.
>
> del cecchi
>
>

64 bit really isn't useful for typical (or even most atypical) desktops,
anyway.

--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Anonymous
a b à CPUs
June 29, 2004 5:27:14 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <23s6r1xcjn.ln2@mail.sfchat.org>, archmage@sfchat.org
says...
> In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@ezrs.com> wrote:
> > Interesting reading here, and very common-sense. Itanium may be the next
> > casualty in the 64-bit wars, when Itanium was the one that caused the 64-bit
> > wars to start in the first place.
>
> Errr... hype about Itanium may have brought the interest from the Unix world
> to the destkop, but Dec and Sun both came closer to getting Alpha and
> UltraSparc on the desktop than Intel's come to putting Itanic there.
>
> The 64-bit war for the desktop is still a non-starter; right you can either
> get software without consumer hardware (Windows for Itanic) or consumer
> hardware without a mass-market OS (x86-64).
>
If "mass market" == Windows, sure. Linux runs AMD64 quite well. SuSE
9.1 is running on an Opteron quite happily at home.

--
Keith
Anonymous
a b à CPUs
June 29, 2004 9:04:14 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Nate Edel wrote:

(snip)

> The 64-bit war for the desktop is still a non-starter; right you can either
> get software without consumer hardware (Windows for Itanic) or consumer
> hardware without a mass-market OS (x86-64).

There is Windows (2003 server, I believe) for x86-64.

There is even a free 1 year evaluation version available.

-- glen
Anonymous
a b à CPUs
June 29, 2004 10:18:44 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:iihEc.130267$HG.98476@attbi_s53...
> Nate Edel wrote:
>
> (snip)
>
> > The 64-bit war for the desktop is still a non-starter; right you can
either
> > get software without consumer hardware (Windows for Itanic) or consumer
> > hardware without a mass-market OS (x86-64).
>
> There is Windows (2003 server, I believe) for x86-64.
>
> There is even a free 1 year evaluation version available.
>
> -- glen

Not a released product, just a beta. And it is for AMD64 - apparently it
doesn't work with the Intel flavour yet. (lack of IOMMU hardware?)

Peter
Anonymous
a b à CPUs
June 29, 2004 10:46:10 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 28 Jun 2004 21:34:17 -0500, del cecchi wrote:

> Or you can get both, Apple G5. duh.

Exactly what 64bit capabilities does Panther have? That's just a question,
I don't really know :) 

I was under the impression that Apple won't have a 'proper' 64bit OS
until Tiger (10.4) early next year.

Cheers
Anton
Anonymous
a b à CPUs
June 29, 2004 10:46:11 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"AD." <me@privacy.net> writes:

> Exactly what 64bit capabilities does Panther have? That's just a
> question, I don't really know :) 

Certainly not a 64-bit memory model.

> I was under the impression that Apple won't have a 'proper' 64bit
> OS until Tiger (10.4) early next year.

Which was just previewed yesterday at Apple's WWDC 2004. Apple will
be going to an LP64 model in "Tiger":

http://www.apple.com/macosx/tiger/64bit.html

Apple's development tools also have support for "Fat Binaries":
allowing for both 32- and 64-bit instructions in the same
executable. I've heard it mentioned that the binary format would also
allow different architecture code (e.g., both PowerPC and x86) in the
same binary as well.

So we'll have UltraSPARC, 'AMD64' and PowerPC as the most popular
64-bit platforms?

--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Anonymous
a b à CPUs
June 29, 2004 10:48:31 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips del cecchi <dcecchi.nojunk@att.net> wrote:
> "Nate Edel" <archmage@sfchat.org> wrote in message
> > The 64-bit war for the desktop is still a non-starter; right you can
> > either get software without consumer hardware (Windows for Itanic) or
> > consumer hardware without a mass-market OS (x86-64).
>
> Or you can get both, Apple G5. duh.

Well, you can kinda-sorta get the OS on the G5, as others have noted. And
Apple, while consumer hardware, is only kinda-sorta in the mass-market game.
Even within the Apple market, are the G5s down throughout the line yet, or
are they just the top-end model?

The educational-priced Sun Blade 100 was under $1000 well before the G5s
shipped, and Solaris 9 personal licenses are free. That doesn't make Solaris
on UltraSparc (or the UDB/Multia Alphas, long long ago) any more of a
mass-market 64-bit platform.

--
Nate Edel http://www.nkedel.com/

"Wanted: One .Sig-quote. Must work cheap."
Anonymous
a b à CPUs
June 29, 2004 10:53:25 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
> Nate Edel wrote:
> (snip)
> > The 64-bit war for the desktop is still a non-starter; right you can either
> > get software without consumer hardware (Windows for Itanic) or consumer
> > hardware without a mass-market OS (x86-64).
>
> There is Windows (2003 server, I believe) for x86-64.
> There is even a free 1 year evaluation version available.

Unless it's shipped quite recently when I wasn't looking, it's still a
beta/pre-release version of the software.

http://www.microsoft.com/windowsxp/64bit/evaluation/upg...

--
Nate Edel http://www.nkedel.com/

"Wanted: One .Sig-quote. Must work cheap."
June 30, 2004 1:06:58 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

CJT <abujlehc@prodigy.net> wrote :

> I suppose if you write bad enough code, you need that much linear
> memory for essentially parallel tasks. But typical applications
> don't.

Its not the code, its data.


Pozdrawiam.
--
RusH //
http://pulse.pdi.net/~rush/qv30/
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.
Anonymous
a b à CPUs
June 30, 2004 6:02:00 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Warren Spencer <wspencer@ap.dontspamme.org> wrote:
> Perhaps this is the first case of a processor acting as a catalyst:
> The Itanium sparked the 64-bit-for-consumer trend, but isn't actually
> going to take part in it ;-)

Interesting way of looking at it, I'll admit.

Yousuf Khan
Anonymous
a b à CPUs
June 30, 2004 6:39:18 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Nate Edel <archmage@sfchat.org> wrote:
> Well, you can kinda-sorta get the OS on the G5, as others have noted.
> And Apple, while consumer hardware, is only kinda-sorta in the
> mass-market game. Even within the Apple market, are the G5s down
> throughout the line yet, or are they just the top-end model?

Does AIX which runs on Power4 chips work on the G5?

Yousuf Khan
June 30, 2004 7:01:52 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

RusH wrote:

> CJT <abujlehc@prodigy.net> wrote :
>
>
>>I suppose if you write bad enough code, you need that much linear
>>memory for essentially parallel tasks. But typical applications
>>don't.
>
>
> Its not the code, its data.

Precisely.
>
>
> Pozdrawiam.


--
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam. Our true address is of the form che...@prodigy.net.
Anonymous
a b à CPUs
June 30, 2004 11:59:17 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On 2004-06-30, Yousuf Khan <bbbl67@ezrs.com> wrote:
>
> Does AIX which runs on Power4 chips work on the G5?

Not yet, but IBM plans to support AIX on the BladeCenter JS20 (ppc970) in
the third quarter of 2004. Don't know if that means it will run on
apple/non-ibm machines..



-jf
Anonymous
a b à CPUs
June 30, 2004 5:41:22 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 30 Jun 2004 06:26:07 GMT, CJT <abujlehc@prodigy.net> wrote:
>Tony Hill wrote:
>> On Tue, 29 Jun 2004 19:52:23 GMT, CJT <abujlehc@prodigy.net> wrote:
>>>I suppose if you write bad enough code, you need that much linear
>>>memory for essentially parallel tasks. But typical applications
>>>don't.
>>
>>
>> Not bad code, just LOTS of graphics. Eye candy and graphics seems to
>> be what sells in video games for the most part, so I expect that we'll
>> see the data set for games continue to expand at a rather prodigious
>> rate.
>>
>
>Sure, but that stuff doesn't need a linear address space. Segments
>work just fine.

Segments? Ya mean like PAE?!?! Not a chance in hell! Do this the
*RIGHT* way, ie 64-bit flat linear address space, not some
ugly-as-all-hell kludge!

64-bit may not be NEEDED to get more than 2GB (3GB in some cases) of
memory space, but it's the RIGHT way to do it. All the other
solutions are way more trouble than their worth.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 30, 2004 6:06:51 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <MPG.1b4b7080294c8bd898969c@news.individual.net>,
Keith R. Williams <krw@att.bizzzz> wrote:
>In article <23s6r1xcjn.ln2@mail.sfchat.org>, archmage@sfchat.org
>says...
>> In comp.sys.ibm.pc.hardware.chips Yousuf Khan <bbbl67@ezrs.com> wrote:
>> > Interesting reading here, and very common-sense. Itanium may be the next
>> > casualty in the 64-bit wars, when Itanium was the one that caused the 64-bit
>> > wars to start in the first place.
>>
>> Errr... hype about Itanium may have brought the interest from the Unix world
>> to the destkop, but Dec and Sun both came closer to getting Alpha and
>> UltraSparc on the desktop than Intel's come to putting Itanic there.
>>
>> The 64-bit war for the desktop is still a non-starter; right you can either
>> get software without consumer hardware (Windows for Itanic) or consumer
>> hardware without a mass-market OS (x86-64).
>>
>If "mass market" == Windows, sure. Linux runs AMD64 quite well. SuSE
>9.1 is running on an Opteron quite happily at home.

The Debian port appears to be up and running as well. (ie, actually
usable, with a relatively simple install, rather than the install from
hell of a month or two ago). It's a pure-64 bit port -- if you want to
run 32 bit binaries then you'll need to install a 32-bit Debian in a
chroot. (Fortunately, debootstrap makes this a one-liner).

Phil



--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
Anonymous
a b à CPUs
June 30, 2004 6:06:52 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 30 Jun 2004 14:06:51 +0100, phil@kantaka.co.uk (Philip
Armstrong) wrote:
>In article <MPG.1b4b7080294c8bd898969c@news.individual.net>,
>Keith R. Williams <krw@att.bizzzz> wrote:
>>>
>>If "mass market" == Windows, sure. Linux runs AMD64 quite well. SuSE
>>9.1 is running on an Opteron quite happily at home.
>
>The Debian port appears to be up and running as well. (ie, actually
>usable, with a relatively simple install, rather than the install from
>hell of a month or two ago). It's a pure-64 bit port -- if you want to
>run 32 bit binaries then you'll need to install a 32-bit Debian in a
>chroot. (Fortunately, debootstrap makes this a one-liner).

That's the last of 'em then. It looks like EVERY major Linux
distribution has managed to beat Microsoft to market with a usable
AMD64/x86-64 operating system (at least as long as you don't count
Slackware as a "major distribution", which most people don't these
days). SuSE, RedHat, Mandrake, Gentoo, Turbolinux and now Debian are
all out there now. Debian's distribution is still in the "unstable"
stream, but those who know Debian should know that Debian "unstable"
is roughly equivalent to pre-SP1 release of Windows rather than a beta
version.

Ohh, and FreeBSD and OpenBSD also have full support for AMD64 as well.
Kind of makes you wonder just what the heck is taking MS so long?!

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
June 30, 2004 6:42:01 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
news:fts5e0536f09o7c2cj6g0no6jomnvre9u2@4ax.com...
> On Wed, 30 Jun 2004 14:06:51 +0100, phil@kantaka.co.uk (Philip
> Armstrong) wrote:
> >In article <MPG.1b4b7080294c8bd898969c@news.individual.net>,
> >Keith R. Williams <krw@att.bizzzz> wrote:
> >>>
> >>If "mass market" == Windows, sure. Linux runs AMD64 quite well. SuSE
> >>9.1 is running on an Opteron quite happily at home.
> >
> >The Debian port appears to be up and running as well. (ie, actually
> >usable, with a relatively simple install, rather than the install from
> >hell of a month or two ago). It's a pure-64 bit port -- if you want to
> >run 32 bit binaries then you'll need to install a 32-bit Debian in a
> >chroot. (Fortunately, debootstrap makes this a one-liner).
>
> That's the last of 'em then. It looks like EVERY major Linux
> distribution has managed to beat Microsoft to market with a usable
> AMD64/x86-64 operating system (at least as long as you don't count
> Slackware as a "major distribution", which most people don't these
> days). SuSE, RedHat, Mandrake, Gentoo, Turbolinux and now Debian are
> all out there now. Debian's distribution is still in the "unstable"
> stream, but those who know Debian should know that Debian "unstable"
> is roughly equivalent to pre-SP1 release of Windows rather than a beta
> version.
>
> Ohh, and FreeBSD and OpenBSD also have full support for AMD64 as well.
> Kind of makes you wonder just what the heck is taking MS so long?!

What is taking them so long? Answer = Intel! If 64-bit was such a big deal
for consumers, we would be looking at Itanium Workstations. 64-bit = not
big deal = why MS hasn't pushed it very hard. Wait for Intel's 80+ percent
market share to join in and then release something for OEM's to sell their
i64 and AMD64 systems. It's a very smart business move.
Anonymous
a b à CPUs
June 30, 2004 7:33:55 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Warren Spencer wrote:
> bbbl67@ezrs.com (Yousuf Khan) wrote in
> <ur6Dc.4$6sE1.1@news04.bloor.is.net.cable.rogers.com>:
>
>
>>Interesting reading here, and very common-sense. Itanium may be the next
>>casualty in the 64-bit wars, when Itanium was the one that caused the
>>64-bit wars to start in the first place.
>>
>>http://www.infoworld.com/article/04/06/25/26enterwin_1....
>>
>> Yousuf Khan
>>
>
>
> Perhaps this is the first case of a processor acting as a catalyst: The

No, quite definitely not the first. Plenty of architectures out there
that died a quiet death and were resurrected in another form for other
markets. :) 

> Itanium sparked the 64-bit-for-consumer trend, but isn't actually going to
> take part in it ;-)

Much as I hate to say it : I think the Alpha did, NT was first ported
the Alpha/MIPS/PowerPC. IA-64 came much later. In practice I only saw
NT on Alpha actually in production, which is why I didn't say MIPS. :/ 

Worth noting that DEC did initially point Alpha at Embedded and low
end workstation space, and they continued their spasmodic efforts to
push it at the desktop for a long time.

Alpha appears to have had quite a large "Open Source" user base for a
long time, but that doesn't really count as consumer. However a lot of
that 64bit clean push was accomplished with Alphas, and that lowered
the barrier of entry for vendors of 64bit gear.

Cheers,
Rupert
Anonymous
a b à CPUs
June 30, 2004 8:00:46 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In <1088606034.417027@teapot.planet.gong> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> writes:

>Worth noting that DEC did initially point Alpha at Embedded and low
>end workstation space, and they continued their spasmodic efforts to
>push it at the desktop for a long time.

Care to elaborate on the difference between "low end workstation" and
"desktop"? Since 1994, all low end Alpha workstations have actually been
PCs with an Alpha processor instead of an Intel processor. What can be
more "desktop" than such a system?

>Alpha appears to have had quite a large "Open Source" user base for a
>long time, but that doesn't really count as consumer. However a lot of
>that 64bit clean push was accomplished with Alphas, and that lowered
>the barrier of entry for vendors of 64bit gear.

This is true. DEC OSF/1 exposed plenty of open source code that wasn't
64-bit clean. Plenty of proprietary code, too, which severely restricted
the number of commercial applications available for that platform, during
the first years.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
Anonymous
a b à CPUs
June 30, 2004 9:50:30 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Dan.Pop@cern.ch (Dan Pop) writes:
>This is true. DEC OSF/1 exposed plenty of open source code that wasn't
>64-bit clean.

From the "flogging a dead horse" department: More precisely, code that
was not I32LP64 clean. I am pretty sure my code and lots of other
code was ILP64 clean, and lots of the I32LP64-clean code would not
work on an ILP64 system (IIRC the Cray T3E was such a system), and
probably lots of the ILP64-clean and I32LP64-clean code will need
changes to work on an IL32LLP64 system (Win64, right?). So you should
not use "64-bit-clean" for programs that are just I32LP64-clean.

> Plenty of proprietary code, too, which severely restricted
>the number of commercial applications available for that platform, during
>the first years.

There were tricks around that (-taso etc.). Netscape was 32-bit code
until it was cleaned up in Mozilla. Or was it? Fedora Core 1 for
AMD64 still contains a 32-bit Mozilla.:-(

Followups to comp.arch.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
Anonymous
a b à CPUs
June 30, 2004 10:06:48 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <ngs5e0p6607jl4ctpgoc1r9t6gs6fk0fmj@4ax.com>,
Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
>On Wed, 30 Jun 2004 06:26:07 GMT, CJT <abujlehc@prodigy.net> wrote:
>>Tony Hill wrote:
>>
>>Sure, but that stuff doesn't need a linear address space. Segments
>>work just fine.
>
>Segments? Ya mean like PAE?!?! Not a chance in hell! Do this the
>*RIGHT* way, ie 64-bit flat linear address space, not some
>ugly-as-all-hell kludge!
>
>64-bit may not be NEEDED to get more than 2GB (3GB in some cases) of
>memory space, but it's the RIGHT way to do it. All the other
>solutions are way more trouble than their worth.

That is quite simply wrong.

Using multiple hardware segments to create a software segment that
is larger than the indexing size is, I agree, an abomination. It
has been done many times and has never worked well.

But a single flat, linear address space is almost equally ghastly,
for different reasons. It is one of the surest ways to ensure
mind-bogglingly revolting and insecure designs.

What is actually wanted is the ability to have multiple segments,
with application-specified properties, where each application
segment is inherently separate and integral. That is how some
systems (especially capability machines) have worked.


Regards,
Nick Maclaren.
Anonymous
a b à CPUs
June 30, 2004 10:06:49 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Nick Maclaren" <nmm1@cus.cam.ac.uk> wrote in message
news:cbuvfo$hpn$1@pegasus.csx.cam.ac.uk...
> In article <ngs5e0p6607jl4ctpgoc1r9t6gs6fk0fmj@4ax.com>,
> Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
> >On Wed, 30 Jun 2004 06:26:07 GMT, CJT <abujlehc@prodigy.net> wrote:
> >>Tony Hill wrote:
> >>
> >>Sure, but that stuff doesn't need a linear address space. Segments
> >>work just fine.
> >
> >Segments? Ya mean like PAE?!?! Not a chance in hell! Do this the
> >*RIGHT* way, ie 64-bit flat linear address space, not some
> >ugly-as-all-hell kludge!
> >
> >64-bit may not be NEEDED to get more than 2GB (3GB in some cases) of
> >memory space, but it's the RIGHT way to do it. All the other
> >solutions are way more trouble than their worth.
>
> That is quite simply wrong.
>
> Using multiple hardware segments to create a software segment that
> is larger than the indexing size is, I agree, an abomination. It
> has been done many times and has never worked well.
>
> But a single flat, linear address space is almost equally ghastly,
> for different reasons. It is one of the surest ways to ensure
> mind-bogglingly revolting and insecure designs.
>
Smile when you say that, pardner. AS400/iseries has exactly that. And has
since S/38.

del cecchi
Anonymous
a b à CPUs
June 30, 2004 10:40:36 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
> Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
>> Segments? Ya mean like PAE?!?! Not a chance in hell!
>> Do this the *RIGHT* way, ie 64-bit flat linear address space,
>> not some ugly-as-all-hell kludge!

That's a bit rough on PAE. It's not a bad trick for the
OS to use when it needs lots of RAM to run lots of process
that each fit inside 32 bits. Transparent to applications.
Admittedly useless for single apps that need >32 bits.

> But a single flat, linear address space is almost equally
> ghastly, for different reasons. It is one of the surest ways
> to ensure mind-bogglingly revolting and insecure designs.

> What is actually wanted is the ability to have multiple
> segments, with application-specified properties, where each
> application segment is inherently separate and integral.
> That is how some systems (especially capability machines)
> have worked.

I'm not sure what you mean here. What is so wrong with flat
address spaces, virtualized through the paging mechanism?
That's what we have on all PMode OSes today. Apps usually
start at the same addresses (IP & stack) and think they
have the machine to themselves. Paging hardware (LDTs)
keeps processes separate.

-- Robert
Anonymous
a b à CPUs
June 30, 2004 11:38:26 PM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <EODEc.9306$oS7.265@newssvr22.news.prodigy.com>,
Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>> Tony Hill <hilla_nospam_20@yahoo.ca> wrote:
>>> Segments? Ya mean like PAE?!?! Not a chance in hell!
>>> Do this the *RIGHT* way, ie 64-bit flat linear address space,
>>> not some ugly-as-all-hell kludge!
>
>That's a bit rough on PAE. It's not a bad trick for the
>OS to use when it needs lots of RAM to run lots of process
>that each fit inside 32 bits. Transparent to applications.
>Admittedly useless for single apps that need >32 bits.

Yes, precisely. And it also allows a 32-bit application efficient
access to large memory-mapped files - a seek on such things is little
more expensive than a TLB miss.

>I'm not sure what you mean here. What is so wrong with flat
>address spaces, virtualized through the paging mechanism?
>That's what we have on all PMode OSes today. Apps usually
>start at the same addresses (IP & stack) and think they
>have the machine to themselves. Paging hardware (LDTs)
>keeps processes separate.

Yes, they do, don't they? And many of the foulest problems are
caused by various forms of corrupting one (logical) segment by
means of a pointer to another. There are many ways to tackling
that problem, and one of the best is secure segmentation - but
in the sense of a capability model and not a page table hack.

If you don't care about robustness and security, then obviously a
single flat address space is best. But even current systems are
now trying to separate the executable segments from the writable
ones, which is moving away from a single flat address space. If
you think about it:

Why shouldn't I be able to load a module onto the stack, or use
part of an executable as a temporary stack segment? We used to be
able to do that, after all, and a genuinely integral flat address
space would allow it.

The reason is that it is generally accepted to be sacrificing too
much robustness and security for flexibility.


Regards,
Nick Maclaren.
Anonymous
a b à CPUs
July 1, 2004 12:12:42 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
> Why shouldn't I be able to load a module onto the stack,

You can. Trampoline code does this, and making the stack
no-exec really doesn't increase security in the face of
buffer overflows corrupting return addresses. An exploit
can be pure data, no code.

> or use part of an executable as a temporary stack segment?

Not so wise. Code pages are marked read-only to permit
all sorts of nice things like sharing between processes
(think of how many httpd processes running on a webserver).
It also permits discarding codepages instead of swapping out.
Just reload from disk image. Of course, a sufficiently
sophisticated CoW policy could handle this.

-- Robert
Anonymous
a b à CPUs
July 1, 2004 12:28:23 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Dan Pop wrote:
> In <1088606034.417027@teapot.planet.gong> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> writes:
>
>
>>Worth noting that DEC did initially point Alpha at Embedded and low
>>end workstation space, and they continued their spasmodic efforts to
>>push it at the desktop for a long time.
>
>
> Care to elaborate on the difference between "low end workstation" and
> "desktop"? Since 1994, all low end Alpha workstations have actually been

Marketing and the perceptions of PHBs with the chequebooks.

> PCs with an Alpha processor instead of an Intel processor. What can be
> more "desktop" than such a system?

Not my call. Reminds me a little of the thread about some Intel dude
calling SPARC "proprietry".

I think we should play the Marketoids at their own game : Let's start
referring to IA-64 as "Legacy" now that we have a dual-sourced 64bit
architecture in the x86 world.


Cheers,
Rupert
Anonymous
a b à CPUs
July 1, 2004 12:31:11 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <_8FEc.9318$f_7.2539@newssvr22.news.prodigy.com>,
Robert Redelmeier <redelm@ev1.net.invalid> wrote:
>In comp.sys.ibm.pc.hardware.chips Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>> Why shouldn't I be able to load a module onto the stack,
>
>You can. Trampoline code does this, and making the stack
>no-exec really doesn't increase security in the face of
>buffer overflows corrupting return addresses. An exploit
>can be pure data, no code.
>
>> or use part of an executable as a temporary stack segment?
>
>Not so wise. Code pages are marked read-only to permit
>all sorts of nice things like sharing between processes
>(think of how many httpd processes running on a webserver).
>It also permits discarding codepages instead of swapping out.
>Just reload from disk image. Of course, a sufficiently
>sophisticated CoW policy could handle this.

Er, that was the use of reductio ad absurdam, and the paragraph does
not make much sense on its own. I could provide reasons why either
of those is a good or bad idea (think exception handling for the
latter), and all combinations have been done in the past.


Regards,
Nick Maclaren.
Anonymous
a b à CPUs
July 1, 2004 2:06:36 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Judd wrote:

[SNIP]

> Thanks Mr. boogerall... but 64-bit is really not that essential for the
> general consumer market just yet. It's a niche right now. That's why it's
> important to have a "hybrid" 64-bit CPU that still works (perfectly) with
> the old 32-bit code. No kludgy or slow emulations! If 64-bit is all we
> needed, then Itanium would be selling like hotcakes. Face it, there is no
> killer app creating a 64-bit buzz.

Video editing. People edit home movies. They can quite happily eat > 4GB
of disk doing that. A friend of mine was complaining of his 32bit app
tripping up at > 2GB files, so he had to split the files up. The final
result was only about 10 mins long too. :( 

Cheers,
Rupert
July 1, 2004 2:06:37 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote :

>
> Video editing. People edit home movies. They can quite happily eat
> > 4GB of disk doing that. A friend of mine was complaining of his
> 32bit app tripping up at > 2GB files, so he had to split the files
> up. The final result was only about 10 mins long too. :( 

thats FAT limitations


Pozdrawiam.
--
RusH //
http://pulse.pdi.net/~rush/qv30/
Like ninjas, true hackers are shrouded in secrecy and mystery.
You may never know -- UNTIL IT'S TOO LATE.
Anonymous
a b à CPUs
July 1, 2004 2:43:48 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Judd" <IhateSpam@stopspam.com> wrote in message
news:10e694r11qf9v52@corp.supernews.com...
> Thanks Mr. boogerall... but 64-bit is really not that essential for the
> general consumer market just yet. It's a niche right now. That's why
it's
> important to have a "hybrid" 64-bit CPU that still works (perfectly) with
> the old 32-bit code. No kludgy or slow emulations! If 64-bit is all we
> needed, then Itanium would be selling like hotcakes. Face it, there is no
> killer app creating a 64-bit buzz.

64-bit pointers are, pardon the pun, pointless for the vast majority of
desktops. 64-bit ints are somewhat useful, but the big benefit to x86
machines is the extra eight GPRs that amd64 offers -- which is orthogonal to
64-bitness. It just makes sense to add everything at the same time, since
we only get an opportunity for such a radical ISA change once a decade.

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
Anonymous
a b à CPUs
July 1, 2004 2:43:49 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Stephen Sprunk" <stephen@sprunk.org> wrote in message
news:ac890a453c50c3d8c4bf6942651fb0c5@news.teranews.com...

> 64-bit pointers are, pardon the pun, pointless for the vast majority of
> desktops.

I have to disagree here. File sizes in serious applications have long
exceeded the size where you could 'mmap' them with 32-bit pointers. Without
64-bit pointers, the usable memory space for typical applications is between
..5Gb and 3.5Gb depending upon how the system is set up. Raising it to 3.5Gb
or so has other serious compromises. The current generation of software
doesn't use this type of capability simply because it hasn't been available.

Sure, 64-bit anything is pointless for the vast majority of anything
*today* simply because the vast majority of software is 32-bits. That
doesn't mean that the software couldn't be better if it had access to a
massive address space.

Think about things like hash tables and sparse arrays. Their
implementation could be much simpler if the address space were massive and
the OS allocated memory upon usage.

DS
Anonymous
a b à CPUs
July 1, 2004 2:43:49 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Stephen Sprunk <stephen@sprunk.org> wrote:
> 64-bit pointers are, pardon the pun, pointless for the vast majority of
> desktops.

Only until > 1 or > 2 gb desktop machines (depending on choice of OS) become
ubiquitous. Which is only a RAM price drop or two away; as it stands, 1gb
machines are getting to be pretty close to ubiquitous among geeks.

Not to mention all the video card RAM...

--
Nate Edel http://www.nkedel.com/

"Wanted: One .Sig-quote. Must work cheap."
July 1, 2004 2:52:13 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

> > Using multiple hardware segments to create a software segment that
> > is larger than the indexing size is, I agree, an abomination. It
> > has been done many times and has never worked well.
> >
> > But a single flat, linear address space is almost equally ghastly,
> > for different reasons. It is one of the surest ways to ensure
> > mind-bogglingly revolting and insecure designs.
> >
> Smile when you say that, pardner. AS400/iseries has exactly that. And
has
> since S/38.
>
> del cecchi
>
>

The S/38 / AS/400 / iSeries uses a flat 64 bit linear address space and is
probably one of the most secure systems available. It achieves this with
hardware bounds checking on memory reference and by making pointer
manipulation a privileged instruction. It also provides hardware support
for capabilities checking for each object - data or code with all objects
residing in the virtual address space of the system.
Anonymous
a b à CPUs
July 1, 2004 3:31:20 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

RusH wrote:
> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote :
>
>
>>Video editing. People edit home movies. They can quite happily eat
>>
>>>4GB of disk doing that. A friend of mine was complaining of his
>>
>>32bit app tripping up at > 2GB files, so he had to split the files
>>up. The final result was only about 10 mins long too. :( 
>
>
> thats FAT limitations

Unlikely, he is running Windows XP.

I can think of a couple of reasons why :
1) The application using signed 32 bit ints as a file pointer (doh)
2) The OS simply not allowing the app to Mem map anything > 2Gb in
size. IIRC NT used to have a 2Gb address space for the user on 32bit
platforms, I should try and find out if that's the case with XP, but
I *really* CBA. :) 

Cheers,
Rupert
Anonymous
a b à CPUs
July 1, 2004 3:31:21 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.sys.ibm.pc.hardware.chips Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
> RusH wrote:
> >>32bit app tripping up at > 2GB files, so he had to split the files
> >>up. The final result was only about 10 mins long too. :( 
> >
> > thats FAT limitations
>
> Unlikely, he is running Windows XP.

Plenty of Windows XP (especially XP Home) users still use FAT32, which is
still limited in terms of its maximum file sizes.

--
Nate Edel http://www.nkedel.com/

"Wanted: One .Sig-quote. Must work cheap."
Anonymous
a b à CPUs
July 1, 2004 3:42:34 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Rupert Pigott" <roo@try-removing-this.darkboong.demon.co.uk> wrote in
message news:1088634677.520726@teapot.planet.gong...
> RusH wrote:
> > Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote :
> >
> >
> >>Video editing. People edit home movies. They can quite happily eat
> >>
> >>>4GB of disk doing that. A friend of mine was complaining of his
> >>
> >>32bit app tripping up at > 2GB files, so he had to split the files
> >>up. The final result was only about 10 mins long too. :( 
> >
> >
> > thats FAT limitations
>
> Unlikely, he is running Windows XP.
>
> I can think of a couple of reasons why :
> 1) The application using signed 32 bit ints as a file pointer (doh)
> 2) The OS simply not allowing the app to Mem map anything > 2Gb in
> size. IIRC NT used to have a 2Gb address space for the user on 32bit
> platforms, I should try and find out if that's the case with XP, but
> I *really* CBA. :) 
>
> Cheers,
> Rupert
>

You can install an update to XP to allow 3GB user space addressing. 3GT I
think? I'd have to go look it up on Microsofts web site....

Carlo
Anonymous
a b à CPUs
July 1, 2004 3:46:59 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Judd" <IhateSpam@stopspam.com> wrote in message
news:10e69cb3on6rkba@corp.supernews.com...
>
> "Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
> news:fts5e0536f09o7c2cj6g0no6jomnvre9u2@4ax.com...
> > On Wed, 30 Jun 2004 14:06:51 +0100, phil@kantaka.co.uk (Philip
> > Armstrong) wrote:
> > >In article <MPG.1b4b7080294c8bd898969c@news.individual.net>,
> > >Keith R. Williams <krw@att.bizzzz> wrote:
> What is taking them so long? Answer = Intel! If 64-bit was such a big
deal
> for consumers, we would be looking at Itanium Workstations. 64-bit = not
> big deal = why MS hasn't pushed it very hard. Wait for Intel's 80+
percent
> market share to join in and then release something for OEM's to sell their
> i64 and AMD64 systems. It's a very smart business move.
>
>

That or the simple fact that MS can't deliver anything on time

Carlo
Anonymous
a b à CPUs
July 1, 2004 3:50:13 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

mike <mike@mike.net> wrote:
> The S/38 / AS/400 / iSeries uses a flat 64 bit linear address space
> and is probably one of the most secure systems available. It
> achieves this with hardware bounds checking on memory reference and
> by making pointer manipulation a privileged instruction. It also
> provides hardware support for capabilities checking for each object -
> data or code with all objects residing in the virtual address space
> of the system.

What do you mean it makes pointer manipulation a privileged instruction?
What kind of manipulation are we talking about that would cause a privilege
exception?

Yousuf Khan
Anonymous
a b à CPUs
July 1, 2004 3:50:14 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:VkIEc.30$65O.23@news04.bloor.is.net.cable.rogers.com...
> mike <mike@mike.net> wrote:
> > The S/38 / AS/400 / iSeries uses a flat 64 bit linear address
space
> > and is probably one of the most secure systems available. It
> > achieves this with hardware bounds checking on memory reference and
> > by making pointer manipulation a privileged instruction. It also
> > provides hardware support for capabilities checking for each
object -
> > data or code with all objects residing in the virtual address space
> > of the system.
>
> What do you mean it makes pointer manipulation a privileged
instruction?
> What kind of manipulation are we talking about that would cause a
privilege
> exception?
>
> Yousuf Khan
>
Any kind. Pointers have tag bits.
>
Anonymous
a b à CPUs
July 1, 2004 3:50:14 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Yousuf Khan wrote:
> What do you mean it makes pointer manipulation a privileged instruction?
> What kind of manipulation are we talking about that would cause a privilege
> exception?

I would highly recommend reading the book by Frank Soltis about how the
internals of the AS/400 (or whatever letter of the alphabet it is this
week) works.

Compared to current operating systems, it functions in a totally different
way, with similar hardware but some extra hardware assist. That includes
the pointer mechanism, as well as the memory system.

(My pet theory is that eventually Java will re-invent every portion of
the AS/400. Give it another decade or so.)

Roger
July 1, 2004 5:56:17 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Yousuf Khan" <bbbl67@ezrs.com> wrote in message
news:VkIEc.30$65O.23@news04.bloor.is.net.cable.rogers.com...
> mike <mike@mike.net> wrote:
> > The S/38 / AS/400 / iSeries uses a flat 64 bit linear address space
> > and is probably one of the most secure systems available. It
> > achieves this with hardware bounds checking on memory reference and
> > by making pointer manipulation a privileged instruction. It also
> > provides hardware support for capabilities checking for each object -
> > data or code with all objects residing in the virtual address space
> > of the system.
>
> What do you mean it makes pointer manipulation a privileged instruction?
> What kind of manipulation are we talking about that would cause a
privilege
> exception?
>
> Yousuf Khan
>
>
In the AS/400 you can not move an arbitrary integer value to a pointer
variable and then use that pointer. That is you can not modify memory at
that pointer address or jump to that address or call a program at that
address, etc. Pointers are protected objects with specific "capabilities".
Initial values are set by interrogating the kernel for the address of an
object. You can increment or decrement within the bounds of an object but
you can not change the object type and therefore it's capabilities or change
the pointer. This stops execution of data modified by a worm or virus, it
stops buffer overflows, etc. Any attempt to break these rules raises an
interrupt similar to a floating point underflow or overflow or some other
machine exception.
Anonymous
a b à CPUs
July 1, 2004 6:21:17 AM

Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 30 Jun 2004 14:42:01 -0600, "Judd" <IhateSpam@stopspam.com>
wrote:
>"Tony Hill" <hilla_nospam_20@yahoo.ca> wrote in message
>news:fts5e0536f09o7c2cj6g0no6jomnvre9u2@4ax.com...
>>
>> That's the last of 'em then. It looks like EVERY major Linux
>> distribution has managed to beat Microsoft to market with a usable
>> AMD64/x86-64 operating system (at least as long as you don't count
>> Slackware as a "major distribution", which most people don't these
>> days). SuSE, RedHat, Mandrake, Gentoo, Turbolinux and now Debian are
>> all out there now. Debian's distribution is still in the "unstable"
>> stream, but those who know Debian should know that Debian "unstable"
>> is roughly equivalent to pre-SP1 release of Windows rather than a beta
>> version.
>>
>> Ohh, and FreeBSD and OpenBSD also have full support for AMD64 as well.
>> Kind of makes you wonder just what the heck is taking MS so long?!
>
>What is taking them so long? Answer = Intel! If 64-bit was such a big deal
>for consumers, we would be looking at Itanium Workstations. 64-bit = not
>big deal = why MS hasn't pushed it very hard. Wait for Intel's 80+ percent
>market share to join in and then release something for OEM's to sell their
>i64 and AMD64 systems. It's a very smart business move.

Smart business move for who?!? For Intel maybe, but how exactly does
it help MS' cause? It's not like they're selling more by not having a
product now and I can't see any way that it would help them long-term.
Not releasing the product until the end of this year or early next
year (it looks like 64-bit Windows is being delayed *again*) is only
going to hurt Microsoft relative to Linux.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
Anonymous
a b à CPUs
July 1, 2004 6:21:18 AM

Archived from groups: comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Wed, 30 Jun 2004 22:05:58 +0000 (UTC), RusH <logistyka1@pf.pl>
wrote:
>Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote :
>
>>
>> Video editing. People edit home movies. They can quite happily eat
>> > 4GB of disk doing that. A friend of mine was complaining of his
>> 32bit app tripping up at > 2GB files, so he had to split the files
>> up. The final result was only about 10 mins long too. :( 
>
>thats FAT limitations

Not this time (though it could be in other situations). FAT32 has a
limit on file sizes of 4GB (unsigned 32-bit int), so if it's tripping
up at 2.0GB (signed 32-bit int) he's looking at something else, almost
certainly memory limitations. 2GB is the maximum memory you can
allocate in a 32-bit app, so to deal with videos larger than that you
either need to kludge the splitting up of videos into < 2GB chunks
through software of manually do it like the above poster.

There definitely are situations where 64-bits would help on the
desktop TODAY. Those situations are only going to become more common
over the next few years that it'll take for the software to arrive.
IMO AMD was late in releasing a 64-bit x86 processor, it should have
been here 3-5 years ago. Intel is just more late (and, as per usual,
Microsoft is REALLY late).

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