🚀 go-pugleaf

Dave Glue wrote:
>>If one were as misinformed as you, perhaps it would seem that way.
>>However, some of us who have interest in PC gaming take the time to
>>actually resarch its progression- apparently you do not.  The
>>resulting message is so far off-base with innacurate technical specs,
>>ignorance of developer movement and arising industry standards, and
>>the resulting faulty logic displayed that the message could almost be
>>considered a troll.  I hope it is.
>>
>>Let's begin the corrections, shall we?  Take out your notebooks and
>>turn to page 1.

You're absolutely right.  I shouldn't even touch this one, and normally
I wouldn't if this was on comp.sys.intel or one of the advocacy groups,
but I've already seen a couple posts that are praising this guy, and I
think there are people here that might actually believe him.

As always, I'm speaking as an avid PC user, and a computer gaming
enthusiast.  I in no way speak for Intel, nor the P6 design team. All
of my information comes from the following sources:

http://www.intel.com
http://www.zdnet.com/<insert favorite PC magazine here>
http://techweb.wais.com/techweb/eet/current/	<--EE Times
comp.sys.intel newsgroup
and various other snippets from various trade rags.


"nobody" originally wrote:
>>
>>(brief X86 history deleted)
>>
>>>  clock frequency as the previous X86 processor, the 486. P5 was the max 
>>>  a native X86 processor can achieve in performence, so Intel chose to 
>>>  make a RISC processor that would emulate 386 instruction set in order 
>>>  to increase the performence, and P6 was born. P6 is the first X86 
>>>  precessor from Intel that is not X86; hence it is an admission from 
>>>  Intel that it is no longer possible to enhance X86 architecture.
>>

Dave Glue correctly replied:
>>First error.  The p6 is a X86 chip through and through- any readings
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>on the chip would indicate this. It does no "emulation" of any sort.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Then "nobody" responded:
>
>  No, it is YOUR error. The P6 is not a native X86 processor, period!
>    It is a superscalar and superpipelined RISC processor equipt with   
>  four hardwired instruction translaters in order to translate X86     
>  instructions to its native RISC instructions on the fly. Most of simple 
>  386 instructions can be mapped into 1 or 2 P6 RISC instructions, but   
>  16bit and complex instructions have to be sent to a ROM to generate    
>  strings of P6 RISC instructions.    
>    In fact, the RISC processors emulating X86 appears to be the way to  
>  go nowadays.
> 

And I say:

Please do some research.  The fact is, every single microprocessor known
to man does some sort of instruction decoding.  It's how you break up
the bits to be used for opcodes, data, etc.  With the 486, when the
designers wanted to implement a pipelined architecture, they did a bit
more decoding than normal to make the wide range of instruction types
"fit" into each pipeline stage and keep each stage churning away
simultaneously.

With the Pentium, when they wanted to add a superscalar architecture
in addition to the pipeline, they needed yet more instruction
decoding to make it possible to execute multiple instructions at
the same time.  And now with the P6 (sorry, Pentium Pro :p), they
have carried this concept to its logical conclusion.  All instructions
get decoded into fixed-lenth micro-ops that are of the same format
and length, allowing all sorts of cool tricks to be done to them.
This is nothing new, and it can hardly qualify as "RISC emulation".
The P6 simply has a more complex instruction decode pipeline stage
than other processors.  Big deal, as long as it works, and it's fast
(which it is).


Dave Glue continued:
>>It gains its speed by further tweaking the X86 architecture with more
>>advanced branch prediction and the same-die L2 cache.  If the P6 was
>>truly a RISC chip "emulating" a 386, then it would of course have a
>>super-fast "native" mode speed that you could program directly.
>>Obviously, it does not.

And "nobody" incorrectly replied:
>
>   As I stated above, the P6 has four hardwired instruction translaters  
>  to emulate X86 so fast(386 and above only. It has a problem emulating  
>  286 and below)
>

To which I say:

Where the hell do you get this "four hardwired instruction translaters"?
See above about the instruction decode pipeline stage.  And the bit
about "emulating 286" is just wrong.  The reason 16-bit code doesn't
execute as fast has to do with the out-of-order mechanisms in the P6
core, and how it can't do all of it's tricks with 16-bit data.
PC Magazine had a very good semi-technical description of why this
happens, so I'll defer to that article (it's on the web page).

