HDTenEightyP/NetNews huggingface dataset:
From: gumby@Cygnus.COM (David V. Wallace)
Subject: Ideas for new LISP Machines
        <GUMBY.92Apr7160702@Cygnus.COM> <kuc3nlINN46s@boogie.cs.utexas.edu>
Organization: Cygnus Support, Palo Alto, California
Date: 14 Apr 92 02:12:04

   Date: 10 Apr 92 21:56:05 GMT
   From: wilson@cs.utexas.edu (Paul Wilson)

   In article <GUMBY.92Apr7160702@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
   >
   >   Date: 7 Apr 92 19:54:48 GMT
   >   From: wilson@cs.utexas.edu (Paul Wilson)
   >                                                     (I think most
   >   of the costs of floats are the compiler's problem, not the hardware's;
   >   with good inlining, dataflow analysis, etc., most floats can be raw
   >   untagged values on the stack or in registers.
   >
   >This makes scavenging the stack painful if you're doing realtime gc in
   >another execution thread.

   The easy way to do this is to partition the register set into pointer
   registers and nonpointer registers, as is done in Yale's T compiler.

This doesn't work on current architectures (and I apologize that I had
forgotten that this discussion is on _future_ architectures).  The two
problems are:
 o - on a register-poor architecture (such as the sparc) the cost of
     untagging may still be lower than the cost of all the reloads
     you'll have to do because you don't have enough free registers of
     the proper type.  Judicious tag choice and bibop-ing is needed to
     make this true, of course.
 o - You can't intercall with functions written in other languages
     unless you inhibit the GC.

Current microprocessors do make some concessions in this direction,
often with dedicated fp and sp regs.

One implementation that used this technique to great advantage as
MACLISP.  In fact maclisp maintained a seperate PDL for flonums.
(This was made easier by the fact that on the 10 any reg -- or any
word in fact -- can be a stack pointer).  Its numeric performance was
claimed to be better than the 10's FORTRAN compiler's, though I never
verified this myself.  

   The ``right'' way to do it is to have the compiler record what's where,
   and in what format, at what point in the code.  (For compactness, that
   might involve defaults so that you only record the (relatively few)
   exceptions explicitly.)

Would you keep this info close to the function or in a seperate area?
Which has better performance?
Newsgroups: comp.arch,comp.ai
From: markg@pdx077 (Mark Gonzales)
Subject: Re: Voice Recog. on Desktop
Organization: Intel Corp., Hillsboro, Oregon
Date: Wed, 15 Apr 1992 01:51:06 GMT

In article <1992Apr15.004813.24392@nas.nasa.gov> eugene@wilbur.nas.nasa.gov (Eugene N. Miya) writes:
>
>The same problem goes for speech recognition and synthesis.  The SR
>community has been very poor about educating the naive community
>about the problems of SR.  You get snippets attending conferences.
>To this end I put together the RhosettaStone (nice name) benchmark test.
>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.  For example, in a conversation about speech recognition, one
would tend to hear [1], if you said [2]. (Or [2] for [1], in a
conversation about beaches. :-)

Where speech recognition would be useful is in making menu selections
when typing or drawing ("boldface", "subscript", "save", "undo",
"rectangle", "circle", "other window" ).  Here the command set is
small, generally unambigous, and general connected speech recognition
is not needed.  This would allow fast typing of ornamented text,
without stopping to fumble for the mouse every few words.
From: mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 6 Apr 92 06:05:03 GMT

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
From: moss@cs.umass.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: Any FTP Sites for DEC Alpha (ps) documents?
Date: 9 Apr 92 12:56:01 GMT
Reply-To: moss@cs.umass.edu
Distribution: usa
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: barroso@priam.usc.edu's message of 8 Apr 92 21:41:05 GMT

The place is: gatekeeper.dec.com: pub/DEC/Alpha

Enjoy! Also, the Alpha Architecture Handbook can be had (for those in the US
at least) by a call to 1-800-332-2717. Mine arrived the next day!
--

		J. Eliot B. Moss, Assistant Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.edu
Xref: sparky comp.arch:5055 comp.ai:2012
From: grover@brahmand.Eng.Sun.COM (Vinod Grover)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 20:36:23 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: brahmand

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.

Provided the system can filter out  ambulance and police sirens or the
sounds of those speeding motorists :)
Newsgroups: comp.arch
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: Re: 88110
Date: Thu, 16 Apr 92 17:45:17 GMT
Organization: School of Computer Science, Carnegie Mellon

In article <0105010F.13bi6p@mpr.mpr.com> 
	mslater@mpr.com (Michael Slater) writes:
>> Where can I find some extensive information on the motorola 88110 ? Ultimately  
>> I would like to see the spec sheets.
>> 
>The 88110 is still not officially announced, so data sheets are under
>NDA.

You could do what I did, which is look up Motorola Semi in the phone
book, call the nice salesperson, and ask for the 88110 User's Manual.
It's about an inch thick, and not under NDA.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Ideas for new LISP Machines
Followup-To: comp.arch
Organization: Intel Corp., Hillsboro, Oregon
	<CARLTON.92Apr2164722@husc8.harvard.edu>
	<MEISSNER.92Apr3104846@tiktok.osf.org>
	<GLEW.92Apr3172834@pdx007.intel.com>
	<MEISSNER.92Apr6102821@tiktok.osf.org> <GLEW.92Apr6212044
	<MOSS.92Apr11093655@ibis.cs.umass.edu>
Date: Sun, 12 Apr 1992 03:17:27 GMT


Me> | What a well-designed architecture would have is a signed 17 bit
Me> | offset, plus a load immediate as upper 16 bits instruction.

Meissner> Or two instructions, one that sign extends, and the other zero
Meissner> extends.

Moss> Actually, and not meaning to be picky, a zero-extend-constant and
Moss> sign-extend-constant overlap on the positive half of the range. It makes more
Moss> sense to me to have load-positive-constant (zero extend) and
Moss> load-negative-constant, or, if you like, add-immediate and sub-immediate,
Moss> where the constant is zero extended. 

What about
    AND-positive-constant
    OR-positive-constant
    XOR-positive-constant

and their counterparts
    AND-negative-constant   
    OR-negative-constant    
    XOR-negative-constant
although it has been pointed out that
    ANDNOT-positive-constant
    ORNOT-positive-constant
    XORNOT-positive-constant
are equivalent.

Q: what are the relative frequencies of
    ANDNOT reg,reg -> reg
and
    ANDNOT reg, positive-immediate -> reg
?


--

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: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Voice Recog. on Desktop
Organization: Intel Corp., Hillsboro, Oregon
Date: Fri, 10 Apr 1992 05:50:50 GMT


    >How many years before speech recognition is a stock "feature" and
    >bundled/wired into the OS? 

I've seen quite usable speech recognition running on an i486(tm)/25.
The actual speech recognition code runs on the i486; a DSP board does
the DFT.  Pretty soon you won't need the DSP. (I'd like to see this on
an i486DX2/66.)

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.

Since I was having trouble with typing (repetitive motion syndrome) at
the time, I was really tempted to buy. The price was the only
bottleneck: 10K$ for the 30K word vocabulary, somewhere around 1K$ for
the 10K vocabulary.

I hope/expect that the price will go down as vendors start bundling
this technology - particularly when software only is acceptable.


I probably shouldn't mention specific vendors, but you can buy this
stuff right now, in English, and a number of European langauges.


Frankly, in a year when I've seen a lot of demos, this was the most
impressive demo I've seen.
--

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: bourne-linda@CS.YALE.EDU (Linda Bourne)
Subject: Alan J. Perlis Symposium
Organization: Yale CS Mail/News Gateway
Date: Wed, 8 Apr 1992 20:05:53 GMT

ALAN J. PERLIS SYMPOSIUM:  Parallel Computers of the Future

Sponsored by the Department of Computer Science, Yale University

April 23, 1992

Sheffield-Sterling-Strathcona Hall
Room 114
Corner Grove and Prospect Streets
New Haven, Connecticut


Morning Session (9:30-11:00)

	Opening Remarks
		Drew McDermott
		Chairman, Yale CS

	"Dataflow Architectures:  From Monsoon to *T"
		Arvind
		Massachusetts Institute of Technology


Afternoon Session (1:30-4:30)

	"PRAMs:  Theory, Physical Design, and Application"
		Wolfgang Paul
		University of Saarbrucken

	"Will Parallel Architectures Converge?"
		H.T. Kung
		Carnegie-Mellon University



Following the last talk a public reception will be held at the
Department of Computer Science, Arthur K. Watson Hall.

All talks are free and open to the public.

For further information please call (203) 432-1246.
-------

Newsgroups: comp.arch
From: payne@theory.TC.Cornell.EDU (Andrew Payne)
Subject: Re: Condition Codes and RISC arch.
Organization: Cornell Theory Center
Distribution: comp
Date: Tue, 7 Apr 1992 17:28:26 GMT

In article <1992Apr7.140852.16000@cs.cornell.edu> huff@cs.cornell.edu (Richard Huff) writes:
[ ... stuff about conditional instructions and converting if-else statements
  to straight line code ... ]

>For RISC machines the wins are not so large.
>Why?  Well, for one thing, if-conversion implies that the
>CPU will issue the instructions for BOTH the true and false
>branches.  If you have a VLIW with empty slots for the
>extra instructions, it costs nothing.  But a RISC will
>always eat one cycle per nullified instruction.

