HDTenEightyP/NetNews huggingface dataset:
Newsgroups: comp.arch

>: I don't know much about HP except that I have been told that their
>: operating system isn't really UNIX.

HP complies with all applicable industry standards:  SVID2, XPG2, XPG3,
and POSIX (and probably others).


Perry Scott
HP Ft Collins
Newsgroups: comp.arch,comp.sys.intel
From: peter@ferranti.com (peter da silva)
Subject: Re: Superscalar vs. multiple CPUs ?
Keywords: software pipelining, VLIW, LIW, superscalar
Organization: Xenix Support, FICC
Date: Sat, 12 Dec 1992 01:08:02 GMT

A transputer-like multi-CPU chip would make a killer UNIX box! Use Synthesis-
type techniques to map read and write over a pipe into message passing over
the interprocessor channels, and then run your UNIX pipeline one process per
CPU.
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
Newsgroups: comp.arch
From: rminnich@super.org (Ronald G Minnich)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Organization: Supercomputing Research Center (Bowie, MD)
Date: Wed, 16 Dec 1992 20:08:46 GMT

In article <1992Dec15.205639.25591@super.org> rminnich@super.org (Ronald G Minnich) writes:
>TurboChannel is a dog. 

I was wrong. I got some bad information from a DEC technical person 
who was here a while back to show us the Alpha box. His firm claim was 100 
Mbits/second. He blew it. 
An engineer at DEC relates that the number should be 100 MBytes/sec.
The person further indicated that actual measured was over 90% of this 
figure. 

So TurboChannel is about twice as fast as our best SBUS efforts at SRC.

ron
-- 
you want windows? I got windows. 4608 by 3600,    | rminnich@super.org
16 channels of sound, 4' by 6'. Fun.              | (301)-805-7451 or 7312
Most abused words: open, scaleable, [more later]  |
Newsgroups: comp.arch
From: cecchi.rchvmx.vnet.ibm.com (Del Cecchi)@rchland.vnet.ibm.com
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: Wed, 16 Dec 1992 16:45:48 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
Organization: IBM Rochester
Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus

Why wouldn't you use one of the defined versions of the already specified
IEEE-1596-1992 or Scalable Coherent Interface?  If you adopt the 1596.3 signaling
levels, you will be able to buy the core logic from LSI Logic or perhaps
National.  Dolphin SCI Technology will be happy to provide advice.

All in all, you are about three years late if you want to invent, but right on
time if you want to use.
-- 

Del Cecchi  
cecchi@rchvmx.vnet.ibm.com
From: jtien@verdi.eng.uci.edu (Joe Tien)
Subject: How to list software as reference
Newsgroups: comp.arch
Reply-To: jtien@verdi.eng.uci.edu (Joe Tien)
Organization: University of California, Irvine
Date: 20 Dec 92 00:00:51 GMT


Hope this is appropriate to this newsgroup.

How should I list software packages/programs I used in my research as references?
They are even more significant than the papers I read in terms of getting actual
results and stuff. So I'm sure I should list them, just don't know how.

Any pointer is appreciated.

Joe Tien
jtien@balboa.eng.uci.edu
Newsgroups: comp.arch
From: rminnich@super.org (Ronald G Minnich)
Subject: Re: [Anet: Compaq Proposal]
Organization: Supercomputing Research Center (Bowie, MD)
Date: Thu, 17 Dec 1992 20:43:36 GMT

In article <1992Dec17.192509.18453@twisto.eng.hou.compaq.com> leigh@croatia.eng.hou.compaq.com (Kevin Leigh) writes:
 (re sci)
