HDTenEightyP/NetNews huggingface dataset:
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: BUSES
Date: Thu, 23 Jul 1992 18:00:16 GMT
Organization: U of Toronto Zoology

In article <1992Jul23.092211.18462@nuscc.nus.sg> eletanjm@nuscc.nus.sg (TAN JIN MENG) writes:
>It seems to me that many if not most applications do not need (relatively 
>speaking) such a high bandwidth...
>Software controls the rate at which you exercise the bus at these high speeds.

True.  However, you assume that software efficiency is remaining constant.
It's not; it's declining.  Even without considering the rising expectations
of the customers, software bloat is more than keeping pace with the hardware.
Running X at useful speed takes far more horsepower than, say, the old Blit
window system (typically much snappier than X despite running on a 68000).
If you're one of the poor people doomed by bureaucratic fascism to run the
OSI networking protocols, you need far more horsepower than the TCP/IP crowd
to get the same performance.  And so on.

>Also, if I get my file within 0.5 sec as opposed to 1.0 sec, will I
>notice enough to pay for the hardware? 

If you get a hundred files in 50 seconds as opposed to 100, you will notice.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Newsgroups: comp.arch
Subject: Re: Cached DRAM from Mitsubishi
Date: 30 Jul 92 14:28:57 GMT
Organization: Nanyang Technological University - Singapore

In article <1992Jul30.003907.10654@eng.ufl.edu> jon@alpha.ee.ufl.edu (Jon Mellott) writes:

: 
: The vital statistics (for the -10 suffix devices) are:
: 1) Cache Hit Access/Cycle = 10ns/10ns

At this speed, we start questioning the need for internal caches in Alpha and
P5. Even with 128 pins for Alpha, it cannot beat the 16 data width for 
each output bit of the DRAM cache. This is just the beginning.
	The question is, what sort of technology is used to bring static and
DRAM technology together? Will it ever be cheaply mass produced?
	Instead of 4 bit wide data per chip, when will they put 16-bit wide
packages on the standard(JEDEC?) 40-pin packages.

I wish that someone more knowledgeable could contribute.

: 2) Cache Miss Access/Cycle = 70ns/280ns *

After 16 write cycles of  10nS each, it must be followed by a 70nS cycle. 
However if there is a backward jump to the previous bank, the cycle time
would be 280nS. I am cloudy here.
	I thought that caches are good only for random access. Here is an
example of cache optimised for sequential access. I agree that sequential
access is the most common for microprocessor.
: 3) Direct Array Access/Cycle = 70ns/140ns
This mode is only necessary for completely random accesses.

The above are just my guesses. Anyone can comment on that?

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Date: 24 Jul 1992 23:04:22 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>    Maybe true. But for a user, should he buy one $2000 21064 chip or another
>    two $1000 CY7C601!?
>
>This is a rather bogus discussion.
....

Yes:
1) For many applications, one will happily leave them as 32-bit applications,
because they'll probably run faster in 32-bit model, so why mess with
them?

2) A few applications exist where pushing 64-bit integers around
conveniently might have good gains, either due to 64x64->128
multiplies, or just puhsing data 2X faster conveniently.

3) The main reason is to get more address sapce (conveniently).
There are not a *huge* number of these things; however, the ones that
are there are *extremely* important to the people who use them, as they
are things like:
	1) Scientific codes
		"Goody; we expand our FORTRAN arrays by factor of 10"
	2) Some ECAD programs
		"Goody, we can still simulate the R11000 after all"
	3) Some MCAD programs
		"Great, we can simulate the 199x automobile in one piece."
	4) Video& animation
		"Great, let's get put Terminator 6 in memory for editing"
	5) Financial
		"Good, we can finally put the financial model of the US
		in memory and grep around in it at speed."
	6) DBMS
		"Good, we can map 4 whole 1GB SCSI disks into memory at once",
		i.e., disks that fit in a desktop box.
	7) CASE
		"Thank goodness, there's still space for the new EMACS" :-)

o
>    Some of the applications I will want to use in a few years
>    will undoubtedly run faster (or, more likely, be easier to code)
>    because of 64 bits -- like the oft-awaited global flat namespace.
>    But I won't hold my breath (at least not until ISDN).

Each to their own; fortunately for us, plenty of people want this
in 1993.  I'd guess the "just recompile this FORTRAN program bigger"
cases will get there quickest.

As I've noted several times before, having 64-bit integers cost
something like 5% of the die space, so it's not a big deal.
Certainly, a 64-bit chip doesn't automatically (or even usually)
go 2X faster than a 32-bit chip.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
DDD:  	408-524-7015,  or 524-8253
USPS:	(soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
Newsgroups: comp.arch
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: Fri, 24 Jul 1992 12:53:42 GMT
Organization: The Portland Group, Portland, OR

In article <2373@nic.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
>Among current microprocessors I don't know of any that are able to
>issue multiple data fetches.

The i860 can issue 3, that is, the bus can handle 3 pipelined accesses.
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Organization: Xenix Support, FICC
Date: Mon, 27 Jul 1992 13:19:23 GMT

In article <TOMW.92Jul25174038@orac.esd.sgi.com> tomw@esd.sgi.com writes:
> In article <id.TJRR.XR8@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> > Why is it that backplanes aren't more common on the desktop?

> I think the important word here isn't "better", it's "cheaper."  With
> motherboard, it's easier to put your system in a smaller box, use less
> board space, and fewer connectors.  All that adds up to lower production
> costs.

This is true for systems that are essentially single-board-computers with
expansion slots, like the Amiga 3000 or the typical Mac. In the PC world,
though, you almost always have at least one or two cards in every system
shipped: so you're using as much board space and as many connectors as a
backplane design... plus making upgrades harder and more expensive.

Yes, I know that there are exceptions (Compaq Deskpro 386/{16,20,...}e, for
example), but the vast majority don't have built in disk and video.
-- 
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: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Date: Tue, 21 Jul 1992 21:04:21 GMT
Organization: U of Toronto Zoology

In article <1992Jul19.212901.8857@bcars64a.bnr.ca> schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
>>Of course, a RISC bigot like me :-) would say that this means your machine
>>is unbalanced:  the hardware has useful capabilities that the software is
>>unable to exploit in a general-purpose way.  A straight byte-for-byte copy
>>is not the only thing one might want to do at top speed...
>
>Ah, I see you belong to the rewrite-code-for-each-new-machine school
>of programming. Otherwise, how do you write optimal loops that depend
>on the cache line transfer size?

One obvious possibility is to generate them automatically, perhaps even
on the fly, perhaps just in a shared library.

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.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
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: Sat, 25 Jul 1992 15:15:37 GMT

In article <1387@sousa.ltn.dec.com> supnik@human.enet.dec.com (Bob Supnik) writes:

: 
: In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
: > 
: >    Maybe true. But for a user, should he buy one $2000 21064 chip or another
: >    two $1000 CY7C601!?
: As I pointed out originally, from measuring both the R4000 and the Alpha chip
: die, the 64-bit (vs 32-bit) integer/addressing data paths adds 10% (or less)
: to die area.  This will NOT drive a 2X difference in costs; more like 1.2X.
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.
	The packaging also increases. You need 471 pins for Alpha. 64-bit
