If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Is Itanium the first 64-bit casualty?
|
#22
|
|||
|
|||
Is Itanium the first 64-bit casualty?
On Sun, 07 Jun 2009 22:34:46 GMT, Brett Davis wrote:
In article , Yousuf Khan wrote: Brett Davis wrote: The embedded market is the high volume market, not low end x86. Once the volumes are up and the bugs worked out, then you worry about changing to x86 encoding. Changing the instruction decoder ROM is easy, especially if you have planned for it. Now you have volume sales protected from Intels interference, flip a switch for x86 compatibility and start selling into the low end x86 market. Intel sees this coming, which is why Atom exists, to turn the low end x86 market into a profit wasteland. This magic x86 decoder ROM that you keep talking about, doesn't exist. The decoding is all done internally in the processor, and the opcodes are built-into the processor. Transmeta is the only one that ever tried fully reprogrammable opcodes, and it wasn't a great performer. There is a tiny part of the CPU that maps a read opcode byte to the instruction used. The 6502 CPU for example has only 4,000 transistors for everything and implements a pretty complex opcode scheme. That may be true, but the ISA goes a *lot* deeper into the machine than the decoder. The 6502 is trivial compared to the bus controller on a modern CPU. IOW, a stupid comparison. Changing an ADD so it maps to hex 5A instead of hex B6 is not that hard. CHanging the number of registers is simple too. Change a 16 into 32... Oh, wait... Even after adding all the x86 garbage, its still just not a big deal. Spoken by someone who has never done such work. The hard parts are the millions of transistors that implement the OutOfOrder part of the CPU. And the patents you will run into. Complete nonsense. |
#23
|
|||
|
|||
Is Itanium the first 64-bit casualty?
Brett Davis wrote:
The big problem for both these firms is OutOfOrder design and getting all the details right, which took AMD a decade. Also the portfolio of patents needed to actually implement OoO for x86 in a competitive way. It did not take AMD a decade to get OoO, it took 3 designs. The first design (K5) bought (created) the test vector suite that enabled actually testing the future designs and proving that they are indeed x86's. The second (k6) was bought from an outside company in order to create enough revenue so that AMD could survice until K7 arrived. Finally K7 (athlon) arrived, performed to par with Pentium III and just happened to have OoO components. Thus while it did take a decade, it is unfair to blame OoO on much more than 6 months of that decade. Creating the necessary base of intelect in order to produce what someone else will recognize as an x86 is vastly harder than doing an OoO processor that happens to look and smell vaguely like and x86. One needs no protfolio of patents to implement an OoO x86, what one needs is a designe that does not violate any of the myriad of patents in the portfolios of the majors. I can assure you that OoO-ness is not the problem; it is the patented sequences of instructions that will cause many more headaches than the OoO-ness {especially in long mode and switching in and out of long mode.} Mitch |
#24
|
|||
|
|||
Is Itanium the first 64-bit casualty?
it is the patented sequences of instructions that will
cause many more headaches than the OoO-ness {especially in long mode and switching in and out of long mode.} Hmmm....one can really patent a series of instructions? What is the inventive step in these cases? Jan |
#25
|
|||
|
|||
Is Itanium the first 64-bit casualty?
On Jun 8, 8:55*am, Jan Vorbrüggen
wrote: * it is the patented sequences of instructions that will cause many more headaches than the OoO-ness {especially in long mode and switching in and out of long mode.} Hmmm....one can really patent a series of instructions? What is the inventive step in these cases? * * * * Jan See USPTO 6,973,562 See USPTO 6,901,505 Mitch |
#26
|
|||
|
|||
Is Itanium the first 64-bit casualty?
In article ,
krw wrote: On Sun, 07 Jun 2009 22:34:46 GMT, Brett Davis wrote: In article , Yousuf Khan wrote: This magic x86 decoder ROM that you keep talking about, doesn't exist. The decoding is all done internally in the processor, and the opcodes are built-into the processor. Transmeta is the only one that ever tried fully reprogrammable opcodes, and it wasn't a great performer. There is a tiny part of the CPU that maps a read opcode byte to the instruction used. The 6502 CPU for example has only 4,000 transistors for everything and implements a pretty complex opcode scheme. That may be true, but the ISA goes a *lot* deeper into the machine than the decoder. The 6502 is trivial compared to the bus controller on a modern CPU. IOW, a stupid comparison. Before castigating me could you bother to actually look at the Renesas RX ISA? http://documentation.renesas.com/eng...b0435_rxsm.pdf Now that you have looked, please point out what insurmountable barriers there are to convert this chip to a 32 bit x86 clone. This is no Load/Store RISC chip with fixed 32 bit instructions, that I am claiming can be converted to a x86 clone. Were I to design a simplified x86 chip with a new ISA, this is the chip I would design. We are now to the point were backwards compatibility with 8086 and 16 bit mode are no longer needed. This rids x86 of most of its brain damage. People now only care about 32 bit mode and 64 bit mode, which are quite sane. It is doubtful that Renesas has the money or talent to make a serious run at the x86 business, of course that never stopped the last dozen poseurs from trying before crashing and burning, or getting bought out. Renesas of course would prefer not to be in Intels cross hairs, so bloviators like me are not welcome. Changing an ADD so it maps to hex 5A instead of hex B6 is not that hard. CHanging the number of registers is simple too. Change a 16 into 32... Oh, wait... Even after adding all the x86 garbage, its still just not a big deal. Spoken by someone who has never done such work. Just about every software and hardware engineer in college/University will take a hardware course on how to design a simple 4 bit CPU, like I did a decade ago. So this lame attempt at an insult just points out your lack of education in this field. Here is a University text I studied on how to design a 32 bit RISC chip, that you might find useful if you care about this topic: "Digital Design and Computer Architecture" http://www.amazon.com/Digital-Design...Harris/dp/0123 704979 The hard parts are the millions of transistors that implement the OutOfOrder part of the CPU. And the patents you will run into. Complete nonsense. |
#27
|
|||
|
|||
Is Itanium the first 64-bit casualty?
On Mon, 08 Jun 2009 01:16:09 +0100, MitchAlsup wrote:
One needs no protfolio of patents to implement an OoO x86, what one needs is a designe that does not violate any of the myriad of patents in the portfolios of the majors. I can assure you that OoO-ness is not the problem; it is the patented sequences of instructions that will cause many more headaches than the OoO-ness {especially in long mode and switching in and out of long mode.} I don't understand, but given that patents are involved perhaps I shouldn't expect to. However... Your cited example (long mode transitions) is surely quite rarely executed, so questions of efficiency (rather than correctness) don't arise. I can imagine that some sequences are harder (to get right) than others for a hardware designer, but correctness is pretty much a requirement for being an x86 processor and I thought you couldn't patent a method if it is the only way to do it. (There's my naivety showing.) So why does the patented-ness of the instruction sequence matter? And since you can patent copmputer programs (at least in some places) and they are also sequences of instructions, why don't they matter? Do these same issues affect people like Transmeta or VMware? |
#28
|
|||
|
|||
Is Itanium the first 64-bit casualty?
MitchAlsup wrote:
See USPTO 6,973,562 See USPTO 6,901,505 Amazing... but again, where is the inventive step? In order for a patent claim to be valid, it must propose a concept, idea, or item that is "useful," "novel," and "nonobvious." The ability to enter long mode is definitely useful, but what exactly is novel and non-obvious about it? All I can see is a description of an implementation detail of a very specific hardware architecture. Best regards Piotr Wyderski |
#29
|
|||
|
|||
Is Itanium the first 64-bit casualty?
Brett Davis wrote:
Yes and VIA Nano has almost twice the performance of the VIA C7 or Intel Atom, but still only offers two thirds the performance of AMD or Intel chips at the same clock. It will take another 5 to 10 years for VIA to engineer a competitive chip at low clocks. Then there is the problem of getting a good fab processes to take a stab at high clock rates. But your assertion that VIA doesn't do OoO is now refuted. A company like Nvidia could take the existing Nano base and throw enough money at it to turn it into a respectable beast. It's not 5 or 10 years out, it's one or two design cycles out given enough money, which means about two to four years. Yousuf Khan |
#30
|
|||
|
|||
Is Itanium the first 64-bit casualty?
On Jun 9, 1:14*pm, Yousuf Khan wrote:
But your assertion that VIA doesn't do OoO is now refuted. A company like Nvidia could take the existing Nano base and throw enough money at it to turn it into a respectable beast. It's not 5 or 10 years out, it's one or two design cycles out given enough money, which means about two to four years. And by then Windows could be running on Arm or Windows could be well on its way to obscurity, and the dominance of x86 right along with it. IBM about lost its shorts betting on historical determinism. DEC did lose its shorts. Why would anyone else be tempted to the same game? Mainframes forever! Minis forever! x86 forever. Robert. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Is Itanium the first 64-bit casualty? | Yousuf Khan | General | 234 | August 24th 04 08:43 AM |
Is Itanium the first 64-bit casualty? | Yousuf Khan | Intel | 234 | August 24th 04 08:43 AM |
We NEED an Itanium 3! | John Savard | Intel | 15 | April 7th 04 01:15 PM |
Itanium experts- Building Itanium 1 systems from old parts | Matt Simis | Intel | 5 | December 20th 03 03:41 PM |
Itanium Experts - Building Itanium 1 systems (parts)? | Matt Simis | General | 1 | December 18th 03 08:02 PM |