>A. for I/O (we don't want to carry the coherency bag)

did you look at the noncherent load/store operators that SCI supports? 
I know SCI makes people think only coherency but it need not. 
There is a set of noncoherent memory operators that ought to be good for I/O.

Also SCI is targeted in one form to fiber  (i.e. one 'wire') 
which has been mentioned as a 
desirable thing, as opposed to a bytewide path.


ron

-- 
you want windows? I got windows. 4608 by 3600,    | rminnich@super.org
16 channels of sound, 4' by 6'. Fun.              | (301)-805-7451 or 7312
Most abused words: open, scaleable, [more later]  |
Newsgroups: comp.arch
From: timhu@ico.isc.com (Timothy Hu)
Subject: Re: Motorola RISC architecture
Organization: Interactive Systems Corp., Boulder CO
Date: Wed, 16 Dec 1992 17:24:11 GMT


You can call your local Motorola office or Manufacturer's rep. office.
They'll be glad to send you all they have on the 88xxx family.


Newsgroups: comp.arch
From: simonich@croatia.eng.hou.compaq.com (Chris Simonich)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Organization: Compaq Computer Corp.
Date: Wed, 16 Dec 1992 23:50:11 GMT

In article <AJC.92Dec16112232@thendara.pa.dec.com> ajc@pa.dec.com (AJ Casamento) writes:
>
>  Actually, I personally find a great deal of merit in the COMPAQ proposal. I
>quite agree that a modular I/O design (whether one uses the terminology of a
>"star topology" or, as we do here in DEC, "radial") has a great deal to 
>recommend it. Consider a TURBOchannel implementation like this:
>
>			------------	    -------	
>		        |          |	    |	  |
>			|  Memory  |========| CPU |
>			|	   |	    |	  |
>			------------	    -------
>			     |		       |
>			     | <--- DMA	       |
>			     |		       |
>			----------	       | <--- PIO
>			|	 |	       |
>			| Tc/CTL |--------------
>		 -------|        |_________________________
>		/	----------			   |
>	       /	   |   |			   |
>	      /		   |   |___________		   |
>	     /		   |		   |		   |
>	    /		   |		   |		   |
>	-------		-------		-------		-------
>       |     |         |     |         |     |         |     |
>    	|sysIO|		| Tc0 |		| Tc1 | 	| Tc2 |
>	|     |		|     |		|     |		|     |
>   	-------		-------		-------		-------
>
>
>Where each of the links to the TURBOchannel Controller (Tc/CTL) is a standard
>25MHz 32bit wide TURBOchannel. The DMA path could be a 50MHz 64bit wide version
>of TURBOchannel (in order to balance the I/O requirements. This would generate
>a system with an aggregate bandwidth of 400MB/s of I/O. The key point here is
>obviously the Tc/CTL ASIC as it will require careful design to support this
>kind of bandwidth (additionally, one could imagine a true dual ported memory
>being used such that the CPU is not starved when DMA access is underway).
>

Very well put.  However, wouldn't it be MUCH cheaper if you used a byte wide
interface instead of 32 bit wide interfaces?  The same architecture with
the Compaq Proposal saves a lot of pins on the control block.
I don't know all that much about Tc, but I've been told that each channel
requires about 60ish pins on the controller once data, control, and power/
gnd pins are taken into account.  The Compaq proposal requires 20ish pins
per channel on the controller.  One could save 120 pins on the controller
for this case by using the Compaq Proposal rather than Tc.  A 120 pin savings
translates into a significant cost savings.

Also, it is possible to scale the aggregate bandwidth of a system using
the Compaq Proposal to 400MB/s or higher.  The bottleneck is system memory.
--
======================================================
Christopher Simonich        simonich@twisto.compaq.com
Compaq Computer Corp.       [713] 374-1898
======================================================
Newsgroups: comp.arch
Subject: Re: Whatever happened to govt. std. peripheral interface?
Organization: I.E.C.C.
Date: 12 Dec 92 13:53:22 EST (Sat)
From: johnl@iecc.cambridge.ma.us (John R. Levine)

>I remember some years ago the U.S. govt. was getting set to require all
>vendors selling to the government to use a standard peripheral interface
>so they could have competition in the peripherals market.  The standard
>was going to be the IBM channel-to-control-unit interface because there was
>already competition in peripherals for IBM 360 systems.  ...

The 360 interface is by current standards a moderate performance channel
interface in the same ballpark as SCSI-1, only somewhat more complex and
with great big connectors about the size of a tennis ball.  The main
advantage it has over SCSI is that the lines can be many feet long, which
was important back when a 20MB disk was the size of a washing machine.

These days I'd think that de-facto and de-jure standards like SCSI and IPI
and the various backplanes like VME and even EISA make the old 360
interface pretty uninteresting.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
Newsgroups: comp.arch,comp.sys.intel
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Why doesn't NeXT think the Cyrix 486 is a "real 486"  (was: Any new instructions in a i486?)
Followup-To: comp.sys.intel
Organization: The Backbone Cabal
	<1992Dec14.134109.3367@fasttech.com> <edm.724366309@wrs.com>
Date: Tue, 15 Dec 1992 01:48:02 GMT

In article <edm.724366309@wrs.com> edm@wrs.com (Ed McClannahan) writes:
> 
> >>>NeXTStep is said to not run on the Cyrix 486 chips because "they are
> >>>not real 486's".  No one has come up with a reliable reason _why_ NeXT
> >>>doesn't think they are "real 486's" or why NeXTStep won't run on them.
> 
> >>I don't have any real data, but I expect the problem is that the Cyrix
> >>chip doesn't have a floating point unit.  
> 
> >A 10/21/92 semi-official net posting on NextStep claims it runs on SXs:
> 
> The jist I got was that NeXTstep wants to maintain compatible File Systems
> between 680X0 and X86 platforms.  To do this, they needed to do a lot of
> byte swapping on the X86 platforms.  Since the 486 has a simple instruction
> to do it while the 386 does not, NeXT just went with the 486.


Well, we have come full circle.  According to Microprocessor Reports,
the Cyrix chip _does_ have the BSWAP instruction, so unless you have
more than just guesses that it doesn't, then my original statement
still holds:

*No one has come up with a reliable reason _why_ NeXT doesn't think
that they are "real 486's" or why NeXTStep won't run on them.*


There are *guesses* that it's because of performance differences, but
that doesn't seem to make too much sense.


There are *guesses* that it's because NeXTStep requires floating
point, but that doesn't seem to be the case.


There are *guesses* that it's because the Cyrix chip doesn't have the
BSWAP instruction, but it seems that Cyrix does have the instruction.


There are *guesses* that it's because of the Cyrix chip doesn't manage
the cache the same way, but know one knows if it is really different.


There are *guesses* that it's because of some of the new control flags
that the i486 has that Cyrix may not have, but know one knows if that
is really a difference.


I have posted all the hard facts that I know, but continuing to
*guess* what NeXT means by the "Cyrix isn't a real 486" phrase is
pointless.



Please, if _someone_ has hard info, post it and kill this thread.  If
you don't have hard info, then don't guess.


thanks

-wayne
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: uniprocessor design ceiling
Date: 14 Dec 92 11:14:17 GMT
Organization: Department of Computer Science, U of Copenhagen

plaw@usc.edu (Patrick Law) writes:

>Correct me if I am wrong. For the last 20 years, we have 4-bit 
>microprocessor, CISC, cache, RISC, superscalar, superpipeline,
>etc. Have we reached a point of diminishing return in uniprocessor
>design? Could we still get a speedup of "X" every "N" years like
>before? The above evolutions are just experiences we learnt in
>building big machines like the IBM 390. I think it is a time for
>MIMD and a change of serial programming style.

That has been the opinion of many people for many years. Why then, has
it not happened? My guess is that there are two reasons:

1) Micro-parallelism (superscalarity etc.) in uniprocessors has kept
them going faster at a steady rate for many years.

2) Implementing "traditional" programming styles on MIMD architectures
has met with little success. Languages that support parallel
programming style has not gained widespread acceptance for
"mainstream" programming.

The real questions are then

ad. 1) How long can we expect this to continue.

ad. 2) Can we expect any change is this area.

My guess is that uniprocessors will continue to increase their speed
at approximately the present rate by use of new fabrication
technologies and extended micro-parallelism. The relative cost will
however rise faster than the speed. We have already passed the point
where multiprocessors based on cheap processors offer more raw
performance per $ than fast uniprocessors. The programming problems of
the multiprocessors has kept these from gaining popularity.

This brings us directly to the other question. I fear that we will
never get acceptable compilers for low-level languages (like C) for
MIMD machines. So, as long as people insist on using these languages,
they (and as a consequence, we) are stuck with uniprocessors. People
need a very good incentive for changing to a completely different
programming language and style, and the only good incentive for the
people who matter (the industry) is money. So until someone produces a
parallel machine that runs the programs people want at twice the speed
and half the cost of competing uniprocessor designs, there is not
likely to be any change.

Specialist areas will in all likelihood use more parallel machines,
but these tend to be very expensive systems, either because they
combine a huge number of processors (like CM2) or because they are
based on (relatively few) expensive high-end uniprocessors (like CM5).
These systems are not likely to compete against workstations and
high-end PCs.

	Torben Mogensen (torbenm@diku.dk)
From: philip@concave.cs.wits.ac.za (Philip Machanick)
Newsgroups: comp.arch
Subject: sales / market share?
Date: 14 Dec 92 13:12:38 GMT
Organization: Computer Science Dept, Wits University
X-Xxdate: Mon, 14 Dec 92 15:01:58 GMT
X-Useragent: Nuntius v1.1.1d12

