HDTenEightyP/NetNews huggingface dataset:
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: trapping speculative ops
Organization: Massachusetts Institute of Technology
Date: Fri, 28 Aug 1992 01:38:46 GMT


If the objective is to avoid branches, why not use a method for which
precedent exists: add conditional operations to the architecture like HP and
DEC have done.  For memory, add non-trapping cache prefetch instructions as
well as conditional loads and stores.

A trap flag on each register is an interesting idea, but I think a greater
performance increase can come from conditional operations.  The hardware
implementation may choose to use something like a trap flag, especially if
it executes out of order, but making this invisible and implementation-
dependent makes the hardware and software simpler.

--
    John Carr (jfc@athena.mit.edu)
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: No progress in parallelism? (was: History)
Date: 27 Aug 92 12:47:18 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 26 Aug 92 15:30:25 GMT, smith@sctc.com (Rick Smith) said:

smith> I think the future of computer architectures is in various forms
smith> of parallelism not addressed by the von Neumann tradition.

smith> And pcg@aber.ac.uk (Piercarlo Grandi) replied:

pcg> Pious hope, I am afraid. Research in this field has been going on
pcg> forever, and without much progress. Architectures here seem wedded
pcg> to particular application shapes, and almost all variations have
pcg> been tried out, and only a few have been found cost effective. But
pcg> some particular application shapes are so important...

smith> It should be clear from von Neumann's writings that
smith> multiprocessing was never part of his model. However, I think it
smith> is fair to say that the cost effectiveness of multiprocessor
smith> configurations has been well established.

Since at least the early sixties (and there were sort-of multiprocessors
in the fifties), in some important application areas. And closely
coupled multiprocessors are in the Von Neumann tradition, even if the
man himself did not write about them.  After all multiprocessing is not
an architectural issue, it is an implementation issue. The architecture
of a Von Neumann style multiprocessor is not in any way different from
that of a Von Neumann uniprocessor.

The interesting aspects of parallelism rather lie in large scale
parallelism, which is something that requires architectures not in the
Von Neumann tradition, and as to that the cost effectiveness has been
domonstrated only in fairly narrow, if important, application domains.

Such fairly narrow domains however are going to become fairly common, as
multimedia and virtual reality percolate to the masses.

smith> I think it's also fair to say that many of the "big issues" these
smith> days (cache management comes immediately to mind) are driven by
smith> parallelism problems.

Again, nothing new. Many such issues have existed forever, even before
caches. I am thinking of the GE 600 series system controllers, for
example. Yes, there has been some progress, more interesting algorithms.
Hardly anything new under the sun for computer architecture, and even
for computer engineering.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Multi threaded CPUs
Summary: Where can I find out more about them?
Organization: Pix Technologies -- The company with no adult supervision
Date: Wed, 2 Sep 1992 01:57:35 GMT

A little while ago I read about a RISC CPU (SPARC I think) that some
researchers had designed.  It had a cache of threads (I got the impresion
that that includes registers, and posabble MMU state as well), four in
the current chip, and when there was a pipe stall the execution would just
switch to another thread.

Unfortinutally the EE Design mag I read this in didn't say where to find out 
more, does anyone know anything about this?
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
From: cliffc@rice.edu (Cliff Click)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops
Date: 26 Aug 92 14:41:59 GMT
	<1992Aug12.155317.27437@bcars64a.bnr.ca>
	<l8j0qkINNikb@exodus.Eng.Sun.COM> <BtEzrK.Jso.2@cs.cmu.edu>
	<GLEW.92Aug25180333@pdx007.intel.com>
Organization: Center for Research on Parallel Computations

In article <GLEW.92Aug25180333@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>      ...what about traps while executing speculatively?
>      1) Let the hardware do all the speculative execution. This puts it on
>      the hardware's head to not trap until it knows it really should have.
>      2) Allow compiled code a way to postpone consequences until it
>      wants to know. 
>      -- 
>      Don		D.C.Lindsay 	Carnegie Mellon Computer Science
>  Andy Glew, glew@ichips.intel.com

Yes to (2)!

Let every register have some extra "trap" bits.
A read of the register with it's trap bits set, causes the exception.
A write to the register sets the trap bits according to the success of
the operation.

With this design, exceptions are triggered at the START of some operation,
instead of in the middle of it.

Pre-fetch for long-distance memory can be implemented with a simple LOAD.  
If a page fault is required for the LOAD the fault is delayed until the 
register is used.  If the pre-fetch is speculative, no page fault occurs.

Do you have a division with a zero-denominator guard test?  Schedule the 
division as early as you like, and don't read the result register if the
guard fails.

If you require precise interupts, arrange to use the results of every
possibly-faulting operation before a second control path merges with
your current control path.  Then the trap handler can back up the 
instruction stream until it finds the instruction which wrote to the
faulting register.  This gives precise interupts, but still allows some
scheduling.

Cliff
cliffc@cs.rice.edu
--
The Sparc ABI has the most brain-damaged calling convention I've ever seen.
Cliff Click (cliffc@cs.rice.edu)  |  Disclaimer:  My lawyer made me say it.
Newsgroups: comp.arch
From: alvitar@xavax.com (Phillip Harbison)
Subject: A reminder about posting to comp.arch (last mod 06/14/90)
Reply-To: alvitar@xavax.com (Phil Harbison)
Organization: Xavax
Date: Tue, 1 Sep 1992 07:00:05 GMT
Followup-To: poster
Summary: Stop, Think, Observe, Plan
Keywords: Netiquette

This article is posted monthly in the hope that it will encourage
proper use of comp.arch.  Your cooperation will help improve the
signal to noise ratio of comp.arch, making the newsgroup more
valuable to readers.

1) Consider using mail instead of posting a followup article.  If
   your response is of limited interest to anyone other than the
   author, then please use mail instead of posting a followup.  A
   mail message goes to a small number of machines, while an
   article consumes communication and storage resources at
   thousands of sites.

2) Exhaust local sources of information before posting a question
   to comp.arch.  It makes little sense to waste the communication
   and storage resources of thousands of sites, not to mention the
   time of thousands of comp.arch readers, when the answer to your
   question may be as close as your bookshelf.  Do read the manual.

3) If you raise new topics, make sure the subject corresponds to your
   comments.  However, do not needlessly change or amend the subject
   line, as some news readers allow a user to skip an entire thread
   based on the subject line.

4) Consider limiting the distribution of your article.  Announcements
   such as user group meetings may be of interest only to a limited
   geographic area.  Check with your local news administrator to see
   what regional or local distributions are available.

5) Quoting portions of the base article is encouraged.  It helps the
   reader to understand the context of your comments, especially if
   the reader has not read the base article.  However, you should
   include only as much of the base article as is necessary to convey
   the context of your comments.  Use an editor to remove unnecessary
   portions of the base article.

6) Make sure your article is related to computer architecture.

7) Computer nostalgia has a place on the net, but that place is not
   comp.arch.  If you are discussing architectural features of past
   generations of computers, then comp.arch is appropriate.  However,
   the prescribed place for computer nostalgia is alt.folklore.computers.

8) Sale advertisements and product announcements are not appropriate
   for comp.arch.  There are specific groups for these purposes.  Try
   misc.forsale, misc.forsale.computers, and comp.newprod.  Also, keep
   in mind that news articles are distributed by various services which
   forbid use for personal gain.  Sites which use these services often
   selected newsgroups such as comp.arch assuming a high information
   content and no personal gain use.  Please do not make their life
   more difficult by posting advertisements and product announcements.

-- 
*realName: Phil Harbison
*mailAddress: Xavax, PO Box 125, Shokan, NY 12481
*eMailAddress: alvitar@xavax.com
*phoneList: <home>: 914-657-8645  <work>: 914-385-2881
From: YOUNG@tattoo.cs.widener.edu (Rob Young)
Newsgroups: comp.arch
Subject: Hudson vs Pasadena (Was Re: ALPHA : Single Transistor Clocking)
Date: 3 Sep 1992 04:29:35 GMT
Organization: Widener University Department of Computer Science, Chester PA
Distribution: world
NNTP-Posting-Host: tattoo.cs.widener.edu
X-News-Reader: VMS NEWS 1.20


In article <1992Sep3.004732.15291@rkna50.riken.go.jp> wong@rkna50.riken.go.jp (Wong Weng Fai) writes:
   >>According to what I know, right dead center of the
   >>ALPHA chip is a single, huge transistor that is used
   >>for clock distribution. 
   >>What are the advantages and disadvantages ?
   >>Is it the way to go for distribution of high
   >>frequency clocks ?

In <MJOHNSON.92Sep2185309@netcom.Netcom.COM> mjohnson@netcom.Netcom.COM writes:

 ....

> 
> "Is this the way to go?" --- depends on who you ask
> and what research or design community they represent.
>     If you ask the question in Hudson, MA ...... "yes"
>     If you ask the question in Pasadena, CA .... "no"
> 

Maybe others view this as a matter of opinion also.  But consider that
DEC is talking (yes talking, if they are blowing smoke. . . ) about an Alpha 
"PC" rated above 70 Specmark.  Likewise, high numbers for workstations and
"minis".  Arguably not everyone is ready to pay 6-7 thousand for a PC so they
have a 50 Spec machine in the pipeline for $3,500 according to the rags.  A
redefinition of what is a PC, i.e.  "your workstation is a PC".  The Mountain
may be scalable in Mountain View but it doesn't look like the architecture 
is.  ;-) 

				Rob


                                                     young@tattoo.cs.widener.edu
"Any escape might help to smooth the unattractive truth but the suburbs have 
 no charm to soothe the restless dreams of youth."   -- Neil Peart"
From: dong@milton.u.washington.edu (Dong-Lok Kim)
Newsgroups: comp.arch
Subject: Re: Computer Architecture Rationale
Date: 29 Aug 92 04:49:00 GMT
Article-I.D.: u.1992Aug29.044900.19852
Organization: University of Washington, Seattle

>>I once made the mistake of giving my manager a copy of the
>>architecture description with the rationale visible as struck out
>>text, clearly indicated as such. The rationale described some of the
>>rejected alternatives, and the reasoning --- but it also clearly
>>stated what was planned, in the form of a specification. Status report
>>said "Architecture description more a collection of alternatives than
>>a plan".  Right away I gave him a copy of the same spec, with the
>>rationale conditional text turned off (invisible). Next status report
>>said "Architecture description much improved."

>>Moral: no matter how clearly you try to separate rationale from
>>decision, some people will get confused.
--

>>Andy Glew, glew@ichips.intel.com

I agree on Andy. The rationale gives more confusion..

Sometimes we get involved in a project where some specification or 
methodology is alredy given by political reasons. For example, you need to use
i860 because your company or school is funded by Intel. We usually have
to include some white lies (?) in the rationale even though we clearly see
some critical limits of i860(for example) for your target appliation. Or you 
don't have much time to look around other processors to give another rationale 
to replace i860.  It is painful in either case.

Dong-Lok Kim

-- 
ICSL (Image Computing System Lab)
Dept. of Electrical Eng., FT-10
University of Washington
Seattle, WA 98195
Newsgroups: comp.arch
From: XB.UVC@forsythe.stanford.edu (Judith Lemon)
Subject: Computer Architecture Videos
Organization: Stanford University, California, USA
Distribution: net
Date: Wed, 2 Sep 1992 02:30:02 GMT

[Apologies if you see this twice]

UVC would like to know if the comp.arch community
would like us to post information on our computer
architecture videotpaes.

University Video Communications offers 50-minute videotapes
by major architects on RISC, large scale parallelism,
multiprocessors, and supercomputers at modest cost.

Abstracts and ordering information available on request.


Dr. J.L. Lemon
President
uvc.lemon@forsythe.stanford.edu
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: trapping speculative ops
Organization: Intel Corp., Hillsboro, Oregon
	<l8j0qkINNikb@exodus.Eng.Sun.COM> <BtEzrK.Jso.2@cs.cmu.edu>
Date: Wed, 26 Aug 1992 02:03:33 GMT


    But this is just a specific optimization. The broader question is,
    waht about traps while executing speculatively? There seem to be two
    answers:

    1) Let the hardware do all the speculative execution. This puts it on
    the hardware's head to not trap until it knows it really should have.

    2) Allow compiled code a way to postpone consequences until it
    wants to know. This covers e.g.

	    if( b != 0 ) c = a/b;

    and an assortment of other cases.

    The problem with (1) is that it makes for complex hardware. The
    problem with (2) is that instruction sets are generally not set
    up to allow such leeway.
    -- 
    Don		D.C.Lindsay 	Carnegie Mellon Computer Science


Wen-mei Hwu's IMPACT group at the University of Illinois has been
publishing a sequence of papers exploring instruction set architecture
support for 2).


--

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)
Newsgroups: comp.arch
From: grunwald@foobar.cs.colorado.edu (Dirk Grunwald)
Subject: Re: Multi threaded CPUs
Reply-To: grunwald@foobar.cs.colorado.edu
Organization: University of Colorado at Boulder
	<1992Sep3.143341.11285@bcars64a.bnr.ca>
Date: Fri, 4 Sep 1992 02:17:45 GMT

>>>>> On Thu, 3 Sep 1992 14:33:41 GMT, schow@bqneh23.bnr.ca (Stanley T.H. Chow) said:
STC> Interesting. I had no idea that Motorola had any multi-threaded
STC> CPU. I understood that another company (who dominates the PC market,
STC> but will remain nameless :-) actually have at least one CPU for sale
STC> with multithreading used internally but not visible to the
STC> customer.
--

This would be difficult, I would think. Harry Jordan at Univ. Colorado
told me he's had students build multithreaded micro cores as class
projects. It's not difficult, and effectively hides memory latency.
The question is, when will this become commercially viable?

I think the answer rhymes with ``when will offchip memory delays be
more than 25 cycles''.

Dirk Grunwald                          Asst. Prof, Univ. of Colorado at Boulder
Newsgroups: comp.arch
From: schow@bqneh23.bnr.ca (Stanley T.H. Chow)
Subject: Re: Multi threaded CPUs
Organization: Bell Northern Research Ltd, Ottawa
Date: Thu, 3 Sep 1992 14:33:41 GMT

In article <Sep02.141909.45739@yuma.ACNS.ColoState.EDU> rro@cs.ColoState.EDU writes:
>Apropos this subject, there will be a minisymposium on Multithreaded
>Computer Systems at the Supercomputing Conference this November in
>Minneapolis.  Greg Papadopoulos, MIT,  will cover architecture, Wim
>Bohm, Colorado State, will discuss software, and Tony Dahbura,
>Motorola, will give an industrial perspective.

Interesting. I had no idea that Motorola had any multi-threaded
CPU. I understood that another company (who dominates the PC market,
but will remain nameless :-) actually have at least one CPU for sale
with multithreading used internally but not visible to the
customer.

--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
Newsgroups: comp.arch
From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
Subject: Re: trapping speculative ops
Organization: Bell Northern Research Ltd, Ottawa
Date: Thu, 27 Aug 1992 00:53:40 GMT

In article <CLIFFC.92Aug26084159@medea.rice.edu> cliffc@rice.edu (Cliff Click) writes:
>Let every register have some extra "trap" bits.
>A read of the register with it's trap bits set, causes the exception.
>A write to the register sets the trap bits according to the success of
>the operation.
>
>With this design, exceptions are triggered at the START of some operation,
>instead of in the middle of it.

Very nice model, but what to do about saving and restoring registers
across subroutine call, interupts, etc.?

>Pre-fetch for long-distance memory can be implemented with a simple LOAD.  
>If a page fault is required for the LOAD the fault is delayed until the 
>register is used.  If the pre-fetch is speculative, no page fault occurs.

Presumably, the prefetch will use a different opcode, or do you mean all
references should behave like this?



--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
Newsgroups: comp.arch
From: ligon@eng.clemson.edu (Walt Ligon)
Subject: Re: Scientists as Programmers (was Re: Sma
Reply-To: ligon@eng.clemson.edu
Organization: College of Engineering, Clemson Univ.
Date: Wed, 2 Sep 1992 18:38:33 GMT

In article 24957@newsroom.bsc.no, izahi@bsc.no (Raul Izahi Lopez Hernandez) writes:
>In article <1992Sep1.173636.6387@nntpd.lkg.dec.com> edp@math.zko.dec.com (Eric Postpischil) writes:
>
>   A good compiler and a good optimizer can help any scientist to write
>reasonable code, however there is no software yet that can help a CS
>person write any physics code.
>
>-- 
>         -----> 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

Clearly you speak from a position of little understanding or experience.  I have seen
much "code" written by "scientists" and "engineers" that no compiler or optimizer in
the world could fix, and very few souls would be willing to dive into.  Usually they
were written by smart-asses like you, and then left for some other poor slob to try
and pick up to solve their own problem.

On the other hand, I have always been able to improve the implementation in some way
or other, sometimes with great results.  I have also found that, given an adequate
specification, I can impelment darn good code for mathematical systems whose meaning
and purpose I do not (and do not wish to) understand.

Now, a computer scientist is not a physicist (or chemist or whatever) any more than
a physicist is a computer scientist.  A "scientist" can be just as difficult to
communicate with as a computer scientist.  In my experience, the trouble most CS guys
have are scientists who expect the rest of the world to understand their problem, and
thus do not provide an adequate specification.  OK, the tables can just as easily be
turned.

Next to last point: not all CS guys specialize in scientific codes.  To assume that
they SHOULD is goddamn'd arrogant!  Do all EE's specialize in controls?  Do all
physicists specialize in optics?  Give me a break!

Last point:  every jerk that walks out of a CS department with a BS is NOT a computer
scientist in the true sense of the word.  To just blindly go out and hire a green
CS grad, regardless of his background, and throw him an your favorite numberical
problem and say solve it, and then complain about the result is asinine.

You are propagating a myth that is clearly obsolete, and born of misunderstanding,
arrogance, intolerance, and fear.  Times are fast approaching when your old approach
will nolonger be adequate, and you'll find yourself using techniques developed by
computer scientists.  As always, you will refuse to admit it when that time has come.

Beyond that, it is unclear to me that this thread has any more relevence.

Thpppppt!

Walt