Is Itanium the first 64-bit casualty?

  • Thread starter Thread starter Yousuf Khan
  • Start date Start date
Tony Hill said:
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.
 
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
 
Nick Maclaren said:
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
 
Rupert Pigott said:
Video editing. People edit home movies. They can quite happily eat
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 said:
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
 
Judd said:
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
 
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.
 
mike said:
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
 
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
 
Yousuf Khan said:
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.
 
Yousuf Khan said:
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.
 
Yousuf said:
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
 
In comp.sys.ibm.pc.hardware.chips CJT said:
Sure, but that stuff doesn't need a linear address space. Segments
work just fine.

Segments aren't the issue; they're limited to a 4GB linear space.

PAE sucks, though it's better than a hard limit.
 
Rupert Pigott said:
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
 
In comp.sys.ibm.pc.hardware.chips Rupert Pigott said:
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.
 
Judd said:
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
 
In comp.sys.ibm.pc.hardware.chips Stephen Sprunk said:
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...
 
Roger Binns said:
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

Yes the Frank Soltis book is excellent. I think Frank said that when Java
came out the /400 people in IBM's Rochester lab kicked themselves for not
previously releasing a similar software version of the /400 virtual machine
since there were so many parallel concepts with Java especially in the area
of code validation and security.
 
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.
 
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).
 
Back
Top