HDTenEightyP/NetNews huggingface dataset:
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: No Branch Delay Slot(s)...
Organization: Metaflow Technologies Inc.
Date: Thu, 10 Sep 1992 00:46:47 GMT

In article <1992Sep9.044231.12217@fcom.cc.utah.edu>, phil@news.ccutah.edu (Phillip Neiswanger) writes:
|> 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.

Delay slots came about because scalar processors with neither branch
prediction nor branch target buffers are unable to issue the branch
target in the clock following issue of the branch instruction.  In an
attempt to make use of at least one clock of this bubble, you delay the
execution of the branch, and issue the instruction following it.

The trouble is, if you take a look at typical MIPS or SPARC code, the
delay slot is often filled with a NOP, or with a duplicated
instruction.  In general, delay slots artificially constrain code
generators (human or otherwise) and tend to dilute the code (i.e., with
duplicate instructions or NOPs).  Bigger code means more instruction
cache misses, more text page faults, and more text page TLB misses.

In a superscalar machine of order 2 (i.e., it can issue 2 instructions
per clock), a single delay slot can be useful.  Still, you have to live
with the above-named deficiencies.  Besides, what are you going to
issue in the next clock, Sherlock?

When you get into more aggressive superscalar architectures (such as
Metaflow's order-4 machine), a single delay slot instruction doesn't
help you very much.  I suppose you might want *more* than 1 delay slot,
but how many do you want to burden the instruction set with?

In any event, delay slots were an elegant solution in the days when
pure, simple RISC architectures were the best solution to the
performance problem.  These days, many folks are waking up to the
realization that merely boosting the clock rate and the cache sizes
will not get you where you want to go.  You need superscalar (or
superpipelining, for those of that bent).  Then, to really make
superscalar architectures work effectively, you need branch prediction,
speculative execution, register renaming and out-of-order execution.  

(If you're interested in these concepts, go read Metaflow's article in
the June '91 issue of IEEE Micro.)
-- 

...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: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Not using integers
Date: 10 Sep 92 15:52:05 MDT
Organization: Utah State University

In article <6419@armltd.uucp>, abaum@armltd.uucp (Allen Baum) writes:
> But, I seem to recall the Burroughs 5000 series mainframes did something like that.
> Integer was just a special case of FP.-- 

They put the binary point on the right, so an integer appeared to be a floating
point number with a zero exponent. Of course, you couldn't have integers with
more bits than were representable in the mantissa of a floating point 
number...

Roger Ivie
ivie@cc.usu.edu
Xref: sparky comp.arch:9388 comp.lang.misc:3051
From: rvinluan@cs.cornell.edu (Rolando Vinluan)
Subject: Re: Multi uP P5 systems
Organization: Cornell University, CS Dept., Ithaca, NY
Date: Sat, 12 Sep 1992 02:45:53 GMT

In article <n2vn=9h.erb@netcom.com>, erb@netcom.com (Elizabeth R. Brown) writes:
|> 
|> Well, I'm back.  Asia was great.  Prepair for hot rumor mongering.
|> 
|> On a tour of a major MB manufacturing plant my friend showed me what they
|> were working on in the design lab.  It was an EISA board with sockets for
|> four P5 chips!  He said the P5 has features that make it very easy to
|> design multi-CPU boards.  I asked him what software was able to take
|> advantage of this type of system, but he said he couldn't tell me, but
|> he said it was *not* UNIX.  He also said they are working on an 8-CPU design.
|> 
|> Talk about an up-gradable mother board!  Buy it with one P5, then add
|> more as the budget allows.
|> 
|> My question is still: What software will be able to take advantage of
|> this?  A version of Mach?  Solaris?  OS/2?  Has anybody heard anything
|> about this?

	Isn't it obvious? Windows NT. Buy the SDK CD now for $69.


	Seriously, did your friend say when these kinds of boards will
be out? This is great news. If these things come by say, last year,
then multiprocessing will finally come to the masses.
From: rw@dcs.ed.ac.uk (Robert Walker)
Newsgroups: comp.arch
Subject: CACHE WRITES
Date: 9 Sep 92 17:25:24 GMT
Organization: Department of Computer Science, University of Edinburgh

Hi,

I am interested to learn more about write strategies in caches.
A read-modify-write sequence is mentioned in H&P (Computer Architecture
a Quantitative Approach). A couple of problems might help....

-------------------------------------------------------------------------------
P1

Does this mean that on a WRITE HIT (with a WRITE BACK policy) would result
in the following actions (parallelism is shown - I hope):

(1) index field sent to each set;
    match tag field with tag-memory (hit/miss generated by each set);
    read data from cache line       (line from each set);

(2) hit/miss? Valid?

(3) multiplex cache lines (1/set)   (if 2-way(+) associative)
((1)/(2)/(3) - as for read??)

(4) write new data into portion of cache line
    (indexed by cache block offset)

(5) write updated cache line back into cache (into same set!)

-------------------------------------------------------------------------------
P2

Does this mean that on a WRITE HIT (with a WRITE THROUGH policy) would result
in the following actions (parallelism is shown - I hope):

(1) index field sent to each set;
    match tag field with tag-memory (hit/miss generated by each set);
    read data from cache line       (line from each set);

(2) hit/miss? Valid?

(3) multiplex cache lines (1/set)    (if 2-way(+) associative)
((1)/(2)/(3) - as for read??)

(4) write new data into portion of cache line
    (indexed by cache block offset)

(5) write updated cache line back into cache   (into same set!);
    write updated cache line into write buffer (or stall if it is full)

-------------------------------------------------------------------------------

Does this look right? I think I'm just fleshing out what the book says anyway
(us enginery types...). Hopefully these solutions aren't too obvious! Is the
parallelism about right, do you think?

  Thanks in advance,

     Rob

-----------------------
Email: rw@uk.ac.ed.dcs
Newsgroups: comp.arch,comp.parallel
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: sgi/sun shared memory machines question
Apparently-To: comp-parallel@uunet.uu.net
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Sun, 13 Sep 92 02:00:34 GMT

(I've removed the Distribution line; why limit things like this
to the US?)

In <1992Sep11.121830.17069@hubcap.clemson.edu> zilla@nj.nec.com (John Lewis) writes:
| Someone told me that the SGI multiprocessor machines cannot run
| different unix processes on different processors; they can only
| run a single (but possibly parallelized) process at a given time.

This is completely incorrect.  You can run multiple threads of
one process, or completely seperate processes on each CPU.

| The reason was said to be that the machines do not implement
| any mechanism for simultaneous writes.

There is a bus called the MP or Sync bus that handles cache
coherency issues.  If a process with multiple threads, or
seperate processes use shared memory, they need to provide
some mechanism (normally the hardware spinlocks or higher
level library routines based on them) to avoid attempts
at simultaneous access to the same memory locations (if
they care).

| Is the new sun multiprocessor (4/690?) similar?

It is 'similar' in that multiple processes can run on multiple
CPUs.  The exact methods used for semaphoring are different.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com



Newsgroups: comp.arch
From: scollins@lookout.it.uswc.uswest.com (Steven Collins)
Subject: Wanted P5 info.
Organization: U S WEST Information Technologies
Date: Mon, 14 Sep 1992 13:56:21 GMT

Is there a news group where more discussion on the
P5 is going on?  Does anybody have specs. on the P5
they can post?
Much appreciated,
-Steve
-- 
||  Steve Collins          ||  INTERNET: scollins@uswest.com      ||
||  1475 Lawrence Ave #500 ||                                     ||
||  Denver, CO 80202       ||  US WEST Multimedia AE              ||
From: fleurant@sparc15.hri.com (P.Fleurant)
Newsgroups: comp.arch
Subject: Fault Tolerant-High Availability comp systems
Keywords: Fault Tolerant-High Availability
Date: 10 Sep 92 20:06:19 GMT
Reply-To: fleurant@sparc15.hri.com (P.Fleurant)
Organization: Horizon Research

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?

Thanx

-------------------------------------------------------
P.Fleurant          Horizon Research, Inc, Waltham, MA
From: preece@urbana.mcd.mot.com (Scott E. Preece)
Newsgroups: comp.arch
Subject: Re: No Branch Delay Slot(s)...
Date: 9 Sep 92 15:56:29 GMT
Article-I.D.: predator.PREECE.92Sep9105624
Distribution: comp
Organization: Motorola MCG, Urbana Design Center

In article <1992Sep9.044231.12217@fcom.cc.utah.edu> phil@news.ccutah.edu (Phillip Neiswanger) writes:
|
|   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.
---
Well, in the 88110 User's Manual it says:

   Delayed branching was developed for the MC88100 to help reduce penalties
   associated with changes in program flow; however, in future machines,
   delayed branching may be implemented in software and may actually reduce
   performance.  Therefore it is recommended that new software (e.g.,
   compilers) avoid delayed branching.

I think the implication is that the chip folks now believe they can do
better with branch prediction and speculative execution than they could
with a single delay slot.  Speeds being what they are, filling one slot
in the bubble is no longer very interesting, and filling more than that
is just not practical for hand (or compiler) coding techniques, so the
chips basically *must* do it themselves, anyway.

--
scott preece
motorola/mcg urbana design center	1101 e. university, urbana, il   61801
uucp:	uunet!uiucuxc!udc!preece,	 arpa:	preece@urbana.mcd.mot.com
phone:	217-384-8589			  fax:	217-384-8550
Xref: sparky comp.arch:9417 comp.lang.misc:3069
From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 14 Sep 92 19:44:36 GMT
Article-I.D.: CS.1992Sep14.194436.6726
Organization: Oregon State University, Corvallis Oregon

In article <BuJ3qG.2FD@mentor.cc.purdue.edu>
hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>In article <1992Sep13.033602.3708@CS.ORST.EDU>
>crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>>word processing, spread-sheeting, etc. for six years, and I don't think she's
>>ever done a characteristic root.
>
>Who would expect procedures like that to make good use of square roots?

Which is my point.  You tell me what a architectural feature costs, and what
alogorithms it improves, and I'll decide whether those costs and benefits are
appropriate to my application.  (Or, if I were making a machine, whether it
is appropriate to my potential customers.)

>I suspect that if fixed-point arithmetic were used for spreadsheets, it
>would be faster than floating.

It wouldn't suprise me.  Fixed-point is also faster on the Mandelbrot set.

>I suggest you try generating non-uniform random numbers.  The fastest
>algorithms by far are acceptance-rejection and related ones.

Now we're getting somewhere.  What specific architectural features speed up
the generation of such numbers; what do you expect to be the speed up to be;
and what do you expect the cost to be?

-- 
  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.arch,comp.lang.misc
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Computer Science, University of Melbourne, Australia
Date: Sun, 13 Sep 1992 22:30:23 GMT

jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:

>Not quite that, but look at IBM's VM/HPO. A large part of the virtual machine
>assists and thus of VM is actually done in microcode, probably individually
>for every model series. Saving 25% or more of your 3090's processing power
>is certainly worth a few man year's microcoding slavery.

Well, that may not necessarily be the case.
If those few man-years of microcoding slavery mean that your product takes
six months longer to get to the market then it may not be worth the effort.
As the technology improves processing power is almost doubling every year,
so in those six months, your competition may well introduce a machine that
is 30-40% faster, so your +25% is now looking more like -5% or -10% (to
pluck a few figures out of the air).

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: smanicka@oucsace.cs.ohiou.edu (Senthilkumar Manickavasagam)
Newsgroups: comp.arch
Subject: SPARC
Date: 8 Sep 92 16:56:32 GMT
Organization: Ohio University C.S. Dept, Athens


  I'm looking for some good intro materials on SPARC
  (Scalabel Processor ARChitectues). If any one of
  U there came acros some paper, a book or.. any indepth
  material please let me know.
  Reply to me at 
    senthil@bobcat.ent.ohiou.edu
  (or)  
    smanicka@oucsace.cs.ohiou.edu  
    
  thanks in advance
  Senthil
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: trapping speculative ops (LONG)
Organization: Intel Corp., Hillsboro, Oregon
	<1992Sep9.121701.13208@odin.diku.dk>
Date: Thu, 10 Sep 1992 04:26:50 GMT


	A more radical solution: Put the flags in the memory system! Given a
	CPU/memory interface that only supports aligned 64-bit register loads
	and stores (not too far from some current RISCs), it would be easy to
	add some extra bits to both registers and memory words. This looks
	very much like earlier tagged architectures, except that the extra
	information is the history of a value instead of its type.

	Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)


An entirely reasonable approach. 

Unfortunately, tagged architectures of any type, whether the tag is
used for type (LISP machines) or flow control (HEP) or security (I
vaguely recall a VMEbus system with a 33rd bit - or was it Futurebus?)
have never been wildly successful.  The same pressures that have
encouraged standardization on 16, 32, 64, 128 bit wide architectures
and datapaths discourage tags - you have to build special memory
boards/SIMMs/...

The only way extra bits in memory are going to succeed is if you can
demonstrate enough *commercial* advantage to motivate changing the
industry defacto standards.

In the meantime, you have to live with mechanisms for tags on
registers without tags in memory, or nothing.


--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Newsgroups: comp.arch
Subject: Re: MC68020 -- how does it compare?
Date: 14 Sep 1992 16:04:17 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

In <1992Sep11.134019.12511@ryptyde.cts.com> scott@ryptyde.cts.com writes:

> 
> Hi all,
> 
> 	Does anyone have some kind of comparison between the 68020 and
> the i386?  I'm interested in performace differences mostly.
> If this is included in a FAQ somewhere, please tell me where I can find 
> it and I'll go away quietly.  8-)
> 
> Thanks in advance,
> 
> Scott
> 
> -- 
> INTERNET:  scott@ryptyde.cts.com                     | "Nuke the homeless gay
> ARPANET:   ryptyde!scott@nosc.mil                    |  baby whales for Jesus!"
> UUCP:      {crash, nosc}!ryptyde!scott               |    - bumper sticker

For 32-bit code the overall performance of the i386 and the 68030 is about the 
same for chips operating at the same frequency. The 68020 isn't very much
slower than the 68030 (~10%), so its performance is also similar to the i386.
This is from memory, refering to a benchmark comparison by Motorola that I read
quite a while ago. Seemed to be quite fair, though (Usually, I work with Intel
processors). If you want to know for sure, just dig up the SPECmarks for the
Macintosh models that use the 68030 (If I rememer correctly, an i386-33
performs at 6.5 SPECmarks (1989 benchmark suite)). 


Norbert
-------------------------------------------------------------------------------
Norbert Juffa         email: S_JUFFA@IRAVCL.IRA.UKA.DE       Live and let live!
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 14 Sep 92 14:39:29 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Sep12.024553.18997@cs.cornell.edu>, rvinluan@cs.cornell.edu (Rolando Vinluan) writes:

| 	Seriously, did your friend say when these kinds of boards will
| be out? This is great news. If these things come by say, last year,
| then multiprocessing will finally come to the masses.

  The original poster said something about the OS "not being UNIX,"
could you imagine that someone would be ignoring the MP UNIX versions
which are currently shipping (MPX and V.4MP) to go to a new OS?

  Of course if dreams come true maybe someone is porting Multics to a
popular hardware platform...
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    I admit that when I was in school I wrote COBOL. But I didn't compile.
From: div@NAD.3Com.COM (Dinesh Venkatachalam x5498)
Newsgroups: comp.arch
Subject: Is there a mail daemon to get Technical reference Info
Date: 10 Sep 92 15:20:36 GMT
Reply-To: div@NAD.3Com.COM
Organization: 3Com Corp


I am looking for a mail daemon (site) to obtain Technical Reference Information
similar to

  graf-bib-server@decwrl

where I can give important keywords in the Subject: field and get responses back.

Thanks.

...Dinesh

P.S: I am only interested in Comp.Arch (Hardware) references
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: Computer architects forced to change careers. NOT!
Date: 11 Sep 92 15:33:07 GMT
Organization: I.E.C.C.

>There are at least two interesting parts to a project like 432
>	Conception/Requirements and 
>	Execution (Design and Implementation)
>If a group has done a great job in the Execution of mistaken
>Concepts/requirements, maybe you should let them try another Execution.

This is a good point.  For all the 432 was bloated and slow, it
really worked.  I've heard first-hand reports that people who looked
for bugs in its microcode couldn't find any.  Considering how much microcode
it had, that's no small achievement.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
From: butrfeld@swift.cs.tcd.ie
Newsgroups: comp.arch
Subject: Re: Fault Tolerant-High Availability comp systems
Date: 11 Sep 92 11:50:14 GMT
Organization: Computer Science Department, Trinity College Dublin

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 (?)
> 
In

"Computers in Banking and Finance: The Impact of Fault Tolerant Systems",
by Chris Summers (Financial Times Business Information, 1984)

there is a list of some 20 or so fault tolerant companies that existed in
1984. How many of these exist today is another question entirely.

> .... stuff ommitted ....
> Is Fault Tolerant just some marketing hype used to sell expensive low
> performance yet highly
> redundant computer?
> 
The same reference states:
"The importance of keeping computer systems running under such circumstsances
(component failure) is vital now that huge sums of money are comtrolled by
computer-held information .... The cost of having a fault tolerant system is
not considered high by the users (banks) covered in this report"

Fault-Tolerant systems are more expensive and slower in general (given the
hardware contents) than conventional systems. But some applications, such
as banking funds transfer, computerised trading desks and aircraft avionics,
have critical safety requirements that cannot be met by ordinary computer
systems.

However, if someone tries to sell you a fault-tolerant word-processor,
that is probably hype :-)

Andrew Butterfield,
Dept of COmputer Science, Trinity College Dublin.
butrfeld@cs.tcd.ie

Newsgroups: comp.arch
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Subject: Are 64 Int or FP registers useful?
Summary: Maximum number of registers on-chip
Keywords: Chip Real State, Register Usage
Organization: Bergen Scientific Centre, Bergen, NORWAY
Date: Mon, 7 Sep 1992 09:19:04 GMT

   Can somebody provide me with comments or references to pros and cons of
having a large register set on-chip. Lets say 64 Int and 64 FP registers be it
32-bit or 64-bit.
   Specifically is there a study that shows how many registers typical
programs would like to have (i.e. unlimited registers as resources, like
the studies on unlimited number of execution units)?
   This is for a microprocessor.
-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	Izahi Engineering
izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-5)54-4653
Newsgroups: comp.arch