HDTenEightyP/NetNews huggingface dataset:
From: nradov@jarthur.claremont.edu (Slippery Jim)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 01:40:32 GMT
Organization: Harvey Mudd College, Claremont, CA 91711

In article <1992Apr6.131334.22658@cis.uab.edu> 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:
>>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
>>

The Cyrix 486 is a pin compatible replacement for the 386sx.  Despite the
name however, it isn't a real 486, just a 386sx with a small internal cache
and a few other improvements to make it run faster.  I think that Cyrix
claims it will be up to 70% as fast as a real 486 at the same clock speed,
but I haven't seen any tests.  Doing the replacement should be easy if
your 386sx isn't soldered in.
-Nick Radov (nradov@jarthur.claremont.edu)
Xref: sparky comp.arch:4779 comp.lang.lisp:1320
From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 6 Apr 92 23:48:30 GMT
Article-I.D.: chamarti.JINX.92Apr6194830
Reply-To: jinx@zurich.ai.mit.edu
Followup-To: comp.arch
Organization: M.I.T. Artificial Intelligence Lab.
In-reply-to: torbenm@diku.dk's message of 2 Apr 92 09:56:32 GMT

In article <1992Apr2.095632.11709@odin.diku.dk> torbenm@diku.dk (Torben AEgidius Mogensen) writes:

* The problem with special purpose LISP architectuers is that they tend
* to use a technology that is a few years behind the "hottest" RISC
* processors. THis means that clever implementations on RISC processors
* tend to be faster or at least as fast as implementations on dedicated
* LISP hardware. I would expect that, with the present compiler
* technology, a dedicated LISP architecture using state-of-the-art
* design and fabrication technology would be 20-50% faster than LISP on
* RISC processors.

Well, I'm not quite sure.  There are two major places where Lisp pays
a significant cost on current RISC hardware:

- Generic arithmetic.
- Type/range checking.

The way to get efficient LISP code on RISC machines is to write
un-Lispy code, that is, to tell the compiler to compile unsafely (no
type or range checking) and to ignore generic arithmetic and use
fixnum-specific or flonum-specific arithmetic instead.

If you are willing to do this (and in that case you might be better
off programming in C), then you can get code close to the efficiency
of C, whereas with a little hardware support Lisp programmers could
have their cake and eat it too.

* >If one took the hardware approach what features should be implemented
* >in hardware to increase LISP performance, make it more robust,
* >maintainable, or flexible.

* >Another way to look at this question is what features of today's
* >architectures makes the implementation a LISP system hard.

* Hardly any.

Again, I disagree.  If you want an efficient (compared to C) Lisp,
in which users can use generic arithmetic, and don't have to worry
about their system blowing up underneath them, then it is very hard.
Xref: sparky comp.arch:5011 comp.lang.lisp:1388
Newsgroups: comp.arch

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

---------------------------------------------------------------------------
DISCLAIMER:  The views expressed here do not		Linley Gwennap
represent the views of the Hewlett-Packard		PA-RISC Marketing
Company.  Caveat emptor.				Hewlett-Packard
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Cray Soap Opera WAS: Re: GaAs Alpha implementation
Keywords: Alpha, Gallium Arsenide
Date: 9 Apr 92 15:17:37 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Apr06.174145.10353@skynet.uucp>, ice@skynet.uucp (Ice) writes:

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

  He is still working on his computer system. I'm working with someone
who was in Chen's group the last few years, and he reports that work is
prograssing. Since he's honoring the non-d very closely I don't have any
tidbits to reveal, nor would I if I had them, but Chen is still very
much doing computer design.
-- 
	- bill davidsen (davidsen@crd.ge.com)
	GE Corp. R&D Center; Box 8; Schenectady NY 12345
By analysis of usenet source, the hardest part of C to use is the comment
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: comp.arch
Subject: Re: Tagged Architectures.
Date: 8 Apr 92 13:27:52 GMT

From article <1992Apr8.050251.6313@news.unomaha.edu>,
by FULKERSON@Zeus.unomaha.edu (Robert Fulkerson):
>
> a 1973 paper by Fuestel.  I am curious as to whether or not tagged
> architectures emerged into the 1980s or 1990s at all

You should take a look at the IBM System 38 / AS 400 development.  The only
problem with that machine is that IBM's documentation seems to go out of
its way to obscure how the machine works.  It is a capability architecture,
with tagging used to distinguish capabilities from data.  All other type
information is carried by the capabilities.  Much of the security of the
architecture rests on the loader, which takes strongly typed object code
and finishes the compilation process to produce weakly typed machine code
that IBM calls vertical microcode.

In the original design of the System 38, the vertical microcode was really
microcode; it was used to directly interpret the strongly typed instruction
set of the System 38.  The problem was that this was slow, so the loader was
enhanced so that it compiled code segments in the officially defined
System 38 instruction set into vertical microcode.  The vertical
microinstruction set of this machine is a typical register-memory
architecture in many ways, but with special support for the operations that
are needed to support the secure tagged capability architecture.  The
advantage of compilation to this lower level architecture at load time are
that things like capability access rights checking can be done once
prior to a long sequence of accesses, instead of having the access rights
on a capability checked with every use.

					Doug Jones
					jones@cs.uiowa.edu
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: Microcoded processors?
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Tue, 14 Apr 92 17:06:20 GMT

In article <36204@ogicse.ogi.edu> borasky@ogicse.ogi.edu (M. Edward Borasky) writes:
>>In article <1992Apr10.214150.5525@cs.tu-berlin.de> tolk@opal.cs.tu-berlin.de (Robert Tolksdorf) writes:
>> > are there or have there been microcoded microprocessors on which the
>> > microprogram could be changed during runtime thus changing the
>> > semantics of assembly-code??
>This idea was implemented at least once in the 1960s.  I forget the
>name of the vendor but they built a microprogrammed machine that could 
>emulate the popular 36-bit machines of the day -- IBM 7040/7090, UNIVAC 
>1106/1108, etc.  I believe someone more recently built a chip-slice
>machine (AMD parts, I think) that emulated either a PDP-11 or Intel
>8086, depending on the microcode.

I know of two machines which had this property. 
The Nanodata QM-1 was a user-programmable microcode machine. It was
built by Nanodata Corp, Buffalo NY. I think that Bob Rosin (microcode
heavy at SUNY at Buffalo) was a principal of that organization.

The Burroughs B1700. Don't know more than that, and may in fact have the
model number wrong...

Bob




Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.arch,comp.lang.lisp
From: solworth@bert.eecs.uic.edu (Jon Solworth)
Subject: Re: Ideas for new LISP Machines
Organization: University of Illinois at Chicago
Date: Wed, 8 Apr 1992 18:48:14 GMT

mash@mips.com (John Mashey) writes:

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

>The proposed addressing mode needs to add 3 distinct inputs, which probably
>means back-to-back adds *before* the data address is available. There is
>a good chance that this could be in the critical path for many pipelined
>designs.
>H&P note that from IBM S/360 data on [Rb + Ri + d], 85% of the time,
>Ri was 0.

I find myself almost always agreeing with John Mashey, but not this time.
Frankly, I don't see anything *fundamentally* different --- the above statement
is like saying several years ago that multiply instructions are fundamentally
different -- they are not, they just take more hardware to build efficiently.
The addressing instruction could be executed efficiently with a carry-save
adder and need not use the adder used in the ALU.

Also, it is OK to increase the critical path in a RISC (or any other processor)
if the added functionality reduces average computation time.

Jon Solworth

===============================================================================
Jon A. Solworth                 internet:  solworth@parsys.eecs.uic.edu
Dept. of EECS (M/C 154)         telephone: (312) 996-0955
University of Illinois          FAX:       (312) 413-0024
P.O. Box 4348
Chicago, Illinois 60680
From: doconnor@oxygen.inews.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: Who will have the next killer micro?
Date: 6 Apr 92 18:31:27 GMT
	<1992Mar27.034314.926@morrow.stanford.edu> <104Hwtqb6@cs.psu.edu>
	<121292@lll-winken.LLNL.GOV>
	<1992Mar30.001224.6147@noose.ecn.purdue.edu>
	<1992Mar30.010520.7436@noose.ecn.purdue.edu>
Organization: /eng/eng25/doconnor/.organization
In-reply-to: helz@ecn.purdue.edu's message of 30 Mar 92 01:05:20 GMT


helz@ecn.purdue.edu (Randall A Helzerman) writes:
] Wait a minute--I think that throwing laptops into this was a bit of a
] red herring--can't you clock a 3.3V processor faster than a 5V processor?

That depends on what is limiting your clock rates. Generally, CMOS
gates switch more slowly with lower supply voltages. However, in
large chips, it may not be gate speeds that limit your clock rate.
Rather, it may be power disipation that sets the limit. Power
dissipation is a nearly-linear function of frequency in a CMOS
circuit, and to a first order aproximation a function of supply
voltage SQUARED. So if a chip's clock rate were limited by power
dissipation alone, then dropping the supply voltage from 5V
to 3.3V (if possible for the chip) would allow an aproximate 
doubling of the clock rate with the same power dissipation.