alpha requires similar number(can't remember).

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet
From: vhs@darkcube.radig.de (Volker Herminghaus-Shirai)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 27 Jul 92 14:58:08 GMT
Reply-To: vhs@darkcube.radig.de

In article <1992Jul24.010954.265191@cs.cmu.edu> spot@CS.CMU.EDU (Scott Draves)  
writes:
> >>>>> On 23 Jul 92 15:55:13 GMT, doconnor@sedona.intel.com (Dennis O'Connor)  
said:
> 
> Dennis> Perhaps Volker Herminghaus-Shirai is smarter than all those
> Dennis> customers : maybe his freely-given opinion is somehow more
> Dennis> important than the "voting with their wallets" millions of PC
> Dennis> buyers have done.  But it's not important to Intel's bottom
> Dennis> line.
> 
> he probably is.  :)/2
> 
> in any caes, he has the source code to the programs he depends on;
> compatibility is only a compile away.  selling binaries is the
> problem.

To Scott Draves and Dennis O'Connor:
Read my posts. Thoroughly. Think. Think again. Then answer.

Thank you.

--
Volker Herminghaus-Shirai (vhs@darkcube.radig.de)
Newsgroups: comp.arch
From: leonard@ricks.enet.dec.com ()
Subject: Re: Translating ML (was Re: MVC and MVCL)
Reply-To: leonard@ricks.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Mon, 27 Jul 1992 17:02:28 GMT


As I remember, EX on the IBM S/370 is normally used to supply variable arguments
for some instructions.  A machine-language compiler should replace the EX not
with a direct emulation of EX, but with a check that the executed instruction was the expected one (move string, for example), and code that either
simulated the effects directly (doing a variable-length move) or calling the
run-time simulator (for the unusual case where the instruction has actually been
modified).

It may be that self-modifying code is actually a problem for compilers of /370
machine language, but the existence and frequent use of EX is not sufficient
evidence.

Tim Leonard

I don't speak for Digital.
In fact, Digital pays to have my proofs machine-checked.
From: jhauser@pine.CS.Berkeley.EDU (John Hauser)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 31 Jul 1992 20:03:46 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: pine.cs.berkeley.edu

In article <1992Jul28.220306.12549@mprgate.mpr.ca> mcvey@mpr.ca (Iain McVey) writes:
>But if you have a decent turntable and haven't used it in a while, dig
>it out and play some of your records.  You will be surprised at how good
>they do sound.  There is a warmth that comes from vinyl that is very
>difficult to produce from a CD player.

Of the CD's I have bought that are ``reprints'' of pre-CD albums, many are
poorly re-mastered.  I've found this effect to be far more noticeable than
any distortion introduced by the medium.  Not to say that there aren't other
bugs in the system as well.

Yes, I know:  wrong newsgroup.

----------------------------------------------------------------------------
``Why, yes; I *do* speak for the entire University of California system.''
John Hauser---jhauser@cs.berkeley.edu---Boy of DESTINY o o o o o o o o o o o
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Date: 29 Jul 92 05:59:05 GMT
Organization: Auspex Systems, Santa Clara

>  > Unless, for example, your shared libraries are built in
>  > position-independent form; SunOS 4.x/SVR4 shared libraries don't require
>  > system-wide unique virtual addresses, for example.
>
>How does SunOS handle references between different shared libraries?
>Vector tables in memory local to the process?

Yup.  Calls made by a shareable object to other routines (even to
routines that are static to a module, at least with the SunOS bundled
compiler; hopefully, other compilers are smarter about that) go through
the Procedure Linkage Table, which is a process-local jump table.

>  > Shared memories don't necessarily require them, either.
>
>Of course systems can be designed to go without having the same virtual
>memory address for shared memory (maybe Unixes are designed that way),

The UNIX systems I know of *allow* you to ask that shared memory
(whether it's SV shared memory or "mmap"ped shared memory) be put at a
specific virtual address, assuming you know what address to give it
(said address, of course, must be unused by the process running your
program).  They also allow you to ask the system to choose an address.

>  > Umm, the machine running on my desk has a 32-bit virtual address space,
>  > and the OS on that machine supports memory-mapped files.
>
>  > I would not be surprised if a movable mapping window like that weren't a
>  > pain, though.

My phrasing was a bit more ornate than it should have been, and I ended
up saying the opposite of what I wanted to say, namely that I wouldn't
be surprised if having to use a movable mapping window *WAS* a pain -
i.e., I suspect it *is* a pain.

In any case:

>Easier as moving to 64-bit addresses (well, 43 ot 55 bits or whatever
>is implemented in the first chips)?

I suspect "easier as" may be a transliterated German usage, with which
I'm unfortunately unfamiliar; do you mean that the using such a window
is easier than (to use a English - or, at least, US English - phrasing)
moving to 64-bit addresses, or that moving to 64-bit chips is easier
than using a movable mapping window, or that mapping large files will
get easier as we move to 64-bit addresses?
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project
Date: 24 Jul 92 16:41:53 GMT

From article <1992Jul24.144643.19792@crl.dec.com>,
by stewart@crl.dec.com (Larry Stewart):

> THE COMPUTER HISTORY PROJECT

In the last few days, I have been thinking along exactly these lines.  I
am trying to preserve a pair of PDP-8 systems "in the living silicon",
but I've also been thinking about writing emulators.  My idea is to have
the emulator present itself to the user through X-windows, for example,
with a window that represents the front panel (complete with lights,
switches, and the original manufacturer's distinctive graphic designs),
and a second window representing the console teletype (or flexowriter,
if you go back far enough on some machines).  You'd click the mouse
on the switches to toggle them, click on push buttons to depress them,
and you could watch the lights blink (although in run state, most
emulators would probably only show you the states of all the registers
every few hundered instructions, since even X on modern RISC isn't fast
enough to blink emulated LEDs at 0.5 MHz.

A third window could be used for an operator interface to the various
mountable drives on the machine.  You could use this window to mount
tapes, load card decks in the reader, and tote disk packs from drive
to storage.  Of course, each card deck, paper tape, or disk would be
represented by a file on the host system.

I would want the basic framework of the user interface to remain the
same, whether it is for an IBM 701 or an DEC PDP-12, but of course, size
of the front panel will vary and unless you've got a monitor bigger than
my IBM Megapel display, the front panel will be reduced in size, and
files representing magtapes written PDP-12 Linktape format shouldn't
be readable if mounted on an IBM 701 7 track tape drive.

So, yes, I'm very enthusiastic about the idea!

I've also been thinking that the time has come for university CS
departments to start offering technical courses on the history of
computing.  The courses should be technical in the sense that they
require an introductory assembly language and computer architecture
course as a prerequisite (CS3 or something like that), and they should
look at the history in terms of a series of detailed examples of machines
from the past, complete with programming assignments.  Emulators such as
I've described would be essential to such a course.

				Doug Jones
				jones@cs.uiowa.edu
From: mkahn@hopi.sedona.intel.com (Mitch Kahn)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 22 Jul 92 16:25:27 GMT
	<1992Jul17.220112.20995@microsoft.com>
	<1992Jul20.092822.7666@spool.cs.wisc.edu>
Organization: /eng/eng3/mkahn/.organization
In-reply-to: mfrank@wilma.cs.wisc.edu's message of 20 Jul 92 09:28:22 GMT

mfrank@wilma.cs.wisc.edu (Matt Frank) writes:


] >>>There'll be a 686 all right.  It may look like the x86 architecture from the
] >>>outside, but on the inside ...
] [Lot's of stuff about whether the P5 is going to be performance competitive
] with RISC chips and whether PC-compatible owners are idiots or just ignorant]
]
] Backwards compatability has always been a particular pet peeve of mine, so I
] feel the need to add my two cents worth.  I have two specific problems.
]
] 1)  Backwards compatability is a waste of everyones time.

Better tell that to DEC, IBM, MIPs, Motorola etc. as well as all the users
in the world who do not want to buy new software every time they get a
faster box. What color is the sky in your world?

]
] 2) Nobody ever uses the backwards compatable features anyway.

You're right. I'm getting a new workstation this week and to celebrate
I'm going out and buyin $10K worth of new (incompatible) software just
because some technogeek decided incompatibility wasn't an issue. NOT

]
]   Intel has done very well for itself making better/faster 8086's for the past
] 10+ years because they had a monopoly on chip designs that run MS-DOS.  If
] Win/NT is successful they will need to compete against many other chip makers.
] If Intel designs an 80686 some day, Microsoft may port Win/NT to t

Intel boxes will still be the cheapest MIPs on the planet. Who cares if
a Crimson (or a Chartreuse) can run Windows. I'll get my P5 box for
$5k which is about $10K cheaper than anyone else.
--
|  Mitch Kahn              | "I hope you know that this will go down on |
|  mkahn@sedona.intel.com  |  your permanent record..."                 |
*************************MY OWN OPINIONS*********************************
From: jcallen@marley.think.com (Jerry Callen)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 24 Jul 92 13:21:52
Organization: Thinking Machines Corporation, Cambridge MA, USA
	<GLEW.92Jul12214745@pdx117.intel.com> <BrE09F.4JK@metaflow.com>
	<1992Jul15.163217.434@urbana.mcd.mot.com> <BrM813.Du5@zoo.toronto.edu>
	<GLEW.92Jul23184629@pdx007.intel.com>
NNTP-Posting-Host: marley.think.com
In-reply-to: glew@pdx007.intel.com's message of Fri, 24 Jul 1992 02:46:29 GMT

In article <GLEW.92Jul23184629@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:

   By the way: creating virtual address aliases with different cache
   properties is a recipe for a complicated, expensive, and lower
   performance than it should be multilevel cache system.

How so? Since the R4000 uses a completely separate bus for the
secondary cache, I don't see the complication. Uncached access
go straight to the main memory bus; otherwise the usual cache
lookup takes place. What am I missing?

-- Jerry Callen
   jcallen@world.std.com           (preferred)
   jcallen@think.com               (OK, too)
   {uunet,harvard}!think!jcallen   (if you must)

--
-- Jerry Callen
   jcallen@world.std.com           (preferred)
   jcallen@think.com               (OK, too)
   {uunet,harvard}!think!jcallen   (if you must)
From: pgraff@next.com (Peter Graffagnino)
Newsgroups: comp.arch
Subject: Re: Graphics Systems
Date: 22 Jul 92 21:43:13 GMT

In article <1992Jul16.205220.610@darkcube.radig.de> vhs@darkcube.radig.de  
(Volker Herminghaus-Shirai) writes:
> In article <GLEW.92Jul14233412@pdx007.intel.com> glew@pdx007.intel.com  
(Andy  
> Glew) writes:
...
> > NeXT	No coprocessor
> >     	...
> 
> This is not quite right. As far as I know, NeXT has a custom chip doing  
raster
> copies to/in the video ram. This is not exactly block-move, but more like  
BLT.
> It's not what you would call a graphics system, but since the original  
thread
> was about block-move I thought I'd throw my $0.02 in.
> 
> P.S, Andy, my .sig is not meant personally!
> --
> Volker Herminghaus-Shirai (vhs@darkcube.radig.de)
> 
> If I had intel inside(tm), I'd throw up...

Actually, we have no such coprocessor, all compositing (blitting) is done  
with the host CPU.  Our model is to have a high-bandwidth memory subsystem  
where VRAM and DRAM are peers with the same performance characteristics.   
Since NeXTSTEP tends to draw in window backing stores (DRAM) just as  
frequently (if not more) than VRAM, its hard to see how a graphics  
accelerator can help (unless it has its own DRAM/VRAM virtual memory  
subsystem with a CPU/MMU (ala NeXTdimension)).  With this CPU-centric  
graphics architecture, your graphics performance rides the same (steep)  
curve as your general CPU performance -- customers like it when  
*everything* gets faster when they upgrade to a faster CPU.


Peter Graffagnino
Graphics Software
NeXT Computer, Inc.
Newsgroups: comp.arch