HDTenEightyP/NetNews huggingface dataset:
From: abraham@iesd.auc.dk (Per Abrahamsen)
Newsgroups: comp.arch
Subject: Re: Who will have the next killer micro?
Date: 1 Apr 92 03:29:57 GMT
	<1992Mar27.034314.926@morrow.stanford.edu>
	<SIROTT.92Mar27162258@chaos.atmos.washington.edu>
	<1992Mar28.205805.21075@morrow.stanford.edu>
Organization: HUGIN Expert A/S


>>>>> On 28 Mar 92 20:58:05 GMT, dow@nova2.stanford.edu (Keith Dow) said:

Keith> As I stated, everyone has plans to go multiprocessing.  Sun doesn't have
Keith> it as a luxury though.  They did a bad job with Viking and are going to
Keith> have to pay for it by going to multiprocessing sooner.

Keith> Sun violated a few common sense rules.

Keith> 3. Design and build a good chip the first time so you don't have to do
Keith>    again, i.e. Pinnacle.

I thought Sun wanted the CPU manufacturers competing among themselves
with many different designs and implementations.  Sun would then just
pick the best.

Keith> These rules were followed by HP, DEC, MIPS, IBM and Intel.  Why didn't
Keith> Sun follow them?

Because - unlike the others - Sun does not manufacture CPU's?
From: barroso@priam.usc.edu (Luiz Andre' Barroso)
Newsgroups: comp.arch
Subject: Any FTP Sites for DEC Alpha (ps) documents?
Date: 8 Apr 1992 14:41:05 -0700
Organization: University of Southern California, Los Angeles, CA
Distribution: usa
NNTP-Posting-Host: priam.usc.edu

Could anybody send me the ftp site where one can get DEC Alpha postscript
documents. I know that this has been posted already but I cannot find it 
among my files.


Thanks,

Luiz Barroso

Xref: sparky comp.arch:4807 comp.lang.lisp:1331
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 8 Apr 1992 04:24:38 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <MARKT.92Apr7131340@wundt.harlqn.co.uk> markt@harlqn.co.uk (Mark Tillotson) writes:
>And finally I would put a plea in for flexible addressing mode on
>RISCs, of the form:
>[Rb + Ri<<n + d]   Base register plus scaled index plus displacement (signed)
>The key point is that the scaling should be by a power of 2 that is
>specified in the instruction, (here n), NOT implied by the size of
>operand.  This means that you can represent integers with low-order
>zero tag bits and still use them directly to address vectors of bytes,
>words, or doubles...  Of course n is signed too, so the shift is
>either way!
>
>You might think a complex address mode isn't RISCish, but if it is the
>only mode, then it is RISC..  (After all it is a shame to waste the
>ALU during load/store instructions).

Wrong....  just because there's only one doesn't make it RISC.

This address mode (or at least [Rb + Ri<<datasize + d]) exists in
VAX, NSC 32K, 386 & up, 68020 & up.

[Rb + Ri + d] exists in IBM S/360 (i.e., RX-format) and Intel i960.

It's *not* in: AMD 29K, MIPS, SPARC, 88K, HP PA, POWER, i860, NSC Swordfish,
Clipper do not, although as a group, they support:
	[Rb], [Rb + d], [Rb + Ri], [Rb + Ri<<datasize], and various
	auto-modification versions of these things that show up in PA or POWER.

Here's a quiz: what is fundamentally *different* about 
	[Rb + Ri + d] or [Rb + Ri<<something + d]
compared to the addressing modes provided by the RISCs?
This addressing mode subsumes most of those found in RISCs (except the
auto-modification versions), so why didn't people do it?

A: the RISC addressing modes need at most an add of 2 inputs to create
the address, and (depending on the design) may well use the standard
ALU to generate the address.

The proposed addressing mode needs to add 3 distinct inputs, which probably
means back-to-back adds *before* the data address is available. There is
a good chance that this could be in the critical path for many pipelined
designs.
H&P note that from IBM S/360 data on [Rb + Ri + d], 85% of the time,
Ri was 0.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Newsgroups: comp.arch
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Cache hit percents
Organization: The Backbone Cabal
Date: Sat, 11 Apr 1992 16:53:38 GMT


I was thinking about caches and I was think about how bad the hit rate
would be for the very smallest cache.  Say you had an instruction
cache of only one line, (4 words, 4 bytes per word), what would the
hit rate be?

The way I figured it, the first instruction would be a cache miss, but
the next 3 would be cache hits because the entire cache line would be
fetched.  That would be a 75% cache hit rate.  Even if you add in the
misses from branches or starting in the middle of the cache line, you
would still probably have a 50% hit rate.  Of course, you probably
would call this an instruction prefetch queue instead of a cache, but
that's just a matter of naming.

A data cache of 1 line would probably not be very good at all, but it
too would go up very quickly if you had a mere 8-16 lines.

Does anyone have real numbers for these small caches?  Am I totally
off base in my reasoning?  I remember people laughing at the 68030's
256 byte data and instruction caches, but were they actually fairly
effective? 



-wayne
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: CISC vs RISC compilers (Re: whining about "marketing" (was Re: Does every ...))
Date: 14 Apr 92 23:57:33 GMT
Organization: Auspex Systems, Santa Clara

(Another damn over-restrictive distribution.  Really, are only North
Americans interested in this issue?  I think not, so I'm taking the
"Distribution: na" out, and leaving the context in, for the benefit of
non-North Americans seeing this for the first time....)

In article <id.BHWO.943@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Apr14.064325.7459@leland.Stanford.EDU> fangchin@leland.Stanford.EDU (Chin Fang) writes:
>> For some reasons, some CISC machines have very good compilation speed.  Like
>> NeXT (68040) compiles faster than SPARC 1+ on many occations.  
>
>I would guess that the compiler doesn't have to do quite as aggressive a job
>of optimisation to produce acceptably fast code.

Well, before I drew any conclusions whatsoever, I'd first like to hear
what compiler he used on the SS1+ - GCC, or the bundled Sun compiler, or
the unbundled Sun compiler.  I'd also like to hear what versions of the
compilers were used; I'll assume he used the same compiler options, so
that e.g. the same "optimization level" flag was used.

Then, I'd like to hear the SPEC benchmark numbers (there's an "s" at the
end of that last word, kids; the only single number I'd be interested in
would be the "gcc" number from the SPEC suite - either one, as I think
GCC is in both suites - I don't want SPECmarks) for *both* machines; the
SS1+ isn't exactly the top-of-the-line SPARCstation these days, so it
may just be that a 68040 NeXT (which, as I remember, *is* the top-of-the
line) is faster than an SS1+.
Newsgroups: comp.arch
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 6 Apr 92 09:37:57 GMT
Distribution: comp
Organization: Department of Computer Science, U of Copenhagen

r4ty@vax5.cit.cornell.edu writes:

>Here's a question that's been puzzling me for a while.  Why don't the latest 
>RISC processors (or any microprocessors) have conditional codes inbedded in
>every instruction?

The ARM (Advanced RISC Machines, formerly Acorn RISC Machine)
processors do this and have done so since 1986. Four bits in each
instruction are used for condition codes.

>-Very un-standard, never really been done on any high-volume marketed chip (As
>far as I know...)

The ARM processors are quite high volume. The reason you haven't heard
about them is that they are primarily an European product, and
American magazines tend to disregard anything un-American (except
Japanese ;-)

	Torben Mogensen (torbenm@diku.dk)
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Mon, 13 Apr 1992 14:49:11 GMT
Subject: Re: Re: Voice Recog. on Desktop
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch,comp.ai


Joshua Goodman finishes with:

   Andy also mentioned "pen computers."  This is an important point.
   Since the fastest you can legibly print is about 30 words per minute
   and Dragon already hits that rate and is getting better, and you can
   talk _much_ faster than 30 wpm, voice has a big long term advantage
   over pen.

I may not be good at drawing, but I'm even worse at *pronouncing* diagrams. Why
must we think of voice & pen as mutually exclusive?

[Also, what's this about "printing"? I'd expect pen systems to deal with
shorthands - user-definable, of course - in short order. The fact that people
would have to *learn* them doesn't seem too much of an obstacle, if it's done
right; there are lots of other things we have to learn anyway.]
--
Regards,    | ``Wandering minstrels are fogging my brain    | Judy Tzuke
Kers.       | And weird intellectuals are doing the same.'' | Higher & Higher
Xref: sparky comp.arch:5067 alt.folklore.computers:6472
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re:  chip-on-chip technology
From: geoff@satori.equinox.gen.nz (Geoff McCaughan)
Date: Wed, 15 Apr 92 21:14:23   M
Organization: The Equinox Network CHCH NZ (Node SATORI)

Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) writes:

> Yes hash is much better.  I prefer to use the word "pound" for the unit of 
> currency of Great Britain, and to refer to a now archaic system of weight 
> measurement, only used in backward parts of the planet.  (Should I have used 
                                                            ^^^^^^^^^^^^^^^^^^
> smiley?)
  ^^^^^^
No.

I write surveying/mapping software for a living. This would be an infinitely
simpler and more enjoyable task if certain backward parts of the planet
would wise up and realise this is the 20th century [soon to be 21st].

Grumble grumble.

| Geoff - Sysop Equinox (equinox.gen.nz) +64 (3) 3854406 (4 Lines)
| Email:  geoff@satori.equinox.gen.nz
|         "If I post something lucid, is that satorial eloquence?"
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: multiplies by constants
Organization: Intel Corp., Hillsboro, Oregon
	<1992Apr12.165128.878@rice.edu>
Date: Tue, 14 Apr 1992 21:45:59 GMT

    glew@pdx007.intel.com (Andy Glew) writes:
    >Many processor implementations have early outs for multiply and divide.
    >Theoretically a compiler could schedule for these when it knows the
    >constant value.

    Absolutely.  Actually, this (multiply by constant) is one of the
    things that can be done pretty well.  But we don't need special
    instructions; just use shift, add, and subtract.  If the chain costs
    more than the hardware multiply, then use the multiply instead.
    And there's always the hope of reusing partial products, though this
    may not occur much in real programs.

Actually, I was thinking more along the lines of not fully complete
multiplier arrays.

E.g. an implementation may provide a full 32x32->32 (or 32x32->64, or
64x64->64) array, pipelined one per clock, in which case the shift-add
sequence is unlikely to be any faster.

But an implementation may, e.g., have a 32x8->32 array (I believe that
one of the Berkeley RISC processors had this - SOAR perhaps?).

In which case:

    Multiplication by a constant in the range 0-255 => 1 cycles

    Multiplication by a constant in the range 255-64K-1 => 2 cycles

    Multiplication by a constant in the range 64K-16M-1 => 3 cycles

    Multiplication by a constant in the range 16M-4G => 4 cycles

(You may need to add more cycles depending on implementation)

Thus, even using the full multiply instruction, the compiler may
schedule for different latencies if it knows the range of one of the
constants.

Plus, there are interesting possibilities for optimizations that mix
multiplies and shift and adds (e.g. if the multiplier is pipelined
every other cycle).


    
    
--

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
Subject: Re: Who will have the next killer micro?
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Mon, 6 Apr 1992 22:09:22 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.


In article <1992Apr6.130911.22545@cis.uab.edu>, hyatt@cis.uab.edu (Robert Hyatt) writes:
      [...] previous quote omitted
|> I'm not sure where this is coming from or where it's heading.  However, to the
|> best of my limited knowledge the MHZ problem is REAL.  What works at 1Mhz 
|> DOES NOT work at 100Mhz due to a multitude of different RF-type problems.
|> Minimal capacitance between traces has little effect at 1Mhz, but massive
|> effect at 100-200Mhz.  Same for trace lengths.  I recall seing many of the
|> original Cray-1 modules that had lots of "zigzags" on them to equalize trace
|> lengths and/or effect delays where they were needed.
|> 
|> I can only assume that this is a serious problem based on what the Cray-3
|> guys have been fighting at 500Mhz.  Did I overlook something here?
      [...]

Apart from any rf & capacitance type problems what about the maximum useful
circiut length?  At 500MHz at the speed of light gives a wavelength of 600mm,
now I know electric signals go slower than this.  Therefore this would indicate
that the effective circuit size must be MUCH shorter.

This would seem to suggest that the high clock rate circuitry should all be on
the same chip, connected to a bus running at a lower clock rate.  Like Acorn did
with the ARM3.

Gavin



-- 
                     Tomorrow's Society
                         Depends on
                     Today's Children  - help us raise them properly!
******* These comments have no known correlation with dept. policy! *******
From: drake@drake.almaden.ibm.com (Sam Drake)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 14 Apr 92 00:21:08 GMT
Organization: IBM Almaden Research Center

In article <1992Apr10.214150.5525@cs.tu-berlin.de> tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes:
>are there or have there been microcoded microprocessors on which the
>microprogram could be changed during runtime thus changing the
>semantics of assembly-code??

Yes ... in school I used a Burroughs B1700 system that was programmed in
this way.  Each task in the operating system could run with different
MICROCODE loaded, so that for example the instruction set generated by the
FORTRAN compiler was different than the instruction set generated by the
Pascal or COBOL compilers.  Each language had both a compiler and a set
of microcode that realized that language's instruction set.  The operating
system would swap instruction sets with each process swap.

Naturally, our project on the machine was to design and implement an 
instruction set.  Involved writing lots of microcode onto audio casettes,
toggling in microcode boot loaders via paddle switches, and cursing.


Sam Drake / IBM Almaden Research Center 
Internet:  drake@almaden.ibm.com    BITNET:  DRAKE at ALMADEN
From: FULKERSON@Zeus.unomaha.edu (Robert Fulkerson)
Subject: Tagged Architectures.
Organization: Junior, Creighton University; Omaha, NE
Date: Wed, 8 Apr 1992 05:02:51 GMT
X-News-Reader: VMS NEWS 1.11

I am looking for information regarding tagged computer architectures (machines
that carry a tag field along with every instruction or data element indicating
what that word is -- data or instruction, if data that what _type_ of data,
etc.  Hardware code recognition, essentially.

I am writing a paper for my undergraduate Computer Architecture class based on
a 1973 paper by Fuestel.  I am curious as to whether or not tagged
architectures emerged into the 1980s or 1990s at all (most likely on mainframe
systems).  Essentially I'm looking for more current information to include in
my paper and presentation... ;->

Thanks in advance,
Bob Fulkerson, Frustrated Comp Sci Major

.--------------------------------------------------------------------------.
.            I'm a citizen in Legoland travelling incommunicado.           .
.                  Robert Fulkerson, Creighton University                  .
.       rfulk@parrot.creighton.edu  (or)  fulkerson@zeus.unomaha.edu       .
.--------------------------------------------------------------------------.
Newsgroups: comp.arch,comp.ai
From: lee@uhunix.uhcc.Hawaii.Edu (Greg Lee)
Subject: Re: Voice Recog. on Desktop
Organization: University of Hawaii
Date: Wed, 15 Apr 1992 20:21:58 GMT

In article <1992Apr15.015106.18722@ichips.intel.com> markg@pdx077 (Mark Gonzales) writes:
}In article <1992Apr15.004813.24392@nas.nasa.gov> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
}>...
}>I have yet to find a machine which can get pass the first test:
}>	How to recognize speech.     [1]
}>	How to wreck a nice beach.   [2]
}>
}
}This is a rather unfair test, most humans would have trouble
}distinguishing [1] from [2], especially without any conversational
}context.  ...

Oh, I don't think most human English speakers would have trouble, if
the test sentences are said right.  The sound segments can be practically
identical, since many would devoice the z of recognize to s and omit
the g, and also devoice the b of beach to p.  But the timing is
different.  "to recognize" in [1] is an intonational phrase comparable
to "to wreck" in [2]; "speech" in [1] is an intonational phrase
comparable to "a nice beach" in [2].

--
Greg Lee <lee@uhunix.uhcc.hawaii.edu>
Xref: sparky comp.arch:4768 comp.lang.lisp:1313
From: ted@aps1.spa.umn.edu (Ted Stockwell)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 13 Apr 92 16:18:40 GMT
Article-I.D.: lynx.TED.92Apr13101840
	<GLEW.92Apr9215050@pdx007.intel.com> <1992Apr10.152204.1544@sctc.com>
	<GLEW.92Apr11194245@pdx007.intel.com>
Organization: Univ. of Minnesota Astronomy Dept., APS Lab


In article <GLEW.92Apr11194245@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
>    In-Reply-To: smith@sctc.com's message of 10 Apr 92 15:22:04 GMT
>        In an earlier post I underlined the word pattern matching as the big
>        problem. Are _all_ 30,000 word patterns available at all times? 
> 
>    I believe that all patterns were "matchable" at the same time, but it
>    is possible that some paging may occur. Still, 6MB seems an entirely
>    reasonable number. They did have large caches.
> 
>    The searching is, of course, not exhaustive.

DragonDictate has an active vocabulary of 30000 words, selected from a
dictionary of 80000 on disk.  You can also train new words if they don't
exist in the dictionary.   The PC must have at least 8 megabytes.

>        Does it take special hardware to manage these 30,000 words?  

386 based PC  + memory + Dragon's DSP board

>        >Usable = speaker adaptive (little need for explicit, exhausting,
>        >    training; adapts to the speaker as it goes), discrete speech
>        >    (slight pause between every word, but not enough to be really
>        >    annoying), large vocabulary (30,000 words) voice typewriting.
> 
>        Discrete speech means - that - you - talk - like - a - computer - when
>        - talking - to - a - computer. That's slower than the way real people
>        talk, so it doesn't compete with normal dictation. 

You just talk with  extremely good diction,  the pause is quite short; mine
is set to 0.16 seconds.

>        There are a whole bunch of other issues, too, concerning errors and how it "adapts to
>        the speaker" without doing anything damaging.
> 
>    Once again, they seemed to have error handling down pretty well - you
>    say "oops", and the software displays a menu of "sound alike" words.

It works very well in practice.

--
Ted Stockwell                                     U of MN, Dept. of Astronomy
ted@aps1.spa.umn.edu                          Automated Plate Scanner Project
Newsgroups: comp.arch
From: jedwards@ms.uky.edu (Jonathan Edwards)
Subject: Magnetic bubbles
Date: Thu, 16 Apr 1992 13:09:17 GMT
Organization: University Of Kentucky, Dept. of Math Sciences
X-Bytes: 

I'm doing a paper on magnetic bubbles and I could use some help with
information on why they failed to fulfill their early promise (i.e.,
why do we use hard drives rather than large bubble memories for
mass storage)?  I *thought* it was due to access times, but some of
the papers I've read indicate that sub-millisecond access times had
been demonstrated in the mid 1970s.  So it must have been something
else (density?  price/bit?)  Any pointers appreciated...
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Ideas for new LISP Machines
Organization: Rice University, Houston
Date: Thu, 9 Apr 1992 05:28:37 GMT

>what is fundamentally *different* about 
>	[Rb + Ri<<something + d]
>compared to the addressing modes provided by the RISCs?

An alternative set of answers:

	Have to specify 3 registers and 2 immediate fields.

	Can synthesize it quickly out of simpler instructions.
	The extra instructions sometimes go away with optimization.

	Strength reduction makes the shift unnecessary in many
	important cases (e.g., inside loops).

	Most people would rather have extra bits for d.

Further, I claim it's CISC-like in that the complex addressing mode
specifies a relatively deep expression tree and the whole instruction
yields a single result.  Compare this with auto-increment addressing,
which specifies a pair of _shallow_ trees yielding two results.  Or
the various VLIW processors, which can specify many shallow expression
trees, each producing a useful result.

The only reason people get away with staged multiply-accumulate
instructions is because they are pipelined and the instructions are
too short to specify the more flexible 6-input instruction;
that is, <a=b+c; d=e+f>.

Preston Briggs
Newsgroups: comp.arch
From: frazier@oahu.cs.ucla.edu (Greg Frazier)
Subject: Re: hardware support for Fine-grained comp.
Organization: UCLA, Computer Science Department
Date: Wed, 15 Apr 92 17:55:10 GMT

yariva@GEMINI.MATH.TAU.AC.IL (Aridor Yariv) writes:

>I am working on a parallel language which combines functional and object 
>oriented subsets. In general the implementation is based on light-weight tasks
>which as usual, causes overhead (in every processor) due to their
>allocation/scheduling/context-switch.

>I am looking for references on SPECIAL HARDWARE FEATURES which helps to
>overcome this local overhead like : 

>1. co-processors/hardware which prepare (IN PARALLEL) the next task(process)
> in the 
>   queue for work (Make ready the relevant data in registers). 

*T: A Multithreaded Massively Parallel Architecture,
	Nikhil, Papadopoulos, Arvind

I have a tech report handed out at a workshop on multithreaded
architectures at Supercomputing '91.  The nodes of the *T
computer consist of 2 processors - one to execute sequential
code, the other to parse incoming messages and, if necessary,
to queue them up as processes to be executed by the first
processor - very similar to what you are talking about.

You can also look at some of the stuff Dally has written
wrt the J-Machine - he's interested in supporting fast
context switches to handle funcitonal and object-oriented
computing.  He is also working on "named state" (he is
doing this with Peter Nuth - "Named State and Efficient
Context Switching"), which might be relevent to what you
are doing.

*Lots* of people are interested in multi-threading, pre-fetching
of data, etc.  This may or may not appeal to you as a
potential solution for what you are looking at.  Culler at
Berkeley, the DASH project at Stanford, *T/Alewife, the
J-Machine, Teradata, etc.

-- 


Greg Frazier	frazier@CS.UCLA.EDU	!{ucbvax,rutgers}!ucla-cs!frazier
Newsgroups: comp.arch