It's looking like dual graphics will be the default scenario pretty soon anyway. Not in the sense of two graphics cards as in SLI or Crossfire. But more like a combination of graphics cards and integrated graphics. Both Intel and AMD are working towards their combined CPU/GPU chips (Fusion, etc.). So in the not too distant future I can see all machines having a default integrated GPU built-in. Then high-end gamers will invariably add-in a high-end GPU. So why not make use of both resources? Instead of using either the integrated graphics or the add-in graphics, use both at the same time. It doesn't have to be for graphics alone, but it could also be used for OpenCL and DirectX 11's physics engine.
Well we'll see. Even in a two chip package, Silverthorne, depending on the power management and idling features, might net out a better total watts/hour of use. Remember that it will accomplish most tasks much more quickly than a geode will and will probably be able to get back into sleep/idle sooner.
Better Watt/hours? What do you expect they're going to be doing with these laptops, running Folding@Home simulations? The XO laptop comes with a single integrated operating system applications suite which is specially designed for this laptop. They're not going to be able to install applications into this thing, nor will they be able to change the OS.
As it happens, the OS is based on Linux, therefore Microsoft is against it, even though the OS is not really a full Linux, just a stripped-down kernel for running the customized interface. The processor happens to be AMD-based, therefore Intel is against it, even though it's not one of their consumer processors, it's one of their embedded controller processors. Both Intel and Microsoft really have nothing to be threatened by it, but neither of them can stand to have a party in which neither of them are invited, no matter how small the party.
Do you think Intel joined the project (MSFT did NOT) just to help AMD integrate the XO v2? Geode is a dead end.
I know about Silverthorne, but it looks like it isn't good enough to join XO just yet, either. The AMD Geode still has the substantial advantage of being both CPU and a chipset in the same package. So all of the power calculations are based on a single chip, so a 1.1W Geode is altogether a 1.1W product. A Silverthorne even if it is 1.0W vs. Geode's 1.1W, is going to have a substantial hit in power consumption once you add its external chipset in. Even if they can get the chipset down to the exact same power consumption as the Silverthorne processor (highly doubtful), you would then have a 1.0W CPU + 1.0W chipset = 2.0W package. Then there's the additional problem that having two chips to deal with, will substantially complicate the circuit board layout.
For this reason Intel announced that they are now working a totally new processor architecture, which will be separate from Silverthorne. They haven't released too much info about it yet, but my feeling is that it's going to be an integrated solution just like Geode. Don't expect that to be out till 2009.
I'm not sure about Intel's role in this, but Microsoft undoubtedly sees a threat beyond what's being discussed here. The threat isn't directly Negroponte and the One Laptop Per Child project, it's Linux.
In Intel's case, the reason that they're angry is because the XO laptop uses an AMD chip rather than Intel. The reason for this was really simple, AMD provided a single-chip solution (AMD Geode LX) that integrated all of the CPU and chipset functions into one chip, and thus saved power and real-estate, something which Intel has no solution for. Altogether, this single-chip solution uses up only a little over 1 Watt, which can last for 8 hours on a small low-powered battery charge. Nothing from Intel can match this.
The investors are suing because they believe that this unreported money served to inflate Dell's profits and revenues for each quarter, thus making their stock more valuable than it should've been.
When Intel first announced IA-64 around 1994, everybody assumed that it was the successor the x86 architecture, which means that it has to also be able to run x86 binaries. That also means being able to boot up into an x86 operating system and run it natively, and then run all of that OS's applications, etc. Basically it should've been able to let us keep running vanilla x86 seamlessly until we were ready for more powerful stuff. If we wanted to go to another architecture, then Power, Sparc, MIPS, and Alpha already existed at that time. Since nobody on x86 wanted to migrate to any of those other architectures, why would they want to migrate to Itanium?
Turned out that that promise was kept by the AMD64 architecture, which is really what people on x86 wanted to go towards.
Simple, they run the dual-cores at a couple of Mhz increments lower than the fastest current single-cores. That way the two slower cores together don't use up much more Watts than the fastest single core out there.
If the Oracles and BEA's of the world don't change their licensing policies, then Open Source is looming over their heads like a giant wooden caveman club. Before Open Source, these companies could've just told their customers where to go. These days they at least have to think about it.
Microsoft has at least partially come around to understanding this. A couple of months ago, AMD and Sun launched a similar initiative as what HP and Intel did this time.
Single License for Dual Core at Microsoft http://www.internetnews.com/bus-news/ar ticle.php/3 423971
Forget PowerPC, right now MS can't even bring out a port of Windows to the 64-bit extensions (called AMD64) of x86 on time! The 64-bit extensions are just a minor upgrade from the existing 32-bit x86 codebase; Microsoft was given the earliest access to AMD's hardware -- at least a year before it was put on the market. What was the result? Well, SuSE Linux had an AMD64 version available the first day the Opteron AMD64 processor was released. Now there are several distros for AMD64 from Red Hat, and others too, as well as BSD ports. By the end of this year there will even be a version of Sun's Solaris OS also available for Opteron, even though Sun started porting its OS about a year later. What about Microsoft? Well, it's now almost two years since Opteron was first put on sale, and Microsoft is still in beta-testing with its Windows port!
So does anyone seriously think with this level of incompetence, that Microsoft will be able to port a version to PPC all that quickly?
If open source is more accepted in the developing world, then the need to pirate commercial software will not be there. How can you pirate something that is already free?
I don't really think they mean 192 kiloHertz but 192 kilobits per second. There is a difference in the case of lossy-compressed audio. The higher the bps, the less lossy the quality of the audio is. And this bitrate also includes all of the channels together, not just one channel.
I think it's rather more likely that you're not reading enough between the lines. Why would Microsoft put a contract stipulation that allows the competition's OS to be included? The 'No OS' was always a wink-wink-nudge-nudge meaning non-Microsoft OS without stating as much.
Then my follow-up question would be, on a design level at least, is carrying over a 32-bit instruction set into the 64-bit processor feasible and/or trivial enough task?
The usual answer to that is "it depends." If the 32-bit ISA were sufficiently thought out in advance for future expandability, then it shouldn't be a problem, obviously. The most common example of an ISA regeneration was the x86 instruction set architecture.
For example, the x86 ISA has not just a 16-bit and a 32-bit mode, it also has a compatibility mode known as Real mode, and a more modern mode called Protected mode. So x86 has Real mode, 16-bit Protected mode, and 32-bit Protected mode. Each mode represents a generational change in the x86 ISA. Real mode represents the mode that the first ever x86 processors operated in, the 8086 and 8088. The 16-bit Protected mode represents the 286 processor, and 32-bit Protected mode represents the 386 onwards.
When they designed the 16-bit Protected mode, existing 16-bit Real mode programs couldn't run in that mode. So the 286 processor usually operated in Real mode to maintain compatibility with programs designed for 8086's. So there wasn't a really good solution put in place to run 16-bit Real mode and Protected mode applications together with the 286. So that was a poorly designed generational upgrade as far as the previous generation was concerned. But they did plan for the future and left lots of growing room for a possible 32-bit protected mode in the next generation; which made it a good generational upgrade in that sense.
When the 386 came out with the 32-bit Protected Mode, they had come up with ingenious solutions to preserve compatibility with all modes simultaneously: Real, 16- and 32-bit Protected modes! They could run programs designed for all three modes simultaneously, which made the 386 processor one of the landmark processors of the x86 ISA -- not simply because it extended the architecture out to 32-bits.
However, it did look like 32-bits was the end of the road for x86, because I really didn't think they could continue to extend x86 out to 64-bits the way it was currently setup. Intel agreed with me, and came up with Itanium processor with its IA64 or EPIC ISA, which is not compatible at all with its previous generation IA32 or x86 architecture. AMD disagreed with me, and came up with an ingenious way to extend x86 out to 64-bit, i.e. the x86-64 ISA. x86 is a series of ingenious hacks that just keep the life of the ISA going. The way AMD has implemented their x86-64, they've probably left a lot of growing room for future improvements beyond 64-bits.
So based on this similar history, and whether PPC's architecture is sufficiently flexible enough to accomodate 64-bit, IBM may have an easy job or a hard job.
That being the case, I hope like hell Apple has been doing some serious talk with IBM about doing exactly that. I love Macs, but fercrissake, they are fighting a losing battle with this MHz Myth stuff.
I don't think Apple is fighting a losing battle against a Mhz myth, they are simply fighting losing battle against the weight of more available software and hardware choices. Let's face it, this Mhz mania in the x86 world is just a recent mania, resulting from the competition between the two main x86 CPU makers, Intel and AMD. Prior to this everybody used to laugh at how pathetic x86 architecture was at scaling up in Mhz compared to other ISA's including PPC. But that didn't stop people from buying x86 PC's in the past either.
Actually, the source of incompatibility is not from whether the processor is 32-bit or 64-bit. The incompatibility comes from whether the processor's instruction set has been carried over or not. Any 64-bit processor should be able to maintain compatibility with a 32-bit processor, provided it implements the 32-bit instruction set. So the idea behind a 64-bit PowerPC would be to carry over the 32-bit instruction set intact. If it is carried over, then there's no problem, as far as 32-bit programs are concerned they will think they are still working on a 32-bit processor.
Hypertransport (as well as a built-in DRAM controller) is only useful on multiprocessor systems (I'm not downplaying their usefulness at all) The onboard DRAM controller allows each processor to have its own seperate memory (whereas many, including the IA-64, share the same memory through the system bus.) Combined with the increased multiprocessing effecinecy Hypertransport offers, the Hammer processor line seems to be clearly designed for multiprocessor systems. (Hypertransport and onboard DRAM doesn't provide any real benefit to a single-processor system)
You have a lot of overarching opinions, but not a lot of background. How could you possibly say that onboard DRAM controller doesn't provide any benefits to SP systems? All you have to do is see the history of the PC to know how foolish that statement is. Even the recent history shows that a reduction in memory latency has a greater effect on PC performance than an increase in bandwidth.
As for Hypertransport, the idea behind that is not just absolute performance increases, but also design flexibility. So the same chipset that serves as a PC chipset, may also be able to serve as an 8-way server chipset, with few design changes (perhaps by adding or subtracting a few more HTT channels). Even within a desktop environment, you can easily separate out shared PCI/AGP buses, into multiple switched PCI/AGP buses with Hypertransport underlying them. There's lots of potential even within a desktop environment.
One key here is that Hypertransport is not unique to the Hammer; SUN, HP, Motorola, SGI and Apple are all members of Hypertransport consortium, and intend to incorporate it into their processor designs.
Absolutely, the more the merrier. But it's not all of the other players it has to worry about, just one player: Intel. Intel may be allowed to use the HTT, but its absolutely certain they would rather die than use their great competitor's designs. All of the other players are small-fry in terms of volume compared to the x86 camp.
Anyways, the only RISC player that is likely to use HTT is Sun, and they will likely use it in their upcoming Opteron servers. HP has no need to use HTT in its processors, simply because it has no processors anymore, all of them (PA-RISC and Alpha) have been EOL'ed according their own roadmaps, so what are they going to use them for, Itanium? It's likely that IBM, HP, in addition to Sun all have Opteron plans secretly already devised.
If it were designed from the ground up, it wouldn't be x86 compatible; not, at least, if the designers wanted a truly great processor. Rather, AMD hopes to ride the x86-compatibility market and is therefore adapting a phenomenal RISC core to the pre-existing x86 set. It's like bolting a jet engine on a farm tractor.
It's precisely this x86-compatibility which will make it successful. There is nothing wrong with the x86 ISA that is holding it back in the least. It's got a set of simple instructions which are just as atomic and simple as anything in the RISC world, and it's got a set of complex instructions that help immensely in simplifying compiler design -- which is the great advantage of CISC design. Bolting a jet engine to a tractor? Haven't you heard of gas turbines? Jet engines are just one example of one, but not the most appropriate one, gas turbines power everything from diesel-electric locomotives to jets.
Actually, it's primarily because Intel pushed better fab processes into production earlier than the RISC crowd, of whom only Motorola & IBM fab their own.
The reason for x86 crowd's frequency increases was partly due to better fab processes, but also quite a bit to do with splitting up the decoder stages into multi-stages. Allowed them to conveyor belt several atomic instructions simultaneously.
For example, the Athlon and the P3 were both identically at 10 pipeline stages and 0.18um, but the Athlon was able to overhaul the the P3 by quite a bit due to newer design, and quite a bit better fab processes (copper interconnects, etc.). The P3 at 0.18um topped out at 1.0Ghz, but the Athlon soared all of the way to 1.7Ghz at the same process node.
Then the P4 came out with 20 pipeline stages (twice the P3 or Athlon), and using the same process technology as the P3 at 0.18um node, it was able to touch 2.0Ghz. So the doubling the pipeline stages allowed it to double the speed just by itself.
So with the improved process technology they were able to get 70% better speeds (Athlon vs. P3), but with increased pipeline stages (P4 vs. P3) they were able to get 100% better speeds.
That being said, the actual RISC processing core (of the Hammer) is significantly larger than the K7's RISC core. (On the order of 20-30%). It's just that the decode stage is so huge that it hardly makes any difference.
There you go about the decode stage again. It's a broken record, it's obvious that this hasn't hurt AMD or Intel, or any of the x86 crowd in the least. In fact, this has been the big secret behind their big performance advantage. It's the x86's experience and expertise in designing large decoder stages that has allowed both Intel and AMD to reach the 1Ghz+ frequency stage so far ahead of any of the RISC crowd, despite all of RISC's much vaunted simplicity. Yes, frequency is just one factor in performance, but it is a design aspect that most RISC processors had not been able to exploit very well up until now; and they are still having trouble exploiting it.
The Alpha was making a run for this crown, and it was the only horse in this race for the longest time, and then all of a sudden from out of nowhere both Intel and AMD both overhauled the Alpha as if it wasn't there. I think most of us had assumed that the Alpha would be the first to 1Ghz, but instead it was the Athlon.
The Hammer is akin to a pickup truck: A fairly inexpensive, medium-quality vehicle. It's loved because it does its job at a bargain price. It's utilitarian. It's the 'people's truck', and is affordable to most of the population.
Workstation processors (Such as Power, SPARC, Alpha, PA-RISC, Itanium) are compared to a semi-truck (Kenworth, International, Caterpillar): They don't necessarily go any faster, but they can tow huge cargos, but the corresponding rise in cost is far from linear.
Oh, I see. I can agree with some of your characterizations, but it is still woefully wrong. You can call x86 processors pickup trucks, but only in certain guises. A pickup truck is basically a small truck with an upgraded car engine. An x86 inside a desktop or laptop PC is a car. But a server x86 (Xeon, Athlon MP) inside a server is a pickup truck.
That leaves the whole category of heavy-haul trucks unanswered by x86 at the moment. But what distinguishes a heavy-haul truck from a pickup? The ability to pull large loads. Is that all achieved by the truck's engine? No! Large trucks have incredible 18-speed transmissions, and stiff chassis, etc. In other words it's the overall package that distinguishes a heavy-hauler from a pickup. Is any of this sounding familiar? If it doesn't, then it should, because they describe a similar approach to how you distinguish a RISC processor-based (heavy haul) server from a PC (pickup) processor-based one.
So how's this got anything to do about Hammer? Well, what it leads to is that Hammer has been designed right from the start to be everything from a car engine, to a pickup engine, to a heavy haul engine. That's because of its various features, such as Hypertransport, and onboard DRAM controller. Well, actually, only the Clawhammer (two Hypertransport channels) will work as a car or pickup engine, but Sledgehammer (three Hypertransport channels) will be a truck engine. They've been able to design an engine family that can fulfill many different roles. That's why Hammer is so exciting, and it's garnering so much anticipation.
Hammer has a substantially smaller die than P4, it's main competitor.
Again, that's comparing a fab tech that is in the near-future compared to one that's been used for over a year. Not a fair comparison by any means. It's like saying that the Athlon has a smaller die than the K6. Completely different chip generations.
AMD has stated that adding the 64-bit extensions to Hammer has only increased its core size by about 5% over K7, at the same process size! Why do you think people are so excited about Hammer? It will not only add substantial processing power to the existing core, it will also be not much harder to manufacture. It will be substantially smaller than the P4 core even with 64-bit extensions, let alone an Itanium!
Seperation and protection of code and data etc is done at the page level.
Which is not surprising because that's the direction that x86 memory protection had evolved to anyways, under most OSes.
Say, what size can the pages get in Hammer anyways? I assume that they start at 4K and go up to something from there.
long mode has a 64 bit OS and supervisor model. However, long mode allows *applications* to run in either flat 64 bit mode, or an emulated 32/16 bit protected mode.
In Protected mode segmentation, you had upto 4 levels of privileges (with ring 3 being where applications usually resided with the least privileges, and ring 0 where the OS resided with the most privileges). Most OSes never used anything other than ring 0 and ring 3, ignoring rings 1 and 2. Can this emulated 16/32-bit protected mode emulate all of the original segment ring levels, or does it just treat it as simply privileged vs. non-privileged?
ia64 does something very similar for x86 emulation, except that the simulated internal segmentation protection mechanisms are even weaker. For example, on ia64, you can edit your GDT and change your %cs etc as you please. It just simply doesn't do anything interesting because you are mapped onto a 64 bit address space. There are no "priviliges" granted by the segmentation system in this mode.
You know, I always assumed that IA64 despite it being an x86-emulator, was at least a full x86-emulator. So I had assumed that it could be made too boot up DOS if you ever so wanted to. But this makes it sound like they haven't bothered to emulate Real Mode or anything under IA64.
The only reason IDE is cheap is because everyone uses it, because it is cheap. Thus, we're stuck with it. FireWire is one possible way out of it.
Well, who's fault is it that IDE became cheap and SCSI didn't? It's the SCSI manufacturer's fault, trying to keep everything about it artificially high priced. The electronics in a SCSI are no more complicated than the electronics in an IDE drive, in fact in many cases it's the exact same drive with slightly different connector and slightly different firmware that does the same job whether it is IDE or SCSI.
Firewire will never take over from IDE (or even SCSI) as a disk drive standard, simply because there is no need to. IDE is already much faster than Firewire, it's more or less Plug'n'Play (using cable selects), and IDE is evolving towards a high-speed serial standard, Serial-ATA.
Taking the Mac again as an example, they had great serial ports, could do RS-422 as well as pseudo-RS-232, could handle asynch and synchrounous, had a larger internal buffer than standard PC serial chips. Serial connections still have their uses, but for most home use, they are utterly useless now.
Yes, yes, the Mac was always superior to the PC, that's why it was such a raging success.
Exactly true. Although the number and arrangement of the interrupts may be different. I would prefer not to think of how dog slow computers would be if they had to actively poll system devices (from video cards to keyboards). It's sooo much nicer to use an interrupt system.
About the only problems with the PC IRQ system in the past has been that: (1) you had to manually choose an IRQ on a plugin device with a jumper, (2) you had to know enough to avoid using the same IRQ twice, and (3) you couldn't share an IRQ between two or more devices.
All of these had been taken care of by various technologies (mostly introduced with PCI). (1) Plug'n'Play eliminated having to set jumpers on the cards. (2) Again, P'n'P chose the appropriate IRQ for you, thus eliminating conflicts, but also PCI has the level-sensitive IRQs which allow multiple devices to be multiplexed onto the same IRQ number, which also answers point #(3).
While not arguing this point in the least, I will say one thing: The way the serial ports are set up on the x86 is a bit messy. The Unix boxen I've worked with had a more elegant system for serial ports.
Well, the Unix boxes all use RS-232 serial interfaces just like PC's, so there shouldn't be much, if any difference. But the one major difference is that PC BIOSes don't redirect their consoles outputs through the serial ports like Unix boot firmware does.
Funny... I seem to remember most RISC processors I've known (or designed) to have at least 32 GPR's.
UltraSparcs are 16 GPR's, so were the last bunch of PA-RISC processors I looked at (PA-RISC 7200's).
The instruction decode section of the pipeline shouldn't be the single most complex part; unfortunately on a CISC processor, that's where ~50% of the transistors are.
Doesn't seem to have done them much harm in getting good performance out of these processors. Besides, over 50% of the processor die isn't the decode units, it's the caches.
IBM was dumb in the way they handled MCA, but that doesn't make PCI "compatible" with ISA.
No doubt today if IBM had to do MCA all over again, then they would've implemented an ISA bridging chip. But they didn't and that's what killed them. Besides, I don't think that back when MCA was created, that the level of technology existed to really create the quality of ISA bridges that could be had when PCI came out.
Slashdot Mirror
It's looking like dual graphics will be the default scenario pretty soon anyway. Not in the sense of two graphics cards as in SLI or Crossfire. But more like a combination of graphics cards and integrated graphics. Both Intel and AMD are working towards their combined CPU/GPU chips (Fusion, etc.). So in the not too distant future I can see all machines having a default integrated GPU built-in. Then high-end gamers will invariably add-in a high-end GPU. So why not make use of both resources? Instead of using either the integrated graphics or the add-in graphics, use both at the same time. It doesn't have to be for graphics alone, but it could also be used for OpenCL and DirectX 11's physics engine.
Better Watt/hours? What do you expect they're going to be doing with these laptops, running Folding@Home simulations? The XO laptop comes with a single integrated operating system applications suite which is specially designed for this laptop. They're not going to be able to install applications into this thing, nor will they be able to change the OS.
As it happens, the OS is based on Linux, therefore Microsoft is against it, even though the OS is not really a full Linux, just a stripped-down kernel for running the customized interface. The processor happens to be AMD-based, therefore Intel is against it, even though it's not one of their consumer processors, it's one of their embedded controller processors. Both Intel and Microsoft really have nothing to be threatened by it, but neither of them can stand to have a party in which neither of them are invited, no matter how small the party.
The investors are suing because they believe that this unreported money served to inflate Dell's profits and revenues for each quarter, thus making their stock more valuable than it should've been.
Nope, they went out of their way to say that Itanium *would* run x86 software. It just turned out later that they were talking about emulating x86.
Turned out that that promise was kept by the AMD64 architecture, which is really what people on x86 wanted to go towards.
Simple, they run the dual-cores at a couple of Mhz increments lower than the fastest current single-cores. That way the two slower cores together don't use up much more Watts than the fastest single core out there.
If the Oracles and BEA's of the world don't change their licensing policies, then Open Source is looming over their heads like a giant wooden caveman club. Before Open Source, these companies could've just told their customers where to go. These days they at least have to think about it.
r ticle.php/3 423971
Microsoft has at least partially come around to understanding this. A couple of months ago, AMD and Sun launched a similar initiative as what HP and Intel did this time.
Single License for Dual Core at Microsoft
http://www.internetnews.com/bus-news/a
Forget PowerPC, right now MS can't even bring out a port of Windows to the 64-bit extensions (called AMD64) of x86 on time! The 64-bit extensions are just a minor upgrade from the existing 32-bit x86 codebase; Microsoft was given the earliest access to AMD's hardware -- at least a year before it was put on the market. What was the result? Well, SuSE Linux had an AMD64 version available the first day the Opteron AMD64 processor was released. Now there are several distros for AMD64 from Red Hat, and others too, as well as BSD ports. By the end of this year there will even be a version of Sun's Solaris OS also available for Opteron, even though Sun started porting its OS about a year later. What about Microsoft? Well, it's now almost two years since Opteron was first put on sale, and Microsoft is still in beta-testing with its Windows port!
So does anyone seriously think with this level of incompetence, that Microsoft will be able to port a version to PPC all that quickly?If open source is more accepted in the developing world, then the need to pirate commercial software will not be there. How can you pirate something that is already free?
I don't really think they mean 192 kiloHertz but 192 kilobits per second. There is a difference in the case of lossy-compressed audio. The higher the bps, the less lossy the quality of the audio is. And this bitrate also includes all of the channels together, not just one channel.
I think it's rather more likely that you're not reading enough between the lines. Why would Microsoft put a contract stipulation that allows the competition's OS to be included? The 'No OS' was always a wink-wink-nudge-nudge meaning non-Microsoft OS without stating as much.
The usual answer to that is "it depends." If the 32-bit ISA were sufficiently thought out in advance for future expandability, then it shouldn't be a problem, obviously. The most common example of an ISA regeneration was the x86 instruction set architecture.
For example, the x86 ISA has not just a 16-bit and a 32-bit mode, it also has a compatibility mode known as Real mode, and a more modern mode called Protected mode. So x86 has Real mode, 16-bit Protected mode, and 32-bit Protected mode. Each mode represents a generational change in the x86 ISA. Real mode represents the mode that the first ever x86 processors operated in, the 8086 and 8088. The 16-bit Protected mode represents the 286 processor, and 32-bit Protected mode represents the 386 onwards.
When they designed the 16-bit Protected mode, existing 16-bit Real mode programs couldn't run in that mode. So the 286 processor usually operated in Real mode to maintain compatibility with programs designed for 8086's. So there wasn't a really good solution put in place to run 16-bit Real mode and Protected mode applications together with the 286. So that was a poorly designed generational upgrade as far as the previous generation was concerned. But they did plan for the future and left lots of growing room for a possible 32-bit protected mode in the next generation; which made it a good generational upgrade in that sense.
When the 386 came out with the 32-bit Protected Mode, they had come up with ingenious solutions to preserve compatibility with all modes simultaneously: Real, 16- and 32-bit Protected modes! They could run programs designed for all three modes simultaneously, which made the 386 processor one of the landmark processors of the x86 ISA -- not simply because it extended the architecture out to 32-bits.
However, it did look like 32-bits was the end of the road for x86, because I really didn't think they could continue to extend x86 out to 64-bits the way it was currently setup. Intel agreed with me, and came up with Itanium processor with its IA64 or EPIC ISA, which is not compatible at all with its previous generation IA32 or x86 architecture. AMD disagreed with me, and came up with an ingenious way to extend x86 out to 64-bit, i.e. the x86-64 ISA. x86 is a series of ingenious hacks that just keep the life of the ISA going. The way AMD has implemented their x86-64, they've probably left a lot of growing room for future improvements beyond 64-bits.
So based on this similar history, and whether PPC's architecture is sufficiently flexible enough to accomodate 64-bit, IBM may have an easy job or a hard job.
I don't think Apple is fighting a losing battle against a Mhz myth, they are simply fighting losing battle against the weight of more available software and hardware choices. Let's face it, this Mhz mania in the x86 world is just a recent mania, resulting from the competition between the two main x86 CPU makers, Intel and AMD. Prior to this everybody used to laugh at how pathetic x86 architecture was at scaling up in Mhz compared to other ISA's including PPC. But that didn't stop people from buying x86 PC's in the past either.
Actually, the source of incompatibility is not from whether the processor is 32-bit or 64-bit. The incompatibility comes from whether the processor's instruction set has been carried over or not. Any 64-bit processor should be able to maintain compatibility with a 32-bit processor, provided it implements the 32-bit instruction set. So the idea behind a 64-bit PowerPC would be to carry over the 32-bit instruction set intact. If it is carried over, then there's no problem, as far as 32-bit programs are concerned they will think they are still working on a 32-bit processor.
You have a lot of overarching opinions, but not a lot of background. How could you possibly say that onboard DRAM controller doesn't provide any benefits to SP systems? All you have to do is see the history of the PC to know how foolish that statement is. Even the recent history shows that a reduction in memory latency has a greater effect on PC performance than an increase in bandwidth.
As for Hypertransport, the idea behind that is not just absolute performance increases, but also design flexibility. So the same chipset that serves as a PC chipset, may also be able to serve as an 8-way server chipset, with few design changes (perhaps by adding or subtracting a few more HTT channels). Even within a desktop environment, you can easily separate out shared PCI/AGP buses, into multiple switched PCI/AGP buses with Hypertransport underlying them. There's lots of potential even within a desktop environment.
Absolutely, the more the merrier. But it's not all of the other players it has to worry about, just one player: Intel. Intel may be allowed to use the HTT, but its absolutely certain they would rather die than use their great competitor's designs. All of the other players are small-fry in terms of volume compared to the x86 camp.
Anyways, the only RISC player that is likely to use HTT is Sun, and they will likely use it in their upcoming Opteron servers. HP has no need to use HTT in its processors, simply because it has no processors anymore, all of them (PA-RISC and Alpha) have been EOL'ed according their own roadmaps, so what are they going to use them for, Itanium? It's likely that IBM, HP, in addition to Sun all have Opteron plans secretly already devised.
For example, the Athlon and the P3 were both identically at 10 pipeline stages and 0.18um, but the Athlon was able to overhaul the the P3 by quite a bit due to newer design, and quite a bit better fab processes (copper interconnects, etc.). The P3 at 0.18um topped out at 1.0Ghz, but the Athlon soared all of the way to 1.7Ghz at the same process node.
Then the P4 came out with 20 pipeline stages (twice the P3 or Athlon), and using the same process technology as the P3 at 0.18um node, it was able to touch 2.0Ghz. So the doubling the pipeline stages allowed it to double the speed just by itself.
So with the improved process technology they were able to get 70% better speeds (Athlon vs. P3), but with increased pipeline stages (P4 vs. P3) they were able to get 100% better speeds.
The Alpha was making a run for this crown, and it was the only horse in this race for the longest time, and then all of a sudden from out of nowhere both Intel and AMD both overhauled the Alpha as if it wasn't there. I think most of us had assumed that the Alpha would be the first to 1Ghz, but instead it was the Athlon.
Oh, I see. I can agree with some of your characterizations, but it is still woefully wrong. You can call x86 processors pickup trucks, but only in certain guises. A pickup truck is basically a small truck with an upgraded car engine. An x86 inside a desktop or laptop PC is a car. But a server x86 (Xeon, Athlon MP) inside a server is a pickup truck.That leaves the whole category of heavy-haul trucks unanswered by x86 at the moment. But what distinguishes a heavy-haul truck from a pickup? The ability to pull large loads. Is that all achieved by the truck's engine? No! Large trucks have incredible 18-speed transmissions, and stiff chassis, etc. In other words it's the overall package that distinguishes a heavy-hauler from a pickup. Is any of this sounding familiar? If it doesn't, then it should, because they describe a similar approach to how you distinguish a RISC processor-based (heavy haul) server from a PC (pickup) processor-based one.
So how's this got anything to do about Hammer? Well, what it leads to is that Hammer has been designed right from the start to be everything from a car engine, to a pickup engine, to a heavy haul engine. That's because of its various features, such as Hypertransport, and onboard DRAM controller. Well, actually, only the Clawhammer (two Hypertransport channels) will work as a car or pickup engine, but Sledgehammer (three Hypertransport channels) will be a truck engine. They've been able to design an engine family that can fulfill many different roles. That's why Hammer is so exciting, and it's garnering so much anticipation.
Say, what size can the pages get in Hammer anyways? I assume that they start at 4K and go up to something from there.
In Protected mode segmentation, you had upto 4 levels of privileges (with ring 3 being where applications usually resided with the least privileges, and ring 0 where the OS resided with the most privileges). Most OSes never used anything other than ring 0 and ring 3, ignoring rings 1 and 2. Can this emulated 16/32-bit protected mode emulate all of the original segment ring levels, or does it just treat it as simply privileged vs. non-privileged? You know, I always assumed that IA64 despite it being an x86-emulator, was at least a full x86-emulator. So I had assumed that it could be made too boot up DOS if you ever so wanted to. But this makes it sound like they haven't bothered to emulate Real Mode or anything under IA64.Firewire will never take over from IDE (or even SCSI) as a disk drive standard, simply because there is no need to. IDE is already much faster than Firewire, it's more or less Plug'n'Play (using cable selects), and IDE is evolving towards a high-speed serial standard, Serial-ATA.
Yes, yes, the Mac was always superior to the PC, that's why it was such a raging success.All of these had been taken care of by various technologies (mostly introduced with PCI). (1) Plug'n'Play eliminated having to set jumpers on the cards. (2) Again, P'n'P chose the appropriate IRQ for you, thus eliminating conflicts, but also PCI has the level-sensitive IRQs which allow multiple devices to be multiplexed onto the same IRQ number, which also answers point #(3).
Well, the Unix boxes all use RS-232 serial interfaces just like PC's, so there shouldn't be much, if any difference. But the one major difference is that PC BIOSes don't redirect their consoles outputs through the serial ports like Unix boot firmware does.