HDTenEightyP/NetNews huggingface dataset:
From: rthomson@mesa.dsd.es.com (Rich Thomson)
Subject: Re: Graphics Systems
Reply-To: rthomson@dsd.es.com (Rich Thomson)
Organization: Design Systems Division, Evans & Sutherland, SLC, UT
Date: Wed, 22 Jul 92 21:25:24 GMT

In article <1992Jul20.200401.14637@awdprime.austin.ibm.com>
	repass@futserv.austin.ibm.com (James Repass) writes:
>CPU <-> Bus <-> Display Adapter (DA)
>CPU <-> Bus <-> DA with memory
>CPU <-> Bus <-> DA with memory and processing (CPU)
>CPU <-> Bus <-> DA with memory and CPU
>CPU <-> Bus <-> DA with memory and CPU <-> Bus <-> Display Adapter
>                                  /                             /
>  /------------------------------/                             /
> /                                                            /
>/                                   /------------------------/
>CPU <-> Bus <-> Display Adapter (DA)
>
>Where will it END?
>Where WILL it end?

How about this:

    CPU <-> Bus <-> 44 DSPs with memory <-> 4 pixel processors <-> memory

Graphics pipelines are becoming more parallel in their implementation
since graphics problems have lots of parallelism in them.  Many
graphics algorithms are "embarrassingly parallel" because they don't
require any communication between the separate sub-problems.  An
example of this is screen-space decomposition of polygons for
rendering.  Each screen "bucket" (rectangular area) touched by the
polgyon can be rendered independently.

						-- Rich
-- 
	Repeal the personal income tax; vote Libertarian in 1992.
Disclaimer: I speak for myself, except as noted; Copyright 1992 Rich Thomson
UUCP: ...!uunet!dsd.es.com!rthomson			Rich Thomson
Internet: rthomson@dsd.es.com	IRC: _Rich_		PEXt Programmer
From: brzezins@hplred.HP.COM (Dennis Brzezinski)
Date: Wed, 29 Jul 1992 21:25:35 GMT
Subject: Miss Rates using Victim Caches
Organization: Hewlett Packard Labs, Palo Alto CA
Newsgroups: comp.arch

Jouppi from  DEC published a paper in the 1990 Computer Architecture Proceedings
that gave some preliminary data for miss rates of direct mapped caches augmented
with a small fully associative "victim cache."    Has any follow up work been 
done?   Specifically, has anyone gathered  miss statistics for a superscalar 
CPU with two or more memory ports into a direct mapped cache plus a "victim"?

Thanks in advance for any data or pointers to the literature I may have missed.

This is my posting, not my employer's
Dennis Brzezinski
HP Labs, Palo Alto, Ca
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: SuperSPARC doesn't need superscalar compiler?!
Date: 21 Jul 92 13:19:41 GMT
Reply-To: moss@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: lycmit@X1SUN6.CCL.ITRI.ORG.TW's message of 21 Jul 92 01:42:07 GMT

>>>>> On 21 Jul 92 01:42:07 GMT, lycmit@X1SUN6.CCL.ITRI.ORG.TW (Yin-Chih Lin)
>>>>> said:

Yin-Chih> ... one of the Sun Micro employees had adverted that the SuperSPARC
Yin-Chih> (superscalar SPARC which can issue 3 intructions at max performance)
Yin-Chih> does not require the superscalar compiler to obtain the best CPU
Yin-Chih> performance.

It could be that compilation principles followed for other models of SPARC
will indeed yield good results for this implementation, too. For example,
there is the load delay of two cycles, which would cause instruction
schedulers to space loads and succeeding uses at least three instructions
apart, so they would fall into separate windows for issue on the SuperSPARC.
That is, a non-superscalar might require spacing things out in time,
especially for non-fully-pipelined functional units. This spacing will tend to
help on a superscalar with a limited number of functional units. It's a
transformation between time and space, but there are significant similarities.

Of course, you are right that in general a good schedule for a non-superscalar
may not be the best schedule for a superscalar that does not have enough
resources available on each cycle. For example, a non-superscalar might be
able to issue one register to register multiply every cycle, given one fully
pipelined multiplier. A superscalar that issues N instructions per cycle would
need N fully pipeined units to guarantee not to stall, but most code probbaly
does not need N fully pipelined multipliers.

