BeNewsletter Article
Chips Questions
By Jean-Louis Gassée
Reproduced from BeNewsletter Volume III, Issue 35;
September 1, 1999
Now that IBM has announced the availability of a PPC
motherboard, why doesn't Be jump on the bandwagon and commit
to this hardware? My apologies for not doing full justice
to the number, variations, or eloquence of the messages sent
to info@be.com or directly to me. You get the idea, though.
Something is happening in the PPC world and Be ought to
support it. One correspondent expressed it as a brutal Wall
Street reduction: "I would even be willing to bet that this
would cause the most dramatic rise in Be stock since the
IPO."
The stock price is not a topic for me to comment on, but the
sentiment regarding the PowerPC needs to be addressed
(immediately, which is why I've postponed the next
installment of the IPO story, "Going Public: Part II"). The
processor itself is a fine one, as the benchmarks prove.
We've had versions of BeOS on the PowerPC since 1994,
including our current 4.5 release (whose package clearly
states "For x86 and PowerPC"). So, what we're dealing with
is not really a processor dilemma. Is it then a question not
of chips but of chipsets? Setting aside a possible
oversimplification for the moment, this turns out to be a
better lead to the real issues.
Look at the evolution of PC motherboards. More and more
functions get integrated, as opposed to implemented on
plug-in cards. In the process, the "chipset," the chip or
chips interposed between the faster and faster CPU and
slower devices such as the PCI bus, memory, frame buffers
and the like, become richer and richer mediators. The
complexity of the better chipsets now rivals or exceeds that
of the CPU itself.
The operating system, in turn, needs to support these
mediating devices; otherwise, the hardware, or the OS, or
both aren't going anywhere. Take Silicon Graphics' recent
decision to de-emphasize their low-end workstations based on
Intel processors and Windows NT. These workstations required
two proprietary objects, a physical one and a logical one.
On the physical side, Silicon Graphics decided to use ASICs
to express their knowledge of the application space.
Together, these Application Specific Integrated Circuits
constituted a "chipset" providing high-performance I/O for
graphics, video, and audio applications in SGI's heritage.
The idea was to achieve a level of performance higher than
that offered by the standard PC clone organ bank. This, in
turn, required a logical object, NT software, drivers and,
perhaps, modifications to NT itself. Meanwhile, the
relentless clone industry continued to drive the price of
standard organs down and the performance up. The clone drive
reached a point where the SGI solution became less likely to
achieve its original goals.
If that example isn't enough, recall recent announcements
regarding high-end chipsets for servers. Two camps were
ready to make war over a standard, one led by Intel and, if
memory serves, the other by Compaq. But the cost of the
conflict and the benefits of having only one standard led to
peace. We can now expect organ bank support for eight-way
multiprocessing, coming soon from your favorite motherboard
supplier.
To return to PowerPC hardware, we need to know more about
chipsets that support the PowerPC. Who builds them, how
competitive are they, which I/O devices are supported, how
is the technical documentation accessed, who fixes bugs in
the product and the documentation? As far as the IBM PPC
hardware is concerned, other questions arise. Where can I
buy it and where can I get it fixed, for instance? As
answers emerge, it will be easy for us to make a decision.
That said, I still haven't answered the Apple question. If
Apple is selling respectable quantities of PowerPC hardware,
how come we don't support the latest G3 and G4 machines? As
I said above, it boils down to a chipset issue. Intel
doesn't have an operating system to defend. In their best
interest, they profess to be "OS-agnostic," the more
options, the better. In Apple's case, it's different. They
own and operate an OS and, like Microsoft, see no reason to
help a competitor. Linux provides access to classical Unix
applications and, therefore, is little competition for
Apple's multimedia heritage. The same can't be said of BeOS,
and I can see the logic in Apple's decision not to help us
with access to chipset technical data for a G3/G4 BeOS port.
Some have suggested that we look into the Linux sources for
such data. Perhaps, but I see little reason to open
ourselves to possible accusations of reverse-engineering.
We're welcome on x-86 hardware, we're not welcome on Apple
G3/G4. We respect the logic and that settles it for us.
|
