HDTenEightyP/NetNews huggingface dataset:
From: limes@straylight.Eng.Sun.COM (Greg Limes)
Newsgroups: comp.arch
Subject: Re: Voice Recog. on Desktop
Date: 10 Apr 92 00:53:10 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: straylight

In article <1992Apr09.135834.15056@eng.umd.edu> sysmgr@king.eng.umd.edu writes:
>How many years before speech recognition is a stock "feature" and bundled/wired
>into the OS? 

>Speech recognitizion solutions do exist today, but they're not "mainstream" and
>cost much bucks, when compared to the cost of a PC....

Limited speech recognition is available for the PC for well under
two hundred bucks. Keyword recognition, and only sixteen active
templates at a time, but it works ... call Covox for info, or
drop by your local Hacker Heaven.

Why can't we do this on our workstations? The audio is there, the
processing power is there ...
Xref: sparky comp.arch:5053 comp.ai:2008
From: kehler@endor.uucp (Andy Kehler)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 17:59:43 GMT
Article-I.D.: das.1992Apr15.175943.27200
Organization: Aiken Computation Lab, Harvard University

In article <1992Apr15.150519.5356@sctc.com> smith@sctc.com (Rick Smith) writes:
>> 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]
>
>And markg@pdx077 (Mark Gonzales) replies:
>
>>This is a rather unfair test, most humans would have trouble
>>distinguishing [1] from [2], especially without any conversational
>>context.
>
>Not so. Even the best speech recognition systems today
>can't distinguish between the two when spoken at a normal
>rate of speech, even when seen _in_ context.
>

This may be so, but so what?  Practically speaking, how often are we
going to encounter such an intense ambiguity?  I agree that generic
speech applications will have to account for context; speech
understanding (and full-blown general recognition does require
understanding) has all of the problems of textual NLP and more.  But
that does not entail that suitable applications don't exist, or that
we should trash systems on the basis of the beach/speech example.

>My original post (in comp.arch, for those that remember) stated the
>opinion that general purpose speech recognition isn't going to
>be a turnkey application any time soon. Miya's example illustrates
>it perfectly. Speech recognition is too knowledge intensive and
>it rapidly becomes dependent on techniques that won't be able to
>to solve the problem in real time. 

I agree with most of this, except about Miya's well-known example.
Miya describes this as the "first test", but it should be the last
test.  There are many more realistic examples of deficiencies with
speech recognition systems, ones that can be used as points of
comparison between different systems for different applications.  Use
of examples like the beach/speech one are inappropriate and
short-sighted.  As with other software, 80% solutions may yield useful
products.

>
>Speech recognition can and will be used in applications with
>severely restricted discourse, like single-word commands over
>phone lines to answering machines, telemarketers, and such.
>That's really different from a general purpose dictation system.

Sure, but there is a large spectrum between single-word systems and
full-blown, generic speech recognition.  How far along that spectrum
we can get is the issue.


 -- Andy
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Mon, 13 Apr 1992 15:36:47 GMT
Subject: Re: Condition Codes and RISC arch.
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch


Linley Gwennap writes:

   (Dale Morris) posts:
   > 
   >   if(a==b)
   >     c--;
   >   else 
   >     d+=10;
   > 
   > could be coded in PA instructions without any branches, as follows:
   > (for clarity, let me assume that a,b,c, and d are already in registers
   > 1,2,3, and 4)
   >	
   > 	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
   > 	addi	-1,r3,r3	; c <- c-1
   > 	sub,=	r1,r2,r0	; compare a and b, nullify next if equal
   > 	addi	10,r4,r4	; d <- d+10
   ----------

   Actually, the example can be coded in three instructions:

   sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
   addi,tr	-1,r3,r3	; c <- c-1, always nullify next instruction
   addi	10,r4,r4	; d <- d+10

The ARM also manages it in three instructions: with the same assumptions
(variables in registers)

    teq Ra, Rb
    subeq Rc, #1
    addne Rd, #10
    