However, the designers of the Motorola 88110 did do some balancing analysis
and decided to replicate some functional units. It's a dual issue machine, and
some kinds of instructions are popular enough that it pays to be able to issue
two in the same cycle, which requires two similar functional units.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Newsgroups: comp.arch
From: noah@cs.washington.edu (Rick Noah Zucker)
Subject: Re: Cached DRAM from Mitsubishi
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Wed, 29 Jul 92 22:42:23 GMT

In article <1992Jul29.214908.7876@trantor.harris-atd.com> dwilliam@jabba.ess.harris.com (David Williams) writes:
>   I was flipping through the May issue of Electronic Design, and an
>ad from Mitsubishi caught my eye.  They have a DRAM chip now available
>with built-in cache.  This looks interesting - a 1M by 4 DRAM with a 
>built-in 4K by 4 SRAM cache.  Apparently, the chip has an internal bus
>that lets the SRAM cache do a line copy to/from the DRAM portion at
>64 bits.  (16 x 4bit internal bus)  Speed is claimed to be 10ns when a
>cache hit occurs, 70ns in case of a miss (actually, a miss causes a 
>280ns DRAM cycle, but the SRAM can start doing stuff again in 70ns while
>the DRAM is busy)

	This is a little unclear, and if you have more detailed
information, please clarify my point.  You say that 70 ns after a cache
miss, the SRAM can start doing stuff, but the DRAM is busy for another
210 ns.  Does this mean that you will get your data in 70 ns, but the
DRAM is busy for another 210 ns because it has to write back the data you
just read out?  Or does it mean that you can initiate another request in
70 ns?  That is, you can make another request to the chip, which will be
satisfied if it is in the cache.

						Rick Noah Zucker
						noah@cs.washington.edu
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: BUSES and other things
Date: 26 Jul 92 01:15:07 GMT
Organization: Auspex Systems, Santa Clara

>>Besides speed, what else do you think is important in a desktop bus?
>
>For the hundreds of thousands of users (this is a conservative estimate
>based on observations at a few universities) who do mathematical typing,
>an extremely important thing to have would be a large variety of characters
>available for simultaneous display on the screen,

Well, the machine on *my* desktop can display quite a variety of
characters...

...because the hardware doesn't know beans about characters; the
software can turn pixels on and off as it chooses.  It's the *software*
that's responsible for having the characters available.

(And if you're going to argue that "bitmapped displays are the wrong
answer", you'll have to explain why your favorite solution is better;
I'm sure not going to simply take your word for it....)

But what does that have to do with a desktop *bus*?  Desktop buses
usually don't *care* about characters; do you have a proposed design for
a desktop bus that does?  Or do you just have a proposed design for a
*display adaptor* that displays a large variety of characters, but that
requires a specialized sort of bus?
From: enbody@ss33.cps.msu.edu (Richard Enbody)
Newsgroups: comp.arch
Subject: Re: Could I compete the low-end CM5 with multiple SPARCstations?
Date: 22 Jul 92 19:12:50 GMT
Organization: Dept. of Computer Science, Michigan State University

In article <9207221613.AA05637@x1sun6.ccl.itri.org.tw>, lycmit@X1SUN6.CCL.ITRI.ORG.TW (Yin-Chih Lin) writes:
|> 
|> I am curious, if I connect 32 SPARCstation 10 model 30 (33MHz, SuperSPARC
|> module with 86.1 MIPS - Sun Micro adverted!?) computers (loosely-coupled
|> MIMD multicomputers?) either by Ethernet, ISDN or FDDI with the multi-
|> thread OS and might use facilities from Linda-like distributed data
|> structures. Is it possible for me to obtain the reasonable performance
|> when compared with the 32-node TMC CM5 (SIMD machine)?

Greatly simplified response:

The difference is communication latency.  For many, but certainly not all,
applications that could kill you.


-rich
enbody@cps.msu.edu
From: narad@nonsequitur.Eng.Sun.COM (Chuck Narad)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 28 Jul 1992 20:05:28 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: narad@nonsequitur.Eng.Sun.COM
NNTP-Posting-Host: nonsequitur


In article 92Jul23183353@pdx007.intel.com, glew@pdx007.intel.com (Andy Glew) writes:
>
>Now, admittedly, in the PC world I have been surprised by how common
>cache coherent I/O is.  How about other worlds?  Which is more common,
>cache coherent or cache incoherent I/O?  I believe John Mashey already
>noted that on the R3000 I/O was non-coherent, but on the R4000 I/O is
>coherent.
>

Sun has had coherent I/O on many systems; this includes the 4/3x0 family, the 4/4x0
family, the SS600MP family, and the SS-10.

chuck/
disclaimer: speaking for myself, not for my employer
From: dbg@slacvm.slac.stanford.edu (David Gustavson)
Newsgroups: comp.arch
Subject: Re: BUSES
Date: 28 Jul 92 02:59:29 GMT
Followup-To: comp.arch
Organization: SLAC

In article <1992Jul27.191347.4485@ksmith.uucp>, keith@ksmith.uucp (Keith
Smith) wrote:
> 
> IMHO the only way to solve this is to have seperate input and output
> "busses" that allow for multiple electrons to be traveling across the
> "wires" at the same time.  Seperate because you can be sending fetch
> requests off of one side while yanking them in on the other.
> 
Well, not electrons exactly, but signals. You're right that buses are 
a bottleneck, because devices have to take turns using them, and the
solution to that requires lots of independent paths (at least two for
each processor) that can signal at the same time if you don't want the
processors to be waiting needlessly for access to the bus.

The latest 'bus' uses that approach, and is called the Scalable Coherent
Interface. It recently became approved as IEEE Std 1596-1992. It will 
first be used in super multicomputers, but soon in some interesting
workstation-class machines too.

SCI uses fast narrow unidirectional differential links that run at
1 GByte/s for short distances (meters), and slower bit-serial fiber 
optic (up to 10km) or coaxial (up to 20m) links at 1 Gbit/s.

SCI also provides a scalable cache-coherence mechanism to support
distributed shared memory systems, and a variety of multiprocessor
supporting features (queue reservations, fair access, forward progress
guarantees).
--------------------------------------------------------------
-- David B. Gustavson, Computation Research Group, SLAC, POB 4349 MS 88,
    Stanford, CA 94309   tel (415)926-2863  fax (415)961-3530
-- What the world needs next is a Scalable Coherent Interface!
-- Any opinions expressed are mine and not necessarily those
   of the Stanford Linear Accelerator Center, the University, or the DOE.
Newsgroups: comp.arch
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: Symmetric MP
Date: Thu, 23 Jul 1992 11:22:20 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <1992Jul18.151923.211432@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:


>pjg@acsu.buffalo.edu (Paul Graham) writes:
>>i'm actually more interested in why it's apparently hard to do right

>It is harder to do than it often looks on paper. This is partly
>because a kernel can have a lot of locks, and a lot of possible
>sequences of events, and the interactions get you. So, complexity,
>and debugging.

>Another major reason SMP takes time to achieve, is that almost
>everyone seems to start from scratch. Back in the PDP-11 days, Unix
>locking consisted of turning off interrupts whenever the kernel was
>entered.

This is not entirely true. Interrupts were (are) still enabled, only
task-switching was (is) disabled. Therefore, critical regions could (can)
only exist when datastructures could (can) be accessed by "normal" kernel
functions and interrupt code. These accesses were (are) protected by
"spl"-calls which raise(d) the interrupt level of the processor thereby
effectively locking out interrupts FROM THIS PARTICULAR INTERRUPT SOURCE
(and all sources that had lower priority).
I've put past and present tenses, because a lot of single-processor UN*X
systems still work this way nowadays.

>	  A perfectly good decision, in its day. However, the legacy
>is that the kernel code became a bit of a trackless wilderness, where
>it wasn't clear what was shared and by whom.  For historical reasons,
>a large number of groups have *indepentantly* MP-ified this
>wilderness. Well, OSF used Encore/Mach ... but who else didn't roll
>their own? It's as bad as this mad desire to define one's own bus,
>but with longer timelines.

It's the old problem of "not invented here" combined with "If You want
my code, You pay for it".
In the early days of UN*X, source code flowed quite freely between
interested parties (modtly universities and other ersearch institutes),
because there was no commercial interest. Nowadays every single idea to
"enhance" UN*X spells "$$$", so everyone wanting to do MP will have to
roll their own dice.

>-- 
>Don		D.C.Lindsay 	Carnegie Mellon Computer Science
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Prime
Keywords: gone
Date: 29 Jul 92 16:51:15 GMT
Article-I.D.: cs.1992Jul29.165115.293842
Organization: School of Computer Science, Carnegie Mellon

In article <1992Jul24.203449.3903@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
>In article <1992Jul21.040216.13502@primerd.prime.com> danw@hobbes.prime.com (Dan Westerberg) writes:
>>I've spent the last
>>3 years designing a new CPU for a proprietary architecture (Prime 50 Series)
>>that was originally a copy of a Honeywell machine from the early '70s.
>And at least three, probably four, possibly five, different instruction
>sets.
>Prime's backwards compatibility is rather impressive...

_Was_ rather impressive. Prime has terminated all manufacturing
operations.

This might be a good moment to ask the Net's Pr1me people for
instructive tales.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: samf@yosemite.dell.com (Sam Fuller)
Newsgroups: comp.arch
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Date: 24 Jul 92 17:22:58 GMT
Organization: Dell Computer Corporation

In article <BrrBvA.E0w@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes:

|> 
|> The fact is, rewriting the code -- in some way, not necessarily involving
|> human effort or maintaining multiple versions -- *makes it run faster*.
|> If it's worth the trouble, you find a way to do it.  If it's worthwhile
|> for bcopy, it's probably worthwhile for (some) other things for at least
|> some customers... if the machine will let you.

In the mainframe world it's easier to build faster machines than to "rewrite the code."
And since most of the code is written in assembly language to begin with, compiler
optimizations are moot.   

-- 
=================================================================
Sam Fuller                                  samf@perform.dell.com
Advanced Systems Development                       (512) 338-8436
Dell Computer Corporation   9505 Arboretum Blvd, Austin, TX 78759
=================================================================
Newsgroups: comp.arch
From: kitchel@moray.dpsi.com (Sidney W. Kitchel)
Subject: Re: What's in a name?
Organization: Data Parallel Systems, Inc
Date: 23 Jul 92 13:52:34 GMT

mkahn@hopi.sedona.intel.com (Mitch Kahn) writes:

>Intel boxes will still be the cheapest MIPs on the planet. 

	WRONGO!!!! As of now, the cheapest MIPS on the planet come
from MasPar Computer Corp. The MasPar MP-1 offers them at $50 / MIPS.
You should ask Intel when you are going to get a 200 MIPS box for
$10,000.
	I do agree with your points about backward compatability. Too
many folks have too much invested in existing code.

							--Sid
--
Sidney W. Kitchel  	    kitchel@cs.indiana.edu, kitchel@dpsi.com
Data Parallel Systems, Inc.  ============||  DPSI  ||===============
4617 E. Morningside Drive	                      (812) 334-8100
Bloomington, Indiana,  47408  USA		FAX:  (812) 334-8121
Newsgroups: comp.arch
From: rootc@ferranti.com (Peter da Silva)
Subject: Re: Graphics Systems
Organization: Xenix Support, FICC
Date: Tue, 28 Jul 1992 13:29:36 GMT

In article <1992Jul27.110218.57519@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
> In article <1992Jul24.164933.11591@hal.com>, lindzey@hal.com (Gardner Lindzey) writes:
> >>Where will it END?
> >>Where WILL it end?

> > CPU->Monitor

> It's been done. Ever here of the Williams Tube?

Atari 2600, Sinclair ZX81.
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
From: kirk@tallis.enet.dec.com (Matthew B. Kirk)
Subject: Re: Translating ML (was Re: MVC and MVCL)
Organization: Digital Equipment Corporation
Date: Mon, 27 Jul 1992 01:07:21 GMT


In article <65D202Zn1bIR01@JUTS.ccc.amdahl.com>, jjs40@cd.amdahl.com (John Sullivan) writes...
> 
>As I understand it, the ability to translate VAX assembly code to Alpha is
>highly dependent on the "good behavior" of the original VAX code, such
>as seperate data/code segments, no self-modifying code, well behaved OS calls,
>etc.  Obviously it's possible to handle these cases, but then your
>compile-time translation degenerates to run-time emulation with a big
>performance hit (and a lot of added complexity.)

Not exactly.  Not having separate data and code segments will not affect
the performance of your translated images provided that you have no self
modifying code.  What you do is to tell the translator that code in 
read/write PSECTs should not be interpreted.

While the translator will complain about a number of poorly behaved types
of code (e.g. unaligned stack, code that doesn't follow the VAX calling
standard, etc), it will still translate them.  

I'm not sure I understand what you mean by "well behaved OS calls".  If
you mean calls to undocumented, unsupported system services, then no, 
the translator doesn't support them.                                
=============================================================================
Matthew Kirk				  	     kirk@tallis.enet.dec.com

All opinions expressed here are mine and do not reflect those of Digital
Equipment Corporation.
=============================================================================
From: zstern@adobe.com (Zalman Stern)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 27 Jul 92 16:58:07 GMT
Organization: Adobe Systems Incorporated

I'll make the following points to support Matt Frank's criticisms of Intel's  
backward compatibility in particular:

1) The 486 still supports an incredibly baroque segmentation scheme that no  
interesting piece of 32 bit software uses. (I.e. Segmentation should have  
been left out of the 32 bit architecture and the gates and other resources  
used to do something productive.)
2) The 286 protection bits in the middle of an address debacle in which the  
Intel architects insisted on sticking with protection model that did not  
(does not, and never will) jibe with software people really write and use.  
(I consider the 286 responsible for most of the pain in IBM PC clone memory  
models.)
3) The performance anomalies in which the previous generation of an Intel  
Arch. run MS-DOS software faster. Especially so when there are much faster  
clockspeed variants to be had. like the AMD 286 and 386 parts vs Intel 386  
and 486. (If your goal is to run old software fast, then you better had do  
that.)

There are examples of better ways to do things as well. On the extreme edge  
there is the HP3000->precision architecture and DEC VAX->Alpha. For a good  
example of thinking ahead in architecture design, look at the R3000->R4000  
32 to 64 bit architecture expansion. (The jury may still be out on this  
though. The architecture could have been reworked for 64 bit mode, perhaps  
profitably.) An interesting thing about the R3000->R4000 is that MIPS II  
binaries (32 bit) will run in MIPS III mode (64 bit) unless they depend on  
previously undefined opcode raising an illegal instruction exception. Is  
this true for any other architecture transitions? (286 code in 386 mode?)

Backward compatibility can be good, but it can also be an excuse to keep on  
doing stupid things "'cause we've always done it that way."
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Newsgroups: comp.arch
From: ed@weir.pa.dec.com (Ed Gould)
Subject: Re: Translating ML (was Re: MVC and MVCL)
Reply-To: ed@pa.dec.com
Organization: DEC Network Systems Lab, Palo Alto
Date: Sun, 26 Jul 92 19:32:48 GMT

>> I don't think this necessarily follows.  For example, one of the compiled
>> languages for Alpha is Macro-32, i.e., VAX Assembly.  It's unusual to think
>> of what started out as an assembly language to be run through a compiler,
>> but there's nothing magic about it.

> As I understand it, the ability to translate VAX assembly code to Alpha is
> highly dependent on the "good behavior" of the original VAX code ...

> Unfortunately for IBM/370 customers, very few of the above properties are
> guaranteed to hold for a given program.  ...

That's true for the binary translator, but I was commenting on a
compiler that's available (or will be available - I have no connection
to any of the product groups) for Alpha.  This compiler reads VAX
assembly as its input, and produces native Alpha as output.  Note, of
course, that this requires the assembly *source*; I don't know if
machine-disassembled code would have enough information.  Also, recall
that the comment I was addressing was that there could be no compiler
optimizations in such a situation.  Further, the VAX doesn't have an EX
instruction.

> John Sullivan, Engineer/Computer Development.   Email: jjs40@cd.amdahl.com.
> Amdahl Corporation, Sunnyvale CA.               Phone: (408)746-4688.

--
Ed Gould	  ed@pa.dec.com		Digital Equipment Corporation
+1 415 688 1309	  Network Systems Lab	505 Hamilton Ave, Palo Alto, CA  94301

"Unison is only one form of harmony." -- LW
From: ahmad@eta.ee.ufl.edu (Ahmad Ansari)
Newsgroups: comp.arch
Subject: MIMD Architecture Simulator
Date: 26 Jul 92 23:23:35 GMT
Organization: EE Dept at UF

I am looking for a public domain simulator for a MIMD
machine which runs on Spark or PC platforms. I would
greatly appreciate any information on this.

thanks
ahmad ansari
Newsgroups: comp.arch