HDTenEightyP/NetNews huggingface dataset:
From: toon@moene.uucp (Toon Moene)
Newsgroups: comp.arch
Subject: Re: Voice Recog. on Desktop
Date: 10 Apr 92 20:24:52 GMT

In article <ku9pnmINNhhf@exodus.Eng.Sun.COM> limes@straylight.Eng.Sun.COM  
(Greg Limes) writes:

> 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 ...

'Our' workstation ? 'Your' workstation you mean ! (See bottom line :-)
--
Toon Moene (toon@moene.uucp)
Kantershof 269, 1104 GN  Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
Newsgroups: comp.arch,comp.lang.lisp
From: gumby@Cygnus.COM (David V. Wallace)
Subject: Ideas for new LISP Machines
Organization: Cygnus Support, Palo Alto, California
Date: 5 Apr 92 06:39:26

I wish you could still execute out of data space.  This makes it
easier to build callable closures (and do downward funarg by
indirecting through the stack).  Gnu C has to stand on its head in
order to make this work.  Fortunately register windows are on their
way out; _those_ can make lexical variables in downward funarg expensive.

It would also be nice to cheaply be able to intercept page-miss in
user space.

I've talked about these to C hackers who always reply "but I've never
heard of anyone doing that."

A lot of nice features of the old machines turned out to be losers.
For instance, invisible pointers sounded like a good idea, but can
slow down every access.  And, as someone else pointed out, there are
alternatives (necessity is the mother of invention, I guess).
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.arch
Subject: Re: 128 bit floating point
Date: 16 Apr 92 21:18:04 GMT
Article-I.D.: ogicse.36358
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

>I'd love to hear about particular examples of algorithms that
>really need 128 bit fp and don't have more accurate alternatives.
The classical example is the solution of ill-conditioned linear equations.
The standard algorithm (LINPACK, LAPACK) uses Gaussian elimination (LU
decomposition) with partial pivoting to factor the matrix.  This takes 
approximately 2/3*N**3 flops (adds AND multiplies) and its error 
properties are well known ("Matrix Computations" by Golub and Van Loan).
For a given type of matrix, eventually as N gets large enough the 
condition number will get bad enough that LU decomposition in 64 bits no
longer give you a usable answer, and you must go to 128 bits. 

But there is another algorithm, based on QR decomposition rather than
LU, which doesn't have the numerical problems that Gaussian elimination
exhibits (also in Golub and Van Loan).  This algorithm requires twice 
the flops as LU.  Unfortunately, the number of multiplies and adds in 
the inner loop is not the same; most supercomputers do one of each per 
cycle, so you won't get peak speed on a QR decomposition.  On the LU, 
whether you use dot product or "GAXPY" you have one add and one multiply
in each cycle; the computation runs at near-peak speed in today's 
machines.  In fact, special-purpose machines (FPS-164/MAX) exist that 
do the LU decomposition.

My question, then, is, given all this, why don't those who have large
poorly-conditioned linear equations to solve build or sponsor special-
purpose machines based on the QR decomposition?  It's been proposed,
but never, to my knowledge, been done.
Newsgroups: comp.arch
From: ice@skynet.uucp (Ice)
Subject: Cray Soap Opera WAS: Re: GaAs Alpha implementation
Keywords: Alpha, Gallium Arsenide
Organization: Cyberdyne Systems Corporation
Date: Mon, 06 Apr 1992 17:41:45 GMT

[Times change so quickly. I was in grade ten, talking about the Cray 2 in
front of my data processing class, and discussing about massive parallelism
in the Non-Von by David Shaw of Columbia University. Cray 2 was the hottest
thing back then; all of 1 billion MFLOPS at peak. Unimaginable to someone
reared on Commodore PET 4032s]...

<nostalgia mode off>

In article <1992Apr2.170128.6515@craycos.com> sog@craycos.com (Steve Gombosi) writes:
>>But the Cray-3 was Cray Computer.
>                ^^^
>
>AAAAAAAARRRRRRRRRGGGGGGGHHHHHH!

:-) :-)

>Hey, guys! We're still here! We're still building it! Yes, Seymour's car
>is still in the parking lot and everything!
>
>Steve Gombosi
>Cray Computer Corporation

And what of Steve Chen? Haven't heard anything about him recently. Something
about a falling out over a computer design with optical connections which
were still experimental... budget at $50 Million... nothing tangible...
asked to tone down... felt his approach was way to go... so he left...

[from an issue of Science about 2-3 years ago].

Is this man a dark horse?

Sorry if this conjecturing isn't really appropriate but it's always
interesting to wonder about the people behind this unparalleled :-)
advancement of such savage technology.

-- 
/* Ice's Hypermedia Sig */ #include <cyberpunk.h> #include <industrial.h> 
Hardware required: biological neural net with _unsupervised_learning_
Audio() Burning Inside by Ministry; "The Mind is a Terrible Thing to Taste" 
Visual() Sarah Connor's flesh on fire blasted away leaving screaming skeleton 
From: morris@aspen.IAG.HP.COM (Dale Morris)
Date: Mon, 6 Apr 1992 19:09:06 GMT
Subject: Re: Condition Codes and RISC arch.
Organization: HP Information Architecture Group - Cupertino, CA
From: gsarff@meph.UUCP (Gary Sarff)
Newsgroups: comp.arch,comp.sys.dec
Subject: Re: Use of "crashme"
Date: 7 Apr 92 05:36:36 GMT
Article-I.D.: meph.00348
Reply-To: gsarff@meph.UUCP
Organization: WICAT Systems Inc., Orem Utah

In article <1992Apr1.054901.2534@spcvxb.spc.edu>, terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes:
>  Indeed. A few months ago, the CACM (I think it was CACM, anyway) published
>a study where some users tried throwing "unusual" input into various system
>utilities on various Unix implementation. The results were quite startling -
>I think they found major bugs in just about everything. I mean, you'd think
>that "ls" ought to be solid, but... Anyway, an interesting read.

I would not be startled in the least tiny bit.  Nor would I think that 'ls'
out to be solid.  I have seen several discussions, one I think on alt.sys.sun
where a user was complaining about a specific behavior and wondering if it
was a bug, and blaiming the software &| hardware provider.  The poster was
told, that this behavior was known, and was a bug, but not to blame Sun since
the code came from BSD and that came from AT&T (the bourne shell I believe).

The replyer then went on to enumerate several other bugs that everyone seemed
to know about and that had been plaguing people for years, and yet nobody had
fixed them.  Nealy every company that came out with a machine running unix,
ported the code, bugs and all, and presumably did not fix the bugs because of
the fear of being struck by a lightning bolt from the unix gods.  Or possibly
if they fixed the bugs it would not be "compatible".  This kind of thing has
been happening for years, and it is instead amazing to see that there manages
to be any progress at all.  Assuming the reader believes SVR4 _is_ progress.
    (insert 0.4 8-)'s) 8-(


---------------------------------------------------------------------------
We want to offer a more standard product; smaller, slower, less reliable, and
more profitable, but standard.  
Using yesterday's technology to solve tomorrow's problems.
  --Computer company X
From: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: And now for something completely different...
Date: 9 Apr 92 10:22:15 GMT
Organization: Advanced RISC Machines Ltd

tch@kepler.unh.edu (Travis C Hayes) writes:

>I am only a dabbler in processor architecture, etc., but it just occurred to
>me today that some of the things we take for granted in ALU design may not
>be the best/fastest solutions.

>Example: hardware multipliers.... adding some extra hardware to detect when
[multiply is finished] to >avoid shifting and bit testing all the remaining [MSB]s?


The technique is called early termination, and is implemented on the ARM processors.
Others probably do as well.

>Also,  easier to shift once and subtract rather than shift and add?

In a hardware multiplier, this is the Booth algorithm- it is well known and
almost everybody uses it. If you're talking about constructing multiplication
by shift-and-add/subract (ala HP-PA) it's a bit trickier, as the intermediate
partial products could overflow/underflow. There is an excellent paper by
Dan Magenheimer in the proceedings of the second (1987) ASPLOS conference:
Ineger Muliplication and Division on the HP Precision Architecture (pp. 90-99).
Xref: sparky comp.arch:4907 comp.lang.misc:1635
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: Condition Codes and RISC arch.
Organization: Kithrup Enterprises, Ltd.
Date: Fri, 10 Apr 1992 09:49:58 GMT

In article <1992Apr9.093141.26283@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:
>Distribution: comp

`comp' is not a valid distribution.  A growing number of sites will discard
any articles with invalid distributions.  If your news software put this
error in automatically, you should complain to your system administrator; if
you put it in yourself, you should complain to you.

-- 
Sean Eric Fagan  | "One form to rule them all, one form to find them, one
sef@kithrup.COM  |  form to bring them all and in the darkness rewrite the
-----------------+  hell out of them" -- sendmail ruleset 3 comment from DEC.
Any opinions expressed are my own, and generally unpopular with others.
Newsgroups: comp.arch,comp.ai
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Voice Recog. on Desktop
Organization: Xenix Support, FICC
Date: Thu, 16 Apr 1992 20:54:26 GMT

In article <1992Apr15.175943.27200@das.harvard.edu> kehler@endor.uucp (Andy Kehler) writes:
> This may be so, but so what?  Practically speaking, how often are we

< This maybe sew, butts sow watt? Practical lisp peaking, how off tenner wee

> going to encounter such an intense ambiguity?  I agree that generic

< go into Anne counters session tents ambiguity? I agree thought generics

> speech applications will have to account for context; speech

< peach chap lick cautions well half tour count fork on text; speech

I dare say that in reality most of these ambiguities can be resolved,
but if even 5% slip through dictation of text is going to be an excersize
in frustration.
-- 
/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: grout@sp90.csrd.uiuc.edu (John R. Grout)
Subject: Re: Condition Codes and RISC arch.
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development
Date: Mon, 13 Apr 92 17:24:56 GMT

linley@hpcuhe.cup.hp.com (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

>(I love catching Dale on these!)  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.

This last example (nullifying instructions which would in turn nullify others)
reminds me of the use of nested skip instructions in the PDP-10 architecture,
where one could also implement this example with three instructions without
"branches" by doing:

	CAMN	AC1,AC2		; Compare AC1 to AC2 and skip if not equal
	SOSA	AC3		; Subtract one from AC3 and always skip
	ADDI	AC4,12		; Add 12 (octal) to AC4

where D and one of A or B have to be in accumulators (although they all could
be, since ACs were addressable as memory)... also, a "SOSA AC3,D" could
subtract one from D (in an AC or memory) and also load the result to AC3.

Although I am sentimental about the many different types of skip instructions
implemented in the PDP-10 (e.g., compares, moves, arithmetic, masking tests), I
suppose both nullification and Alpha-style conditional moves (being
three-operand ALU instructions) fit better into the RISC paradigm than skips do
(although all instructions are the same length...  again :-).

--
John R. Grout
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

    INTERNET: j-grout@uiuc.edu
Newsgroups: comp.arch
From: gessel@cs.swarthmore.edu (Daniel Mark Abrahams-Gessel)
Subject: Re: Microcoded processors?
Organization: Swarthmore College
Date: Mon, 13 Apr 1992 16:54:49 GMT

In article <9204121433.AA11491@iecc.cambridge.ma.us>, johnl@iecc.cambridge.ma.us (John R. Levine) writes:
[....]
> Back when ROMs were a lot faster than RAMs, it made sense to microcode,
> since you could run several ROM instructions in the time it took for one
> RAM access.  These days, there's no great difference in speed and it makes
> more sense to compile directly to microcode, one of the ideas behind RISC.

If your memory subsystem can keep up with your processors top speed,
then compiling to microcode makes sense. But if you're running out of
a cache, it seems that a programmable microcode processor would be
useful, the idea being to shrink your code enough to fit in the cache.

Now I realize that shrinking can be done with subroutines, but subroutines
have a lot of overhead as I understand it. I would think that a microcoded
instruction would have no overhead, since there's no call, not even a
jump.

Dan

Newsgroups: comp.arch,comp.ai
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: Voice Recog. on Desktop
Organization: The Backbone Cabal
	<GLEW.92Apr14153132@pdx007.intel.com>
Date: Thu, 16 Apr 1992 12:21:14 GMT


Although I have never seen a voice recognition system in action, I
have some real doubts as to how practical it could really be.

Take a look at most of these postings and think about how you would
have to say things in order for the system to generate the exact
sentences.  How does a system know that you have ended a sentance?
How can it now that there is supposed to be a "?" instead of a "." at
the end of a sentance?  In the last sentance, how would it have
handled the double quotes?  If you had to say "double quote" every
time you wanted a double quote, then how would you get the words
"double quote"?  Look at the capitalization, commas, and colons: how
would a speech recognition system possible know where to put that
stuff automatically.  If it isn't done automatically, how many extra
words are you going to have to use in order to make the system give
you what you want?

I just get the feeling that even though it is not too hard (relatively
speaking) to get 80% of the words right, that making the system handle
the last 20% in what ever form, would be a real nightmare.  Making
people go back and edit the text with the keyboard seems like it would
kind of defeat the purpose of the speech recognition system.

-wayne

Newsgroups: comp.arch,comp.ai
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Voice Recog. on Desktop
Date: Thu, 16 Apr 1992 19:39:05 GMT
Organization: U of Toronto Zoology

In article <1992Apr15.172528.30412@alliant.com> tj@alliant.com (Tom Jaskiewicz) writes:
>The first company with the hardware/software to allow a driver to "write"
>memoes is going to make a lot of money.

And cause a lot of traffic accidents.  We've already got pinheads who
think they can shave or chatter away on a cellular phone while weaving
through traffic.  99% of the time they're right...
-- 
ISDN, n:  Incredibly Slow and Dumb      | Henry Spencer @ U of Toronto Zoology
Networking                              |  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.arch,comp.ai
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Voice Recog. on Desktop
Organization: Intel Corp., Hillsboro, Oregon
	<1992Apr10.152204.1544@sctc.com> <1992Apr12.055723.13230@
	<KERS.92Apr13154911@cdollin.hpl.hp.com>
Date: Tue, 14 Apr 1992 23:31:32 GMT

       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?

Agreed. Give me a pen or a mouse for drawing. (I actually find a mouse
easier to use for drawing now that I have been using it enough.)

Give me voice for entering mass quantities of text. Give me offline
editing with a red pen on paper for simple review tasks. Give me
online editing with a pen/mouse when I'm the principal maintainer of a
document.
--

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: jerry@cs.mcgill.ca (Gerald (Jerry) KUCH)
Subject: Re: Voice Recog. on Desktop
Organization: McGill University, Montreal, Canada
Date: Fri, 10 Apr 1992 04:45:39 GMT

In article <1faH$$hm6@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes:
>
>In article <ku9pnmINNhhf@exodus.Eng.Sun.COM> limes@straylight.Eng.Sun.COM (Greg Limes) writes:
>
>   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.

Wow...is this the same Covox that used to make a product with similar features
and similar price for the Commodore 64 and Atari 8-bit machines about six 
years ago...Voice Master or something to that effect?

>   Why can't we do this on our workstations? The audio is there, the
>   processing power is there ...
>
>You can.  SimonSays on the NeXT.
>
>-Mike


-- 
 Jerry Kuch (jerry@cs.mcgill.ca) | "Sic Gorgianus Allos Subjectatus Nunc."
 "I was wrong to play God.  Life is precious, not a thing to be toyed with.
  Now take out that brain and flush it down the toilet."
                  --- M. Burns  "Treehouse of Horror II"
From: hyatt@cis.uab.edu (Robert Hyatt)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 6 Apr 92 13:13:34 GMT
Organization: University of Alabama at Birmingham

In article <mch.702540303@regent.e-technik.tu-muenchen.de> mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann) writes:
>helz@ecn.purdue.edu (Randall A Helzerman) writes:
>
>>|> In article <1992Mar31.184215.10232@b11.ingr.com> (comp.arch), dclark@b11.ingr.com (Dave Clark) writes:
>>|> > I just heard that Cyrix announced a 486-compatible processor which plugs
>>|> > into a 386SX socket.  I also heard that Intel stock dropped from 65 to
>>|> > 53 per share.
>>|> 
>
>>I take it to mean that you can plug it right into an existing 386sx motherboard?
>>If so, how much faster will it be than the old 386sx was?
>
>Has ANYONE a 386sx-board with a socket for the processor??
>To my understanding the main idea of the 386sx is to bring 
>386-functionality at the 286 price because at that time noone
>besides intel made 386xyz-devices. A socket for a qfp-package
>is by no means cheap. 
>So if you don't have a board with a socket, you might want to 
>look at the processor and then decide if you like the idea
>of desoldering the existant 386sx, cleaning the pads (if they
>are still there after the desoldering :)) and solder the
>cyrix-part.
>I bet, you'll forget about this replacement rather quickly.
>
>Best regards,
>Michael Hermann
>


all the 386sx machines I have seen have a socket (that is probably not the
right term any longer as the chips I have seen don't have "legs").  However,
I am confused here.  The 386sx has only 24 bits worth of address lines (16mb
real address space) as opposed to the 386dx with it's 32 bit addressing (again,
real addressing not virtual which both are equal at).  The 486sx is not a
pin-compatible chip to the 386sx (both Intel chips here, not AMD) as the 486sx
is still a full 32-bit address bus chip.  Does this mean that AMD has built
a 486-compatible chip with only a 16mb real memory addressing capability?  Seems
foolish if they did.

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
Newsgroups: comp.arch
From: pngai@adobe.com (Phil Ngai)
Subject: Re: Cyrix 486
Organization: Adobe Systems Incorporated
Date: Thu, 9 Apr 1992 19:36:47 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. While the integrated

Either you've never heard of the Intel 486sx, or you think you know
better than Intel what a 486 is.


-- 
My opinions are my own.
Newsgroups: comp.arch
Subject: Re: Microprogrammed processors (PDP-11 and VAX)
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 14 Apr 92 09:42:37 GMT
Distribution: world
Organization: The Wolery

supnik@human.enet.dec.com (Bob Supnik) writes:
> In the TTL/ECL VAX's, the 11/730, 8600, 8800, and 9000 implemented all
> microprogram memory as writeable control store.  On the 8800, this

Not forgetting of course the VAX 8500 -> VAX 8530 upgrade, which comes on 
a disk.....  8-)

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
Newsgroups: comp.arch,comp.ai