The ARM solution is aplicable even if the THEN & ELSE branches compile to
several instructions, including procedure calls, although (of course) once you
have a lot in there it would be cheaper to branch.
--
Regards,    | ``Wandering minstrels are fogging my brain    | Judy Tzuke
Kers.       | And weird intellectuals are doing the same.'' | Higher & Higher
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 14 Apr 92 07:30:30 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

>>(Dale Morris) posts:

>>>   if(a==b)
>>>     c--;
>>>   else 
>>>     d+=10;

>linley@hpcuhe.cup.hp.com (Linley Gwennap) writes:
>>Actually, the example can be coded in three instructions:

>> 	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
>> 	addi,tr	-1,r3,r3	; c <- c-1, always nullify next instruction
>> 	addi	10,r4,r4	; d <- d+10

>>If a<>b, the first instruction nullifies
>>the second and executes the third.  If a==b, the second instruction is
>>executed, which nullifies the third.  Three cycles, no branches.

preston@dawn.cs.rice.edu (Preston Briggs) writes:
>Can the compiler find either of these solutions from the source code?

I can't say for sure about whether the HP compiler finds that or not,
but it's not very hard.  At the assembly language level, all you're
looking for is a block with two successors that are both single-entry
and single-exit with a common successor.  Furthermore, the condition
on the first block is a compare for equality, and the other two blocks
contain just one instruction-equivalent.

That sounds nasty, but the technique is pretty straightforward.

Another trick is to read Peter Damron's thesis (I think this sort of
thing is discussed in there) and perform pattern-matching on the PDG.
That is certainly cleaner in its specification, and will probably not
shorten your life as much as writing all that peephole crap by hand.
Pattern matching code generation is an enormous win.

David Chase
Sun
Newsgroups: comp.arch,alt.folklore.computers
From: peter@ferranti.com (Peter da Silva)
Subject: Slow linkers
Organization: Xenix Support, FICC
Distribution: na,comp
Date: Fri, 17 Apr 1992 14:31:24 GMT

In article <1992Apr15.175241.11746@vax5.cit.cornell.edu> umh@vax5.cit.cornell.edu writes:
> 2) It has nothing to do with optimization and is largely due to slow 
> linking. Linking on most UNIX systems is pathetically slow.

I take it you've never run TKB on RSX/11M. Now *that* was pathetically slow.
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
Xref: sparky comp.arch:5024 comp.ai:1995
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 1992 00:40:19 GMT
Organization: University of California, Berkeley
Distribution: world
NNTP-Posting-Host: forney.berkeley.edu

In article <GLEW.92Apr14153132@pdx007.intel.com>, glew@pdx007.intel.com (Andy Glew) writes:
|> Give me voice for entering mass quantities of text.

Really?  I type almost as fast as I talk and I don't have to worry about
the ums, ers, and changes of mind.  I don't think that voice is a reasonable
way to enter mass quantities of text except maybe to use a telephone when
you're away from your machine.  Speech is a low-bandwidth way of communicating
lots of text.



-- 
Joe Buck	jbuck@ohm.berkeley.edu
From: robin@lsl.co.uk (Robin Fairbairns)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 15 Apr 92 11:41:36 GMT
Distribution: comp
Organization: Laser-Scan Ltd., Cambridge

In article <1992Apr14.153512.17427@cl.cam.ac.uk>, cet1@cl.cam.ac.uk (C.E. Thompson) writes:
> In article <1992Apr6.093746.1574@lsl.co.uk>, robin@lsl.co.uk
> (Robin Fairbairns) writes:
>>[about ARM doing conditional execution] 
>> Which is perfectly right: ARM architecture comes from Cambridge, where
>> _everyone_ (of a certain age - like me ;-) is influenced by the
>> Titan(Atlas) architecture. 
>> 
>> ... Which was fundamentally RISC before all of today's hype, and which 
>> did indeed have this sort of operation.
> 
> The Titan(Atlas) architecture had one or two RISC-like features, but it
> was most certainly not `fundamentally RISC', imho.

I hesitate to contradict even the `ho' of such an eminent person, but I 
keep learning things about current RISC machines that put me in mind of 
Titan (which was the first architecture I ever understood).

