HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (Peter da Silva)
Subject: Re: Voice Recog. on Desktop
Organization: Xenix Support, FICC
Date: Wed, 15 Apr 1992 14:17:04 GMT

In article <1992Apr15.015106.18722@ichips.intel.com> markg@pdx077 (Mark Gonzales) writes:
> This is a rather unfair test, most humans would have trouble
> distinguishing [1] from [2], especially without any conversational
> context.

I don't use dictation to enter code, and when someone calls me and asks me
to do something I almost always get them to email me as well, just to avoid
this sort of thing. I hate dealing with technical support lines where droids
are taking notes because they can't possibly handle the ambiguities... and
they have *way* better context handling than any less-than-AI speech handling
computer.

This isn't a speech recognition problem, it's a speech problem. If you want
to replace keyboards with dictaphones you have to solve it.

It's not a matter of "fair" or "unfair", it's a matter of practicality. If
you're saying it's in general unsolvable, fine.

> Where speech recognition would be useful is in making menu selections [...]

Yeh, like I said. Command input.

Larry Niven used this rather well in The Integral Trees. He even had them
use a command prefix: "prikazyvat" (approximately: Niven implied it was the
word "command" in Russian) to disambiguate commands from normal speech. Much
better than Star Trek...

	Kirk-Picard: "... what do we do about that computer crash..."
	Computer: "Crashing, sir"
	Kirk-Picard: "...on deck... hey! Belay that order. Computer..."
		(silence)
	Kirk-Picard: "...computer?..."
-- 
/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: ggw@wolves.uucp (Gregory G. Woodbury)
Subject: Re: 88K family computers?
Organization: Wolves Den UNIX
Distribution: usa
Date: Thu, 9 Apr 1992 16:20:35 GMT
X-Md4-Signature: a2f74ffbd21b23e5db374ba372d7f227

jpab+@andrew.cmu.edu (Josh N. Pritikin) writes:
>> Aydin Contols (Real-Time Workstation line)
>> CETIA (Cetia line)
>> Data General (Aviion line)
>> Dolphin Server Technology (Triton lin)
>> Encore Computer (Encore 91, Encore 93, Infinity 90)
>> Harris (Night Hawk line)
>> IPC Corp (IPC Serve 88000)
>> McDonnell Douglas (Series X line)
>> Modcomp (Real/Star Modcomp line)
>> Motorola (Delta Series 8000 line and MPC line)
>> OMRON (Luna-88k)
>> Sanyo Icon (SI line)
>> Unisys (S/8400)
>
>So which of these are actually making workstations or minicomputers?

We just went through getting an 88k machine (we got a DG 4620) and I
know that DG, Dolphin, Harris, Motorola, and Omrom are really available.

Not listed, but also available are Add-in card 88k cpus (for ISA-bus
PCs) from Opus Systems (Cupertino CA)  and AlphaMicro is also making an
88k based workstation.

The Encore machines are "high-end" mini or mainframe type computers, as
is the (unlisted) Tadpole board product.   I could NOT get a response
from Sanyo/Icon about their products.
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu     ggw%wolves@duke.cs.duke.edu
[The line eater is a boojum snark! ]           <standard disclaimers apply>
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: And now for something completely different...
Date: 12 Apr 92 12:41:02 GMT
Organization: Purdue University Statistics Department

In article <GLEW.92Apr11190114@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:

>    For multiplies by constants, you could let the compiler detect the special
>    case and have some mechanism for letting the processor know this.  For
>    example, you could have a "constant multiply" instruction that takes
>    a pair of bit masks.  The first tells it on what shifts to add, and the second
>    tells it on what shifts to subtract.

>Many processor implementations have early outs for multiply and divide.

>Theoretically a compiler could schedule for these when it knows the constant value.

This was actually done in the past.  It is not as useful now, when 
built-in multiplication is only a few times as costly as shifting and
adding, but on old machines, it was used quite a bit.  It was also used
for multiplying floats by small integers, and even more so for raising
numbers, both integer and floats, to integer powers, and a good Fortran
compiler will still do that.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: andrewr@highland.oz.au (Andrew Rothwell)
Subject: Re: Microprogrammed processors (PDP-11 and VAX)
Organization: Highland Logic
Date: Thu, 16 Apr 92 03:09:32 GMT

in article <363@sousa.ltn.dec.com>, supnik@human.enet.dec.com (Bob Supnik) says:
> 
[stuff about PDP-11, LSI-11, VAX(-11) writeable control stores...]
> 

As did/do the Prime 50 series boxes. Special versions of ucode were
written to help support the Prime 4GL/RDBMS system. And yeah, CPU upgrades
used to be done via floppy/PROM insertion. Seems to me writeable control
stores appeared quite frequently on boxes that we used to call (super)
minicomputers. But...

