Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!princeton!njin!rutgers!modus!otello!gear!cadlab!martelli
From: martelli@cadlab.sublink.ORG (Alex Martelli)
Newsgroups: comp.arch
Subject: Re: ACE, buses, and the future of ultrix
Message-ID: <864@cadlab.sublink.ORG>
Date: 22 May 91 18:25:36 GMT
References: <281f3e99.2f35@petunia.CalPoly.EDU> <1991May2.224316.17903@ico.isc.com> <816@cadlab.sublink.ORG> <3683@spim.mips.COM>
Organization: CAD.LAB, Bologna, Italia
Lines: 57

mash@mips.com (John Mashey) writes:
:In article <816@cadlab.sublink.ORG> martelli@cadlab.sublink.ORG (Alex Martelli) writes:
:>	...
    ...
:>Don't forget they'll support BOTH Dec Turbochannel AND EISA... so, times 
:>two again... the bus variation may be the most important of the three, for
:>3rd party addon-board manufacturers, and for purchasers of vast numbers of
:>machines, who can't really buy machines with different buses if they want
:>to be able to minimize spare parts inventory for the addon cards.
:
:This is nonsense.

Thanks, very diplomatic of you.  Have you read what you quoted?  I opined that
the bus variation can be more important than the variation in operating
systems and in CPUs (R3000's vs R4000's) for two classes of companies:
manufacturers of add-on cards, and purchasers of many machines, who want
bus uniformity for spare-parts inventory.

You seem to be answering, and deeming 'nonsense', some different assertion,
one which I did not make...:

:In the PC world: there are XT busses, AT busses, EISA busses, MCA busses.
:Much of this happened sort of by accident, and a lot of software knows too
                                                        ^^^^^^^^^^
:much about what's there, in gory detail.
	...
:Hence, the ACE compatibility specifications are structured so that one can
:have a reasonable shrink-wrapped kernel that doesn't HAVE
                                 ^^^^^^^^
:to know about the I/O bus choice, but still has enough info to

Sure, it's evil for application software to know about bus structure, and
sure, it's nice for the kernel to be able to ignore it, too, but what does
this have to do with my assertion being 'nonsense'?  It makes life easier
for writers of software, and for purchasers of same, but does not remove
the misery from manufacturers and purchasers of add-on cards... if the ACE
consortium had blessed ONE bus, instead of two, it would have something
more 'standard' in its hands, just as if it had blessed one OS, rather than
one and one half.

Incidentally, the XT->AT->EISA bus evolution is a possible solution, although
not necessarily optimal; another one is to standardize just an 'EXTERNAL' bus,
for add-ons, whose performance may be acceptable even on an 'old' bus, while
keeping implementor freedom for internal structures (the EISA in an HP/700,
like the VME in a Soulbourne or the Sbus in an SS2, is not really slowing
down the machine, is it?  Besides, look at what Soulbourne is doing - if
the 25 Mbytes/sec total throughput of VME is stunting your growths, just
put in *multiple* VME 'buses', on separate "I/O channel boards").

I should point out that this 'nonsense' is just personal opinion and
interest - my employer is strictly a SW business anyway, so I guess it
HAS no opinion on buses or anything as gross as that...:-)
-- 
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/407.314 (home only).