Is Itanium the first 64-bit casualty?

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Toggle sidebar Toggle sidebar
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
 
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
 
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.
 
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
 
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
 
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.
 
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
 
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
 
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.
 
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
 
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.
 
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
 
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
 
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."
 
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.
 
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
 
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."
 
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
 
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
 
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
 
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.
>
 
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
 
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.
 
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
 
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
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom