HDTenEightyP/NetNews huggingface dataset:
From: u926135@tasman.cc.utas.edu.au (Adrian Hassall Lewis)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: University of Tasmania, Australia.
Date: Sat, 12 Dec 1992 11:18:54 GMT

>In article <1992Nov26.015031.29333@ringer.cs.utsa.edu>, senseman@ricky.brainlab.utsa.edu (David M. Senseman) writes:
> 
> I agree with everything Thomas Sippel said and only want to add one point.
> More and more, high performance computing is graphical computing. This is
> certainly true in Biology and I expect in Chemical Physics as well.
> 
> If you look at Dec, Sun, and IBM, their graphics strategy has been 
> pretty uninspired. As an old PDP-11 user, I have tremendous respect for
> Ken Olsen -- but let's face it, if there ever was a "left-brained" 
> person, it was Ken. Dec never had a coherent graphics vision and as far I
> can see, it still doesn't. Sun is just as bad -- witness the TACC-1, 
> the incompatible TACC-2, and the lastest in the line, the incompatible
> Freedom 3000 (Evans&Sutherland add on board). And IBM? As someone
                                                ^^^^^^^^^^^^^^^^^^^
> who still owns an IBM PC/RT, don't get me started...
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> -- 
> David M. Senseman, Ph.D.     | A man who has never gone to school may steal 
> (senseman@lonestar.utsa.edu) | from a freight car; but if he has a university
> Division of Life Sciences    | education, he may steal the whole railroad.
> UT San Antonio               |             Theodore Roosevelt (1858-1919)

Excuse me but I'd like to get you (and anyone else) started.

Firstly, on the RS/6000's a large amount of the graphics hardware and software
is licenced from SGI, so what's the big problem with IBM's graphics?

Secondly, I am looking at doing computational chemistry on an RS/6000 and I'd
like to see you (or anyone else) try to talk me out of it (or support it).

	ajax

Adrian.Lewis@iasos.utas.edu.au

PS   Sorry about the cross-posts, but I don't know where this thread first
     started.

PPS  Please attack via email.
Newsgroups: comp.arch,comp.lsi,comp.periphs,comp.arch.storage,ba.seminars
From: freeman@cis.Stanford.EDU (Martin Freeman)
Subject: CALL FOR PARTICIPATION: HOT CHIPS SYMPOSIUM V
Originator: freeman@cis.Stanford.EDU
Organization: Center for Integrated Systems, Stanford University, California
Date: Thu, 17 Dec 92 03:05:06 GMT


		     HOT CHIPS SYMPOSIUM V
		Stanford University, Stanford, CA
		       August 8-10, 1992


		    CALL FOR CONTRIBUTIONS
	                  
	General Chair:      John Hennessy, Stanford University
	Program Co-chairs:  Ruby Lee, Hewlett-Packard Company
			    Teresa Meng, Stanford University




HOT CHIPS is back once again! Sponsored by the IEEE Computer Society
Technical Committee on Microprocessors and Microcomputers, Hot Chips V
is a conference that consists of presentations on high-performance
chip and chip-set products, and related topics. This conference is
directed particularly at new and exciting products. The emphasis is on
real products, not academic designs. Participants will not be required
to prepare written papers. The proceedings will consist of copies of
the slides to be presented.

Contributions are solicited in the following areas:

* RISC and CISC Processors             * JPEG, MPEG and H.261 Chips

* Floating Point Processors            * Personal Communications Devices     

* Embedded CPUs                        * Media Processors                        
* Graphics, Image and Video Chips      * Neural Chips                 

* Interconnection Chips                * Compiler Issues with Hot Chips      

* Network Chips                        * Benchmarking/Performance Evaluation  

* Cache and Memory Chips               * Low-Power Design

Proposals should consist of a title, an extended abstract (1-5 pages) 
describing the product or topic to be presented, and the name,
title, address, phone number, fax number, and electronic mail address
of the presenter. If this is a not yet announced product, and you would
like the submission kept confidential, please indicate it; we will do
our best to maintain confidentiality. Submissions can be made by hard
copy, fax, or electronic mail, by Friday, March 12, 1992 to:

                HotChips V
                c/o Ms. Lilian Betters
                CIS 036
                Stanford University
                Stanford, CA. 94305
                Tel: (415) 725-3651
                Fax: (415) 725-6278
                Email: hotchip@tilden.stanford.edu

For further general information about the symposium, contact John Hennessy
at (415) 725-3712 or jlh@vsop.stanford.edu. For further information
about submissions, contact Ruby Lee at rblee@nsa.hp.com, or Teresa Meng at 
teresa@tilden.stanford.edu.


Newsgroups: comp.arch
From: dhd@exnet.co.uk (Damon)
Subject: Re: Heat Output of New uPs
Organization: ExNet Systems Ltd Public Access News, London, UK
Distribution: usa
Date: Mon, 14 Dec 1992 01:03:07 GMT

In article <1992Dec9.155802.29342@sequent.com> thall@sequent.com (Trevor Hall) writes:
>Here's a new thread.  Think about the latest generation of uPs: Alpha,
>R4000/4400, Pentium, M88110.  Now think about the heat dissapation of
>those chips.  I think the Alpha's in the 20+ watt range, Pentium is
>12-15 watts.  Now try to imagine one of these guys in a laptop...
>
>Any ideas for (safely) implementing a laptop based on one of these
>chips?  If I remember correctly, I think 10-20 watts was about the
>heat output of the Kenner Easy-Bake Oven.  I can't picture putting
>one of those on my lap for a 2-3 hour plane trip.

Well, I think one could use it for ruggedised computing in colder
climes (like Scotland and northwards).

"150SPEC with built in hand/crutch warmer, maintains typing speed at
-5C..."

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: ajc@pa.dec.com (AJ Casamento)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 16 Dec 92 17:55:42
Organization: Digital Equipment Corporation
	<1992Dec15.194637.10009@eng.umd.edu> <1992Dec15.205639.25591@super.org>
NNTP-Posting-Host: thendara.pa.dec.com
In-reply-to: rminnich@super.org's message of Tue, 15 Dec 1992 20:56:39 GMT



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

>>In article <1992Dec15.194637.10009@eng.umd.edu> sysmgr@king.eng.umd.edu 
>>writes:
>> >You guys ever thought of licensing TurboChannel from DEC and building a
>> >Pentium box/server around it? 

>> TurboChannel is a dog. 

>> Actually, seems to me they could look at SCI. Except they want low cost.
>> But if the CMOS chips for SCI pan out, maybe they will meet the cost 
>> range.
>> ron

Ron,

  I'm confused. Is there something to back this opinion up? Which machine or
implementation are you discussing? For my own view of things TURBOchannel is
the fastest shipping desktop interconnect in the market (with internal designs
of network options that have sustained over 80MB/s under software control).

If there are specific examples of issues you've seen with performance I'd be
interested.

The platform breakdown looks something like this:

	12.5MHz  50MB/s				25MHz  100MB/s

	DS5000/20				DS5000/200
	DS5000/25				DS5000/240
	DS5000/33				DS5900
	DS5000/120				DEC3000/400 (actually 93MB/s)
	DS5000/125				DEC3000/500
	DS5000/133

If you have questions about specific platform implementations (the numbers
quoted are theoretical peak bandwidth, the highest I've seen a 12.5MHz system
run is ~44MB/s and a 25MHz system is ~82MB/s). And the DS5000/200 started 
shipping in April of 1990.

I hope that clears things up.

				Thanx,
				  AJ


ps. I haven't included the VS4000/60 or VS4000/90 on this as the TURBOchannel
    on those systems is a bridge adapter which is bounded in performance by the
    bus on the system module.

      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************
Xref: sparky comp.arch:11784 comp.arch.storage:874
From: mike@cbl.umd.edu (Michael Santangelo)
Newsgroups: comp.arch,comp.arch.storage
Subject: Re: ?Concurrent DMA possible on smarter PC buses (EISA/MCA/Localbus)
Date: 19 Dec 1992 03:06:15 -0500
Organization: University of Maryland, Chesapeake Biological Laboratory
NNTP-Posting-Host: cbl.umd.edu
Keywords: EISA,MCA,Localbus,VESA,PC,IBM,smartIO

In comp.arch you write:

>mike@cbl.umd.edu (Michael Santangelo) writes:

>>Can EISA, MicroChannel, or the new VESA LocalBus on PC's allow
>>multiple controllers plugged into them (say two smart bus mastering
>>SCSI disk controllers on one of these buses) xfer data simultaneously
>>to main memory (DMA)?
>Both EISA and MicroChannel support the concept of multiple preemptable
>bus masters. In the case of EISA, the system DMA controller also behaves
>like a bus master. EISA arbitrates round robin. MicroChannel arbitrates
>priority-based, but degenerates to round-robin once the "fairness feature"
>is turned on.
>Therefore e.g. an SCSI controller and an FDDI network controller can
>xfer data "simultaneously" to/from main memory on these buses. Of course
>the bus is a shared medium, so the devices will "fight" for the bus
>and share the available bandwidth with some of the bandwidth lost due to
>the preemption/re-arbitration overhead.

So this theoretical EISA SCSI controller and this theoretical EISA FDDI
controller could both be doing DMA writes to main memory (interleaving their
accesses I assume)?  Since PC's do not have multiport memory, I assume
the EISA subsystem would itself (on behalf of BOTH of these controllers) have
full control over the memory during the dual transfers, starving out the CPU?

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@cbl.umd.edu
Computer & Network Systems Director   +           mike@kavishar.umd.edu
UMCEES / CBL (Solomons Island)        + BITNET:   MIKE@UMUC
University of Maryland                + Voice:    (410) 326-7237 (direct)
                                      +           (410) 326-4281 x237
-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@cbl.umd.edu
Computer & Network Systems Director   +           mike@kavishar.umd.edu
UMCEES / CBL (Solomons Island)        + BITNET:   MIKE@UMUC
Newsgroups: comp.arch
From: nagle@netcom.com (John Nagle)
Subject: Re: Compaq's Proposed Scalable I/O Architecture
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Distribution: usa
Date: Fri, 18 Dec 1992 03:10:32 GMT

     A few questions:

     - Presumably there is a card form-factor and connector defined for
       this standard.  Could you say more about that?

     - Similarly, there is presumably an inter-box cable and connector
       defined, or will be.  Comments?  Incidentally, are the signals
       differential-drive, or do we have to worry about common-mode noise
       and grounding?  And do peripheral devices get to draw power from
       the big box over this interface?

     - Given that Microsoft's NT supports multiprocessors (16 CPUs have
       been demonstrated) and Compaq's position as a high-end vendor for
       Microsoft-compatible iron, I'm suprised that Compaq is proposing an
       I/O architecture that is single-CPU oriented.  Why?

     - Another likely multiprocessor application appears in laptop-type
       "docking stations", where the laptop plugs into a desktop machine.
       Is this bus suitable for that application?

					John Nagle
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 15 Dec 92 08:47:24
Organization: Intel i960(tm) Architecture
	<1992Dec14.134109.3367@fasttech.com> <edm.724366309@wrs.com>
NNTP-Posting-Host: potato.intel.com
In-reply-to: edm@wrs.com's message of Mon, 14 Dec 1992 20:51:49 GMT


edm@wrs.com (Ed McClannahan) writes:
[ WRT NeXTSteP being 486-only, and not 386 ]
]	because it is FFAASSTT - like his car, get it?  BTW: I took this
]	"486" decision to be yet one more indicator that NeXT does not
]	target the mass market.

Intel486(tm) SX processors are priced at just a little over $100 in 
1000-unit quantities, and Intel plans to continue dropping the price
of it's x86 products. Which is to say : in very few years, 486-class
machines will be the mass market, and 386-class machines will be where
the 286-class machines are now : low-end laptops and toys for the kids.

--
Dennis O'Connor			doconnor@sedona.intel.com
From: spackman@disco-sol.dfki.uni-sb.de (Stephen Spackman)
Newsgroups: comp.arch
Subject: Re: Date request
Date: 20 Dec 92 17:47:58 GMT
	<1992Dec14.134109.3367@fasttech.com> <1992Dec16.171133.2856@lsl.co.uk>
	<BURLEY.92Dec16135311@apple-gunkies.gnu.ai.mit.edu>
Reply-To: stephen@acm.org
Organization: DFKI Saarbruecken GmbH, D-W 6600 Saarbruecken
NNTP-Posting-Host: disco-sol.dfki.uni-sb.de
In-reply-to: burley@apple-gunkies.gnu.ai.mit.edu's message of 16 Dec 92 13:53:11

English has more words for snow than eskimo (over a dozen vs. less than
six, though it's hard to know where to draw the line: are "sleet" or
"snowdrift" counted?). The whole thing is a very old
hoax/legend/misunderstanding that drives linguists mad. Just so you
know.

But THIS belongs in comp.arch?
------------------------------------------------------------------------
stephen p spackman                                       stephen@acm.org
------------------------------------------------------------------------
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.arch
Date: Tue, 15 Dec 1992 07:06:40 -0500 
From: William.Lott@cs.cmu.edu
Subject: Re: Any use for Branch if Even/Odd ?

endecotp@cs.man.ac.uk (Phil Endecott) writes:
> Can anyone think of a use for the branch if even and branch if odd
> instructions on the Alpha?  I'm completely baffled.
> 
> --Phil.

In our lisp system all pointers have the low bit 1 and all
non-pointers have the low bit 0.  So if your compiler can figure out
that it can use this instruction to handle ``if (obj & 1) ...'' then
our garbage collector might be a wee bit faster.

-William Lott
CMU Common Lisp Group
Newsgroups: comp.arch
From: jg@crl.dec.com (Jim Gettys)
Subject: Re: Heat Output of New uPs
Organization: DEC Cambridge Research Lab
Distribution: usa
Date: Mon, 14 Dec 1992 11:30:00 GMT

In article <Bz85L8.Bnx@exnet.co.uk>, dhd@exnet.co.uk (Damon) writes:
> In article <1992Dec9.155802.29342@sequent.com> thall@sequent.com (Trevor Hall) writes:
> >Here's a new thread.  Think about the latest generation of uPs: Alpha,
> >R4000/4400, Pentium, M88110.  Now think about the heat dissapation of
> >those chips.  I think the Alpha's in the 20+ watt range, Pentium is
> >12-15 watts.  Now try to imagine one of these guys in a laptop...
> >
> >Any ideas for (safely) implementing a laptop based on one of these
> >chips?  If I remember correctly, I think 10-20 watts was about the
> >heat output of the Kenner Easy-Bake Oven.  I can't picture putting
> >one of those on my lap for a 2-3 hour plane trip.
> 
> Well, I think one could use it for ruggedised computing in colder
> climes (like Scotland and northwards).
> 
> "150SPEC with built in hand/crutch warmer, maintains typing speed at
> -5C..."
> 

Well, of course, you turn down the clock way down when you don't need the speed...
So long as the total computation/watt hour stays the same, I'll take the faster machine...

Another suggestion use for the left over heat has been as a coffee warmer;
got to keep the user running fast as well :-).

-- 
Digital Equipment Corporation
Cambridge Research Laboratory
Newsgroups: comp.arch
From: jfc@grouse.dsg.dec.com (John F Carr)
Subject: Re: Alpha Architecture Quirks
Keywords: Alpha 21064
Organization: Digital Equipment Corporation
Distribution: usa
Date: Tue, 15 Dec 1992 00:41:58 GMT

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

>1)  I read that the 21064 divide unit is not pipelined and takes one cycle 
>    per bit to produce a result.  Isn't this going to kill floating point
>    performance? [...] I'm
>    lead to think that DEC isn't interested in the FP performance of this chip,
>    or do I have my facts wrong?

A double precision floating point divide is slow, but look at the benchmark
results: the Alpha AXP 10000 is rated at 200 SPECfp92.  If you buy the
low-end model you get 112 SPECfp92.  Obviously divide performance isn't
critical to this large selection of real-world applications.

In any case, considering the clock speed difference between Alpha AXP and
competitive systems you are better off counting nanoseconds instead of
cycles:

			DEC Alpha AXP			IBM RS 6000
			 	133 Mhz	150 Mhz		 	41 Mhz	62.5 Mhz
			cycles	ns	ns		cycles	ns	ns
FP mult or add		 6	 45	 40		 2	 48	 32
FP divide		63	473	420		20	480	320

This shows floating point latency of the low/mid range Alpha systems to be
similar to the IBM RS/6000.  But this is the worst-case* performance.  The
Alpha can execute 6 independent floating point operations in parallel, and
most floating point code can use at least part of this parallelism.


*Both Alpha and RS/6000 are slower when handling infinities, NaNs, or
denormals, but for most applications this is not an important consideration.


>3)  The manuals say that the 21064 is superpipelined.  Where?  How can this
>    claim be justified in light of the floating point divider not being
>    pipelined at all?

I first heard the term "superpipelined" applied to the MIPS R4000, which
does not pipeline integer multiply or divide (I don't know if it pipelines
floating point divide).


	John Carr
	jfc@grouse.dsg.dec.com

	All facts and opinions in this article are the responsibility
	of the author, not DEC.
From: nand@not-and.Eng.Sun.COM (Nand Mulchandani)
Newsgroups: comp.arch
Subject: Re: RISC assemblers question
Date: 18 Dec 1992 03:26:09 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: nand@not-and.Eng.Sun.COM
NNTP-Posting-Host: not-and

masticol@cadenza.rutgers.edu (Steve Masticola) writes:
: Hi,
: 
: I've met a couple of people who have attempted to write assemblers for
: RISC machines, who say that it's a difficult job. Can someone give me
: an inkling as to why?
: 
: I'm not saying that it isn't; the reason just isn't obvious to me
: right now.
: 
: Thanks,
: - Steve (masticol@cs.rutgers.edu).

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).
2) In general, chip workarounds are done in the assembler, and this code
   is just yuckier to deal with
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.
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". 

There may be others, these are the only ones that come to mind right now. 

Cheers.

- Nand
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 18 Dec 92 10:07:00 MDT
Organization: Utah State University

In article <1992Dec17.190553.17417@twisto.eng.hou.compaq.com>, simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:
> In article <1992Dec17.100528.62134@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>>
>>Well, working for a small company that can't afford to run out and spin
>>ASICs for every design, I would much rather deal with a TURBOchannel that
>>can be managed with a few PALs and jellybeans than a lower pin-count bus
>>that requires an ASIC to unpack that packets.
> 
> Uh, why do you assume an ASIC is required?  Anyway, the intermediate nodes
> of the network may be used over and over in any new design.  The only time
> you would have do design anything new is if you changed the system interface.

Perhaps an ASIC isn't required, but picking the transactions apart on this
sort of bus requires a more complex state machine than something like the
TURBOchannel. You've traded pin-count for states; to make up for the lack of
pins on the bus, each module has to keep track of which state the bus is in.
On something like TURBOchannel, the state is visible on the bus (the main
exception being DMA burst word count; that's, well, different).

-- 

Roger Ivie                      "My God! That computer is full of Pentium!
ivie@cc.usu.edu                  It's a wonder that you haven't been turned
                                 into mutants!"
From: C88002@TRMETU.BITNET
Newsgroups: comp.arch
Subject: help wanted
Date: 19 Dec 92 05:25:18 GMT
Organization: Middle East Technical University - Computer Center

Is there anybody who can give immadiate information about HARVARD
architecture?...
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Organization: Rice University, Houston
Date: Tue, 15 Dec 1992 17:28:08 GMT


>> We describe an efficient software cache consistency mechanism for shared
>> memory multiprocessors that supports multiple writers and works for
>> cache lines of any size.  Our mechanism relies on the fact that, for a
>> correct program, only the global memory needs a consistent view of the
>> shared data between synchronization points.  Our delayed consistency
>> mechanism allows arbitrary use of data blocks between synchronizations.

>cliffc@rice.edu (Cliff Click) writes:
>>This sounds like an paraphrase of Ervan Darnell's thesis proposal here
>>at Rice.

zs@munta.cs.mu.OZ.AU (Zoltan Somogyi) writes:
>This idea is quite old. It was the subject of a tech report six years ago:
>
>%A D. Abramson
>%A K. Ramamohanarao
>%A M. Ross
>%T A software controlled cache coherence policy,
>using selectively clearable cache memories
>%R Technical Report 86/18
>%I Department of Computer Science, University of Melbourne
>%C Melbourne, Australia
>%D 1986

In defense of Ervan's work:
He's exploring compiler optimization to lower the cost of maintaining
cache coherence via software.  Presumably, machines like IBM's will
benefit from his efforts (and the efforts of all the other people
working in the same direction).

Preston Briggs
Newsgroups: comp.arch