Relevant equations :

	Energy in a capacitor = 0.5 * C * V**2 ;

	Power disspated charging/discharging a capacitor =
		frequency_of_charge/discharge * Energy_in_charged_capacitor

	Therefor, for a CMOS circuit with an average switched capacitive
	 load C, switched voltage delta V, and switching rate F ;

		P = 0.5 * F * C * V^^2

Now I've (re)derived this myself so it could be wrong. Probably the
gates-and-wires guys have a better equation. Corrections are solicited.
But you can see why laptops and Alpha are going to 3.3V.
--
Dennis O'Connor			doconnor@sedona.intel.com
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Summary: Alpha conditional move
Keywords: conditional execution
Date: 7 Apr 92 00:02:52 GMT
Distribution: comp
Organization: Digital Equipment Corporation


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?  
> [rest deleted]

Alpha implements conditional move instructions, general syntax:

	CMOV{br cond}	a,b,c		! if a br cond 0, then c < -- b

for both integer and floating point.  These are used for "branchless"
short sequences, such as min and max, to avoid disrupting the instruction
pipeline.

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
Newsgroups: comp.arch,comp.lang.lisp
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: Ideas for new LISP Machines
Organization: The Backbone Cabal
	<GUMBY.92Apr7160702@Cygnus.COM> <kuc3nlINN46s@boogie.cs.utexas.edu>
	<GUMBY.92Apr14021204@Cygnus.COM>
Date: Tue, 14 Apr 1992 14:00:35 GMT

In article <GUMBY.92Apr14021204@Cygnus.COM> gumby@Cygnus.COM (David V. Wallace) writes:
>  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. [ ... ]

umm, pardon my ignorance, but in what way is the sparc a
"register-poor" architecture?  I thought it had 32 registers, split
between calling, current and called functions.  Isnt this enough?


-wayne
Xref: sparky comp.arch:4952 alt.folklore.computers:6335
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re:  chip-on-chip technology
From: Gavin.Flower@comp.vuw.ac.nz (Gavin Flower)
Date: Sun, 12 Apr 1992 22:01:38 GMT
Organization: Dept. of Comp. Sci., Victoria Uni. of Wellington, New Zealand.


In article <liam.02qi@durie.amigans.gen.nz>, liam@durie.amigans.gen.nz (Liam Greenwood) writes:
|> In article <id.D1PO.B0K@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
|> >In article <1223@eouk15.abcl.co.uk> pcockere@abcl.co.uk (Pete Cockerell) writes:
|> >> #define
|> >
|> >> is pronounced `pound-define' (not `hash-define')
|> >
|> >No, it's pronounced `number-define'. :->
|> 
|> 'hash-define' in these parts.

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


Gavin

-- 
                     Tomorrow's Society
                         Depends on
                     Today's Children  - help us raise them properly!
******* These comments have no known correlation with dept. policy! *******
From: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 16 Apr 92 12:31:43 GMT
Organization: Advanced RISC Machines Ltd

shap@xanadu.com (Jonathan Shapiro) writes:

>FYI, on the SPARC architecture, the LISP vendors have stopped using
>the tagged math instructions.  The tag bit code turned out to be the
>wrong choice.  SPARC chose 00 as the fixnum code, which really wants
>to be a pointer tag.

 I must be missing something obvious.  If the fixnum tag is 00, nothing
special must be done to the addition; if it anything else, it must be
subtracted from an addition, and added for a subtraction.

Now, there may be some implication about using (say) 01 as a pointer
tag in an architecture that can't have negative displacements, but
that architecture has to get around that problem anyway- so why
is a fixnum tag of 00 the wrong choice?
Newsgroups: comp.arch
From: mjr@hussar.dco.dec.com (Marcus J. "will do TCP/IP for food" Ranum)
Subject: Re: Generic Top Secret Microprocessor Development Plan
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Thu, 9 Apr 1992 21:09:54 GMT

dow@idtg.UUCP (Keith Dow) writes:

>Do you mean Windows-NT?  You may be right.  Good luck to you
>Unix software guys though.

	I'm not sure if I'm worried about NT or not. From what I gather
it's UNIX, in a lot of ways. Before you flay me, let me explain:

	It's big: I have heard 16Mb on a 486 is a "usable" system

	Now, if someone had a multitasking, efficient operating system
with a windows API that could run DOS applications pretty reasonably,
without requiring a dramatic investment in memory and hardware, I think
it could capture the upward DOS migration trend. With a "typical PC user"
workload (single user, not too many processes, certainly not timesharing)
you *should* be able to get by on current 386es with 4Mb or so, no
problem. If you consider the cost of the memory and hardware that NT
may require, DOSX.0 may be a better deal, and people won't switch to NT
unless there's a clear benefit.

	Still probably won't poor, fat, bloated old UNIX, tho...

mjr.
-- 
When they say "GNU's not UNIX" they mean they have abandoned the UNIX
tenets of "simplicity, elegance, and ease of use."	- rcd
Newsgroups: comp.arch
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Ideas for new LISP Machines
Organization: Massachusetts Institute of Technology
Date: Sat, 11 Apr 1992 16:19:59 GMT

In article <JINX.92Apr11095717@chamarti.ai.mit.edu>
	jinx@zurich.ai.mit.edu writes:

>- External constraints on procedure representation to maintain
>inter-callability, e.g. Unix's qsort routine expects an ordinary
>function pointer, not a closure.

>- Even if the representation were uniform for a given system, that is
>all procedures used two words to contain a code pointer and
>environment pointer, this representation penalizes the vast majority
>of procedures in the world, for which the environment pointer is
>ignored!  The price of closures should be paid by closures, not by
>everything else.

The RS/6000 includes an environment pointer in all function pointers.
This doesn't add much cost because:

	(1) There is already an extra word in the function pointer
	which is used to make all code position-independent and support
	dynamic linking.

	(2) Only calls that use pointers suffer the penalty.  The vast
	majority of function calls are by name, and calls by name to a
	C function do not need to load an environment pointer.

	(3) The load of register 11 is completely overlapped with other
	operations, so indirect calls are not slowed by the presence of
	an environment pointer.  The only cost is the extra word of memory.

Adding an environment pointer to the standard function pointer format also
allows support of nested functions without using two pointer formats and
without generating code.

--
    John Carr (jfc@athena.mit.edu)
From: jgoodman@endor.uucp (Joshua Goodman)
Newsgroups: comp.arch
Subject: Re: Voice Recog. on Desktop
Summary: Voice Recognition -- hear today.
Keywords: speech, voice, dragon
Date: 9 Apr 92 20:47:49 GMT
Article-I.D.: das.1992Apr9.204749.5223
Followup-To: comp.ai
Organization: Aiken Computation Lab, Harvard University

In article <1992Apr9.194903.15465@sctc.com> smith@sctc.com (Rick
Smith) writes: >sysmgr@king.eng.umd.edu (Doug Mohney) asks:
>>I'm thinking it's going to take 2-3 years for first solutions, and
>>another 1-2 on top of that before we have "good" solutions.  
>>Speech recognitizion solutions do exist today, but they're not
>>"mainstream" and cost much bucks, when compared to the cost of a PC....

>It'll be quite a while
>before speech systems can compete with typists working from dictaphone
>tapes.

>I've heard that recent systems
>support bigger vocabularies (more patterns) and I'll bet they
>require boxfuls of processors to do it in real time. 

Well, I've redirected followups to comp.ai, which seems to be the
closest place to the right group to put them, unless you want to
follow up specifically on the hardware...

But I should note that there is a commercial implementation, Dragon
Dictate, of a 30,000 word speaker adaptive discreet speech recognition
system.  Speakers reach 30-40 words a minute.  It runs in real time on
a 386.  The only additional hardware (I think) is a DSP board for
doing the Fourier Transforms.  Dragon Dictate's not cheap, but not
because of hardware.  The main market is people who can't type
(differently abled, as the PC police like to say).

Also, Apple recently announced something about speech recognition
technology, but I think they're less ambitious, and they're not
shipping for quite a while.

By the way, I'm going to be working for Dragon in July, so I am the
worst possible source of information: biased because I have an
interest in the company, but not enough of an insider to be sure I
have my facts straight. :-)

--Joshua Goodman
biased source of mostly correct information
Newsgroups: comp.arch
From: coleman@riemann.gsfc.nasa.gov ()
Subject: Convex C220 numbers???
Organization: NASA Goddard Space Flight Center, Greenbelt MD
Date: Wed, 15 Apr 1992 13:50:47 GMT

Anyone know the numbers on a Convex C220?
clock speed?, memory bw?, disk speed?, and MFLOPS,
if possible, MFLOPS peak at 32 bit and 64.
Thanks,
Greg C. 

- Greg Coleman/Cray Research
  c/o NASA GSFC/301-286-2333
  coleman@eastrg2.cray.com



Newsgroups: comp.arch
From: shocking@cxbne.cx.OZ.AU (Steve Hocking)
Subject: Re: Cyrix 486
Organization: Comperex Australia Pty Limited
Date: Tue, 7 Apr 1992 09:21:19 GMT

I get the dreadful suspicion that this is actually an April Fool's day joke...


	Stephen
-- 
-------------------------------------------------------------------------------
"Love makes the world go around, but sex makes the ride fun"
		Stephen Hocking - Unix consultant
shocking@cxbne.cx.oz.au			-	I am responsible for myself...