... Small (basic) instruction set, capable of executing 1 inst/cycle (if
the slave[=cache] store was working that day), separate FPU with
imprecise exceptions, extracode mechanism (=PALcode) to do things that 
required synchronisation between processes (there were only ever 3 
processors and they were in 3 different places ;-)...

It's not exactly "accurate" but it's not a bad characterisation.

> As regards conditional instructions: the conditional branch was just
> a conditional instruction in which the target register (Ba) was the
> instruction counter (B127 in main control). For any condition and value
> that you could branch to, you could conditionally set the value into
> any B-register. This was useful, but it is very far from the `all
> instructions can be done conditionally' state of the ARM. You couldn't
> do accumulator operations conditionally, for example.
     ^^^^^^^^^^^ = FPU (for those who don't speak the lingo)

I should hope that the ARM _does_ implement some improvements on the 
architecture of a machine that was switched on in 1963    :-) :-)
-- 
Robin Fairbairns, Senior Consultant, postmaster and general dogsbody
Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK
Email: robin@lsl.co.uk  --or--  rf@cl.cam.ac.uk
From: mslater@mpr.com (Michael Slater)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: Wed, 8 Apr 92 09:45:07 PST
Organization: Microprocessor Report
Reply-To: mslater@mpr.com (Michael Slater)
X-Mailer: uAccess - Macintosh Release: 1.5v4

In article <mch.702626673@regent.e-technik.tu-muenchen.de> (comp.arch), mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann) writes:
> hyatt@cis.uab.edu (Robert Hyatt) writes:
> 
> >In article <mch.702540303@regent.e-technik.tu-muenchen.de> mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann) writes:
> >>
> >>Has ANYONE a 386sx-board with a socket for the processor??
> >> ....
> 
> >all the 386sx machines I have seen have a socket (that is probably not the
> 
> Yes, but is this socket holding the processor or is it for the FPU?
> 
As far as I know, the vast majority of 386SX processors are soldered.
> 
> However I'd like to get some more info about the Cyrix 486.
> 
> a) Why is it called 486 if it does have some severe constraints
>    like much smaller cache and also slower core?

It does implement the additional instructions in the 486, and it has
a 486-class core (except that it lacks a dedicated address adder).
As other posters have pointed out, there is a lot of marketing value
in being a low-cost 486, instead of a high-end 386.
> 
> b) How does the cache cope with external busmasters as DMA
>    (which may invalidate the contents of the internal cache)
>    if the processors has the pinout of a 386sx? 
>    I think you would need either additional pins or some new
>    type of bus-transaction for an external invalidate request.
>    Both should destroy compatibility with existing designs.
> 
There are additional signals (using pins that are "no connect
on the 386SX), and there are also software hooks to allow
systems to run without using the additional signals. It does
NOT support snooping. The cache can optionally be flushed
whenever a DMA write occurs; in a notebook PC, which is the
primary target for this chip, DMA writes are used only for
floppy disk access, so this is not a big issue.  There are also
programmable non-cacheable regions, so the disk buffer areas
can simply be marked as non-cacheable. Cyrix expects most users
to add the additional traces to support the cache control pins,
but you can use the part just by setting up the software
controls properly for non-cacheable regions, etc.

> c) What type is the 1K cache?
>    Inst, Date, both, selectable, freezable, x-way associative?
>
Unified instruction/data, two-way set-associative, no locking that
I'm aware of. Four-byte line size, but with a valid bit for each byte.

> d) Can the processor run faster bus-transactions than the 386sx when
>    the external design is tailored towards the Cx468?
> 
Bus transactions are the same as 386sx, I believe.

Michael Slater, Microprocessor Report              mslater@mpr.com
P.O. Box 2438, Sebastopol CA 95473  707/823-4004  fax 707/823-0504
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Cyrix 486
Organization: Xenix Support, FICC
Date: Fri, 10 Apr 1992 15:12:58 GMT

In article <1992Apr9.150513.29297@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>   The things which distinguish the 486 from 386 are (a) slightly
> diferent instruction set, and (b) integral FPU.

So, the 486SX isn't a 486? It's a 386DX on steroids?

Let's just think of them as faster or slower 386es with or without an FPU,
and get back on your surfboard. The shockwave is nowhere near cresting, and
we're all on it. Enjoy the ride.
-- 
/F{findfont exch scalefont setfont}def /S{moveto show}def /T{/Times-Roman F}def
8 T(Ferranti International Controls Corporation)24 28 S(+1 713 274 5180)24 12 S
(Sugar Land, TX  77487-5012)24 20 S 12 /Courier F(`-_-')320 32 S( 'U` )320 16 S
12 T(Peter da Silva)24 36 S 16 T(Have you hugged your wolf today?)358 24 S
Newsgroups: comp.arch
From: kentd@leland.Stanford.EDU (Kent Dickey)
Subject: Re: Condition Codes and RISC arch.
Organization: DSG, Stanford University
Distribution: comp
Date: Tue, 7 Apr 92 20:08:53 GMT

In article <1992Apr4.173725.11509@vax5.cit.cornell.edu> 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?  Here are the pro's and cons that I can think of:
>
>*PROS*: Seriously reduces branch delay slots on pipelined machines, because for
>HLL constructs such as:
>
>  if(a==b)
>    c--;
>  else 
>    d+=10;
    [ SNIP SNIP SNIP ]
>would now be compiled like this:
>
>       cmp a, b
>       dec.eq c
>       add.ne 10, d
>
>No branches, less instructions.  That's got to be less of a pain for pipelined
>chips.  I don't claim to be any sort of expert, but it seems to me like the
>CONS of this type of instruction set have got to be foreshadowed by the PROS.

HP's PA RSIC architecture does just this with its nullification bit(s).
HP's RISC lets many instructions nullify the next instruction conditionally.

So, the above code in PA RISC is:
	sub,<>	a,b,0		; Subtract b from a, throw away result
				;  if a-b != 0, nullify next instruction.
	addi,TR	-1,c,c		; c = c - 1, always nullify next instruction
	addi	10,d,d		; d = d + 10

Explanation:
The sub instruction says: r0 = a-b.  This throws away the result (since
r0 is always 0).  The ",<>" means nullify the next instruction if the
result is != 0.

The next instruction, which only executes if a=b, adds -1 to c, and
ALWAYS nullifies the next instruction (TR="true").

If a<>b, then the first addi is nullified, and so the next instruction
executed is addi 10,d,d, which adds 10 to d.

The main problem I see with nullification is that it doesn't go superscalar
(well, not these cases at least).  Note that the length of the sequence
in each section of the if can be of virtually any length since one can
usually nullify the next instruction unconditionally.

Example:
	if(a=b) {
		c=a+b+c;
	} else {
		c=a+b-c;
	}
(assume everything is in registers)

	sub,<>	a,b,0		;"compare" a and b
	add,TR	a,c,c	;(a=b) c=a+c
	sub.TR	b,c,c			(a<>b) c=b-c
	add,TR	b,c,c	;(a=b) c=b+c
	add	a,c,c			(a<>b) c=a+c

Not all instructions can nullify the next instruction.  Notable exceptions:
Loading immediate constants, accessing memory.  But a clever compiler
can move those instructions outside of the area where we're doing the
nullification sequence.  I have no idea how tricky our compilers get.

Kent Dickey
kentd@cup.hp.com
HP doesn't even know I work here.
From: mslater@mpr.com (Michael Slater)
Newsgroups: comp.arch
Subject: Re: ATT  Hobbit RISC
Date: Wed, 15 Apr 92 09:58:26 PST
Organization: Microprocessor Report
Reply-To: mslater@mpr.com (Michael Slater)
X-Mailer: uAccess - Macintosh Release: 1.5v4

In article <1992Apr15.014935.747@berlioz.nsc.com> (comp.arch), my@laverde.nsc.com (Mike Yip) writes:
> I have read that AT&T plans to introduce the Hobbit RISC as
> the perfect match for the handheld pen-based computers.  
> 
> WHY?  Is it because it runs at ultra-low power?  Or is it
> becuase they cannot crack any other market?
>
Because it is a low-power design with high code density (for a RISC,
anyway). It makes sense for them to target a specific market where
they have unique advantages, rather than slugging it out with a dozen
other competitors for the laser printer or computer market.

Also, I suspect that GO is targeting Hobbit as the first RISC platform
for PenPoint.

Michael Slater, Microprocessor Report              mslater@mpr.com
P.O. Box 2438, Sebastopol CA 95473  707/823-4004  fax 707/823-0504
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Wed, 15 Apr 1992 07:48:53 GMT
Subject: Re: Re: Voice Recog. on Desktop
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch,comp.ai


Eugene N. Miya says:

   I have yet to find a machine which can get pass the first test:
	   How to recognize speech.
	   How to wreck a nice beach.

The first person I tried it on didn't pass, either.
--
Regards,    | ``Wandering minstrels are fogging my brain    | Judy Tzuke
Kers.       | And weird intellectuals are doing the same.'' | Higher & Higher
From: shap@halifax (Jonathan Shapiro)
Newsgroups: comp.arch
Subject: Re: reg windows are losers (was: Ideas for new LISP Machines)
Summary: Register Windows are a BAD idea
Date: 17 Apr 92 15:15:24 GMT
Organization: Synergistic Computing Associates

In article <GUMBY.92Apr16124825@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
>   -is it Sparc's implementation that is a bad idea, or the whole
>    concept of overlapped, automatically pushed windows? For example,
>    what if the overlap size was variable (i.e. you push exactly what
>    you need)? Does the fixed set of globals still make this a bad
>    idea?

The whole concept is a bad idea.  The numbers used to support the register
windows argument were always somewhat suspect, and were predicated on
limited compiler technology.  The MIPS part invariably beats the SPARC
on position-dependent code (MIPS architecture is crippled on position
independent code by the fact that it hasn't got PC-relative long branch
or call instructions).  Given this, wouldn't you rather do something
*useful* with the real estate?

From a VLSI perspective, however, the arguments are even more compelling.
If you want to build a part, the amount of real estate you have to dedicate
to the register file matters alot.  On high-performance parts, where the
register file is duplicated to provide more write ports, you pay even more
area. When you go to 64 bits, you double the size again.  All of that adds
up, and I wouldn't be surprised to see 64-bit SPARC machines spending as
much as 15% of the chip area on the register files.

The really fast machines will all be using some variant on register rename
in the near future, which requires a significant number of spare physical
registers.

So let's see.  16 registers * 7 windows = 112 architected
					   16 spares
					  128 total physical registers.

Another issue is cycle time.  The speed of a register file is limited by
its height, which is basically the number of registers. As you start
getting down into the 5ns clock range, 128 physical registers is definitely
on the ragged edge of what is feasible.

By the way, reducing the windows on those high performance machines doesn't
help, because there are all those programs built to the assumption that
they can be profligate with the register windows.  The impact in
simulations is astonishing.

By the way, someone said that the Berkeley part was designed to run UNIX.
This is mistaken. SOAR (the Berkeley SPARC predecessor) stands for
"Smalltalk On A Risc".  Draw your own conclusions...


Jonathan Shapiro
Independent Consultant
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: CISC vs RISC compilers
Date: 15 Apr 92 16:54:18 GMT
Organization: School of Computer Science, Carnegie Mellon


peter@ferranti.com (Peter da Silva) writes:
>> For some reasons, some CISC machines have very good compilation speed.
>I would guess that the compiler doesn't have to do quite as aggressive a job
>of optimisation to produce acceptably fast code.

Having had my hands in a code generator, and having tuned compile
speed:  nope. At low optimization levels, a CISC target instruction
set, versus a RISC target, is irrelevant to compile speed.

At high optimization levels, CISC falls behind, because of special
cases that don't easily fall to systematic methods. I wouldn't
expect that to be dominant, however - compile speed is mostly
determined by other things.

I'd expect older instruction sets to have compilers that were
specifically tuned for compile speed. The insight here is "older ==
used to be slow".

-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch