Slashdot Mirror
Compaq: Alpha is Better Than IA-64
Compaq released a document (it's in PDF format) that states that their Alpha is better then IA-64 (Intel next generation Itanium Processor). The document compares Alpha (and future generations of Alpha) against the IA-64 (I hate this "Itanium" name - where do they get these names anyway?). Certainly worth a read. What do you think, folks?
I am not an expert in CPUs and I haven't read a basic CPU architecture schematic since the original Pentium came out. Therefore I cannot judge the merits of this document.
I would like to point out that this document is from Compaq, so we must suspect that the document was written with a Pro-Alpha slant to begin with. Its like Intel coming out with a paper debating the merits of the Pentium III vs. the Athlon Processor.
Manung
The alpha processors are not changing their niche in the computer market. They are ripping fast - and Dec first and now Compaq plays to the supercomputing crowd. The XP series motherboards and 21264 chips simply rip any other motherboard/chipset out there.
However, they cost too much for anyone except a supercomputing hound. If Compaq would drop Dec's insanely idiotic OS and component licensing scheme and aid linux on alphas, they might stand a chance of making a LOT of money selling hardware. As is, people buy ten times more alphas one chip generation late and run linux instead of OSF.
Anyone interested should see the linux alpha compilers available. cc is a small improvement, and ForTran is a LARGE improvement.
http://www.unix.digital.com/linux/software.htm
But still, Itanium will come out, and an Itanium box will offer slightly less than half the floating point speed, and it will cost about 1/4th of the fast alpha box from Compaq. And the alpha motherboards will still make it tough to support third party peripherals. And Itanium will dominate the 64 bit market. And Alpha will own the supercomputing market.
It's going to be tough for Digital to edge into Intel's market, mainly because nearly all consumers have been brainwashed to look for the "Intel Inside" Logo.
"Excuse me sir, is this an Itanium?"
"No, Ma'am. This is an Alpha processor by Digital corporation."
"Well Shit, I've never heard of THEM. Where are your Itanium machines?"
Not only that, but Alphas have never really been geared toward the general consumer. Most have been high-end server machines. Also, as far as I know, Alpha won't run x86 code because it uses a different architecture. (Please correct me if I'm wrong.)
"Alpha, huh?
"No Ma'am, this machine runs a Unix variant, and has a different architecture than Intel processors."
"Well Shit, I NEED those programs. Where are your Itanium machines?"
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
The best feature of the Alpha is that they are available. Or are they?
I've wanted an Alpha for a while now because (for various geeky reasons: fun, supposed speed, fun, assembly programming, and fun) but I've never been able to find a reasonably priced machine (even for auction) OR good instructions on how to build them.
If Compaq were smart (note the use of a counterfactual conditional) they'd hype Linux on Alpha like all get out. What better way to screw MS than to give geeks hardware that Windows can't touch (anymore)?
But does Compaq want to screw MS? If they're smart they do: Compaq produces an ostensibly competing OS.
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
I'm also not an OS (or arch) expert, BUT I think another advantage is data bus (and register) size. You've already mentioned the address bus with your 4GB physical RAM, but you've neglected to mention that you can get (and use) a full 64 bit word from that address with a 64 bit OS.
---
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
How do they come up with these processor names, you ask? An astute question, one that requires some of Intel and AMD's most closely-kept company secrets. A friend of mine who used to work for Intel managed to smuggle the following Perl script out, shortly before he was fired. Here it is:
./pnames.pl ./pnames.pl ./pnames.pl ./pnames.pl ./pnames.pl ./pnames-pl
#!/bin/perl
# Copyright (C) 1997 Intel Corporation
# This is a proprietary Intel perl script.
@prefix = ( "Pent", "It", "Max", "Ath", "Cort", "Trit" );
@suffix = ( "ium", "alon", "ex", "anium", "oricon", "agon",
"on", "eres", "obos", "ymede", "itan", "erion" );
@tag = ( "II", "III", "IV", "Pro", "MMX", "Deluxe" );
srand;
printf( "%s%s %s\n", $prefix[rand 6], $suffix[rand 12], $tag[rand 6] );
So if we run this script, we can see where the names come from:
sg1 237%
Cortium II
sg1 238%
Pentalon IV
sg1 239%
Penteres III
sg1 240%
Athalon Pro
sg1 241%
Pentitan II
sg1 242%
Maxymede MMX
Please show discretion when you refer this script to others. It is, after all, an Intel proprietary secret and should therefore only be shared with others on a "need-to-know" basis.
We're going down, in a spiral to the ground
Not anymore. Check this out.
-BrentWhile I don't know enough about chip design (and also don't really care) to judge the chips on their technical merits, the bottom line seems to be that it doesn't matter how good a chip you make if you can't ship/sell it in decent volumes. We all know that the early Intel chips were pretty much garbage, yet Intel today is the king of the chip world. Why? Because most (99+%) of the machines sold feature intel compatible chips.
As long as you can't go to an average computer store and pick up a PPC, Alpha or Sparc chip and build your own computer from it, the general population will not even know they exist. Don't get me wrong: I would like it if all of a sudden the availability of these chips were equal to the Intel chips, but that's just not the reality of the marketplace. With the switch to the 64-bit architecture there may be an opening in the market which will allow these chips to become a more available product in the eyes of the average consumer. But as long as the Intel/MS duopoly (which is showing signs of fracturing) is as dominant as it is now, that's just not going to happen.
There are many organizations that still use VMS for their continuous computing appliations. Alpha is idea for that application.
Ok, I'll try.
:-)
Macin... Linux.
Ma... Linux
Linux.
Linux.
Nope, it just doesn't seem to come out.
(the irony is I'm posting this from a mac)
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
-----------
"You can't shake the Devil's hand and say you're only kidding."
Looks like Compaq has a chip on its shoulder...
1. It's the other way around. "it's" is short for "it is"; "its" is the possessive pronoun.
:)
2. The blurb clearly implied that the PDF format was Compaq's.
3. I had nothing good to say about the article
To the editors: your English is as bad as your Perl. Please go back to grade school.
Getting linux to boot on an IA-64 cannot be done with a quick hack. The IA-64 runs EPIC architecture, not RISC like the Alphas.
If they want some exposure or to compete for the desktop market (Which is where the money is) they need to slash the price on the chips and sell them near cost. Sure they take a hit for R&D but the volume of sales should go up. If they don't have a good strong presence by the time IA64 hits, they may as well close up their doors and go home.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
That darned closed-source programming gets people into bad habits..
/bin/perl -w
First of all with current versions of Perl the srand call is not needed.
Secondly I would recommend using qw() because it is more legible for lists.
Thirdly a little information hiding works well. There is no need to have to synchronize the length of the list with the argument to rand.
And -w is always worthwhile
So rewritten we get
#!
@prefix = qw(Pent It Max Ath Cort Trit);
@suffix = qw(ium alon ex anium oricon agon on eres obos ymede itan erion);
@tag = qw(II III IV Pro MMS Deluxe);
printf ("%s%s %s\n", &rand_elt(@prefix), &rand_elt(@suffix), &rand_elt(@tag));
sub rand_elt {
return $_[rand(scalar @_)];
}
Not that it matters in this case, but good habits are good habits...
:-P
Cheers,
Ben
PS To get the code to look like code use the TT tag, and to get indents use . Warning, IE may mess up the indented space on a cut-and-paste...
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
Don't forget that Intel actually manufactures some AXP CPU's! Digital sold their Alpha Fab plants. I think API makes them as well as Samsung(?) and Intel.
--GnrcMan--
PDF's the format for people who actually want to have a say in how people view their documents. HTML's cool, but it's very limited, typographically and such... There are so many effects you can accomplish via PDF (using Word, Quark, Pagemaker, Illustrator, etc...) that are just impossible to do with HTML...
Besides which, readers are free for just about every platform (Linux included, I believe... and if the official version isn't available - there's surely an opensource reader....)
So, get over it!
:)
(from the back of my Miata (DECspeak for Alpha 500a)):
Model No.: PBPSMIATA
Tested to comply with FCC Standards
For Home or Office Use
This Class B digital apparatus meets all requirements of the Canadian Interference-Causing Equipment Regulations.
(repeated in French)
--GnrcMan--
While I'm not a programmer and therefore can't really contribute much to the cause, I still wonder why there has been no effort to make an opensource emulator... x86 to Alpha... maybe x86 to SPARC... x86 to PowerPC.... and two way, as well... though i suspect the main use would be to run x86 software on other platforms... Wouldn't that be great? And why is there no effort that I can find?
Apologies for potential off-topic.
:)
Let's port this to all other languages like LISP et al.
I will do the easy one and port it to C.
// Copyright (C) 1997 Intel Corporation
// This is a proprietary Intel C program.
static const char * prefix [ ] =
{ "Pent", "It", "Max", "Ath", "Cort", "Trit" };
static const char * suffix [ ] =
{ "ium", "alon", "ex", "anium", "oricon", "agon", "on", "eres", obos", "ymede", "itan", "erion" };
static const char * tag [ ] =
{ "II", "III", "IV", "Pro", "MMX", "Deluxe" };
int
main ( void )
{
srand ( 0 );
printf ( "%s%s %s\n",
prefix [ rand ( ) % ( sizeof ( prefix ) / sizeof ( prefix [ 0 ] ) ],
suffix [ rand ( ) % ( sizeof ( suffix ) / sizeof ( suffix [ 0 ] ) ],
tag [ rand ( ) % ( sizeof ( tag ) / sizeof ( tag [ 0 ] ) ] );
return 0;
}
P.S. Yeah, I know, I should write a perl to C printer, but then the post would be too long.
For I am not master coder yet who can code a super short compressed one-line self-compiling compiler to fit as a post.
Any challenger care to respond with one?
P.P.S. Back to doing some real coding.
Corrinne Yu
3D Game Engine Programmer
3D Realms/Apogee
Corrinne Yu
3D Game Engine Programmer
You are right
--GnrcMan--
No...Win2K is currently a 32 bit platform. Even the Alpha versions were the same 32 bit platform. Nt64 is in development.
--GnrcMan--
I hear it already runs on IA64. Apparently Intel has been dumping quite a few resources into ensuring that this is the case.
--GnrcMan--
Easy way to remember this:
the possessive form does not possess an apostrophe.
so, the possessive form isn't.
Uhhm...try this:
:)
Main Entry: order of magnitude
Date: 1875
: a range of magnitude extending from some value to ten times that value
and
Main Entry: magnitude
Pronunciation: 'mag-n&-"tüd, -"tyüd
Function: noun
Etymology: Middle English, from Latin magnitudo, from magnus
Date: 15th century
1 a : great size or extent b (1) : spatial quality : SIZE (2) : QUANTITY, NUMBER
2 : the importance, quality, or caliber of something
3 : a number representing the intrinsic or apparent brightness of a celestial body on a logarithmic scale in which an increase of one unit corresponds to a reduction in the brightness of light by a factor of 2.512
4 : a numerical quantitative measure expressed usually as a multiple of a standard unit
Seems like they have an inkling.
--GnrcMan--
I'm sure everyone noticed the portion of the doc that mentioned that proper use of the IA64 platform could inflate the size of binaries by almost 33%
33% ??
I guess Intel really is a 'Microsoft Strategic Partner! They're helping them with code bloat!!
.sig: Now legally binding!
uh, it's gramm a r.
I can't help get the feeling that the chip get it's name from the Curator of the Planitarium in South Park.
"welcome to the Plani-arium"
Vs
"Our new chip will be called: I-anium!"
The secret of success is honesty and fair dealing. If you can fake those, you've got it made. (Marx)
You can find inexpensive Alphas. www.dcginc.com sells complete Alpha systems for $1800-$5500 and bare bone systems for much less. Alphas CAN run 32 bit code under NT using the FX32! Emulator.
32 bit x86 code no less... Also, there is support for 32 bit x86 Linux binaries available (in Linux of course.) How well it actually works is best left for someone else to answer. I'm suprised that so many people thought there was no x86 emulation available.
Of course, the emulation isn't quite as important under Linux as it is under Windows since most software for Linux is open source and able to be compiled natively. Note that I am NOT implying that it's always as easy as simply recompiling the source...
BTW, doesn't seem like a great idea to go with an Alpha/NT combo these days anyway. Microsoft ceased development of NT5/Win2k/whatever for the Alpha. Presumably because they need to focus on rigging it to work with the IA64 first. I wonder if Windows for the IA64 will end up being enough 64 bit code to call it a 64 bit OS and as much of the old 32 bit code as they can get away running under emulation. Any guesses?
numb
Not available?
Sure, the chips are expensive, but what Alpha processors need is marketing not necessarily pricing.
And 99% of computers are shipping with Intel processors? Guess you missed AMD having the majority of computer sales a couple months ago (at over 40%) or the iMac's surprising success.
- Michael T. Babcock (Yes, I blog)
This white paper is interesting, if non-objective. In my opinion, the authors are insufficiently careful to distinguish between irreducible architectural advantages and disadvantages and the (temporary) advandates and disadvantages resulting from current implementation decisions. They are also a little slippery about identifying which features are already present in Alpha implementations and which are not yet delivered (e.g. SMT).
The implementation of simultaneous multithreading is something I very much would like to see. I'm impressed that they're able to do it as simply as this paper seems to imply.
One Alpha advantage (one that I think falls in the irreducible category) that I've never seen Digital/Compaq play up is the angle of binary compatibility of the Alpha instruction stream across different implementaions of Alpha. A binary executable that the compiler has tuned/targeted to a specific implementation of Alpha will still run, perhaps not quite optimally, on a later implementation.
Out-of-order execution is key, here. Because the programmer (or compiler) have to be explicit (with memory barrier instructions) about dependencies that might otherwise be hidden, the instruction stream in the binary executable file documents an idealized instruction execution order -- but any execution order that achieves the same result is also acceptable.
More outstanding data fetches, larger out-of-order instruction queue and wider simultaneous issue all work together to transparently make the old code work better. I haven't seen where increasing the VLIW bundle from 3 instructions to 6 instructions, for instance, would be as transparent -- so there's a much stronger need to recompile and maintain separate binaries targeting the various implementations of IA64.
If you do a lot of very CPU intensive tasks, the alpha is quite a bit faster than a comparable x86 box. ...) is x86 only. If you need any of those, An alpha is not the right choice for you.
Other stuff (disk I/O, etc) is not faster than x86, and some hardware (e.g. many recent 3D graphics boards) can't be used in alphas.
Also, you should be aware of the fact that most closed-source Linux software (StarOffice, Netscape, Civ3,
This message is provided under the terms outlined at http://www.bero.org/terms.html
It's going to be tough for Digital to edge into Intel's market, mainly because nearly all consumers have been brainwashed to look for the "Intel Inside" Logo.
I seriously doubt a consumer is going to want an Itanium. Or even an Alpha. These chips are designed as server and technical computing workhorses.
Like with the Alpha, all the operating systems and applications will need to be ported to the new IA-64 architecture to see any useful speed gain. All reports indicate that the on-board x86 compatibility is dog slow, with no appreciable performance gain over Pentium or Athalon chips. Why should gran'ma buy a $5000 Itanium box when the $999 iMac will run rings around it when running Quicken or MS Office?
Then there is the issue of native software: Linux, and NetBSD are gimmies. HP-UX is going to be forced marched to IA-64 (HP originally developed EPIC for the HP9000). IRIX and SCO are "definite maybes".
Sun and Microsoft, on the other hand, will probably port their OS to the platform in hopes of killing it. Microsoft had ports of NT on x86, PowerPC, MiPS and Alpha. Only x86 remains. Like with the older RISC architectures, MS will port and support the platform for a little while, but won't port it's applications, and won't promote their OS on anything other than x86. This way, Microsoft can keep control of their hardware market, and deny competitors popular support for their primary platform. And, when the market drops out, MS can quietly discontinue NT for IA-64, and place the blame squarely on Intel; just as they've blamed Compaq, Apple, and SGI for the failure of NT on RISC. Sun has a cross-platform strategy with similar goals: get them hooked on Solaris, and then entice them over to SPARC, where the applications are.
MS likes x86 becuase it -owns- x86. Linux will always be an also-ran on x86: merely a "Hobbyist's OS". The blind loyalty to intel and x86 I find expressed here is disconcerting. The only thing that will allow Linux to overcome proprietary systems is -ubiquity-, and that means cross-platform parity. Use the fastest and the best when available. That, more often than not, means Alpha.
SoupIsGood Food
It's very simple really. Check out this article in Salon for details.
cjs
The world's most portable OS: http://www.netbsd.org.
P6's can use various tricks to access more than 4GB, but only by using yucky segmentation techniques. At any one moment, only 4GB can be addressed because that's all 32 bits allow. You can't mmap in a 5GB file, or use an array of 550 million doubles. A 64-bit processor can access many petabytes-- directly. Not something useful on most app servers, but the database, video and science folks sure like it.
Following the suggestion, here are a few ports of the above program to some popular languages (substitute underscores for spaces when obvious):
:P
* Scheme
(let ((rand-elt
___________(lambda (l)
________________(list-ref l (round (rand (length l))))))
______(prefix '(Pent It Max Ath Cort Trit))
______(suffix '(ium alon ex anium oricon agon))
______(tag '(II III IV Pro MMX Deluxe)))
_____(begin
__________(display (rand-elt prefix))
__________(display (rand-elt suffix))
__________(display (rand-elt tag))
__________(newline)))
* Python
def rand_elt(list):
____list[int(rand(len(list)))]
prefix = ["Pent", "It", "Max", "Ath", "Cort", "Trit"]
suffix = ["ium", "alon", "ex", "anium" "oricon", "agon"]
tag = ["II", "III", "IV", "Pro", "MMX", "Deluxe"]
s = rand_elt(prefix) + ' ' + rand_elt(suffix) + ' ' + rand_elt(tag) + '\n'
print s
That's all for now... I seem to have run out of creativity
To the editors: your English is as bad as your Perl. Please go back to grade school.
I'm not saying that they're using it because it might support this or that, but wouldn't it be nice if there was that option???
If x86 Linux is headed towards the mainstream, then it's RISC cousins need to be able to have a mechanism in order to use all the software available to x86, otherwise they'll always be treated as second rate to x86.
And yeah, running Oracle in emulation would be just dumb... but for something not as performance hungry, like WordPerfect or Opera, it'd be nice to have the option, i'd think...
Almost certainly not. You do not have to use the segmented addressing more to access more than 4GB of physical memory - you may not be able to have all of it mapped in at the same time, but you could map it in and out dynamically, or give 4GB-or-less chunks to various processes.
In fact, the x86 segmented mode - which is not new in the P6 processors (PPro, PII, PIII), but has been around in its current form since the 386, and existed with smaller addresses in the 286 - doesn't even help. The x86 MMU maps 48-bit segmented addresses (which any OS running in protected mode uses, although most of them set up "trivial" segments and, unless they're running 16-bit programs that use 286-style segmentation to boost their address space size, don't really make use of it) to 32-bit linear addresses; those 32-bit linear addresses are then translated to physical addresses through the page table, if paging has been enabled (which it is, in most x86 OSes, e.g. Windows OT and NT, OS/2, Solaris, Linux, BSD, etc., etc.).
What's new in the P6 processors is the ability to specify page tables that generate 36-bit physical addresses rather than 32-bit physical addresses (an ability that at least some other 32-bit processors, e.g. SPARCs with the SPARC Reference MMU, have had). You need that ability and you need a memory bus that puts out more than 32 bits of physical address; I think some 32-bit platforms have had that, and some high-end "PC" platforms may have it.
srand()
split("Pent It Max Ath Cort Trit", PRE)
split("ium alon ex anium oricon agon on eres obos ymede itan erion", SUF)
split("II III IV Pro MMX Deluxe", T)
b=rand()*100; c=rand()*100; d=rand()*100
CONVFMT = "%2i"
a=b ""
x=c ""
y=d ""
printf "%s%s %s\n", PRE[a%6 + 1], SUF[x%12 + 1], T[y%6 + 1]
}
--
"One World, one Web, one Program" - Microsoft promotional ad
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
I spend most of my day laying out pages using Quark.... A lot of these pages also need to be available online, and we've found that the best way to do so, when formatting is an issue, is to use PDF's.
CSS is relatively new - yes, the spec's been out for a while, but only now do most browsers have somewhat decent support for it. And Mozilla I wouldn't even consider, being that it's pretty much Alpha software... I haven't ventured to try it with Linux (because at this point i feel Linux is best suited as a server OS), but on the Mac, Win 9x, and Win NT, I've found it to be horribly unstable. I also haven't fully investigated Opera, which leaves us with just Netscape and IE...
Of those two, IE seems to more fully implement CSS... version 5 is much better than 4.5, but 5 is Windows only where as 4.5 was also available for the Mac.
Acrobat reader is available for probably as many or more platforms as Netscape Communicator/Navigator. It also (Thanks to QuarkXPress) has MUCH better typographical control than CSS. That's probably because the programs being used to generate PDF's are much more mature than those used to genertate HTML, XML, etc...
You can't generate ligatures with CSS... nor can you have nearly as wide a choice of fonts... With PDF, I don't care what font's you have available, because i can embed them within my document. And also, using PDF's, you're extremely unlikely to need to tinker with the file/code at all, where as anything where detail is that much an issue in HTML, you always need to wade through the code.
So, to summarize... The tools to generate PDF's are much more advanced than the ones to make CSS/HTML. The tools to view PDF's are also much more advanced than those currently available for HTML, in that the designer/author has so much more control over the final appearance of their document than can ever be achieved with CSS/HTML... Yes, I could specify that i'd like this font to appear as Adobe Bembo, but if that's not available on your machine, you may end up with Times, or whatever generic Serif font is available.
That's all in my opinion, of course..
That should've been "You do not have to use the segmented addressing mode".
As per my parenthetical note, you do, in a sense, have to use it to use paging, but you don't have to use it in a non-trivial fashion; most (if not all) x86 OSes don't use full 48-bit addresses, they just use 32-bit addresses with implicit segment numbers, and set up the segments to overlap so that those 32-bit addresses translate trivially to 32-bit linear addresses.
As for FreeBSD vs. NetBSD, I think none of the BSDs map the entire kernel address space into virtual memory; I don't think Solaris does, either - I think they added support for >4GB of physical memory in 2.6 or 7.
MIPS does; however, POWER and Alpha may not. The first POWER and Alpha processors were superscalar (PowerPC being a descendant of POWER).
You're confusing (as per my followup to the person who responded to you) the support for 36-bit physical addresses in the P6 processors (PPro, PII, PIII) with the support for 48-bit segmented virtual addresses, which dates back to the 386 (and which is a 32-bit-segment-offset version of the 286's segmentation). You don't need to use 48-bit virtual addresses, in their full shining glory, to get more than 32 bits of physical address.
There's code in the 2.3 kernel from, if I remember correctly, Siemens, to do exactly that.
I don't know offhand whether any of the BSDs support it; I think either Solaris 2.6 or Solaris 7 do.
So that would mean you've looked/worked on the NT source right? Is it really as bad as everybody claims it is? Would you trust your life's work to this OS? Inquiring minds want to know!
I could tell you...but I'd have to kill you. Seriously, though I've seen a small part of the NT source code, I worked on the compiler(Visual C++ for Alpha). So I'm in no position to comment, even if it wouldn't bring the wrath of MS apon my head. I will let you in on a little secret though. At home I run Linux. :)
--GnrcMan--
The Alpha, MIPS, and PowerPC architectures date from the era when the goal was one instruction per clock cycle and a nice, simple CPU with a fast clock.
Bzzzt..wrong. From the Alpha Architecture Reference Manual, preface, first edition:
We concluded that the remaining factor of 100 would have to come from other design dimentions. If you cannot make the clock faster, the next dimension is to do more work per clock cycle. So the Alpha architecture is focused on allowing implementations that issue many instructions every clock cycle.
down the page a little:
These three dimensions therefore formed part of our design framework:
* Gracefully allow fast cycle time implementations
* Gracefully allow multiple-instruction-issue implementations
* Gracefully allow multiple-processor implementations
It goes on to list specific design decisions made to meet these goals. When they designed the Alpha, they had a 25 year design horizon. BTW, that preface was written in 1992.
--GnrcMan--
64-bits buys other stuff, too. For example, larger file systems. Most 32-bit OS'es give you a 2GB or 4GB file or volume size because that conveniently fits in their 32-bit integers. But things get dicey when you start working with digital video, large databases, etc. because you start hitting those limitations. My biggest problem [off topic] with 64-bits is that nobody writes good 64-bit safe code. Any time I try porting some 32-bit package to my dearly loved Alpha's I get nailed by idiots casting 64-bit pointers to 32-bit ints. People, please don't assume sizeof(long) == sizeof(void *)!
One viagra in the morning before work; I just know I'm gonna be screwed
But yeah, it would be nice for code posting. Oh well, just another example of a few sh*t-heads screwing things up for everyone else...
________________________
Corporate Jenga: You take a blockhead from the bottom and you put him on top...
The segmentation tricks don't help much, if at all; the x86 MMU maps 48-bit segmented addresses to 32-bit linear addresses, and then maps 32-bit linear addresses to 32-bit physical addresses or, on P6, 36-bit physical addresses if that feature is being used by the OS. Thus, you can't get at more than 4GB of linear address space at any one time - you'd have to map segments into and out of the linear address space, although I guess you could do that on demand, so that it's somewhat transparent (although still potentially slow).
However, all that does is, as you note, prevent you from addressing more than 4GB at any one time; stuff can be mapped into or out of the address space (which I guess could be considered a "yucky segmentation technique" - you're an old-timer like me, so you may remember the use of that on some versions of PDP-11 UNIX and various PDP-11 OSes from Digital), and you can have more than one address space by having more than one process.
More than 4GB of physical memory is more useful on machines that let you get at it all at once, in a single address space, but it probably has some use even on platforms such as x86, SPARC V7/V8 with SPARC Reference MMU, etc. that have only 32-bit linear addresses but support more than 32 bits of physical address.
...in a single instruction. You can do 64-bit arithmetic on 32-bit platforms (for example, most if not all modern C compilers for 32-bit platforms support long long int or some equivalent 64-bit integral data type), but the operations generally have to be synthesized from multiple instructions (typically done inline for most operations, although multiplication and division, and possibly others, might be done in a subroutine), with each instruction working on 32 bits at a time, and may require more registers, as the non-floating-point registers on a 32-bit platform are typically 32 bits wide.
32-bit addressing is limited to 4GB of physical RAM at any instant, but you can handle more than 4GB of physical memory in multiple 4GB-or-less process address spaces, or handle it by mapping pages in and out of a given address space, on a platform with 32-bit virtual addresses.
...and there's a patch from, as I remember, Siemens, which, as I remember, was accepted for the 2.3 kernel, to do that on x86, presumably in the fashion I described.
...as does x86 {Free,Net,Open}BSD, versions of NetBSD and OpenBSD on other 32-bit platforms, Solaris 2.6 and Solaris 7 on x86 and 32-bit SPARC, etc., etc., etc....
...and on Linux, with the right patch; I think that patch has also been accepted for the 2.3 kernel.
A 64-bit architecture run in 64-bit mode isn't necessary for handling more than 4GB of memory, or for seeking more than 4GB into a file - fseek() may take a 32-bit offset on those platforms, but fsetpos() could take a 64-bit offset, as could llseek(), say - but it does make it a bit more convenient (no need to muck around with mapping stuff into or out of an address space, no need to use on UNIX all the extra stuff from the Large File Summit, or to use the somewhat clumsy support in Win32 for file offsets >32 bits).
That's how it runs on Alpha - 32-bit address space and, I think, 32-bit page table entries. On Alpha you can do 32-bit page-table entries by doing NT PALcode, as, on all existing Alpha processors, TLB misses are handled in software (well, PALcode, but that's just software loaded into memory from a ROM, running in a special mode that lets it get at processor-specific internal registers), so the software (PALcode) can control what PTEs look like.
I don't know whether IA-64 will do that or not.
Yup. You don't need a 64-bit processor to do 64-bit integer operations; however, you're likely to be able to do it faster on a 64-bit processor.
On another thread here, regarding the mistaken notion that a machine with 32-bit pointers can't hold more then 2**32 memory, it seems to me that an 11/70 would allow more than 64k of memory per machine, but would only let you map in 64k per process.
Yes, 2.4 BSD allowed for overlays, as did RSX/11. This was a matter of the OS reloading some segmentation registers on request. Pentia could do similar things via the page table, should someone care to add the necessary OS calls. But it was yucky even back then. I've recomitted those brain cells to other tasks these days.