Intel simply made a concious choice in the early design stage to
not add enhanced support for 16-bit code, since it meant a whole lot
more transistors to support segmented addressing, among other things.
They assumed that everyone would be using Windows 95 or NT by now,
and DOS would be dead, but Microsoft rained on their parade with
delays of both of these products, as well as some 16-bit shortcuts on
Win95.

Dave Glue said:
>>
>>The only X86 compatible chip that could come close to be called a
>>"RISC" chip that is on the market is the NexGen, which breaks down X86
>>instructions into _risc-"like"_ smaller instructions.  AMD and future
>>clones may take this approach- but it doesn't mean they're
>>"emulating", just taking a different path to the same goal of very
>>fast X86 compatible processors.

And then "nobody" opened his mouth again:
>
>   Intel P6, AMD K5, and NexGen 586 are all RISC processors   emulating 
>  X86.(hell, you can even feed them their native RISC instuctions and   
>  bypass X86 instructions entirely). Only Cyrix's M1 is the true X86   
>  processor with CISC core.
>

I say:

I don't know much about the K5, M1, or NexGen chips, but the above
statement (and Dave's too), illustrates a pet peeve of mine.  What
difference does it make if it's RISC, CISC, DISK, or CHiPs?  As long
as it's _FAST_!  Actually, just about nothing on the market is a true
RISC chip.  The whole idea about RISC back in the '80s was that you
could get better performance by limiting your instruction set to only
very basic functions.  That's all well and good in theory, but even
RISC-chip makers have found the advantage of having integer multiply
and divide operations, string operations, and other "CISC-y"
instructions in the architecture.  A general rule of thumb was that
RISC chips had fewer than 150 instructions, yet the PowerPC has
over 200 instructions.  That's hardly "reduced".

Now what _has_ been agreed upon is that it is better if all
instructions are the same length, format, etc.  In this respect,
yes, Intel has borrowed from some RISC philosophy.  But to be honest,
there just is no clear line between RISC and CISC; they are blurring
more all the time, and all new microprocessors are a hybrid of the
two.  The P6 is no exception.


[some garbage munched, including the part where a 40-60% increase
 in performance isn't considered "significant"...].

Dave Glue spoke:
>>And the advantage of the design of the P6 is that it can be
>>scaled to higher clocks relatively easier than the Pentium.  Like all
>>Intel chips, it will start out expensive, then drop in price.  With
>>actual competition, perhaps even more quickly than the Pentium did.

Then "nobody" spewed several inaccuracies in a row:
>
>    My point was that the P6 did not double the performence over the P5  
>  at the same clock speed as P5 did over P4.

Actually, the initial offering of the Pentium didn't quite double the
486, either.  IIRC, it was about a 50-70% increase in performace
for the P5-60 over the DX2-66.  Then when the DX4-100 came out, it
came close to pulling even with the P5-60. It's simply the nature 
of the biz that when a new version of a complex product is released,
it gets some initial competition from the very mature previous version,
which has had lots of time to get tweaked and improved.  We're seeing
the same thing with the P6 (I also think this is the case with new 32-bit
apps that are coming out).  The Pentium is going to get one more
slight speed increase and then that's it.  But with the P6, well, let's
just say, "you ain't seen nothin' yet."

>  Sure, I know the P6 can be clocked much faster than P5. In fact,
>  clocking faster is the only way to increase the performence of X86
>  (whether native or emulated) processors from now on.

Oh, so these computer architecture enhancements do nothing for performance?

* Out-of-order execution
* Speculative execution
* Branch prediction
* Register renaming

>  The P6 has 12 stage pipeline instead of P5's 5 
>  stage pipeline, so it can be clocked faster. I guess P6's maximum speed 
>  limit would be around 250Mhz, since the complex instruction translaters 
>  won't be able to keep up with pipelines at such speed.

Huh?  How would you know anything about maximum speed?  And how could
one pipeline stage not keep up with another at the same clock speed????
Oh, nevermind.

And the discussion continued (getting tired of attributing)...
>>
>>Keep in mind, all benchmarks done thus far are very early and based
>>also, on early versions of 32-bit software.  We'll know the real
>>performance of the P6 with 32-bit software once developers have had
>>time to work with the beast.
>
>    The tests were conducted with off the shelf softwares, not some   
>  special softwares optimised for the P6, and I believe that was the   
>  right way to test the P6 under normal condition. After all, the   
>  software developers did not release pentium optimised softwares when   
>  the Pentium hit the market, so why should you expect your everyday   
>  spreadsheets and wordprocessors would be optimised for the P6?
> 

First of all, Dave was saying that these real-world applications
are early versions of the software.  Back when betas of Win95
and some 32-bit versions of MS apps were available, many magazines
were doing performance tests, and it was discovered that the
early 32-bit applications didn't really provide much improvement
over the 16-bit apps that had specialized assembly code and other
tweaks to squeeze as much performance out of them as possible.
I doubt future versions of software will be P6-optimized, but
they'll very likely be much more efficient 32-bit code, which
will certainly help the P6.


>
>
>
>>
>>>At the same time, more trouble 
>>>  follows P6. The P6 was optimised to emulate 386 and above,
>>
>>It was designed to deal with 32-bit code, not "optimized" to "emulate"
>>a 386.  Good lord, is this from a Electronic Games Monthly article, or
>>is McDonalds producing pamphlets on modern processor design for
>>interesting reading while you shove down a Big Mac?

<score a point for Mr. Glue>

>
>   From Byte, PC Magazine, PC Computing, and scores more.

I suggest you try Electronic Engineering Times, Microprocessor
Report, and PC Week, among others.

>>
>>>  emulation performence of 286 and below is very poor. A 133Mhz P6 will 
>>>  run old 16 bit codes(DOS, Windows3.1, all PC games)
>>
>>PC games have been 32-bit for years, with the DOS 4GW extender.  DOS
>>is barely an OS in these instances, it's nothing more of a "loader"
>>for these games.  Ever watched the screen upon Doom loading up?  It
>>loads ITS OWN OS.  How many games released in the past year and a half
>>do not run on DOS 4GW?  Very, very few.
>
>   Are you sure the games that run on DOS extenders are coded in 32bit? 
>  Or are they just moving to the protected mode in order to access the   
>  extended memory?

Now we're getting out of my area of knowledge.  I've actually been
curious about this myself.  Perhaps someone could shed some light?
If a game runs in DOS4GW, does that mean it's automatically 32 bit?


>  Remember, the game has to bit coded in 386   
>  instructions in order to see any speed gain on the P6.  
>>
>>>  100Mhz P5 can. It will run Win95 and its "native" applications about 
>>>  same speed at 133Mz P5, and it will run WindowsNT and Unixs 30%~60% 
>>>  fatser than a 133Mhz P5. Since it is very unlikely anybody would run 
>>>  their games on NT or Unix, P6 provides no speed improvement over P5 for 
>>>  PC gamers. Fianlly, gaming on X86 has hit the ceiling.
>>
>>Completely untrue, as the P6 will be scaled to higher clock speeds
>>that the Pentium could only dream of.  And the Pentium is about to be
>>increased as well- 150 & 166mhz speeds.
>
>   Sure, P6's performence will improve with higher clock spped. But the  
>  days of doubling performence between generations is over.
>   From now on, it is all diminishing return for additional transistors. 

This is only partly true.  The 486 was a huge improvement over the 386.
The Pentium was a slightly less improvement over the 486 (but still
excellent nonetheless).  Now the P6 is even less of an improvement
over Pentium, and it's to the point where people are beginning to
doubt the Intel Architecture.  But what we're also seeing is a
shorter amount of time between generations:

1986:			386
1990 (4 yrs later): 	486
1993 (3 yrs later):	Pentium
1995 (2 yrs later):	Pentium Pro (P6)

So if you look at how performance is improving over time, instead
of over generations, then you can see that we're still roughly
following Moore's law, which says that processor performance will
double every ~18 months (18 months ago we only had the P5-66).  You
can still do what the average PC user does and upgrade every three
years, and be just fine.

[stuff about competition and 2D accelerators munched...]

>>
>>And now Microsoft is doing this for games with it's 3D DDI layer in
>>95, its Reality Lab games 3D API, and its DirectX suite of API's for
>>game development.  Developer reaction has been _very_ positive.  They
>>don't have to know about your 3D card or 2D chipset- 95 handles it.
>>OS/2 also has something similar in the works as well.
>
>    More layers, layers and layers! That is exactly what is slowing down 
>  the PC games! For the best performence, the program needs to write 
>  directly to the hardware it is running on.

But that's exactly what the 3D DDI layer does!  It allows direct
access to the hardware (at least according to descriptions I've read
in CGW and PC Mag).  This is exactly why developers feel very
positively about this.  Yes, there is some performance loss, but
for once Microsoft has actually taken some care to see that it is
minimized, while still allowing hardware independence.  I haven't
picked up Win95 yet (short on cash), but from what I've heard and
seen, performance loss on current games has ranged from slight to
non-existant.

[other stuff about DDI being slow and crappy munched because I
 don't know that much about it.  I think he's wrong though].


>>And it's hardly a couple of companies tepidly testing the water.
>>Cirrus Logic, Yamaha, ATI, Matrox, Lockheed (which, while making
>>military simulators also designed SEGA's Model 2 board) and others
>>will all be producing 3D chips for many different board manufacturers.
>>The selection will be quite vast by late '96.
>
>   There is a trouble; none of polygon processors minus over priced 
>  REAL3D you mentioned above does the geometry processing. They all dump 
>  the geometry processing load on to the host CPU(namely, P5 and P6 in 
>  this case), then does drawing and texture mapping acceleration. And P5 
>  and P6 are not exactly known to offer the fastest float-point 
>  performence in town. So, the polygon performence bottle-neck is usually 
>  the CPU, not the polygon processor. This is why I was stressing the 
>  importance of X86's performence. In consoles like the PSX and Saturn, 
>  there are hardwired geometry engines that perform geometry calculations 
>  at blinding speed. On the PC, it is up the CPU to perform geometry 
>  computations via software routins, which is not as efficient as 
>  dedicated hardware engines.

Again, we're outside of my knowledge, but I just don't see how better
3D graphics cards can increase the load on the main CPU?  (is that
what you're saying?)  At any rate, I _do_ know that the floating-
point performance of the P6 is _much_ better than that of the Pentium.
And now that Intel has a serious contender for a workstation CPU,
you can bet that floating-point operation will be a high priority
from now on.

>   
>   There are three sinarios to how the P6 and the PC polygon cards will 
>   fare under various OS and games.

In your opinion.

>  1.DOS and DOS Extenders: Most 16bit DOS games run slower on the P6 than 
>    on P5. If the DOS game is fully 32bit and bypass the DOS, then the 
>    game may run faster on P6, but the game can't use the polygon cards 
>    because DOS and DOS extenders do not offer the DDI and device 
>    independence.
>
>  2.Windows95: The current trend of PC gaming is to go to the Windows95, 
>    which offers device independence, the DDI, and Plug and Play. 
>    But the Windows95 has its own share of problems. First, Windows95 and 
>    its native applications do not see any speed increase on the P6, 
>    thanks to all the lagacy 16bit codes still remaning in the OS. 
>     Second, the games written for the Windows95 cannot bypass the OS. 
>    Because the Win95 is much fatter than any DOS extenders, it eats up 
>    more processor time. A Win95 game would be lucky to have 60% 
>    processor utilization time. Use of polygon cards will remove the 
>    processor the load of texture mapping and drawing polygons, but it is 
>    still up to the processor to perform the geometry calculation. With 
>    less processor time to spare, the calculation slows down.

You make an awful lot of assumptions here without any supporting
evidence to back it up.  60% processor utilization?  Where'd this
come from?  And this bit about increased geometry calculation is
bogus.  If the CPU really does have to do all of the gemeotry
calculation, then that is only a part of the overall process
of 3D rendering, and I'm confident that x86 cpu's can handle it
with ease.  If new 3D cards actually slow the computer down, then
nobody would be wasting their time developing them!

I think you're going to see many enhancements to Win95 and to
x86-compatible architecture over the next couple years that
bring the PC to new heights in computer gaming.  I really think
we're only seeing the beginning.

Ya know, being slightly biased towards Intel <g>, I'm used to hearing
all about how PowerPC or Macintosh is going to beat out the Intel
Architecture.  But now there's somebody that's suggesting that
the PC platform is dead and game consoles are the way of the future.
Give me a break.

One last note:  whoever Mr. "nobody" is, I really wish you'd come
out from behind your false e-mail address and make yourself even
the least bit accountable.  I would really prefer to teach you about
the basics of microprocessor design through e-mail, but must instead
waste hundreds of people's time with this nonsense.  And to the
other denizens of comp.sys.ibm.pc.games.action, I apologize for this
obscene length, and sincerely hope you haven't read this far, as
I wouldn't wish this boring tirade on my own mother.

Have a nice day,

Jim Beavens
jbea...@ichips.intel.com
** I don't speak for Intel ** (they're not that foolish)