HDTenEightyP/NetNews huggingface dataset:
From: ewing-martin@CS.YALE.EDU (Martin Ewing)
Subject: Re: Re : Single Transistor Clock - ALPHA
Reply-To: ewing-martin@yale.edu
Organization: Yale Univ. Science & Engineering Comp. Facility
Date: Tue, 8 Sep 1992 20:14:15 GMT


In article <1992Sep8.091816.22659@rkna50.riken.go.jp>, wong@rkna50.riken.go.jp (Wong Weng Fai) writes:
...
|> 
|> 	1. I guess whether its a single transistor or not depends on how you
|> count. But is this huge "thang" responsible for the infamous "oven-toaster"
|> effect of the 21064 ? Will pumping the clock speed higher melt the chip ;-) ?
|> 

In CMOS and other high-impedance technologies, the transistors are driving
mainly capacitive loads.  Each change of state requires Q=1/2 CV**2
increment of energy, and the current and power drain scale pretty much
linearly with clock rate.   (Conversely the drain goes nearly to zero at
low clock rate.)

The melting point of Si is pretty high, but the thought of a CPU glowing
cherry-red appeals to me.  (The days of 304 TLs and other big glass RF power
tubes are gone forever. :-)

Martin Ewing
AA6E
From: wong@rkna50.riken.go.jp (Wong Weng Fai)
Newsgroups: comp.arch
Subject: Re : Single Transistor Clock - ALPHA
Date: 8 Sep 92 09:18:16 GMT
Organization: Institute of Physical & Chemical Research (RIKEN) Saitama,Japan

Hi,

	Thanks to all those who responded to my question about the clocking of
the DEC 21064 either by posting or email. As I am an amateur in devices, I'm
still puzzled by some things. Here goes ...

	1. I guess whether its a single transistor or not depends on how you
count. But is this huge "thang" responsible for the infamous "oven-toaster"
effect of the 21064 ? Will pumping the clock speed higher melt the chip ;-) ?

	2. I don't know much of solid state physics but if you have such a
big gate width, how can one ensure that the conduction band under the gate
goes uniformly "on" or "off" ? Wouldn't that give a skew problem ? Ahh ...
silly question ... since the damn thing works, I guess not but I still don't
get it ...

	3. Some folks mentioned the possible use of PLL (Phase Lock Loops). I
can appreciate that being used in a large system to, say, synchronize the
clocks on different boards, but on a single chip ? Would that require both
local clock generators as well as the phase lock circuitry ? Isn't that going
to be expensive (in silicon area) ? 

	4. Related to (3), if one wants to put PLLs on the chip, how does
one put them ? In the four corners ? At uniform intervals ? 

Please adjust your answers to the "for dummies" level ;-) Thank You. Also, I
would appreciate someone giving me the full quote of the ISSCC paper on the
Alpha's clock (and other related stuff). I don't have the proceedings
available and I need to fill out an order form for them |-(

	Thanks again !

Regards,

W.F. Wong.
Newsgroups: comp.arch
From: phil@news.ccutah.edu (Phillip Neiswanger)
Subject: No Branch Delay Slot(s)...
Organization: University of Utah Computer Center
Date: Wed, 9 Sep 92 04:42:31 GMT

Hi,

Before I state my question I would like to appologize to all who have been
bothered by my rather inane posts in the past.  They will remain just that;
posts of the past.

In the august issue of Byte there is a rather lightweight article on DEC's
Alpha architecture and its current incarnate the 21064.  In the article it
states that DEC deemed the branch delay slot to be of little value in
future multiple(read >2) instruction issue implementations of the Alpha
architecture.  If I remember correctly, the article states that the use of
delayed branch slots could introduce incompatibilities from implementation
to implementation.  This does not seem very intuitive to me.  Would anybody
care to discuss how branch delay slots are going to affect future generation
of RISC cpus as they enter the era of multiple(read >2) instruction issue
implementations.
 
There.  I hope that was a much more interesting question. :)

				Phil
				email:	phil@csulx.weber.edu
					phil@icarus.weber.edu
Newsgroups: comp.arch,comp.parallel
From: greg@dworkin.wustl.edu (Gregory D. Peterson)
Subject: INFO Request: Delta/Paragon performance
Followup-To: comp.arch
Summary: Please email info concerning performance
Keywords: Paragon, Delta, performance
Organization: Washington University,  St Louis MO
Date: 4 Sep 92 19:46:57 GMT


Hi there!  I have been trying to get information on the
Delta and Paragon, but have not been terribly successful yet.
I need to know the data rate for communications, latency,
clock rate, performance measures (Mips, etc.) and other
relevant info.  Of particular interest is the ratio of
the compute speed to communications speed.  Thanks in advance
for the help - I'll summarize the results as appropriate.

greg


--
Greg Peterson
Computer and Communications Research Center   
Campus Box 1115, Washington University                                 
1 Brookings Drive  Box 1115

Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Xenix Support, FICC
Date: Sat, 12 Sep 1992 17:06:12 GMT

In article <BuFK3y.3H5@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> This programming requires more than a knowledge of HLLs.

ALL programming requires more than a knowledge of HLLs. That's a tautology as
profound as "writing a novel requires more than a knowledge of English". It
doesn't mean that you can get by without a knowledge of English, but you won't
be helped by a knowledge of Latin or Esperanto.
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.arch
Subject: Re: Computer architects forced to change careers. NOT!
Date: 11 Sep 92 14:31:34 GMT
Organization: IDA Center for Communications Research, Princeton

John Ahlstrom <John@boole.uucp> writes:
> Seymour Cray has gone into great detail about the new (cooling)
> technology that was required to be "invented on the spot by the
> construction engineers" for the Cray 1.  He was not forced to change
> careers.

Isn't it the case that he was forced to start and run a new company in
order to build it, because CDC didn't have the sense to do so?  Sounds
like a pretty substantial career change to me.

                                        David desJardins
From: dafuller@sequent.com (David Fuller)
Newsgroups: comp.arch
Subject: Re: Fault Tolerant-High Availability comp systems
Keywords: Fault Tolerant-High Availability
Date: 16 Sep 92 01:43:25 GMT
Organization: Sequent Computer Systems Inc.

In article <7211@bigbird.hri.com.hri.com> fleurant@sparc15.hri.com (P.Fleurant) writes:
>I'm doing a survey on this thing they call Fault Tolerant Computer systems. 
>As far as I know there are only a few companies that market such a system.
>
>   Tandem			   Cupertino, CA   (408) 725-6000	
>   Stratus			   Marlboro, MA	   (508) 460-2000	
>   Sequoia			   Marlboro, MA	   (508) 480-0800	
>   Integrated Micro Products       Los Gatos, CA   (408) 399-5088	
>   Fail-Safe Technology	           Los Angeles, CA  not listed (?)
>
>
>Can someone point me to the following on the subject of Fault Tolerant
>Computer systems?
>   1) a good bibliography 
>   2) the best newsgroup 
>   3) a best trade journal
>   4) a FAQ type article 
>   5) list of companies
>   
>
>Is Fault Tolerant just some marketing hype used to sell expensive low
>performance yet highly
>redundant computer?

Huh?  Ask the New York Stock Exchange that question, or the many other
happy Tandem users.  If you NEED fault tolerance, you know it.  It's a
requirement that sticks out as primary in certain applications and no
fancy juggering of non-FT computers will work your way out of it.
-- 
Dave Fuller		 	All opinions expressed are my own and not
Sequent Computer Systems	those of Sequent Computer Systems, Inc.
dafuller@sequent.com
Newsgroups: comp.arch
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: trapping speculative ops (LONG)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Thu, 10 Sep 1992 08:04:46 GMT

In article <1992Sep9.121701.13208@odin.diku.dk>, thorinn@diku.dk (Lars Henrik Mathiesen) writes:
|> One would hope so. As a reality check, I looked at the 21064 data
|> sheet (it was handy). As far as I can see, destination conflicts do
|> stall the pipeline on that chip. Of course, currently, compilers have
|> no reason to write the same register twice without intervening reads,
|> so chip designers have no reason to build a preemption mechanism.

This is true in straight-line code, but generally a write to a
register is only redundant if *all* possible execution paths that
execute it write to the register another time before reading it.

|> I agree with the point raised by Anton Ertl, that trap bits on source
|> operands should not unconditionally cause a trap, but should propagate
|> to the result instead, because this allows the compiler to move a
|> greater part of an expression.

This is an interesting idea, but how do we know which instruction
caused the exception? Our solution is somewhat different. We check the
trap bit of the original trap-noting instruction. This means of course
that the compiler has to keep the trap bit alive, which restricts
register allocation, if the trap bit is associated with the
destination register. We did not discuss subroutines and interrupts,
but most solutions discussed here would be applicable.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Xref: sparky comp.arch:9278 comp.lang.misc:2966
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Not using integers
Organization: Metaflow Technologies Inc.
Date: Mon, 14 Sep 1992 15:58:05 GMT

In article <1265@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes:
|> The good old Burroughs 6700 (and family now called the A-series) had/has a 
|> FP format for which a value with a 0 exponent looks like a 'normal' integer
|> (they use a signed integer rather than a 2's complement one) - the hardware
|> goes out of its way to keep a 0 exponent for values if it possibly can ...
|> this means that there are no FP/INT instructions, there's only one ADD, SUB,
|> MULT etc instructions

As I recall, the A-series is a tagged architecture, so there would be only one
ADD, SUB, etc., instruction despite the data format.  The tag automatically
indicates the datatype, and therefore, the kind of operation to perform.  Or
didn't the tags go that far?  It's been so long since I mucked with A-series
code generation...
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 14 Sep 92 19:35:17 GMT
Article-I.D.: CS.1992Sep14.193517.6471
Organization: Oregon State University, Corvallis Oregon

In article <1992Sep13.080843.7741@theus.rain.com>
john@theus.rain.com (John Theus) writes:
>In article <1992Sep13.033602.3708@CS.ORST.EDU>
>crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>
>>I've been computing for 17 years, and in all that time I don't think I've
>>done characteristic roots more than a couple of times.  My sister has been
>>word processing, spread-sheeting, etc. for six years, and I don't think she's
>>ever done a characteristic root.  So, 23 years of computing, 2 roots. 
>>
>If you're using an ASCII display, then you may not be doing any roots. If you
>ever do any serious graphics work, then its likely that square root is heavy
>used. I used to be a system architect designing 3D graphics workstations for
>applications like mechanical CAE/CAD. Root performance was always critical in
>those systems, and our RISC processor vendors payed attention when we
>complained about their lack of square root hardware.

Characteristic roots aren't the same as square roots, but at any rate, this
is the kind of post I like to see.  "Square root performance is critical to
graphics systems".  Given that and its cost, I can make a judgement about its
effectiveness for a given application/market.

>Now, maybe you think the graphics market is unimportant to the RISC processor
>vendors, but if that is so, why do several of the current generation parts
>have graphics execution units?

Maybe it was more cost effective than square root hardware?  I don't know.

>Gee, I didn't know anyone in the CS department at Oregon State was designing
>commercial processors with the marketing staff necessary to back up such a
>statement.

Blush.  I was being a touch to expansive in my use of we.  Sorry.

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
From: lycmit@X1SUN6.CCL.ITRI.ORG.TW (Yin-Chih Lin)
Newsgroups: comp.arch
Subject: Where to find the proceedings of HOT CHIP Symp. IV?
Date: 9 Sep 92 22:49:01 GMT

Greetings:

Could anyone send me the info about how to sub the proceedings of
the HOT CHIP Symp. IV held at Stanford U. in Aug. 9-11, 1992?
I thumb through the IEEE Micro recent issue but could not find
the useful stuff.

It seems that many current RISC chips (such as Alpha, SuperSPARC,
P5 etc) are all discussed, so I just want to buy the related 
proceedings if available. (Please send your direction by email)

Thanks,

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yin-Chih Lin                   Industrial Technology Research Institute (ITRI)
Design Eng.                    Computer & Communication Research Labs.  (CCL)
lycmit@x1sun6.ccl.itri.org.tw  Microcomputer System Department X100
Tel: 886-35-917331             14 Bldg, 195 Chung Hsing Rd., Section 4
Fax: 886-35-917503             Chutung, Hsinchu 31015
                               Taiwan, R.O.C.
From: jkenton@world.std.com (Jeff Kenton)
Newsgroups: comp.arch
Subject: Re: Scientists as Programmers
Date: 8 Sep 92 12:30:47 GMT
Organization: Kenton Systems Corporation, Weston MA

In article <1992Sep4.151001.9886@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>
>Now, these people were not fools - they were PhD's in computer science
>

Aha -- the light dawns.


-- 
-------------------------------------------------------------------------
=			Jeff Kenton	(617) 894-4508			=
=			    jkenton@world.std.com			=
-------------------------------------------------------------------------
Newsgroups: comp.arch
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: trapping speculative ops (LONG)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Fri, 11 Sep 1992 07:48:38 GMT

In article <id.G_3T.SH1@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> Isn't this (extra bits for exceptions) basically the whole point of NaNs and
|> Infinities in IEEE FP? Is the IEEE method inadequate, or would it be reasonable
|> to simply ignore FP interrupts and check for NaNs (assuming integer arithmetic
|> has low enough latency it isn't a problem)?

On a superscalar machine even a one-cycle latency is a problem.
However, integer arithmetic causes no exceptions (in C), so what's the
real problem? Loads.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Xref: sparky comp.arch:9250 comp.lang.misc:2950
From: isaac@Cadence.COM (Isaac Sundarajan)
Subject: Talk on MICROPROCESSOR TRENDS by INTEL's CHIEF ARCHITECT
Organization: Cadence Design Systems, Inc.
Distribution: ba
Date: Wed, 9 Sep 1992 16:39:03 GMT


If you are interested in attending a breakfast talk on the topic
"Microprocessor trends in the 90's", please read . . .           
The talk will be given by INTEL's FELLOW and CHIEF ARCHITECT
 - John Crawford.


___________________  ________________________________________

This talk will take place in the "Village Gate Group" which is a 
quality forum for Christian professionals and their friends 
involved in electrical engineering and computer science.  
Following is the agenda:

Agenda

Continental Breakfast

Guest Speaker:  John Crawford
		Intel Fellow & Chief Architect - Microprocessors
		Intel Corporation
			

Topic:	Microprocessor trends in 1990's

	The talk will will cover some of the following items:

  	o historical trends of semiconductors (density, die size, 
       	  frequency, transistor counts)
  	o historical trends of microprocessor performance
  	o some projections for the future (!)

	( He will also share some personal perspectives on his
	  Christian faith )

Date:	Friday, October 9, 1992.

Arrival:	7:00 a.m. to 7:15 a.m.

Program begins:	7:15 a.m.

Location:	Biltmore Hotel, Santa Clara
		Montague at Highway 101

Price:	$7.50

Reservations:	Please call Carolyn no later than Tuesday,
		October 6 at 408-578-1701. 


Village Group Founders:  
Tim Isbell
Mike Tsai
Y.M. Chu
George Larsen
Isaac Sundarajan
Carolyn Hart
From: marks@cs.man.ac.uk (Mark Stephens (MSc Stephen Furber))
Newsgroups: comp.arch
Subject: Re: Computer Architecture Rationale
Date: 4 Sep 92 17:55:38 GMT

haynes@cats.ucsc.edu (Jim Haynes) writes:


>However it would be a service to students of computer architecture to get
>the rationale in public print, even if it has to wait until the end of
>the product life cycle.  One of my favorite books is the one edited by

An article by Ritter & Boney in Byte (many years ago) entitled "A
Microprocessor for the Revolution" (I think?) describes their thinking
behind the features in the MC6809 cpu.

The design of the ARM2 & ARM3 microprocessors are described in VLSI RISC
Architecture and Organization, by Stephen B. Furber, pub. Marcel Dekker,
ISBN 0-8247-8151-1. The author was one of the principal designers of the ARM.
NB Steve Furber is my project supervisor but IMHO it is worth reading.

Mark.

marks@cs.man.ac.uk
Newsgroups: comp.arch
From: koontz@lysithea.jupiter.com (David G. Koontz)
Subject: Re: Are 64 Int or FP registers useful?
Keywords: Compiler Support
Organization: Jupiter Systems, Alameda, CA
Date: Wed, 9 Sep 1992 23:07:25 GMT

If you could use 64 bit values in a C program, they would make things
like crypt(3) and des(2) go awful fast.
From: moudgill@cs.cornell.edu ( Mayan Moudgill)
Subject: Does anyone know the cycle times for SPARCstations?
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Distribution: usa
Date: Tue, 15 Sep 1992 22:12:42 GMT

I'm looking for a instruction/cycle time breakup for the SPARC.
I'm interested in both the integer and floating point instructions.
I know that the fp times depend on the FPU used, but _any_ pointers
will be useful.

THANX!
:)
Mayan
Xref: sparky comp.arch:9369 comp.lang.misc:3030
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch,comp.lang.misc
Subject: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 11 Sep 92 18:47:44 GMT
Article-I.D.: CS.1992Sep11.184744.19329
Organization: Oregon State University, Corvallis Oregon

In article <Bu5qD3.GAM@mentor.cc.purdue.edu>
hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>And then the hardware designers, being told that something is useless, drop
>it from the instruction set?

You misunderstand what has happened in the industry.  The hardware designers
were told that something was rarely used, and therefore was not cost
effective.  As good engineers, they dropped the feature.

>Designing flexibility in both hardware and software is not that expensive;
>putting in something left out may be.

My experience is just the opposite.  Designing flexibility in either hardware
or software is very expensive.  Given the time to program a simple utility
with one option versus one with twenty supports this claim.  The time to build
an shifter of constant shift versus one of variable shift also supports this
claim.  I invite you to provide _evidence_ in support of your claim.

I grant you, putting something in later will be expensive.

>A simple example is that of square root.  The cost of putting in square root
>on any machine which has "classical" division hardware is essentially zero
>at the design and construction stage, but an algorithm to do it is otherwise
>is necessarily slow and costly.

Only costly when making simplistic comparisons.  If the lack of square root
hardware increases my run time from 10 seconds to 10.0001 seconds (which is
probably realistic for many if not most program runs), it is _not_ costly.

>Bit vectors do not necessarily start on a word, or even a byte, boundary,

Yes, but if only one in a million don't, supporting non-aligned bit vectors
probably isn't cost effective.

>and again, it is easier to deal with the problem at hardware design time
>rather than in software.

This claim is strongly supported by the wide abundance of hardware-implemented
compilers and spreadsheet packages.  :-)  My experience indicates that the
cost to deliver a working solution to _almost_any_ problem is cheaper in
software than hardware.  Consider the cost of building a working multiplier
versus the cost of writing an iterative adding subroutine.  I invite you to
provide _evidence_ that your claim is true.

What you meant to say is "its easier for me if the hardware designers gave me
exactly what I wanted".

-- 
  Lawrence Crowl		503-737-2554	Computer Science Department
			   crowl@cs.orst.edu	Oregon State University
	      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
Newsgroups: comp.sys.apple,comp.dcom.modems
From: bell@teal.csn.org (Bell Scott)
Subject: Re: Terminal Emulator for Apple //e
Organization: Colorado SuperNet, Inc.
Date: Sat, 5 Sep 1992 21:46:21 GMT

	I might suggest setting the host to send <NULL>'s after each line.
This was used often in BBS'ing with ]['s to allow the ][ and the SSC to
catch up with the data transmission.

Scott

Newsgroups: comp.sys.apple,comp.dcom.modems
From: zcameron@nexus.yorku.ca (Zachariah Cameron)
Subject: Re: Terminal Emulator for Apple //e
Organization: York University, CS Dept. Toronto
Date: Sat, 5 Sep 1992 13:21:31 GMT

Use Kermit 3.87.  It is cheap and emulates a VT100 very well.
If you want to spend $US 50.00 you could pick up Modem Manager.
Prices go up from there but for occasional use and for VT220 emulation you
could hardly do better than Modem Manager.

                                      zcameron@pro-dharma.cts.com


Newsgroups: comp.sys.apple,comp.unix.misc
From: tftang@ecs.comm.mot.com (Tang Ting Fook)
Subject: Re: MAC Emulation
Organization: Motorola Penang
Date: Tue, 15 Sep 1992 14:13:19 GMT
Followup-To: tftang@comm.mot.com
Summary: Mac Emulation	
Keywords: Mac emulation

In article <1992Sep9.183716.26962@udel.edu> pahountis@ncf.al.alcoa.com (Julia Pahountis) writes:
>Does anyone know of any Macintosh emulation products for UNIX servers; e.g., SoftPC.  Please
>reply to pahountis@ncf.alcoa.com.
>
>Thanks,
>
>Julia Pahountis
>Alcoa Technical Center
>Alcoa Center, PA  15069
>pahountis@ncf.al.alcoa.com

I am also interested. I am currently using an Apollo for my work but
sometimes I need to use the Mac for some of the Applications. Instead 
of searching for a Mac to use, it would be great if I can open a Mac
window on my Apollo and run the Mac applications. I am able to emulate
a PC on my Apollo using DPCE.

Thanks in advance.

Regards,
Tang
Email : tftang@comm.mot.com
Newsgroups: comp.sys.apple,comp.unix.misc
From: pahountis@ncf.al.alcoa.com (Julia Pahountis)
Subject:  MAC Emulation
Reply-To: pahountis@ncf.al.alcoa.com (Julia Pahountis)
Organization: Aluminum Company of America
Date: Wed, 9 Sep 1992 18:37:16 GMT

Does anyone know of any Macintosh emulation products for UNIX servers; e.g., SoftPC.  Please
reply to pahountis@ncf.alcoa.com.

Thanks,

Julia Pahountis
Alcoa Technical Center
Alcoa Center, PA  15069
pahountis@ncf.al.alcoa.com
Newsgroups: comp.sys.apple,comp.dcom.modems