Sign-in / Sign-up
Your question

Cnet says, "no competitors to x86."

Tags:
  • CPUs
  • Performance
  • x86
  • Product
Last response: in CPUs
April 4, 2007 3:12:48 AM

http://news.com.com/Despite+its+aging+design%2C+the+x86...

Quote:
But x86 continues to thrive and has no serious competitors on the horizon because it provides "good enough" performance and because of the vast amount of software written over nearly three decades.


While they do go on to "honorably mention" x86-64/AMD64/EMT64 (all the same), I think they're seriously underestimating 64 bit computing. Every recent CPU model from both AMD and Intel uses x86-64. How in the world is that not a serious threat to x86? Clearly AMD64 has gained widespread adoption among the 2 biggest chipmakers.

Don't get me wrong, x86 will be around for at least 5 more years in PC's. But to say that x86-64 isn't a serious competitor is a little naiive.

Anyone with me on this?

More about : cnet competitors x86

April 4, 2007 3:21:18 AM

Hmmm... but won't the day come where 64 bit processors won't do 32 bit code? Isn't it that way w/ 16 bit code now?
a c 118 à CPUs
April 4, 2007 3:54:39 AM

x86_64 processors will always be able to execute 32-bit x86 code as that's a part of the ISA. You'd have to invent a new ISA or move to a different one that does not support any 32-bit instructions like Intel's IA64 for the Itanium. x86_64 was a very elegant move by AMD as it introduced 64-bit computing without breaking compatibility with either 32-bit programs nor 32-bit OSes. This made the ISA less than a clean sheet, but most will say that it's at least passable and that x86_64 cleaned it up quite a bit.

However, one can make a 64-bit OS unable to execute 32-bit x86 binaries by removing IA32 emulation capabilities from the kernel and removing the 32-bit/64-bit multilib setup that keeps separate directories of 32-bit and 64-bit system libraries. I had that option when I installed my OS but decided to go with the multilib setup as most proprietary programs aren't x86_64 yet and I wanted to be able to still run them. That's ridiculous as the entire rest of the OS is and has been for almost four years, and most of the other programs are too, but I digress. Besides, the 32-bit compatibility takes up very minimal disk space and resources, so what the heck.

As far as 16-bit code goes, I don't think that a processor running in 64-bit long mode can handle 16-bit code. Jack, feel free to correct me on this, but I believe that non-emulated 16-bit code execution requires the chip to be in at best 32-bit mode. I can't be certain on that as my OS cannot execute any 16-bit programs at all as the OS was completely written for 32-bit machines from the start.
Related resources
April 4, 2007 4:10:06 AM

64bit support will evolve faster now that a mainstream OS (Vista) is out in 64bit flavor. Heck, it HAS to evolve, since the next Microsoft OS (Vienna) will be released 64bit only. And its due out in a couple years (althought I'd extend that to 3 due to the delays we are so familiar with).

EDIT: small typo
April 4, 2007 4:15:33 AM

Well, it should be able to run 16bit code.

DOS is 16 bit. If you could not run 16 bit, how could you run DOS or even get into the bios?

I can understand perhaps problem would be more apparent on the windows side of things, but I think the x86-64 should have some support for it.
April 4, 2007 4:38:12 AM

Quote:
I would not call x86-64 a competitor, it is an evolution of x86... the instruction set is the same, just extended to 64-bit.


Yes it seems very logical as X86-64 isnt a competitor as their will be X86-32 will always be with it! BTW i dont think a picture viewer would need 64bit instruction sets 8O too run in the near future :roll:
April 4, 2007 9:02:52 AM


Every recent CPU model from both AMD and Intel uses x86-64.


They, do and 99.99999% of people run 32 bit applications on them in 32 bit operating systems.
April 4, 2007 9:52:07 AM

I see that most people cannot realize that x86-64 is not an architecture but only extensions.
April 4, 2007 10:57:01 AM

I think a lot of people get confused about what x86_64 actually is. It's the same old ia32 architecture but with 64 bit registers included plus some other refinements, the net effect of which is that it can perform calculations on larger numbers and refer to larger address spaces. For example, 32bit Windows XP can only use up to 4GB of RAM whereas as the 64-bit version (and by this I mean x86_64) can address 128GB+ of RAM.

Have a look at the following Microsoft webpage:
http://www.microsoft.com/windowsxp/64bit/overview.mspx

To confuse matters more you than have "true" 64-bit Windows which will run on Itanium, this is a different beast altogether. This is what the article is really talking about when it refers to rival ISAs.
a c 118 à CPUs
April 4, 2007 12:23:38 PM

All x86 chips boot in 16-bit mode and the switch-mode operation does not happen until after the bootloader loads the kernel if I remember correctly. Example in point: you can stick a 64-bit bootable Linux CD into a 32-bit machine and it will take the boot sequence from the BIOS and boot to the GRUB splash screen where you pick screen resolutions, etc. Once you hit "Enter" to load the kernel and boot, the kernel loads and then immediately you get an error about not being able to run the CPU in long mode.

Also, I don't run any DOS programs. If I did, there are full emulators like dosbox that will take care of that.

@maina231: Making a program 64-bit usually just involves recompiling the source code with a 64-bit compiler and making sure that the system libraries it calls on are 64-bit. If you're running the application on a 64-bit system, that will certainly be true and there's really no reason not to recompile it.
April 4, 2007 1:08:34 PM

Quote:
Hmmm... but won't the day come where 64 bit processors won't do 32 bit code? Isn't it that way w/ 16 bit code now?

No.

Windows XP will run most 16 bit applications. I'm sure there are some limitations to doing this, but XP has a compatibility mode for dealing with older applications. Hell, some DOS applications still run under XP.

As far as I know you can still install DOS 6.22 on a modern PC and expect it to run.

But I agree with your overall point... 32 bit code will eventually go away.
April 4, 2007 3:06:48 PM

With Windows Vienna BIOS as we know it could, change completely to the more invisible version that we see on the MACs and some linux only systems.
It would greatly enhance boot-time for one thing. Although, will a less accessible BIOS make things more, or less compatible and thus stable?
April 4, 2007 3:11:51 PM

Quote:
Hmmm... but won't the day come where 64 bit processors won't do 32 bit code? Isn't it that way w/ 16 bit code now?


Any modern pc can run DOS just fine, whether or not windows can compensate nicely and smoothly to make it more accessible in it's shell is a different thing entirely is completely different.

If you wanted to you could dust off your floppy and install DOS 6.22 just fine on it's own.

In short, it's not the processor, it's the software. Windows needs the BIOS (or at least an emulation of it) that we have on our modern pcs to run correctly, for example, whether the OS is 64-bit or not. So the CPU has to be able to be backwards compatible in this case.
April 4, 2007 5:33:33 PM

Yeah, we all have 64-bit chips, but how many of us are running 64-bit OSes?

It'd be like saying the COM port isn't going anywhere because every motherboard has one. Just because it has one doesn't mean they're used.

64-bit adoption has been much slower than I anticipated. One of the problems right now is that 64-bit is the solution to the problem not encountered yet. Until there is a benefit people won't switch.
April 4, 2007 5:58:24 PM

There is a benefit, a huge one for businesses with workstations or other high-end platforms that require more than 4gb of memory for one example
The lack of adoption has only been seen in the desktop market because it hasn't been seen of yet.
64bit OSes have been around for a while with Linux and that's what a company will use since it's already what they have. A 64-bit version of Windows is a bit silly, in that Windows is primarily designed for the type of general computing that makes a 64-bit version (as of yet) unnecessary.
For other uses, a Linux platform (or several) have already been designed for it.
64-bit operating platforms sell well for those that need them, which aren't desktops, which tends to be much of the general frame of reference on most tech sites like this, hence the illusion that it's a failed idea that no one adopted.
a c 118 à CPUs
April 4, 2007 6:46:11 PM

I run a 64-bit OS and 99.9% of my programs are 64-bit.
April 4, 2007 6:54:08 PM

Quote:
x86_64 processors will always be able to execute 32-bit x86 code as that's a part of the ISA. You'd have to invent a new ISA or move to a different one that does not support any 32-bit instructions like Intel's IA64 for the Itanium. x86_64 was a very elegant move by AMD as it introduced 64-bit computing without breaking compatibility with either 32-bit programs nor 32-bit OSes. This made the ISA less than a clean sheet, but most will say that it's at least passable and that x86_64 cleaned it up quite a bit.

However, one can make a 64-bit OS unable to execute 32-bit x86 binaries by removing IA32 emulation capabilities from the kernel and removing the 32-bit/64-bit multilib setup that keeps separate directories of 32-bit and 64-bit system libraries. I had that option when I installed my OS but decided to go with the multilib setup as most proprietary programs aren't x86_64 yet and I wanted to be able to still run them. That's ridiculous as the entire rest of the OS is and has been for almost four years, and most of the other programs are too, but I digress. Besides, the 32-bit compatibility takes up very minimal disk space and resources, so what the heck.

As far as 16-bit code goes, I don't think that a processor running in 64-bit long mode can handle 16-bit code. Jack, feel free to correct me on this, but I believe that non-emulated 16-bit code execution requires the chip to be in at best 32-bit mode. I can't be certain on that as my OS cannot execute any 16-bit programs at all as the OS was completely written for 32-bit machines from the start.



That's correct. In X64, no 16-bit code works, but some will work under XP with the legacy DOS stack. All HW accesses have to be 32bit though as all HW accesses under X64 have to be 64bit.
April 4, 2007 6:59:27 PM

Quote:
One of the problems right now is that 64-bit is the solution to the problem not encountered yet.


That problem is quickly approaching. With enthusiasts recommending 4GB of RAM for Vista it won't be long until OEM's are shipping 4GB of memory w/ the next release of Windows.

Give it 2 years and you'll see 32bit programs take a drastic drop. Vista is the first real OS for x86-64, much like Win95 was the first 32bit OS for the 386 and up.
April 4, 2007 7:27:14 PM

Quote:
Also, I don't run any DOS programs. If I did, there are full emulators like dosbox that will take care of that.


Perhaps I didn't make myself clear on dos. (even though we are repeating ourselves :lol: )

If you need a bios update, how could you do that manually without DOS? (besides using perhaps a 32bit windows updater software) Maybe I'm too old school. :lol: 

I guess it will be a matter of time (kinda doubt it at this time) if the bios will take changes to become more then 16bit later on.

however, I do see the problem running 16bit in a 64bit environment in what you and the other described. Since the x86 can do different modes under certain times (during POST or bootup) is where I was saying it should support 16bit.
April 4, 2007 7:48:04 PM

My prediction is that Like the game industry helped push the cpu technology as we know it.
It will push the heavier requirements, specifically ram, that will require 64-bit addressing. And thus make 64-bit windows necessary to the average user
April 5, 2007 12:12:31 AM

Quote:
A 64-bit version of Windows is a bit silly, in that Windows is primarily designed for the type of general computing that makes a 64-bit version (as of yet) unnecessary.


I disagree: 4GB is a serious limitation for many current applications, and the sooner Microsoft get everyone onto a 64-bit OS the more incentive they'll have to get it to work :) . They should have made Vista 64-bit only as they originally threatened to do.

And the benefits are not just in the amount of memory an application can access, but you also get more registers in 64-bit mode which allow better code optimisation, you can use a different base address for each DLL so they don't need to be relocated when they're loaded, improving startup times, and you can do things like mapping big files into virtual address space so you no longer need to bother doing file accesses, you can just treat them as memory and let the operating system page them in and out as required.

But right now there's a vicious circle in that Microsoft and software companies concentrate on 32-bit Windows, applications and drivers because few people are running 64-bit, and few people run 64-bit because of the lack of software, drivers and robust operating system support.
a c 118 à CPUs
April 5, 2007 12:50:11 AM

Yup, the x86_64 chips all boot in 16-bit mode so that the BIOS can work. This compatibility has not been removed and cannot as it's part of the ISA. Thus, no worries about running 16-bit x86 code on an x86_64 chip as the ISA has to change for this to be removed.

I think what you're really asking is whether we'll migrate to something in the future that is not backwards-compatible in any way, shape, or form with 16-bit x86. That would take a new ISA that's not x86_64 and is not likely to happen for a decade or more, whenever 16 EB of RAM just isn't enough. It *could* happen, but it's extremely unlikely as it would take several events all happening at once to drive people away from x86:

1. Something happens in the x86 CPU market to where there is one dominant maker that has >90% of market share and little to no competition. This drives prices way up and the rate of speed increase down. Think of Intel in the 1980s and early 1990s.

2. A chip of another architecture (PowerPC, SPARC, MIPS, etc.) massively outperforms and is priced well under what x86 chips sell for.

3. People have largely migrated off old proprietary applications and operating systems that are x86-only to open-source or multi-platform applications.

The economic and technological pushes in (1) and (2) provide the impetus to move off x86. This has happened before, but we're all still running x86 machines because software was x86-only and it was up to vendors to choose to port it or not. This would take some work or at least recompiling the code for the new arch. Judging at the glacial response to x86_64, proprietary vendors are too lazy to do this and their lock in must be removed in (3) for people to switch to a new CPU architecture. I could switch CPUs from my Athlon 64 X2 to a Sparc T1, POWER5, or Itanium pretty easily as I don't have anything tying me to x86, but I'm in the distinct minority on that one. Even most Linux users don't want to leave x86 because then things like the win32codecs/amd64codecs packs for proprietary audio and video codecs go away, so does Flash player, Acrobat reader, and the ATi graphics drivers. Not to mention the handful of x86 Linux proprietary games.
April 5, 2007 12:52:54 AM

Will my a Pentium 4 duo run 64-bit?? :lol:  :roll:
April 5, 2007 1:28:06 AM

I didn't say that 64-bit wasn't necessary as a blanket statement.
I have no doubt that what you want to do makes it necessary.
What I said was that the general, and much more common, user even a gamer doesn't need a 64-bit operating system. Therefore a general OS like 64-bit Windows XP wasn't necessary.
How many every-day programs that the average home-user uses needs more than 1GB if that, of memory, let alone 4GB.
a c 118 à CPUs
April 5, 2007 2:13:17 AM

The Pentium 4 duo is certainly a 64-bit chip, but it runs on the Itanium instruction set instead of the x86_64 one. It is codenamed "Nehalem" and was originally planned out around 2000. Intel supposedly canceled the project and gave the Nehalem name to a new project, but we were carrying out the project in the back of D1D behind the stacks of old RDRAM and defunct 820 chipsets. The Pentium 4 duo is a dual-core chip running at 10.0 GHz just like we said it would when we introduced the original Pentium 4 Williamette back in late 2000. We've got Gordon Moore, bitch, we're NEVER wrong! The chip runs on the Itanium ISA as AMD64 wasn't due to be introduced until 2003 and the Pentium 4 duo was started in 2000. IThe higher-ups declined to market the Pentium 4 duo as they were fearing an lawsuit from AMD for anticompetitive tactics, instead keeping the Pentium 4 duo under wraps and using it to secretly power the machines that supposedly contained Core 2 CPUs during the early part of 2006. That is why Intel never let anybody look at the insides of the machines as the Pentium 4 duo is based on Socket 423 and not LGA 775. The reason that Socket 423 was withdrawn was not due to electrical problems after all, but due to the fact that the Socket 423 was being used for the Pentium 4 duo. We didn't accidentally want some noob on his first day to mistake a P4d for a regular P4 on the first day and have DailyNDABreak get a hold of it, so they switched production CPUs to 478 pins. We also added shiny silver IHSes to the Socket 478 and LGA 775 chips so that if the engineer graduated from UM-Rolla or KU and can't count the pins, the mantra "if it doesn't shine, it doesn't ship" kept the unlidded P4ds safely in the back of D1D. In fact, Intel made that rule in all of its fabs except for the one with the Israeli wankers in it making laptop CPUs who keep thinking that the bloody old Pentium III can be tweaked and sold as a new chip or three. They had nothing to do with the P4d and thus didn't have to put IHSes on their chips.

The actual technical specs of the Pentium 4 duo are as follows:
* 2 cores but expandable to 4 or more.
* Quad-channel RAMBUS XDR memory controller, on-die. This used to be quad-channel RDRAM but the XDR stuff is faster. Makes the pile of old RDRAM sticks useless, though.
* Socket 423 with a solid copper Vcc contact in the center pinless region below the CPU and a grounding strap for providing ground. All pins are data pins. Pretty nifty, eh?
* 10 GHz operating frequency just like we predicted in 2000.
* 500 MHz system clock and 20x multiplier. SpeedStep is enabled.
* Uses an unreleased Intel 890 chipset with support for AGP x32, 133 MHz, 128-bit PCI slots, and PATA/533.
* 65 nm process node. You guys seriously thought that the 90 nm Pentium 4s could only do a mere 400 MHz better than the Northwood? And that 3.73 GHz was as fast as the Preslers could go? That's what we wanted you to think and kept the good silicon for the P4d in case the Athlon 64 actually did get over 4 GHz and give the released Pentium 4s and Core 2 Duo some trouble.
* Half-cycle SSE engine capable of executing two 128-bit SSE instructions per clock.
* 67 W thermal envelope for the 10 GHz version, the 8.0 GHz LV version only consumes 35 W.
* 32 KB L1, 120 kUops trace cache, 8 MB L2, 16 MB L3 cache. The chip is about 300 mm^2, which is a little big, but not too bad. That Z-RAM stuff sure does help shrink stuff.
* HyperHyperHyperThreading, which allows each CPU core to be seen as eight logical CPUs. Because we just couldn't let Sun one-up us with HT and let each core be seen as 4 logical ones.

So that's the Pentium 4 duo...say, where'd you get one? Did those fools over in Shipping confuse them with a Celeron again? I swear, can't trust somebody that says they graduated from a school called "Missouri State" as there is no school with such a name. Maybe they were sniffing the dopants again like I caught them doing last week...Hoosiers.