I've been trying to get a picture of the sales of various processors
and complete systems in various categories, including workstations,
minicomputers, mainframes and personal computers. Unfortunately different
sources seem to count these things different ways (e.g., some include
servers in workstations, some don't). I've seen huge variations on
claimed market share (for example, Sun's 1991 figure varying from 29% to
40%), without much clarity on what is being measured.

Is there a reliable reasonably freely available source on these
statistics? I would ideally like to go back a few years.
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965
Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: <None>
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sun, 13 Dec 1992 00:28:49 GMT

In article <jdd.724022716@cdf.toronto.edu> jdd@cdf.toronto.edu (John DiMarco) writes:
>HP-UX ~= Ultrix ~= Solaris ~= UNIX(tm)
>
>They're all different variants of UNIX, unlike VMS. It is indeed quite 
>conceivable to replace say a Sun running SunOS with an HP running HP-UX. 
>Admittedly, the platforms are not binary compatible, but they're much more
>similar to each other than they are to say a VAX running VMS. 

Yes, as I've said before, I've personally moved a complex application
of my own in a matter of a few minutes from SunOS to HP-UX.  Ie, in
practice, I've tested SunOS ~= HP-UX ~= UNIX(tm).

But then I'm biased.  I tend to feel that SunOS *is* UNIX even though I
know better.  Mindshare, you see.  B^>

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: Multiprocessors
Date: 12 Dec 92 22:30:30 GMT
Organization: CWI, Amsterdam

In article <Bz5s9F.J32.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
 > Oddly, although Crays have been multiprocessors for years, a lot of
 > programs only use one Cray processor. This is often largely a
 > function of incentive. One installation offered a big budget break to
 > parallel applications, and sure enough, almost everything suddenly
 > turned out to be parallelizable.

I do not think it is very odd.  If there is no incentive by budget breaks
or things like that, a program which has been parallelized will cost you
more than a program not parallelized.  The program takes more raw CPU time,
although it is done faster.

This is always a problem in places where budgets are used.  I know of
programs for the Cyber 205 that vectorized extremely well but should be
run scalar.  The reason was that the vectorized version required more
memory and you had to pay for that, so much more that it completely
eliminated the advantage of the faster result in CPU time.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Newsgroups: comp.arch
From: pjdm@chmeee.enet.dec.com (Peter Mayne)
Subject: Re: Alpha Architecture Quirks
Keywords: Alpha 21064
Reply-To: Peter.Mayne@cao.mts.dec.com
Organization: Digital Equipment Corporation
Distribution: usa
Date: Tue, 15 Dec 1992 02:12:42 GMT


In article <1992Dec14.072942.21962@doug.cae.wisc.edu>, keiths@cae.wisc.edu (Keith Scidmore) writes:

>2)  The 21064 has no integer divide.  Again, isn't this going to make math
>    performance poor.  Integer constants can be converted to multiplies
>    but this is only a partial solution.

From the Alpha Architecture Handbook, p A-12, or the Alpha Architecture
Reference Manual, also p A-12:

Integer division does not exist as a hardware opcode. Division by a
constant can always be done via UMULH of another appropriate constant,
followed by a right shift. General quadword division by true variables
can be done via a subroutine. The subroutine could test for small
divisors (less than about 1000 in absolute value) and for those, do a
table lookup on the exact constant and shift count for an UMULH/shift
sequence. For the remaining cases, a table lookup on about a 1000-entry
table and a multiply can give a linear approximation to 1/divisor that
is accurate to 16 bits. Using this approximation, a multiply and a
back-multiply and a subtract can generate one 16-bit quotient "digit"
plus a 48-bit new partial dividend. Three more such steps can generate
the full quotient. Having prior knowledge of the possible sizes of the
divisor and dividend, normalizing away leading bytes of zeros, and
performing an early-out test can reduce the average number of
multiplies to about 5 (compared to a best case of 1 and a worst case of
9).