The original question was about "microcoded microprocessors"! Let's stick
to that theme.

Andrew.


Newsgroups: comp.arch
From: jedwards@ms.uky.edu (Jonathan Edwards)
Subject: Re: Cyrix 486
    <9jcHl1ok6@cs.psu.edu> <1992Apr8.025832.25158@u.washington.edu>
Date: Wed, 8 Apr 1992 11:36:19 GMT
Organization: University Of Kentucky, Dept. of Math Sciences
X-Bytes: 

echen@hardy.u.washington.edu (Ed Chen) writes:

>IBM's 386SLC claims a ~90% performance improvement over the Intel 386SX.  It
>has a 16K (I think) cache & faster core.   I agree with Dan that this Cyrix
>486 stuff is all marketing hype, but nonetheless, a good one from the business
>point of view.  

The SLC has an 8K cache.
Newsgroups: comp.arch
From: jackk@leland.Stanford.EDU (Jack Kouloheris)
Subject: Re: Tagged Architectures.
Summary: S/36 != AS/400
Organization: DSG, Stanford University, CA 94305, USA
Date: Thu, 9 Apr 92 22:19:36 GMT

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  
>a lot more lattitude in implementing an emulator.
>
>The story I heard was that IBM was pretty unhappy about this product.  
>(I.e. its price performance against an AS/400 was good enough that people  
>might actually use it.) I don't follow that realm of the computer business  
>though so this is totally second hand.
>
>--
>Zalman Stern		   zalman@adobe.com		    (415) 962 3824
>Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900

The System /36 did not have the high-level instruction set of the S/38 and
the AS/400. It's an older system that evolved from the S/3, S/32, and S/34
family and was if I remember right, a 16-bit machine. The
high level instruction set of the S/38 was a break from this family.
Migration to the AS/400 (and the elimination of most of S/36)
was provided through recompilation and through providing system and library
support for the old code. It's not surprising then that it can be efficiently
supported on the RS/6000 (or other machines, for that matter).

Jack

Newsgroups: comp.arch
From: tch@kepler.unh.edu (Travis C Hayes)
Subject: And now for something completely different...
Organization: University of New Hampshire  -  Durham, NH
Date: Tue, 7 Apr 1992 20:37:35 GMT

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 (not that microcoded designs probably ever use
hardware multipliers).

The traditional shift/add and shift/subtract (for division) method seems to
be somewhat of a time waster. Could it possibly be enhanced by adding some
extra hardware to detect when the desired result has been achieved and thus
avoid shifting and bit testing all the remaining high-order bits (which would
all be zero anyway after the result was achieved)? Since in many multiplies
one of the numbers is likely to be small (bits near the msb end not set)
this idea would seem to save some time. Any ideas? Do any architectures do
this?

Also, if you do the multiply in hardware would it not sometimes be easier
to shift once and subtract rather than shift and add. Example: to multiply
by 7: shift left 3 and subtract once. Is it ever worth it to handle these
special cases? (I mean in hardware, not software. I don't wish to make this a
compiler issue.)

only one 
only thin
-- 
+-----------------------------------------------------------------------------+
| Travis C. Hayes                                             Travis C. Hayes |
| University of New Hampshire                   UNH Research Computing Center |
| Computer Science Sophomore                     Computer Operator/Programmer |
+--------------------+--------------------------------------------------------+
| tch@kepler.unh.edu | This space intentionally left blank... :)              |
+--------------------+--------------------------------------------------------+
Xref: sparky comp.arch:4894 comp.sys.dec:2518
From: borasky@ogicse.ogi.edu (M. Edward Borasky)
Newsgroups: comp.arch,comp.sys.dec
Subject: Re: Use of "crashme"
Date: 10 Apr 92 15:01:44 GMT
Article-I.D.: ogicse.36102
Organization: Oregon Graduate Institute (formerly OGC), Beaverton, OR

Speaking of "well-known UNIX bugs", there is a C-shell "time" command
that prints out, among other things, an integrated CPU-memory product.
This is an extremely useful measurement in performance analysis.  The
problem is that most UNIX systems keep this number in a variable that
isn't big enough to keep from overflow!  So sometimes it will print as
negative!  Am I the only one that CARES?
Newsgroups: comp.arch,comp.lang.lisp
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Ideas for new LISP Machines
Organization: Intel Corp., Hillsboro, Oregon
	<MARKT.92Apr7131340@wundt.harlqn.co.uk> <ku4tc6INN2md@spim.mips.com>
Date: Wed, 8 Apr 1992 20:57:08 GMT

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

The extra input is an important point. (Why route 3*32 or 3*64 wires
when you need only route 2*32 or 2*64?)

But it should be noted that a 3 input adder is *not* the same as 2
back to back adds. You don't need to do two full carry propagate, only
one stage of 3:2 full adders, before using a 2:1 carry propagate add.
Plus, the reduce stage doesn't need to be conventional full adders -
Robertson's work explored all the possible encodings, and found
several which are less expensive (depending on technology).

Bottom line: adding an extra input only to get a 3 input addressing
mode probably isn't worth it. But, if you have some 3 input
instructions anyway, like multiply-accumulate, and they are executed
in the same datapath as the address computation, then you can probably
afford the three input addressing mode.


--

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: dj@godot.mm-world (DJ Walker-Morgan)
Newsgroups: comp.arch
Subject: Re: Whence Andy?
Date: 10 Apr 92 14:51:44 GMT
Reply-To: dj@godot.mm-world
Organization: MicroMuse - The SPARC dudes

HAL is still trundling along working on what sounds like a high-robustity SPARC
implementation at very high Mhz. Last I read, no product was expected for 1-2 years
and no details have yet to be released.


---

============================================================================
  dj@micromuse.co.uk    |"In a perfect world we'd all sing in tune
  Voice +44-71-352-7774 | but this is reality so give some room" 
  Fax   +44-71-351-7834 |                           (Sir) William Bragg
------------------------+---------------------------------------------------
 Non-standard Disclaimer : "I didn't do it, it wasn't me, I wasn't there"
From: jbuck@forney.berkeley.edu (Joe Buck)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 16 Apr 92 21:54:31 GMT
Article-I.D.: agate.skt2nINN8e6
Organization: University of California, Berkeley
NNTP-Posting-Host: forney.berkeley.edu

In article <1992Apr16.200227.18221@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes:
>One of the advantages of the 29k is that the traps can be in user mode, and
>are *cheap*.  (Something like a three-cycle overhead.)  This means that you
>don't incur a horrible penalty each time you spill some registers to memory
>(which, of course, you might not do anyway).

Cool -- one of the things that fast user mode traps can give you are really
fast garbage collectors, also tag bits for Lisp or Smalltalk
implementations can be exploited in interesting ways (take an unaligned
address trap if what you've got isn't a pointer to a cons cell, and still
have fast code for that case).

I think it's the main feature that's missing on most RISC implementations.


--
Joe Buck	jbuck@ohm.berkeley.edu
From: pete@ohm.york.ac.uk (-Pete French.)
Newsgroups: comp.arch
Subject: Re: Microcoded processors?
Date: 13 Apr 92 14:43:11 GMT
Organization: Electronics Department, University of York, UK

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

You could do it on a VAX, but thats hardly a microprocessor I suppose.

> And as a last question: Are there any approaches that use GALs as
> storage for microcode?

Not sure, it would seem to be a bit of a waste unless you're going to change
it frequently. We are working on systems here that use GALs/CALs (and any other
reconfigurable stuff we can lay our hands on really...) to implement processors
that will build hardware versions of commonly used functions as code runs -
the idea being that rather than give a processor a dedicated floating point or
vector unit you let it build one for itself if it finds that it is doing lots
of work that could benifit from hardware speedup. Whether we will actually get
a working system out of it does, however, remain to be seen.

-- 
-Pete French. (the -bat. )     -+
Adaptive Systems Engineering    |
                                +-       memento mori, remember to die
Xref: sparky comp.arch:4956 comp.sys.dec:2538
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.arch,comp.sys.dec
Subject: Re: Use of "crashme"
Date: 13 Apr 92 03:06:18 GMT
Followup-To: comp.arch
Organization: Canisius College, Buffalo NY. 14208

In article <00348@meph.UUCP>, gsarff@meph.UUCP (Gary Sarff) writes:
> ...........  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 because they do not have the resources to re-fix these bugs each
  time they receive a new port... there's enough to do in that realm 
  already, I presume, with X, NFS, etc..


  greg pavlov, 
  pavlov@fstrf.org
From: dow@idtg.UUCP (Keith Dow)
Newsgroups: comp.arch
Subject: Re: Generic Top Secret Microprocessor Development Plan
Date: 9 Apr 92 19:27:51 GMT
Organization: Integrated Device Technology, Santa Clara

>1993 Position new architecture as "the machine that everyone will run in
>	every platform from mainframes to toasters"



So far Mips and the Dec have already said this.

>1994 Scratch heads over lack of toaster-based applications, and the fact
>	that the unit cost is still too high to compete, which makes it
>	hard to convince people to base toasters on a $1800 chip

The 64-bit microprocessors can be down-sized easily.  Typically two
years after a microprocessor has been introduced, the package costs
more than the die. 

>>1999 Add to the MCM a massively parallel neural network implemented
>>2005 in subthreshold logic to save power.
>
>2006 Company goes out of business, while Microsoft DOS10.0-running Intel
>	based machines continue to dominate the market

Do you mean Windows-NT?  You may be right.  Good luck to you
Unix software guys though.  Intel I have a doubt about though.
Since several companies are beginning to make their cash cow, they
won't have such a cushy ride any more.
Xref: sparky comp.arch:4778 comp.lang.lisp:1319
From: meissner@osf.org (Michael Meissner)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 6 Apr 92 15:28:21 GMT
Article-I.D.: tiktok.MEISSNER.92Apr6102821
	<GLEW.92Apr1220416@pdx007.intel.com>
	<CARLTON.92Apr2164722@husc8.harvard.edu>
	<MEISSNER.92Apr3104846@tiktok.osf.org>
	<GLEW.92Apr3172834@pdx007.intel.com>
Organization: Open Software Foundation

In article <GLEW.92Apr3172834@pdx007.intel.com> glew@pdx007.intel.com
(Andy Glew) writes:

| I believe that the MC88110 has added signed offsets back to the 88K architecture.
| 
| Yep, here it is, from the COMPCON paper p. 157:
| 
|     "An option was added to allow 16-bit immediate address offsets and
|     literal constants to be treated as signed numbers (the original
|     88100 treated them as unsigned)."

I don't know how much of the 88110 architecture has been released or
not, but my memory of the signed offsets is that it's a mode bit in
the PSW, which makes it an all or nothing approach.

| I think that unsigned offsets in addresses are pretty much recognized
| as a nice thing for hardware, but not so nice for software.  Lacking
| evidence (beyond the very first architectural study I did, way back in
| 1983, on the distribution of constants), I believe that unsigned
| immediates in general are nice for hardware, but not necessarily the
| best thing to do for software.

For integer constants, and stack frame addresses, I agree that signed
offsets is generally more desirable than unsigned offsets.  However,
for things like loading up a global/static variable, it is less
desirable.  It forces you to add special relocations that deal with
the sign extension of bit 16, when the address is broken into two
instruction (load upper immediate followed by the memory instruction).
Futhermore, it prevents (or at least hinders) splitting up these two
instructions for scheduling purposes.

Finally, with regard to global addresses, I notice that botht he R4000
and Alpha do not deal at all well with global/static variable
addresses being more than 32-bits.  I think that there is an implicit
assumption that linkers won't put things above the 4G limit.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
Xref: sparky comp.arch:4915 comp.lang.lisp:1357
From: wilson@cs.utexas.edu (Paul Wilson)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 1992 16:56:05 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: boogie.cs.utexas.edu

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.

I'm not sure I follow this.  A high-performance implementation (read:
anything with an optimizing compiler) is going to have raw nonpointer
values in registers and/or the stack anyway, because keeping everything
tagged at all times is expensive.  Floats can be treated like any other
nonpointers (say, a word full of ASCII characters) in that respect.

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

   -- PRW

-- 
| Paul R. Wilson, runtime environmentalist          wilson@cs.utexas.edu      |
| U. of Texas Computer Sciences Dept.               voice: (512) 471-9555     |
| Taylor Hall 2.124, Austin, TX 78712-1188          fax:   (512) 471-8885     |
| "Inertia makes the world go 'round."              DoD M.C. # e  (Sz GS450T) |
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: Who will have the next killer micro?
Date: 14 Apr 92 13:59:57 GMT
Article-I.D.: chamarti.JINX.92Apr14095957
	<WAYNE.92Apr13083403@backbone.uucp>
Reply-To: jinx@zurich.ai.mit.edu
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: wayne@backbone.uucp's message of 13 Apr 92 14:34:03 GMT

In article <WAYNE.92Apr13083403@backbone.uucp> wayne@backbone.uucp (Wayne Schlitt) writes:

*   integer and one floating point instruction every cycle.  That would
*   mean that the peak FLOPS would be "only" 100 MFLOPS.  I would think
*   you could come much closer to this peak on the PA7100 than on the 730
*   though... 


The HP-PA 1.1 instruction set includes a multiply-and-add instruction
(and multiply-and-subtract) that can initiate two flops per cycle.
This is already true with the current generation of processors.

Note that the instruction is not a multiply-accumulate instruction,
but a separate multiply and a separate add.  The multiply is a
standard 3-register multiply (two sources, one target), the add is
restricted in that it only has two operands, one of which will be
overwritten by the instruction.