A computer components & hardware forum. HardwareBanter

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.

Go Back   Home » HardwareBanter forum » Processors » General
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Is Itanium the first 64-bit casualty?



 
 
Thread Tools Display Modes
  #22  
Old June 8th 09, 01:10 AM posted to comp.sys.ibm.pc.hardware.chips
krw[_5_]
external usenet poster
 
Posts: 27
Default 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  
Old June 8th 09, 01:16 AM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
MitchAlsup
external usenet poster
 
Posts: 38
Default 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  
Old June 8th 09, 02:55 PM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
Jan Vorbrüggen[_2_]
external usenet poster
 
Posts: 2
Default 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  
Old June 8th 09, 09:00 PM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
MitchAlsup
external usenet poster
 
Posts: 38
Default 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  
Old June 9th 09, 06:49 AM posted to comp.sys.ibm.pc.hardware.chips
Brett Davis
external usenet poster
 
Posts: 22
Default 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  
Old June 9th 09, 10:28 AM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
Ken Hagan[_2_]
external usenet poster
 
Posts: 14
Default 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  
Old June 9th 09, 05:57 PM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
Piotr Wyderski
external usenet poster
 
Posts: 3
Default 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  
Old June 9th 09, 06:14 PM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
Yousuf Khan
external usenet poster
 
Posts: 914
Default 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  
Old June 9th 09, 06:28 PM posted to comp.sys.ibm.pc.hardware.chips,comp.arch
Robert Myers
external usenet poster
 
Posts: 606
Default 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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 09:22 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.