Archives
 
 
 
  Special
 
 
 
  About Us
 
 
 

Newsletter
Free E-mail Newsletter from BYTE.com

 
    
           
Visit the home page Browse the four-year online archive Download platform-neutral CPU/FPU benchmarks Find information for advertisers, authors, vendors, subscribers Request free information on products written about or advertised in BYTE Submit a press release, or scan recent announcements Talk with BYTE's staff and readers about products and technologies

ArticlesWe Build a 615


November 1995 / Cover Story / Why The 615 Matters / We Build a 615

Our hypothetical design combines an x86 and a PowerPC 604 processor on one chip. By using the same package, the processors can share all external memory, support logic, the FPU, and even the on-chip cache to reduce costs.

We chose a 486 core because it is less than one-third the size of the Pentium core. Even so, the 486 with necessary modifications would make the die size of this 615 about 20 percent larger than a standard 604 chip. The 486 should be able to keep up with the clock speed of the 604; both could reach 133 MHz in current IC processes. At this speed, the combined chip would deliver roughly 75-MHz Pentium performance for x86 software and 150-MHz Pentium performance on native-PowerPC software. By the second half of 1996 (when IB M's 615 may debut), process advancements should allow both the 486 and 604 cores to reach as high as 180 MHz, giving a proportional increase in performance.

The Pentium's FPU is significantly faster than the 486's. But our design leverages the fast PowerPC FPU to achieve results competitive with a Pentium's, even with some 486-related overhead in the shared design.

The 486 core natively executes x86 instructions. This approach is faster and simpler from a design standpoint than alternatives that involve decoding and converting x86 instructions into RISC instructions. For a first-generation device, we think it makes sense to use a simple x86 core rather than adding a bulky translation unit. Translating x86 code into the PowerPC's RISC instruction set is difficult and may require modifications to the PowerPC core to handle x86 condition codes and other features.

Finally, a native-PowerPC OS would handle such things as the PC BIOS and core logic. DOS applications that directly access the hardwa re would have to be emulated, as in SoftWindows today. Performance would be mediocre for these types of programs.

As we have designed it here, the 615 would cost about 30 percent more to build than a standard PowerPC 604. At current margins, this would be an additional $30 to $40. However, business considerations would probably encourage a vendor such as IBM to sell the chip without charging a premium.


Building a 615

illustration_link (20 Kbytes)


Up to the Cover Story section contentsGo to previous article: Why The 615 MattersGo to next article: Alternate Views of the 615SearchSend a comment on this articleSubscribe to BYTE or BYTE on CD-ROM  
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it is theoretical--and no language better exemplifies this than C++.

more...

BYTE Digest

BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin, and dozens of other CMP publications—bringing you critical news and information about wireless communication, computer security, software development, embedded systems, and more!

Find out more

BYTE.com Store

BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than 8 years of BYTE.
 
The Best of BYTE Volume 1: Programming Languages
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...

Copyright © 2005 CMP Media LLC, Privacy Policy, Your California Privacy rights, Terms of Service
Site comments: webmaster@byte.com
SDMG Web Sites: BYTE.com, C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, New Architect, SD Expo, SD Magazine, Sys Admin, The Perl Journal, UnixReview.com, Windows Developer Network