HDTenEightyP/NetNews huggingface dataset:
From: dwm@zelig.osf.org (Dave Mitchell)
Subject: Re: Graphics Systems
Organization: Open Software Foundation
Date: Fri, 31 Jul 1992 12:12:28 GMT

>> rthomson@mesa.dsd.es.com (Rich Thomson) writes:
>> It seems time to remind people about that marvellous paper, ``The
>> Computer Graphics Wheel of Re-incarnation'', that charted the
>> history of people moving graphics in and out and in and out of
>> special purpose h/ware (and it was written sometime around the end
>> of the sixties!).  I *think* Ivan Sutherland was the author, but
>> I wouldn't swear to it (*especially* on the net).

	This paper is recommended reading for anybody with an
	interest in architecture, with or without graphics, since
	the insights are quite applicable to the design of any
	special purpose HW "accelerators".

	T.H.Meyer and I.E.Sutherland,
	"On the Design of Display Processors",
	CACM, Vol.11, No.6, June 1968

	The abstract (typos are mine):
		The flexibility and power needed in the data channel
		for a computer display are considered.  To work
		efficiently, such a channel must have a sufficient
		number of instructions that it is best understood as a
		small processor rather than a powerful channel.  As it
		was found that successive improvements to the display
		processor lie on a circular path, by making
		improvements one can return to the original simple
		design plus one new general purpose computer for each
		trip around.  The degree of physical separation between
		display and parent computer is a key factor in display
		processor design.

	dave
-- 
    Dave Mitchell	dwm@osf.org	uunet!osf!dwm      (617) 621-8963
    Open Software Foundation,  11 Cambridge Center,  Cambridge, MA  02142
From: dre@ember.Eng.Sun.COM (David R. Emberson)
Newsgroups: comp.arch
Subject: Re: Prime
Date: 29 Jul 1992 23:19:33 GMT
Organization: Sun Microsystems Inc., Mountain View, CA, USA
NNTP-Posting-Host: ember
Summary: 50 series
Keywords: gone

In article <1992Jul29.165115.293842@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
> 
> This might be a good moment to ask the Net's Pr1me people for
> instructive tales.

What are you interested in?  I was there from '77 to '80 and worked on the
many of these machines.

			Dave Emberson
			dre@eng.sun.com
From: pettengill@cvg.enet.dec.com ()
Subject: Re: Symmetric MP
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Sat, 25 Jul 92 04:54:06 GMT

SMP is an ideal that isn't practical, so SMP ends up being very complicated.

From the viewpoint of the user, you want to create the illustion of
symmetry, but internally you have to deal with the lack of symmetry in
the hardware, for example, the real simple, low level console, interface
usually has an affinity for a single processor, so you have to be prepared
to switch some threads to a specific CPU in order to access the correct
address space.

And there are times when it makes sense to keep a CPU idle even when there
is a computable process, for example, when a process has been running for
an extended time on a CPU with a large cache.  To switch that process to
another idle CPU would result in both the overhead of both flushing the
old cache and filling a new cache.  Given the almost order of magnitude
difference in speed between cache hierarchies and the size of caches and
the time to fill the caches, it isn't unreasonable to find that delaying
the scheduling of a process by milliseconds will result in faster processing
than scheduling it immediately on another CPU.

mulp
DEC
From: jon@alpha.ee.ufl.edu (Jon Mellott)
Newsgroups: comp.arch
Subject: Re: Cached DRAM from Mitsubishi
Date: 30 Jul 92 00:39:07 GMT
Organization: EE Dept at UF

In article <1992Jul29.224223.22285@beaver.cs.washington.edu>, noah@cs.washington.edu (Rick Noah Zucker) writes:
|> 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.

The vital statistics (for the -10 suffix devices) are:
1) Cache Hit Access/Cycle = 10ns/10ns
2) Cache Miss Access/Cycle = 70ns/280ns *
3) Direct Array Access/Cycle = 70ns/140ns

*: "Cache hit cycles can resume after one miss access time, while the copy-back
    completes in the background."

Other interesting facts: This memory is synchronous (has a clock pin) and 
offers a power down mode via stopping the clock. In power down mode the 
part consumes 1 mW. Also, as you might have guessed, the 100 MHz hit cycle 
time is a wee bit fast for a multiplexed row/column addressing scheme: 
the device is packaged in a 44 pin TSOP type II package (obviously the 
address lines are not multiplexed). The device is also available in a 
reverse pin-out TSOP (to simplify layout of double sided memory 
cards and SIMMs). The device is also available in -15 and -20 suffixes.

Hope this clarifies things.

Jon Mellott
High Speed Digital Architecture Laboratory
University of Florida
(jon@alpha.ee.ufl.edu)
Xref: sparky comp.arch:8455 comp.lang.misc:2709
From: Roberto@sunsci.cern.ch (Roberto Divia CERN-ECP/DS +41 22 767 4994)
Subject: Re: Cache Coherence
Organization: CERN - European Laboratory for Particle Physics
Date: Mon, 27 Jul 1992 06:58:44 GMT

I tried to reply directly but the e-mail bounced back...
> From MAILER-DAEMON@thi.informatik.uni-frankfurt.de Mon Jul 27 08:50:08 1992
> Subject: Returned mail: Service unavailable
> <<< 553 riese.thi.informatik.uni-frankfurt.de host name configuration error
> 554 <feivel@riese.informatik.uni-frankfurt.de>... Service unavailable

Here is my original message in reply to Christine Gross request for
information about caches and methods to get cache coherence.

Christine,
  are you interested in the way SCI (the Scalable Coherent Interface) keeps