>Thanks in advance.
>
>Keith R. Scidmore

PJDM
--
Peter Mayne                     | My statements, not Digital's.
Digital Equipment Corporation   |
Canberra, ACT, Australia        | "AXP!": Bill the Cat

Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: RISC assemblers question
Organization: Metaflow Technologies Inc.
Date: Fri, 18 Dec 1992 18:01:51 GMT

In article <lj2h6hINNikj@exodus.Eng.Sun.COM>, nand@not-and.Eng.Sun.COM (Nand Mulchandani) writes:
|> A couple of things make it a *little* harder :
|> 
|> 1) Branches with delay slots (you have to be able to represent them and
|>    deal with them).

Well, actually, the assembler doesn't *have* to know about delay slots.
It's a nice frill if it knows about them well enough to warn you when you
do something unusual in a delay slot, such as a multi-instruction macro.

In general, I don't like "smart" assemblers, trying to fill delay slots
for me.  If I want "smart", I'll use a compiler, thank you.

|> 2) In general, chip workarounds are done in the assembler, and this code
|>    is just yuckier to deal with

This has always really ticked me off.  The SPARC assembler, for instance,
has workarounds (read KLUGEs) for all sorts of stupid things.  When I try
to code a test for a processor that doesn't need the damned kluges, I get
them anyway.  In the sort of tests that I write, I want only the instruction
I'm asking for, no more, and no less.  With the SPARC assembler, so far as
I know, I can't even disable the damned kluges.  So, I have to regress to
the level of machine language programming, and fool the assembler by
inserting an instruction as if it were a data word (can you say manual
assembly?).  Ick!

|> 3) branches have limited scope (on SPARC, you get only 22 bits in the branch
|>    instruction). It is reasonable to leave a check in the assembler to detect
|>    branches to targets that are larger than the displacement will allow.

Yes, but this is true of nearly all microprocessors.  Nothing special about
RISC here.

|> 4) Code to check architectural correctness (try doing something illegal
|>    with the SPARC assembler - if it sqawks, then someone had to write the code 
|>    to do the check). This is very important, because the machine will not always
|>    execute "arbitrary assembly language". 

Again, I consider this sort of thing to be a frill.  



In general, an assembler is an assembler is an assembler.  They're pretty
easy to do, unless you are planning to get too fancy.  I like plain, vanilla
assemblers, perhaps with a simple macro preprocessor.  
-- 

...Russ Schnapp
BIX: rschnapp           Email: netcom!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
From: adm@otter.hpl.hp.com (Alan Marshall)
Date: Wed, 16 Dec 1992 00:09:16 GMT
Subject: Re: Compaq's Proposed Scalable I/O Architecture
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch

In comp.arch, simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:

> Sorry if this is a repost, we were unable to determine if our
> server posted the original copy.  Could someone outside the
> Houston area please post a response upon receiving this article?
> -----------------------------------------------------------------

Well, I see 4 copies of what seems to be the same proposal now.  Thats
probably enough ...

     144+COMPAQ PROPOSED SCALABLE I/O ARCHITE      simonich@croatia.eng.hou
     145+COMPAQ PROPOSED SCALABLE I/O ARCHITE      leigh@croatia.eng.hou.co
     146+Compaq's Proposed Scalable I/O Archi      simonich@croatia.eng.hou
     147+COMPAQ PROPOSED SCALABLE I/O ARCHITE      leigh@croatia.eng.hou.co
From: plaw@usc.edu (Patrick Law)
Newsgroups: comp.arch
Subject: uniprocessor design ceiling
Date: 11 Dec 1992 20:25:31 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: girtab.usc.edu

Correct me if I am wrong. For the last 20 years, we have 4-bit 
microprocessor, CISC, cache, RISC, superscalar, superpipeline,
etc. Have we reached a point of diminishing return in uniprocessor
design? Could we still get a speedup of "X" every "N" years like
before? The above evolutions are just experiences we learnt in
building big machines like the IBM 390. I think it is a time for
MIMD and a change of serial programming style.

Patrick Law