Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (06/02/91)
Info-IBMPC Digest Sun, 2 Jun 91 Volume 91 : Issue 135
Today's Editor:
Gregory Hicks - Rota Spain <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
Intel's CPU Wars
TCP/IP address of WUARCHIVE.WUSTL.EDU
Today's Queries:
Node Name of IBMNET and Other Public Nets
Dysan only Hardware Testing Product?
Multi-tasking in DOS
tape backup without using a board or SCSI port?
Vax/VMS ZModem quirks
Windows with edit buffer
Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
----------------------------------------------------------------------
Date: Thu, 23 May 91 02:57:53 PDT
From: Gregory Hicks <ghicks@wsmr-simtel20.army.mil>
Subject: Intel's CPU Wars
Intel's CPU wars The 32-bit struggle for succession
By RON WILSON
Copyright ELECTRONIC ENGINEERING TIMES via NewsNet May 13, 1991
[reposted with permission, edited by Gregory Hicks]
Intel has never faced such severe challenges to its dominance in
the personal computing market. Sun draws an increasing percentage of
its sales from the business sector. The ACE consortium conspires an
alternative platform standard for desktop software. Longtime business
computing power Hewlett-Packard gathers its resources for a full line
of Precision Architecture RISC machines. Yet, Intel is preparing an
answer.
In Hillsboro, Ore., far away from the traditional Santa Clara,
California home of the X86 family, a new CPU is taking shape. It will
draw heavily on RISC technology, including an advanced bus
architecture, a superscalar layout and RISC-like execution units. The
chip will be virtually a company-wide effort, bringing together design
teams that were once bitter competitors within Intel. The tale of the
586 is not just about technical development, but also about management:
how a decentralized company with three competing 32-bit CPU
architectures could evolve into a company able to shift resources among
design teams to target specific markets. Intel will not comment
officially on the evolution of its architectures. But off-the-record
interviews with present and former Intel employees help to shape a
picture of what happened.
The story begins with the 386 firmly in control of the PC market.
However, the 386 is a CISC machine, which means it takes enormous
effort to make it run faster. Each generation of the X86 has taken
more work than its predecessor. Competitors confidently predicted that
the "archaic" X86 architecture was on its last legs. These weaknesses
in the X86 had been recognized long before within Intel itself. That
was in 1980, when a team of architects in the Hillsboro facility set
out to solve the problem by coming up with a design so advanced that it
would be ready to take over when the X86 finally faltered. Using the
latest thinking in modular design techniques and fault-tolerant,
object-oriented architectures - thinking that would still be ahead of
its time today - the designers produced the ill-fated iAPX432.
Although the 432 went nowhere in the market, the concepts survived.
The result was the comprehensive definition of the 960 system
architecture. This was not a design for a 32-bit embedded controller,
but was a master plan for an object-oriented, fault-tolerant, message
passing multiprocessor system. The heart of this architecture was the
streamlined 960 instruction set, that had incorporated many of the
notions of RISC processing. From the beginning, according to sources
close to the project, the 960 was intended to be the central processor
of Intel's future. However, while the 960 team grew around the kernel
of 432 concepts in Hillsboro, a new architecture group was gathering in
Santa Clara. Chartered with solving the numeric-processing bottleneck,
this team sought to combine concepts from the RISC movement and from
Seymour Cray's vector-processing machines into a single revolutionary
piece of silicon.
The result would be the N10, later known as the 860 architecture.
If the charter envisioned the N10 as a numeric coprocessor, the
architects came to see the chip differently. In order to do its job,
the N10 had to be able to execute ordinary, unvectorized code, so it
had to be at base a general-purpose CPU. It soon became clear the N10
was going to be much faster than the 386, then being developed. So, why
shouldn't the N10 step in as a general-purpose, Unix-based CPU to
gradually lift the mantle from the shoulders of the X86 family? To
remain dominant in the PC world, since Intel had to make the
transitions to RISC and Unix sometime, why not make it with a knockout
product? In fact, the N10 team took this story to workstation
developers outside the company, describing the general outline of the
part, the massive numeric performance, and the opportunity to produce a
cost-effective Unix workstation with a single chip in the roles of Unix
engine, FPU and vector processor. There was, to say the least,
interest.
Now Intel had an embarrassment of riches: not one, but three
32-bit architectures. And it faced the very real threat of having
three enormously expensive design efforts and support programs
competing for the uproven desktop Unix market. Even worse, any one of
these efforts might accidentally shatter the X86's DOS-based hegemony
in personal computing, destroying perhaps the most profitable market
dominance in the history of the semiconductor industry. For Intel
management, it apparently was too great a risk.
The three architecture teams saw themselves as competing for the
right to lead Intel into the next generation of computing. And the
competition was none too friendly, according to some company insiders.
But while competition raged at the technical level, a very different
attitude was forming in corporate management. As one observer put it,
there was a growing concern that the X86 family would be eclipsed by
the new RISC efforts. At some point in this process, corporate thinking
underwent a revolution.
Historically, Intel had been a hardware-driven organization-the
correct solution to a given problem was the solution with the fastest
hardware. But now, the company faced the possibility that better
hardware solutions (in the form of the 860 and 960) could kill the
goose that kept on laying golden eggs. So, the corporate emphasis
shifted to software. As one Intel manager put it, "Software is in the
driver's seat-it is the soul of the product." In less philosophical
terms, software support, and not the virtues of the hardware itself,
determine how customers perceive an architecture. So, by controlling
the software support of an architecture, Intel could control customers'
perceptions. And that seemed to be exactly what the company set out to
do with the 860 and 960. One source close to the 860 team said that
there was a time in the project when the designers envisioned the 860
as the main processor in the system, with an X86 serving as a DOS
coprocessor. But to achieve that, the 860 had to have Unix. Intel
stalled on the Unix port-intentionally, in the view of this source.
The lack of Unix permanently relegated the 860 to its original
role of numeric-intensive coprocessing. The move was effective, and it
gave the 860 a clear focus and a niche to dominate. But it was clearly
hard on the 860 design team. Many of them left Intel, because of the
Unix issue, this source said. The corporate hand shaped the 960
strategy as well. This design team also had visions of being the
central CPU in Intel's future, and the team players had embedded many
features in the instruction set architecture specifically for
operating-system support. But, under the new thinking, the 960 would
not get an Intel operating system. Instead, the company nudged the
design team into repositioning the part as a 32-bit embedded processor.
The silicon shed many of the 432-like big-system features and took
on hardware more suited to telecommunications and printer-controller
applications. The two RISC architectures had been successfully
positioned away from the X86. But Intel still had one more problem.
What if the X86 program really did fail to compete with RISC? Each step
in upgrading the architecture was growing more ambitious than the
previous one, until the 586, the development of which took on huge
proportions.
One solution was to borrow concepts from the RISC programs. "The
X86 people view RISC as a capability, not an architecture," said an
Intel insider. In other words, why not build a RISC processor that
happens to execute 486 code? In fact, the 960 team had already done
something similar, devising a RISC-like execution unit for the 960
instruction set. In theory, at least, the instruction set could be
kept static, tying customers to a particular family. Then the
designers could use whatever architectural techniques they chose for
the CPU. And that is apparently what is happening. The center of
design effort for the 586 has shifted from Santa Clara, where the
previous X86s were done, to Hillsboro, where the superscalar 960CA was
designed.
Sources say the 586 will in fact be a CPU with multiple execution
units arranged in a sort of superscalar architecture. The approach
does carry substantial risks. Superscalar architectures need the
load/store instruction streams, single-cycle execution and low
inter-instruction dependencies present in typical RISC instruction
sets. The 486 instruction set, with none of these features, could
require an enormously complex scheduling and dispatch unit. It might
be practical to dispatch whole sections of code to the execution units,
rather than single instructions.
The danger persists that the 586 will turn out to be too slow, or
too complex to finish. Probably no one outside Intel knows the odds.
"The 586 is a big program, but it's Intel's responsibility to do it,"
one insider said. "People won't raise the question of alternatives
until someone stubs their toe." And there are still alternatives.
Throughout the redirection of effort, the 960 project stayed
customer-driven enough to keep satisfying one big customer: the
military. That led to a continuing implementation of the
systems-oriented pieces of the 960 architecture-CPUs with integrated
floating-point, coprocessors to support inter-object communication over
a secure bus, and the like.
Quietly, the 960 team has done a great deal of general-purpose CPU
work for the military. That leaves one advanced architecture - perhaps
the most advanced architecture yet committed to silicon - ready to step
in if the X86 family runs out of gas. So the architecture wars, in a
way, accomplished the purposes of both the architects and the
executives. At least one of the company's advanced architectures was
allowed to develop as a follow-on to the X86, and the X86 was given a
road map into the indefinite future, built on the work of the other
teams.
------------------------------
Date: Fri, 24 May 91 11:41:32 EDT
From: Jean-Serge Gagnon <JSG8A%ACADVM1.UOTTAWA.CA@VMD.CSO.UIUC.EDU>
Subject: TCP/IP address of WUARCHIVE.WUSTL.EDU
Hi there,
Regarding an article by D. Maddox <maddox@NADC.NADC.NAVY.MIL> in issue
124 with a subject of "Re: simtel session wanted."
He states that a mirror to the simtel archives is the wust1 archives.
Two questions:
1. What is the address of machine wuarchive.wust1.edu? Our ftp server
doesn't know it!
[Probably because the host name is not as written above but is
wuarchive.wustl.edu (note L in wustL and not 1 (one)). The IP
address is: 128.252.135.4]
2. What is a mirror? Is it done automatically by one of the two
machines? Is it the owner of the mirror that gets the new files every
once in a while? Or I am missing the point!
[Mirror? Something that reflects the original? Files are uploaded to
WSMR-SIMTEL20 and then FTPd to WUARCHIVE.WUSTL.EDU. Keith and company go
to great lengths to ensure the mirror archives are current. gph]
Any help would be appreciated.
| Jean-Serge Gagnon <JSG8A@ACADVM1.UOTTAWA.CA>
| Specialiste en Equipement | Computer Hardware
| Informatique | Maintenance Specialist
| Universite d'Ottawa | University of Ottawa
| (613) 564-7813 | (613) 564-7813
------------------------------
Subject: Today's Queries:
Date: Thu, 23 May 91 20:58 +02:00
From: <ATAN%TRBOUN.BITNET@VMD.CSO.UIUC.EDU>
Subject: Node Name of IBMNET and Other Public Nets
Where can I find the nodenames of
IBMNET and other public networks? How can I access EARN through a
public swichting network of PTT? e.g.: Internet has the number 031069.
What is the number of EARN?
Thank you very much in advance.
Levent ATAN ATAN@TRBOUN
------------------------------
Date: Fri, 24 May 1991 00:14 EDT
From: <ACSWILEY%EKU.BITNET@CUNYVM.CUNY.EDU>
Subject: Dysan only Hardware Testing Product?
I need some help, I am looking for a product better than Dysan, for
hardware checking/testing for IBM and compatibles. The student
technicians here keep asking me to find them some better software other
than Dysan.
Thanks!
( Bill Wiley BITNET: ACSWILEY@EKU )
( Academic Computing Services INTERNET: soon )
( Eastern Kentucky University VOICENET: 606-622-1986 )
( Richmond, Kentucky 40475 DISCLAIMER: YES )
------------------------------
Date: Fri, 24 May 91 08:43:42 EDT
From: rachiele@NADC.NADC.NAVY.MIL
Subject: Multi-tasking in DOS
Can anyone tell me: Is there any way to do multi-tasking in DOS? I'm
running a 286. I know there are some packages out there which appear
to do it, like MS Windows and DESQview. Do these really allow task to
procede in the "background" when they're not the main window? Any idea
about cost of packages? I've almost (but not quite) given up on
finding any PD/shareware products which will do this.
Thanks.
Jim Rachiele
rachiele@nadc.nadc.navy.mil
------------------------------
Date: Thu, 23 May 91 14:48 EST
From: Carol Conti-Entin <$CAROL%OCVAXC.bitnet@RICEVM1.RICE.EDU>
Subject: tape backup without using a board or SCSI port?
We are looking into the possibility of using tape backup for
stand-alone Zenith ZW-148s (XT clones) and possibly for some
as-yet-unpurchased 386 machines (either Hewlett-Packard Vectras or
Anonymouses assembled from standard parts). What products are out there
which'll work without boards or SCSI ports? I've heard rumors that tape
backups exist which can work via the serial or parallel port alone, but
I haven't been able to locate any specifics. ALL INFORMATION (brand
names/addresses/phones, prices, pros, cons, etc.) DEEPLY
APPRECIATED--thanks in advance.
Carol Conti-Entin
pconti@oberlin [Sounds like this is a BITNET site]
pconti@ocvaxa.cc.oberlin.edu [Address for Internet]
216-775-8778
Academic Computing Consultant
Oberlin College Mudd 015
Oberlin, OH 44074
------------------------------
Date: Fri, 24 May 91 10:51:10 EDT
From: Jeffrey R Kell <JEFF%UTCVM.BITNET@CUNYVM.CUNY.EDU>
Subject: Vax/VMS ZModem quirks
I obtained the Vax/VMS Zmodem package as advertised here some issues
ago and installed it on our Vax (RZ.EXE and SZ.EXE). It works
marvelously with a straight DOS DSZ or when DSZ is configured as an
external protocol. However, Telix (3.12 and 3.15)
auto-ZModem-downloads hang, as does ZTerm on a Mac (which also supports
auto-ZModem-downloads). Both recognize the transfer as ZModem and
switch to the appropriate file transfer window, but then hang up and
transfer no data, eventually timing out. It is not a timing, parity,
or configuration problem; and we are using default options on SZ.EXE,
supplying only the filename. Before we breakout the line monitor,
protocol specs, and Maalox, has anyone run into this problem before?
Is there a workaround?
Secondary question, are the Xmodem (RX/SX) and Ymodem (RB/SB) VMS
images mentioned in the RZ/SZ documentation available anywhere? Many
thanks in advance to any help/advice/condolences...
| Jeffrey R Kell, Dir Tech Services | Admin Postmaster/Listserv co-ord. |
| Admin Computing, 117 Hunter Hall | Bitnet: JEFF@UTCVM.BITNET |
| Univ of Tennessee at Chattanooga | JEFF%UTCVM.BITNET@CUNYVM.CUNY.EDU |
| Chattanooga, TN 37403-2598 | Bell: (615)-755-4551 |
------------------------------
Date: Fri, 24 May 1991 02:20:38 GMT
From: schriste@uceng.UC.EDU (Steven V. Christensen)
Subject: Windows with edit buffer
Hi,
I am looking for a C windows library (similar to BOSS, or CXL, etc.)
but with an additional feature I don't see in any of them:
I want the user to be able to cursor edit a window's contents like a
full screen editor, i.e. multiple lines, automatic margin new-lining
(e.g. type and it automatically moves you to the next line when you hit
the margins, including your current partially completed word).
Can anyone point me to this? I have an old version of a system called
TINYWIN which promises these features in a "future version". The
archive I have is about 3 years old. Does anyone know where the next
version of this is?
Thanks for your help!
Steven
Steven V. Christensen
U.C. College of Eng.
schriste@uceng.uc.edu
For the adventurous: svc@elf0.uucp
------------------------------
End of Info-IBMPC Digest V91 #135
*********************************
-------