HDTenEightyP/NetNews huggingface dataset:
From: cprice@mips.com (Charlie Price)
Newsgroups: comp.arch
Subject: Re: Fully associative cache
Date: 30 Sep 92 21:31:34 GMT
Organization: MIPS Technologies, Inc
NNTP-Posting-Host: lloyd.mti.sgi.com

In article <1992Sep30.095736.2080@inmos.co.uk> roger@gimli.inmos.co.uk (Roger Shepherd) writes:
>>|                                                                       The
>>| way we did stores, you would check the tag array in one cycle and then
>>| hold the data around in a store buffer until the next store or free slot.  
>
>So, you use 2 cache access cycles per write. Provided that the load on the 
>cache is small (percentage of cycles reading + 2*percentage cycles writing
>< 100) this may be ok. If you have a high proportion of writes you will 
>have a problem.
>
>>|                                                                            At
>>| that time you could retire the store.  There is no delay since it is pipelined.
>
>Pipelining hides the delay - it does nothing to improve the bandwidth lost
>by taking 2 cache cycles to do the write. 

This is not an important point, but I don't want anyone to
carry away the wrong impression about this --
a write doesn't require two dedicated cache cycles.

Paul's explanation probably wasn't detailed enough.
The data cache is split into two parts, the tag side and the data side,
that can be read/written independently.
For a read, both the tag and data sides are read at the same time.
For a write:
 the tag side is read to check for a cache hit/miss,
 the data for the write goes into a couple-deep store buffer,
 the oldest pending write in the store buffer is written
 to the appropriate line in the data side.
In addition to retiring store buffer contents under a subsequent write,
the store buffer will also retire a write in any cycle that
the data cache isn't being accessed (i.e. any instr that isn't a load/store).
The store buffer is non-trivial to build and get right, but not using
two cache cycles for stores was a sufficient win to make it worthwhile.

-- 
Charlie Price    cprice@mti.sgi.com        (415) 390-4457
SGI (MTI) / MS 10U-178 / 2011 N. Shoreline Blvd / Mountain View, CA   94043
Newsgroups: comp.arch
Subject: Is SPIM ported to the Amiga, Mac or IBM?
From: hoffmann@nutmeg.ntu.edu.au (Arthur Hoffmann)
Date: 30 Sep 92 00:41:37 +0900
Distribution: world
Organization: Information Technology, Northern Territory University

Hi,
The subject line says it all. 
I am wondering if SPIM is ported to Amigas or Macs or PCs ?
Thank's for your replys.

Arthur.

				Arthur Hoffmann
				hoffmann@nutmeg.ntu.edu.au
From: tak@hprnd.rose.hp.com (Tom Keaveny)
Date: Wed, 30 Sep 1992 17:58:44 GMT
Subject: Re: Power consumption
Organization: KTOM-fm --> playing all the bits
Newsgroups: comp.arch

/ hprnd:comp.arch / badri@rags.rutgers.edu (Br Badrinath) /  8:47 am  Sep 26, 1992 /

>3. How much power is consumed by an average read from
>the CD disk, from floppy disk, from flash memory, any
>other memory?


flash memory:   	50 - 300 mWatts
static CMOS ram:	200- 350 mWattso

In standby mode, memories will typically consume less than 10 mWatts of power.

In deep power-down mode, power consumption is down to 10's of uWatts.
From: jhauser@pine.CS.Berkeley.EDU (John Hauser)
Newsgroups: comp.arch
Subject: Re: MIPS/Ultrix assembler BUG
Date: 5 Oct 1992 02:07:13 GMT
Organization: University of California at Berzerkeley
NNTP-Posting-Host: pine.cs.berkeley.edu

In article <1992Oct1.180306.13595@prl.dec.com> vanroy@prl.dec.com (Peter Van Roy) writes:
>The MIPS assembler will fill delay slots with instructions at the
>branch destination that overwrite certain registers (e.g., the
>temporary registers t0, t1, ...).  This is ok if the branch is taken. 
>If the branch is not taken, watch out!  The previous contents of the
>register are gone.  This seems to work well for assembly generated by
>the C compiler, but it does not for our independently generated
>assembly code, which would like these registers to stay valid even if
>the branch is not taken.  Is there a way to turn off this "feature",
>for example to tell the assembler that all registers are live across
>branches?

This is certainly _not_ supposed to happen.  However, I'm suspicious:  does
the `.option' directive appear in your code?  This directive is used to
communicate information from a compiler to the assembler, and is intended to
allow the assembler to do just the sort of thing you've described.  If you
don't know what the `.option' does (and I sure don't), it doesn't belong in
hand-coded assembler.  The reason I ask is that you could have gotten this
if you ``borrowed'' some compiler output as a starting place for your own
code.

In any event, it sounds like some assembler optimizations are getting turned
on inadvertently.  If it's through no fault of your own, you've definitely
found a _bug_ and should complain.

----------------------------------------------------------------------------
Boycott redwood.  Boycott Louisiana-Pacific.  Keep the forests.  YYYYYYYYYYY
John Hauser---jhauser@cs.berkeley.edu  YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
From: gscott@VNET.IBM.COM
Newsgroups: comp.arch
Subject: Best Grad Schools for Computer Engineering?
Date: 28 Sep 92 20:21:44 GMT

Since the Gourman Report is late as usual.  What are people's opinions
on the best graduate schools for computer engineering (hardware)?
This would include academic as well as research aspects.  What universities
are doing the best research in areas such as:

Parallel Computing/Multiprocessing?
Fault Tolerance?
Optical Computing?
uP Architrecture?
Networking?

Feel free to add to the list.

I'm interested in hearing from people in both Academia and "The Real World".

Thanks,

George Scott
gms2@po.cwru.edu
gscott@vnet.ibm.com
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 27 Sep 92 07:50:58 GMT
Organization: Auspex Systems, Santa Clara
Originator: news@auspex-gw.Auspex.COM

There's an interview with Roger Ross of in the latest Open Systems
Toady(sic) in which, among other things, he's quoted as saying:

	The only real 64-bit processor out there is Alpha.  The MIPS
	chip is not a 64-bit machine -- not the way I measure it.  And
	neither are the rest and neither is SPARC.  All of them have
	attributes of 64-bit-wide widgets, which makes sense from a
	bandwidth standpoint.  But a true 64-bit machine has 64-bit
	registers, 64-bit adders, quad multipliers.  Only Alpha has
	that.  The present machines are merely 32-bit machines that
	implement 64-bit paths.

Now, I thought the R4000 had 64-bit registers, and presumed it had
64-bit adders.  Is it merely lacking the quad multipliers?  Or is Ross
mistaken?  Or is it lacking something else?

(And speaking of 64-bit architectures, has HP said anything about future
64-bit versions of Precision?  Alpha and, unless you agree with Ross,
MIPS already have 64-bit versions - Alpha having, of course, *only* a
64-bit version - and SPARC and POWER have a 64-bit version specified.

For that matter, has Intel said anything about going to 64 bits in the
*86 architecture?)
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.arch
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 30 Sep 92 17:34:57 GMT
Organization: IDA Center for Communications Research, Princeton

John R. Mashey <mash@mash.wpd.sgi.com> writes:
> Since there may not be anything *after* microprocessors, maybe we'll
> have learned from our previous sins.

I can't tell if this is a joke.  You aren't seriously suggesting that
modern microprocessor design incorporates all of the design principles
that will be needed until the end of time??

I can just imagine those computer designers in the year 2100 or so
saying, "Yeah, single instruction streams with superscalar execution,
that's the ticket."  Not.

I would say that even suggesting that this is a possibility is just
about the most arrogant thing I have ever heard.

                                        David desJardins
From: cprice@mips.com (Charlie Price)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 30 Sep 1992 21:06:30 GMT
Organization: MIPS Technologies, Inc
NNTP-Posting-Host: lloyd.mti.sgi.com

In comp.arch, desj@ccr-p.ida.org (David desJardins) writes:

> None of John's reasons (except for putting integer and fp registers on
> separate chips) seem to explain why the instruction set should not at
> least allow transfers between the integer and fp registers.  After all,
> I as a user am paying in gates and chip space for those registers.  Why
> shouldn't I be able to use them at least as fast temporary storage, for
> register spilling and the like?

John's comments were about why separate general (integer) and FP
register sets might make sense.  I don't think he addressed the issue
of whether inter-register-set transfers made sense.

I know of no good reason not to allow transfer between
general and FP registers in a general-purpose architecture.
The MIPS architecture supports this.
There might be good reasons why doing a transfer either costs money
(an extra bus perhaps) or is slow (if you don't put in an extra bus)
in a particular implementation.

When looking at benchmarks analyses it was clear that not being able
to directly transfer between the register sets in the SPARC architecture
was losing them some performance.  This wasn't a case where someone
wanted to use the registers as temporaries, but rather where
a data object was operated on by both the ALU and FPU.
This is common enough:
  you do an FP calculation,
  you convert the result to an integer to use it as an index...
-- 
Charlie Price    cprice@mti.sgi.com        (415) 390-4457
SGI (MTI) / MS 10U-178 / 2011 N. Shoreline Blvd / Mountain View, CA   94043   
Xref: sparky comp.arch:9656 comp.lang.misc:3177
From: badri@rags.rutgers.edu (Br Badrinath)
Newsgroups: comp.arch
Subject: Power consumption
Keywords: power
Date: 26 Sep 92 15:47:27 GMT
Organization: Rutgers Univ., New Brunswick, N.J.


There has been a lot of discussion about battery power limitations for
palmtops (HP75LX, sharp etc).
 We intend to consider 
power management as a research issue in the design of OS for palmtops,
PDA's etc.
 
We need some numbers about power consumption. Any light (no pun 
intended) on these questions would help us.


1. How much power is needed to transmit a packet of data
over wireless  as a function of distance of transmission, modulation technique,
receiver strength etc? 


2. How much power is necessary to support a CD ROM disk?

3. How much power is consumed by an average read from
the CD disk, from floppy disk, from flash memory, any
other memory?

4. What is the power consumption for remote session operations such as file
transfer, receiving a data packet (Mwatts/byte??)

5. What is the power consumption of the CPU (per n cycles or so)?

6. What is the average lifetime of AA batteries (and under
what usage)?



--Badri

badri@cs.rutgers.edu
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Adobe Systems Incorporated
Date: Mon, 28 Sep 1992 00:52:49 GMT

In article <14813@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
[Roger Ross says the R4000 isn't true 64 bit.]

Roger Ross is full of shit. (As usual.) Somebody at MTI should send Open  
Systems a correction. My R4000 manual is at home but I'm pretty sure the  
R4000 supports 64 bit operations exactly as well as the R3000 supports 32  
bit operations with the following exceptions:

1) Doubleword shifts may take more than a single cycle.
2) Only 40 of the 64 address bits are implemented. (A similar restriction is  
true of Alpha as well.)
3) Synthesizing a 64 bit address takes relatively more instructions hence  
spineless software implementors may introduce 4 gigabyte limits into the  
programming model. (E.g. all code and data fed to the linker must fit into  
the lower 2 or 4 gigs of memory.) The same holds true of Alpha.
4) There is no shipping 64 bit programming environment for the R4000. Of  
course Alpha is non-existient in this regard.

There is the issue that MIPS has a significant installed base of 32 bit only  
hardware which may prevent software developers from shipping 64 bit  
software.

I'll bet DEC learned a fair bit from the MIPS architecture which they used  
in defining Alpha. There are striking similarites. Which is totally cool  
except that it is the last thing they would admit in their public hype.

> 
> (And speaking of 64-bit architectures, has HP said anything about future
> 64-bit versions of Precision?  Alpha and, unless you agree with Ross,
> MIPS already have 64-bit versions - Alpha having, of course, *only* a
> 64-bit version - and SPARC and POWER have a 64-bit version specified.
> 
> For that matter, has Intel said anything about going to 64 bits in the
> *86 architecture?)

At this point, software is probably more important than hardware. These  
companies have plenty of time to implement 64 bit processors. Of course DEC  
and MIPS have an advantage in defining a software model. I don't expect 64  
bit will help either of them that much though. If it was that pressing, you  
would have a 64 bit environment available on the R4000.
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
Newsgroups: comp.arch
From: koontz@lysithea.jupiter.com (David G. Koontz)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Jupiter Systems, Alameda, CA
Date: Tue, 29 Sep 1992 20:39:02 GMT

In article <lcf2lnINN57l@spim.mti.sgi.com>, cprice@mips.com (Charlie Price) writes:
|> In article <14813@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
|> >There's an interview with Roger Ross of in the latest Open Systems 
|>
|> >	The only real 64-bit processor out there is Alpha.  The MIPS
|> >	chip is not a 64-bit machine -- not the way I measure it.  And
|> >			   ..,.  But a true 64-bit machine has 64-bit
|> >	registers, 64-bit adders, quad multipliers.  Only Alpha has
|> >	that.  The present machines are merely 32-bit machines that
|> >	implement 64-bit paths.
|> >
|> >Now, I thought the R4000 had 64-bit registers, and presumed it had
|> >64-bit adders.  Is it merely lacking the quad multipliers?  Or is Ross
|> >mistaken?  Or is it lacking something else?
|> 
|> The R4000 has:
|>  64-bit regs
|>  64-bit adder
|>  64x64 -> 128 bit multiply
|> 
|> Perhaps what it lacks for Roger is a revenue stream into his pocket.
|> I've found Roger's reported remarks in the past difficult to decipher.
|> I can't decide if he is ill-informed, stupid, dishonest, or some
|> combination of them.  His comment about the R4000 seems in character.
|> -- 

I had heard that the compiler lagged 'til IRIX 4.05 for 64 bit objects.  This 
could be incorrect, but 'twere it true, t ain't a 64 bit machine until you can 
use 64 bit values.

Speaking of vaporware, is it possible to buy an Alpha machine?  






Newsgroups: comp.arch
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: Fully associative cache
Date: 1 Oct 92 13:05:41 GMT
Organization: Department of Computer Science, U of Copenhagen

cprice@mips.com (Charlie Price) writes:
>For a read, both the tag and data sides are read at the same time.
>For a write:
> the tag side is read to check for a cache hit/miss,
> the data for the write goes into a couple-deep store buffer,
> the oldest pending write in the store buffer is written
> to the appropriate line in the data side.

Why is the buffer ``a couple'' deep? One should suffice.

In a write-back cache, what happens if a read causes the cache line
where the buffered entry belongs to be replaced? One extra cycle of
delay to update the line before writing it back, I'd guess.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Newsgroups: comp.arch
From: michelotto@dxcern.cern.ch (Michele Michelotto)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Reply-To: michelot@dxcern.cern.ch
Organization: CERN - European Laboratory for Particle Physics
Date: Mon, 28 Sep 1992 20:34:30 GMT


In article <1992Sep28.104858.6781@hemlock.cray.com>, davew@willow03.cray.com (Dave Wagner) writes:
|>Check address spaces in Alpha though.  Alpha (21064) has only a 43-bit virtual
|>space, and a 34-bit physical space.  I think a 'real' 64 bit processor should
|>provide more (64bits) of both.

what I understand is that:
1) Alpha is 64 bit architecture, designed to be full 64 bit.
2) the 21064 chip implementation limit himself to 43 bit (and 34 bit)
3) future processor will have more ore less bit; may be less if you
   will use them in Alpha PC or in Alpha lamp or Alpha toaster :-)
   may be more if you'll use them for a Alpha mainframe.
 
|>Dave Wagner                                     Cray Research, Inc
|>davew@cray.com , uunet!cray!davew               655F Lone Oak Drive
|>(612) 683-5393                                  Eagan, MN  55121
|>
--
						
******************************************************************************
* Michele Michelotto, INFN Padova, Delphi group.                             *
* Internet: michelot@vxcern.cern.ch     BITNET: MICHELOTTO@IPDINFN           *
* Tel (+39).49.844347                   HEPNET: VAXFPD::MICHELOTTO           *
*       When the moon fills the sky, like a big pizza pie, it's amore.       *
******************************************************************************
Newsgroups: comp.arch,comp.benchmarks
From: dseal@armltd.co.uk (David Seal)
Newsgroups: comp.arch
Subject: Re: Integer/FP communication (Was: Goals, Cost, and Flexibility...)
Date: 28 Sep 92 08:52:41 GMT
Distribution: comp
Organization: A.R.M. Ltd, Swaffham Bulbeck, Cambs, UK

In article <1992Sep25.072909.1525@adobe.com> zstern@adobe.com (Zalman Stern)
writes:

>In article <1661@idacrd.UUCP> desj@ccr-p.ida.org (David desJardins) writes:
>> John R. Mashey <mash@mash.wpd.sgi.com> writes several reasons why
>> machines might have separate integer and floating-point registers, even
>> though obviously users would prefer one set.
>
>I feel the term "obviously" is incorrect here. Some people want it, but it  
>does not matter to most users. I would prefer instructions that load all  
>sizes of integers into FP registers and good support for converting from int  
>to FP and back in the FP unit. Playing with the individual bits of an FP  
>number isn't that interesting to most users.

You don't need to want to twiddle the bits of a floating point number to get
the benefit of a combined register bank. For instance, having a shared bank
of 64 registers would be better than having 32 integer registers and 32
floating point registers, because your compiler gets the freedom to choose
how to split them up. So non-floating point code would get the benefit of 64
integer registers, while some types of floating-point intensive code might
get 50-60 floating point registers (you'll probably need a few registers
with integer contents such as addresses). This would be an improvement over
being restricted to 32 registers of each type. How much of an improvement
I'm not certain - how much code benefits e.g. from 64 integer registers
rather than 32 is a subject that has been debated before, IMHO not very
conclusively.

David Seal
dseal@armltd.co.uk

All opinions are mine only...
From: campbelr@hpcuhe.cup.hp.com (Bob Campbell)
Newsgroups: comp.arch
Subject: Re: Which is the Best RISC Arcitecture ?
Date: 29 Sep 92 18:30:27 GMT
Organization: Hewlett Packard, Cupertino

> HP precision architecture may not be available outside HP.

The Precision Risc Organization (PRO) was formed on March 23, 1992.  It 
consists of a group of worldwide partners committed to the use of PA-RISC
in systems from embedded control to high-end computer systems.

Members include Convex, Hitachi, Hewlett-Packard, Hughes, Mitsubishi, 
Oki, Sequoia, Stratus, Yokagawa and Winbond.  Several PRO members have 
licensed the PA-RISC technology from Hewlett-Packard and are expected to
develop and produce their own chips.  Others may be expected to produce
systems using externally produced PA-RISC chips and boards.

---------------------------------------------------------------------------
Bob Campbell                Some times I wish that I could stop you from
campbelr@cup.hp.com         talking, when I hear the silly things you say.
Precision Risc Organization                        - Elvis Costello
Xref: sparky comp.arch:9785 comp.lang.misc:3200
From: limes@ouroborous.eng.sun.com (Greg Limes)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 1 Oct 92 16:15:20
Organization: Sun Microsystems Computer Corporation
	<1992Sep29.232852.22456@CS.ORST.EDU> <BvF75z.GBA@mentor.cc.purdue.edu>
NNTP-Posting-Host: ouroborous
In-reply-to: hrubin@mentor.cc.purdue.edu's message of Thu, 1 Oct 1992 02:05:58 GMT

In article <BvF75z.GBA@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:

|   Counting is from the most significant.  Incidentally, the C code
|   in the case that all bits are used, here illustrated for 32 bit
|   words, is subject to the ambiguity, although it can be eliminated
|   by two additional operations.

Pardon me for interrupting, you had a good rant going, but I still don't
see what you mean by this "ambiguity".

|	   B = 0x80000000 >> (K-1);
|	   H = (B&X) >> N;
|	   B >>= N;
|	   H = B &~ H;
|	   X = (X &~ B) | H;
|
|   The shifts must be logical shifts.  How many additional instructions do you
|   need in portable C to do this?

None. Declare the variables to be unsigned.
Newsgroups: comp.arch,alt.folklore.computers
From: dinda@cae.wisc.edu (Dinda Peter)
Subject: One Instruction Computers
Organization: U of Wisconsin-Madison College of Engineering
Date: 30 Sep 92 15:45:31 CDT


Prevoiusly someone had posted am message regarding one instruction
computers - I believe a 3 operand conditional subtract instruction.
I believe there was also a pointer to a paper that had been written
on the subject.  Please email.


Peter A. Dinda



From: tgg@otter.hpl.hp.com (Tom Gardner)
Date: Thu, 1 Oct 1992 16:50:15 GMT
Subject: Re: Power consumption
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch

|1. How much power is needed to transmit a packet of data
|over wireless  as a function of distance of transmission, modulation technique,
|receiver strength etc?

This is _far_ too complex to summarise. Entire books and careers are devoted
to this subject!

Newsgroups: comp.arch