cache coherency accross ringlets? Snooping is impossible since there is no
exchange of signals accross separate ringlets. So, it must be done via
messages and directories.

   SCI keeps a distributed coherency directory scheme (opposed to centralised
directories very much used today but very delicate and non scalable) which is
source of many discussions but proposes a very elegant, scalable and robust
solution.
-- 
|   Roberto Divia`      | Love at  first sight  is one of the greatest |
|   =============       | labor-saving devices the world has ever seen |
|  CERN :  European Laboratory for Particle Physics,  1211  Geneva  23 |
|  Switzerland (CH)                                                    |
Newsgroups: comp.arch
From: cmr@world.std.com (Charles M Richmond)
Subject: Re: MIPS assembler/linker/memory allocation
Organization: Integrated International Systems Corp. One Longfellow Place, Suite 3309, Boston, Ma.
Date: Sat, 25 Jul 1992 10:40:11 GMT

yuki@watanabe.cs.unc.edu (Yuki Watanabe) writes:

>Is there any detailed documentation on MIPS/Ultrix memory allocation 
>for C language (and assembly language).   I have MIPS RISC Architecture
>book by Kane and Heinrich.   We are interested (eventually) in loading 
>a.out file produced by C compiler in a low-level simulator. 


There is a lot of info online in the man pages. For example:

From "ld"
     The text and data segments must not overlap and all addresses must be
     less than 0x80000000.  The stack starts below 0x80000000 and grows
     through lower addresses, so leave space for it.

     For ZMAGIC and NMAGIC files, the default text segment address is
     0x00400000 and the default data segment address is 0x10000000.  For
     OMAGIC files, the default text segment address is 0x10000000 with the
     data segment following the text segment.  The default for all types of
     files is that the bss segment follows the data segment.

From "scnhdr"
     struct scnhdr
     {
     char            s_name[8];    /* section name */
     long            s_paddr;      /* physical address, aliased s_nlib */
     long            s_vaddr;      /* virtual address */
     long            s_size;       /* section size */
     long            s_scnptr;     /* file ptr to raw data for section */
     long            s_relptr;     /* file ptr to relocation */
     long            s_lnnoptr;    /* file ptr to gp table */
     unsigned short  s_nreloc;     /* number of relocation entries */
     unsigned short  s_nlnno;      /* number of gp table entries */
     long            s_flags;      /* flags */
     };

From "reloc"
     struct   reloc
     {
        long      r_vaddr ;          /* (virtual) address of reference */
        long      r_symndx ;         /* index into symbol table */
        ushort    r_type ;           /* relocation type */
        unsigned  r_symndx:24,       /* index into symbol table */
                  r_reserved:3,
                  r_type:4,          /* relocation type */
                  r_extern:1;        /* if 1 symndx is an index into the
                                        external symbol table, else symndx
                                        is a section # */
     } ;


I hope that some of this is helpful.

Charlie

-- 
*****************************************************************************
*  Charles Richmond 	Integrated International Systems Corporation        *
*  cmr@world.std.com	(Temporary) crichmond@mr4dec.enet.dec.com           *
*  Specializing in UNIX, X, Image Processing, and Communications.           *
From: pmorris@chessie.East.Sun.COM (Phillip Morris - SE Washington D.C.)
Newsgroups: comp.arch
Subject: Re: Call for Opinion: Viking or i860
Date: 31 Jul 1992 11:57:38 GMT
Organization: Sun Microsystems, Inc.
Distribution: world
Reply-To: pmorris@chessie.East.Sun.COM
NNTP-Posting-Host: chessie.east.sun.com

In article 5678@nosc.NOSC.MIL, wolfgang@sunspot.nosc.mil (Lewis E. Wolfgang) writes:
>Call for opinion:
>
>	We run large acoustic modeling programs on a
>variety of Sun Sparc systems and in the past have
>considered purchasing array processors to hasten things
>along.  It seems as if many array processors are based
>on Intel's i660 chip, certainly a respectable 
>numerical masticator, but how does it stack up against
>current RISC based CPUs?
>
>	We have a Sun 690MP that we could upgrade to
>SuperSparc (Viking) with SuperCache for not much more
>money than an equal number of i860 based processors.  
>It seems as if integer performance is better with Sparc,
>with floating point not quite as good.  An advantage of
>a Sparc upgrade is that old code would not have to be
>modified, at a cost of slightly less relative floating 
>point performance.
>
>	What do you think?  Upgrade the cpu with Viking?
>Or purchase an equal number of i860 based array processors?
>
>				Thanks,
>				Lew Wolfgang
>				wolfgang@nosc.mil
>


Mr. Wolfgang,

After noting that I work for Sun, please also be aware that this is a new position (only been here
3 months) and that my previous jobs were at ATT Bell Labs & BBN, both positions as a near-real-time
programmer on Sun SparcStations.  Most of the stuff we did was digital signal processing which is
quite floating point intensive.  For a long while we used either TI or ATT DSP chips, but when our
computing needs got more general than just the dsp code, we needed a more general floating point
processor.  We tried out both the Sky & Mercury i860 boards (4 processors) and found that the only
way to get anywhere near the stated MFLOPS rating was by hand coding in assembly.  The C 
cross-compilers stank!! Any 1st year CS student could have optimized better for a particular cpu
than those compilers did.

All this is to say this:  Don't pay any attention *AT ALL* to stated performance figures.  Either
get a loaner piece of equipment and try out your code, or package the demanding part of your code
into a easily compilable/runnable package and send it to the various manufacturers to let them
perform benchmarking (and make SURE to get exactly how they compiled and ran it).  Then you have a
basis for fair comparison.

My guess, based upon previous experience, is that unless you plan to hand code assembly for the i860,
then you will get *better* FP performance out of the SuperSparc (Viking) with the new SparcCompiler
that has been optimized for that architecture.


---
------------------------------------------------------------------------------
-Phil Morris, SE w/ Sun Microsystems in Vienna, VA
-pmorris@chessie.East.Sun.COM


Newsgroups: comp.arch
From: rootc@ferranti.com (Peter da Silva)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Keywords: Intel 486 Bus
Organization: Xenix Support, FICC
Date: Tue, 28 Jul 1992 13:33:57 GMT

In article <1992Jul27.163536.20755@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>   If you are not upgrading the system often, a motherboard is a lot
> cheaper and more reliable. With reliability related to number of
> connections, having the CPU plug in on a board adds room for problems,
> take space, adds cost, etc.

Agreed, a single-board-computer is cheaper than a backplane system. But most
PC aren't SBCs... they have serial cards and video cards and disk controller
cards and audio cards and tape controllers and so on.

> Also, a backplane normally has boards at
> right angles to the plane, and that makes the total package larger than
> the tiny "pizza box" configurations.

That's OK. Shoeboxes are a better design anyway. Smaller footprint and just
as cheap.
-- 
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
Newsgroups: comp.arch
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Organization: Nanyang Technological University - Singapore
Date: Sun, 26 Jul 1992 04:39:11 GMT

In article <1992Jul26.032636.244142@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:

: 
: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
: >Which die area are you measuring? Have you taken into account the area taken
: >by the pads? The pads are huge and require large drivers and protection 
: >circuits.
: 
: Since the DEC 21064 Alpha chip only supports 43-bit effective virtual
: addresses, the cost is approximately 43-32=11 pins.
How about the 64 pin program and 64 pin data?

: 
: Since the package has 431 pins, I don't think that 11 pins was some
: sort of horrendous burden that changed everything.
If it needs only 11 pins, why do you need 431 pins? Why not just 132+11?
80386 uses 132 pins.

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet
From: esl_manager@gimme.uh.edu
Newsgroups: comp.arch
Subject: Re: Cache Coherence
Date: 29 Jul 92 19:55:19 GMT
Reply-To: esl_manager@gimme.uh.edu ()
Organization: University of Houston

Hi Christine,

	It seems like I am having the same problem sending you e-mails also
because of the MAIL-daemon error at your site.

	Anyway, if it's not too inconvenient, I was wondering if you can mail
me a copy of what you've received so far regarding cache coherence? I'm
not in architecture research but I am interested in porting the
techniques to my area.

---
Arthur Yeo
Dept. of Computer Science
University of Houston-University Park
From: peter@ferranti.com (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project, & backwards compat
Date: 30 Jul 92 14:04:36 GMT
Organization: Xenix Support, FICC

In article <154raeINNcsu@darkstar.UCSC.EDU> haynes@cats.ucsc.edu (Jim Haynes) writes:
> Whether we re-implemented a historic machine in new hardware or ran
> an emulator on a modern machine, there are very few people who would
> want to run old software.

Waxing analogical... who would want to drive a 1920-era car?
-- 
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
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: BUSES
Organization: Xenix Support, FICC
Date: Mon, 27 Jul 1992 13:24:23 GMT

In article <54988@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> If you do not notice the difference in getting your file in .5 sec, you have
> an unusually slow reaction time.  With a useful window system, this is a
> real major nuisance.

Unfortunately, peope have gotten used to bad window systems so waiting a couple
of seconds for a program to wake up seems normal.
-- 
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
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: VAX MIPS (was Re: Proposal: Computer History Project)
Organization: Digital Equipment Corporation
Date: 28 JUL 92 09:48:47    


>In article <1992Jul25.214508.4312@fasttech.uucp> zeke@fasttech.uucp (Bohdan Tashchuk) writes:
>>Aren't SPECmarks computed relative to a VAX 780? Is there still one of these
>>machines somewhere that gets powered up every year or so to run a new set of
>>tests?
> 
My group provided the VAX-11/780 reference numbers to SPEC in 1989. The 
reference numbers do not change as new VAX compilers are introduced. If we
tested the VAX-11/780 today, it could rate around 1.3 SPECmarks. The "reference"
VAX-11/780 is actively used inside Digital to generate VUPs (VAX Units of 
Performance) for newer VAX systems; the latest compilers are used on both new 
and old machines. The machine is located in Boxboro, Mass.

Dileep
Newsgroups: comp.arch
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Subject: Re: Productivity != SPECmarks, crap-compatibility - what for? (was: Re: What's in a name?)
Reply-To: vhs@darkcube.radig.de
Date: Mon, 27 Jul 92 14:33:31 GMT

In article <1992Jul23.185429.24491@crd.ge.com> davidsen@ariel.crd.GE.COM  
(william E Davidsen) writes:
> In article <1992Jul22.163506.306@darkcube.radig.de>, vhs@darkcube.radig.de  
(Volker Herminghaus-Shirai) writes:
> 
> | People also trust (or fear) big vendors. Big vendors tell people to buy  
> | compatible hard/software so these vondors can keep their market share.
> | Because people are too lazy to think for themselves, they believe and buy.
> | That's what I said. That's what I meant. 
> 
>   People buy machines to run software, and in business cases that's
> about the only reason. If the software runs on a MIPS you buys MIPS, if
> you need a Mac you buy it. If you can get the same package for MS-DOS
> for $500 and HP700 for $5000 you buy MS-DOS. The cost of the hardware is
> swamped by the cost of the software. And changing architectures vs.
> faster versions of what you have adds the cost of new software and
> training to the initial cost of the machine.

As I pointed out before, I'm not generally against compatibility. Not at
all. This would be even more silly than this thread has become ;-)
However notify thee how some vendors offer systems that are compatible
*enough* with their other systems so customers can migrate with relative ease.
Notify too, how the performance of their OSes and application software
scales with their hardware. Now look at the x86 world (the only one except
maybe the slash-370-world I was referring to). Note how a whole industry
evolves around (now what are they called, lemme see:) UMB, HMA, EMS, XMS,
EMM, LIM and whatnot. Note how customers have to spend $$ as an entry
price and $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ for their quarterly upgrades
because A won't work with B won't work with C won't work with D won't...
Note how Bill Gates uses his money (instead of technical excellence) to make
people buy his crap. If businesses have to decide on a pure quarterly-revenue
basis I can't help it. If they are too shortsighted because their stockholders
start crying whenever they think long-term and invest, I can't help it either.

I *thought* I could change the world :-(

--
Volker Herminghaus-Shirai (vhs@darkcube.radig.de)

.signature omitted since too many people didn't get the joke
Newsgroups: comp.arch
From: thall@Ingres.COM (Trevor Hall)
Subject: More P5 Speculation...
Reply-To: thall@Ingres.COM (Trevor Hall)
Organization: Ingres, an ASK Company, Alameda CA 94501
Distribution: usa
Date: 23 Jul 92 17:37:24 GMT

According to today's San Jose Mercury News it looks like we're going to 
get another quarter's worth of speculation on the P5 (where do you get
your information, John Mashey?).  So I thought I'd start another round by 
referring everyone to the cover of the July 6 issue of EE Times.

On the cover there's a block diagram of the P5.  It has the expected
units: I and D caches, bus, FP and SScalar RISC CPU.  But there's one
I don't quite follow: Intel386 unit.  Does this mean that the P5 will
be running some kind of emulation of x86 instructions?  Is there a
"native" RISC instruction set that differs from the x86 instruction
set?

p.s. I'm a DBMS engineer. I'm so far removed from our h/w engineers, I 
     can't even spell ASIC...
--
 +-----+ Trevor Hall                     
 |    #| Database Engineer               "My dogma's better than your
 |     | Sequent Computer Systems, Inc.   dogma, my dogma's better
 +-----+ thall@sequent.com                than yours."
Newsgroups: comp.arch
Subject: Re: Graphics Systems
From: albaugh@dms.agames.com (Mike Albaugh)
Date: 29 Jul 92 00:02:28 GMT
Organization: Atari Games Inc., Milpitas, CA

From article <1992Jul27.110218.57519@cc.usu.edu>, by ivie@cc.usu.edu (CP/M lives!):
> 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?

	Nah, they cheated (on the 701) and had a screen's worth of memory.
Now, the Atari 2600 (aka Stella, aka TIA) came pretty close:

 CPU->Shift Register->Monitor

	The shift register was actually a few of them, but none were anything
like a whole line of pixels long. Programming that beast gave one a real
feel for "critical timing"... the sort of feel that makes one chuckle at
comp.arch postings that talk about "real time" in terms of sub _milli_second
interrupt latencies :-)

					Mike

| Mike Albaugh (albaugh@agames.com || netcom.com!agames.com!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035		voice: (408)434-1709
| The opinions expressed are my own (Boy, are they ever)
Newsgroups: comp.arch