But the savings on non-VLIW machines might be more than you think.  Branches
eat cycles, and are effectively "nullified" if they aren't taken.  By 
re-writing if-else blocks as straight line code with conditional instructions
you aren't using branches any more.  And, don't forget the mispredict 
penalty as pipelines get longer.

The best example is a frequently executed if-block.  In the common case, the
conditional overhead is one cycle (for a not taken branch).  In the
infrequent case, the overhead is a taken branch plus a mispredict penalty.
With conditional instructions, the common case overhead is zero and the
infrequent case overhead is the number of instructions in the conditional
block.

So you can save one cycle in the common case (not bad), and pay no penalty
in the infrequent case as long as the block size is less than the
mispredict penalty plus one. 

-- 
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
                          INTERNET:  payne@tc.cornell.edu

Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: CISC vs RISC compilers (Re: whining about "marketing" (was Re: Does every ...))
Organization: Intel Corp., Hillsboro, Oregon
	<id.BHWO.943@ferranti.com> <12439@auspex-gw.auspex.com>
Date: Thu, 16 Apr 1992 01:02:37 GMT

In light of the recent discussion about compilation speed versus
optimization, and in the spirit of the MIPS/MHz or SPECmarks/MHz
definition, may I suggest:

    SPECmarks/second of compilation time

as a new measure which tells you absolutely nothing about the
architectural efficiency of an implementation or system, but which is
a number that people can talk about, argue about, call a duck, and
otherwise have a good time with?

--

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,comp.ai
From: eugene@wilbur.nas.nasa.gov (Eugene N. Miya)
Subject: Re: Voice Recog. on Desktop
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Wed, 15 Apr 92 00:48:13 GMT

Just passing thru....

I would be skeptical of any recognition system if the developer does not
allow me access.  Otherwise I regard it as canned demos.  The problem
is that developers retain critical information that is best kept from a
naive audience (economics).  The problem with the audience (us) is that
we remain naive.  We are frequently unable to study the problems/issues
of this technology.

Fortunately in the Valley, many of these companies are very close to
each other and the relations between the them is incestuous.  For example,
my optical character recognition software has bugs, wrong version, oops!
Phone up the company, turns our service person's father works at Ames.
Send disk to her father, forget channels.  Fortunately, we can check out
the new pen top machines: Go and Momentum.  The question is how to test?
Turns out it has the same problems as OCR: except you can get stroke
information.  In the Case of the GO: I pen 0 1 2 3 4 5 6 7 8 9, only
2 is entered as Z.  OCRs, pens, etc. confuse:  1, l, (<-you might even miss
these depending on your screen), i, j, ;, \,, :, /, and so forth.
In every day life you take parsing these for granted.  I did various
OCR tests, unfortunately we have a long way to go.

The same problem goes for speech recognition and synthesis.  The SR
community has been very poor about educating the naive community
about the problems of SR.  You get snippets attending conferences.
To this end I put together the RhosettaStone (nice name) benchmark test.
I have yet to find a machine which can get pass the first test:
	How to recognize speech.
	How to wreck a nice beach.

Always yield to the hands on imperative.

--eugene miya, NASA Ames Research Center, eugene@orville.nas.nasa.gov
  Resident Cynic, Rock of Ages Home for Retired Hackers
  {uunet,mailrus,other gateways}!ames!eugene
This is the Usenet: do you expect anything other than gross generalizations?
Ref: Mathematics and Plausible Reasoning, vol. 1, G. Polya
From: pngai@adobe.com (Phil Ngai)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 18:24:33 GMT
Organization: Adobe Systems Incorporated

In article <id.2WOO.KHD@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Apr6.131334.22658@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
>> Does this mean that AMD has built
>> a 486-compatible chip with only a 16mb real memory addressing capability?
>
>And with a 16-bit external data path, and low power disspiation. Looks like
>it to me.

Since no one has yet pointed out this mistake (or the many others) I
suppose I get to.

AMD is not involved in this. Look at the subject line. This
is a Cyrix product.

-- 
My opinions are my own.
Xref: sparky comp.arch:4851 comp.lang.lisp:1343
From: baechler@liasun3.epfl.ch (Emmanuel Baechler)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Keywords: LISP machines
Date: 1 Apr 92 07:03:16 GMT
Followup-To: comp.arch
Organization: Ecole Polytechnique Federale de Lausanne

In article <1992Apr1.033547.20514@athena.mit.edu>, pdp8@m4-035-4.MIT.EDU (John W.F. McClain) writes:
|> What is the general felling on purpose built LISP machines.  Ignoring
|> marketing issues do they make sense from a technical viewpoint, or is
|> it more effective to take a RS6000 or a DECstation and write a virtual
|> LISP machine.

Purpose buit LISP machines have the advantage that many of their important
operations are directly supported by the hardware or the microcode. If memory
serves me, this is for example the case for the Flavor Sytem on Symbolics.
I read at several times that this support is very important for the speed
of these operations.

This discussion arose several times on the Symbolics Lisp Users Groups. At
each time the "gurus" answered that a software simulation, although feasible,
would result in a very slow machine. I don't know wether this situation has
really changed with the new RISC machines. There was also a time where TI was
developing a microprocessor with writable microcode. This can be a solution,
if it ever succeeds.

It may also be interesting to look at the architecture of the new 
microprocessors developped by Symbolics for their embedded boards (on
Macintosh, Sun and so on). If they are able to use a quite general RISC
style architecutre, then a software simulation should be more feasible
than previously.


-- 
Emmanuel Baechler.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
MA-Ecublens
CH-1015 Lausanne	Switzerland
Tel.: ++41-21-693-2732
e-mail: baechler@liasun6.epfl.ch
Standard Disclaimer

Ban the bomb. Save the world for conventional warfare.
Newsgroups: comp.arch
From: william@syacus.acus.oz.au (William Mason)
Subject: Re: Tagged Architectures.
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Thu, 16 Apr 1992 14:11:48 GMT

[Context below ... ]

Hi.

Unisys have an A Series called the RAMP that is binary compatible with 
System 36.  So IBM-er can keep their old stuff.  And they get a full
A Series and A Series suite of software capability, eg. OSI, 4GLs, SNA
(I don't know if AS/400-s do SNA, I assume they do).

And it runns the pants off an AS/400, I understand.  

Disclaimer:  No I've never seen one.  It simply seemed like a really
'obvious' clever concept when I heard of it.  Yes it is/was an announced
product.  Some one from the States or Europe might have better information.


... False modesty is also a lie.

kinch@no11sun.csd.uwo.ca (Dave Kinchlea) writes:
>In article <1992Apr9.221936.18336@leland.Stanford.EDU> jackk@leland.Stanford.EDU (Jack Kouloheris) writes:
>>In article <1992Apr9.205334.13216@adobe.com> zalman@adobe.com (Zalman Stern) writes:
>>>In article <12383@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris)  
>>>writes:
>>>> I wonder how much would be involved in making a capability-architecture
>>>> version of the POWER instruction set, and using *that* as the underlying
>>>> instruction set of an AS/400 model, and whether that could be made
>>>> faster than existing models....

>>>I heard there is a company that sells an RS/6000 (POWER, whatever you like  
>>>to call it) package that emulates a System 36. In more 'mainstream'  
>>>terminology it pretty much provides binary compatibility. Binary  
>>>compatibility is not precisely correct since there is a level of  
>>>interpretation that happens on the native machines as well. This gives one  

>As a person who is currently developing such a product, I can attest to its
>price/performance as compared to both AS/400 in S/36 emulation mode and a true
>System/36. The package I am developing runs on a RS/6000-520, one of the first
-- 
_____ "Though the course may change, Rivers ~always~ reach the sea." lz _____
 _--_|\    William Mason                 ACSnet:    william@syacus.acus.OZ
/ ACUS \   Aust Ctr UNISYS S/w           Internet:  william@syacus.acus.OZ.AU
\_.--._/   Sydney, N.S.W,                Voice:     +61-2-390-1322
From: morris@aspen.IAG.HP.COM (Dale Morris)
Date: Wed, 15 Apr 1992 19:14:25 GMT
Subject: Re: Condition Codes and RISC arch.
Organization: HP Information Architecture Group - Cupertino, CA
From: hyatt@cis.uab.edu (Robert Hyatt)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 22:49:47 GMT
Organization: University of Alabama at Birmingham

In article <id.2WOO.KHD@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <1992Apr6.131334.22658@cis.uab.edu> hyatt@cis.uab.edu (Robert Hyatt) writes:
>> Does this mean that AMD has built
>> a 486-compatible chip with only a 16mb real memory addressing capability?
>
>And with a 16-bit external data path, and low power disspiation. Looks like
>it to me.
>
>> Seems foolish if they did.
>
>I don't know... sounds like they could sell a shitload of the parts to all
>the people currently getting 386SX systems. I mean, that's what it all comes
>down to, isn't it?
>-- 

Peter's right of course.  The idea is great.  it's the calling it a 486
that sucks with two straws.  I mean, is a 486 a 486 or is it a 16bit-wide
buss superfast 386sx....  They should have used another number... it;s
already confusing enough.  Now, when we buy pc's for our lab, we have to
determine if it's a "real" 486 with a big S on it's chest, or is it an
imposter.  Much like the damn 486/DX2-50 chip..... that seems to run at
25mhz (Tandy is shipping) and then doubles internally.  I mean, what the
hell is it?  is it 25 or 50.  To me, buying one, it's a 25, but to Tandy's
marketing ads, they call it a 50mhz system.  Boy is all this going to be
fun when we go out for bids.  Think I'll go puke.

Bob

-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !