HDTenEightyP/NetNews huggingface dataset:
From: echen@hardy.u.washington.edu (Ed Chen)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 8 Apr 92 02:58:32 GMT
Organization: University of Washington, Seattle

In article <9jcHl1ok6@cs.psu.edu> danb@gaff.physci.psu.edu (Dan Babcock) writes:
>In article <1992Apr7.224947.19354@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?
>>>
>>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
>
>PC Magazines had an editorial a while ago that recommended its readers
>buy only 486's (similar to how they advocated the 386 a few years
>ago - except this time they're nuts). As a result I would expect all
>chip clones from now on to use the "486" number to please the
>ignorant consumers and magazines.
>

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.  
			
							Ed
							echen@u.washington.edu
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 17 Apr 1992 03:58:34 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <1992Apr16.173309.75482@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>
>Partitioning int/FP makes sense when the widths are, say, 64 and 80.
>It mostly makes sense anyway, since using int instructions on FP
>values leads to programs which e.g. incorrectly think that two NANs
>are equal.
>
>The 68K's int/pointer partition made it harder to write an optimizing
>compiler.

Here's a useful table:

Unified	Separate
	S/360
VAX	
	68K
	X86
88100	88110
	MIPS
	SPARC
	HP PA
	RS/6000
	Alpha

There may well be *reasons* for having separate integer & FP registers...
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS:	MIPS Computer Systems M/S 5-03, 950 DeGuigne, Sunnyvale, CA 94086-3650
Xref: sparky comp.arch:4920 comp.lang.lisp:1361
From: wilson@cs.utexas.edu (Paul Wilson)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 1992 18:44:36 -0500
Organization: CS Dept, University of Texas at Austin
NNTP-Posting-Host: boogie.cs.utexas.edu

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

I'm not exactly sure what you mean here.  Consider a closure to be
a procedure object paired with a particular binding environment
(set of captured variables).  Is it that you want to have a single
object (say, on the heap) that contains both the variables and the
actual executable code?  Is it insufficient to pair a code pointer
with the variables, and call the code indirectly?

(In our Scheme system, we currently represent closures as objects
unto themselves, which hold a pointer to the variable binding environment
and a pointer to the executable code object.  Since you may have many
closures of the same procedure in different---but similarly-structured---
environments, this keeps you from replicating the actual code;  you
just share it using a pointer.)

What is it that you have trouble doing for GNU C?  Do you really need
to be able to execute straight out of user space, or just reclassify
code pages as executable (non-writable) after writing the instructions
there?

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

Yes.  Page-outs, too.  (It's often nice to know when writes get reflected
to disk, and be able to take some special action.)

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

Invisible pointers can be checked in parallel hardware (as on the
Symbolics) rather than in microcode (as on the MIT and at least
some TI Lisp machines).  That's why adding the hardware support is 
not an unreasonable idea---e.g., if you can use it for a parallel
system with futures, where you need to check whether a value is
present (or is still being computed by another thread, in which case
you trap the attempted access and block the thread that attempted it).
 
  -- 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) |
Xref: sparky comp.arch:4802 comp.lang.lisp:1329
From: markt@harlqn.co.uk (Mark Tillotson)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 7 Apr 92 13:13:40 GMT
Organization: Harlequin Limited, Cambridge, England

Andy Glew, glew@ichips.intel.com writes:

> One idea I've always been fond of is to provide an architectural mask,
> part of process context, that is ANDed with all virtual addresses, so
> software doesn't need to mask off the tag before addressing.

But that doesn't gain you anything, since once you've tested the tag,
you can subtract it for free in the addressing mode... (moral, use low
bits for tags!)  (Actually I'm not really being fair, since this might
be handy for BiBOP heap schemes, but you certainly don't want it to
apply to every memory reference!)

Concurrent tag testing, plus a lightweight user trap mechanism are
probably what I'd vote for.  To make it RISCy, how about having a few
bits in each instruction which set a tag-comparison register, which is
used to test subsequent data operations.  This could be done in a
separate execution unit in the processor.

> By now, people are pretty good at placing tags in the upper bits of a
> pointer, and/or in the lower bits of a pointer where misaligned
> address traps can be used to do some tag checking.

No, that doesn't do the job--when only one tag is valid, it is fine to
use a trap for the other (error) cases, but when discriminating
between different valid tags, you want a multiway dispatch on the tag,
which is not really very RISClike, unfortunately.  
Currently the cost of an OS trap is measured in milliseconds!!  This
is part of the reason people want lightweight user traps.

Another thing that might be useful is user access to the dirty-page
information, since this is very handy for keeping track of wrong-way
pointers in a generational GC... (and parallel GCs?)

And finally I would put a plea in for flexible addressing mode on
RISCs, of the form:
[Rb + Ri<<n + d]   Base register plus scaled index plus displacement (signed)
The key point is that the scaling should be by a power of 2 that is
specified in the instruction, (here n), NOT implied by the size of
operand.  This means that you can represent integers with low-order
zero tag bits and still use them directly to address vectors of bytes,
words, or doubles...  Of course n is signed too, so the shift is
either way!

You might think a complex address mode isn't RISCish, but if it is the
only mode, then it is RISC..  (After all it is a shame to waste the
ALU during load/store instructions).

--

------------------------------------------------------
|\  /|          | ,  M. Tillotson       Harlequin Ltd. \
| \/ |  /\| |/\ |<   markt@uk.co.harlqn  Barrington Hall,\
|    |  \_| |   | \  +44 223 872522       Barrington,      \
I came, I saw, I core-dumped...            Cambridge CB2 5RG \
My opinions, like my teeth, are all my own (and full of holes?)\
Newsgroups: comp.arch,comp.ai
From: ljenkins@adobe.com (Luis Jenkins)
Subject: Re: Who will have the next killer micro?
Organization: Adobe Systems Incorporated
Date: Thu, 9 Apr 1992 01:16:59 GMT

In article <ABRAHAM.92Apr1042957@loke.iesd.auc.dk> abraham@iesd.auc.dk 
(Per Abrahamsen) writes:
> ....
>I thought Sun wanted the CPU manufacturers competing among themselves
>with many different designs and implementations.  Sun would then just
>pick the best.
> ....

Speaking about that, does anybody have information on what semiconductor
houses are currently shipping SPARC chips, in what speeds and in what
volume numbers? And what percentage of those are used by SPARC cloners?

Xref: sparky comp.arch:5107 alt.folklore.computers:6565
From: lupe@ukw.uucp (Lupe Christoph)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: chip-on-chip technology
Date: 16 Apr 92 20:51:06 GMT
Organization: cic

peterk@public.sub.org (Peter Kittel) writes:

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

>And as we here don't know this funny character at all, we say
>"Doppelkreuz-define", that would be "double cross" in English.

Well, I learned to call it "Gartenzaun", garden fence.
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany)              |  this *is* the opinion  |
| Res non sunt complicanda praeter necessitatem. |  of my employer.        |
Xref: sparky comp.arch:4943 comp.ai:1965
From: gumby@Cygnus.COM (David V. Wallace)
Subject: reg windows are losers (was: Ideas for new LISP Machines)
	<kumaeoINNpkv@estoril.cs.utexas.edu> <43628@as0c.sei.cmu.edu>
	<1034@armltd.uucp>
Organization: Cygnus Support, Palo Alto, California
Date: 16 Apr 92 12:48:25

   Date: 16 Apr 92 12:48:19 GMT
   From: abaum@armltd.uucp (Allen Baum)

   firth@sei.cmu.edu (Robert Firth) writes:

   (re: SPARC being register rich/poor)
   >In case you haven't guessed it, the trick is very simple: get rid of
   >those stupid register windows.  You also have the satisfaction of
   >knowing that 40% of your memory traffic isn't being wasted in saving
   >and restoring empty registers.

   I always though it was obvious that if windows were a bad idead, then
   you could still run on a Sparc by not using them. I don't think there
   is anything forcing you to do so. Still, I have a few questions:

   -are there compilers for the Sparc that don't use the windows?

I assume you mean C compilers: It's easy to do this with gcc; you have
to fix gdb too if you want to debug your programs.  I think Firth
implied that Python does this too.

   -is it Sparc's implementation that is a bad idea, or the whole
    concept of overlapped, automatically pushed windows? For example,
    what if the overlap size was variable (i.e. you push exactly what
    you need)? Does the fixed set of globals still make this a bad
    idea?

Look at the 29K.  (an architecture, by the way, with a scad, or even
1.5 scads, of registers).

   -Sun would claim that deep call/return structures are infrequent,
    i.e. you tend to hover around some stack depth, and hysteresis
    would tend to keep register spilling to/from memory
    infrequent. So, I'm not sure where your 40% of memory traffic
    is coming from- could you explain?

This goes back to the Berkeley RISC, which was designed to run unix
programs.  Those folks profiled existing code, and designed the reg
windows to speed that kind of code up (fairly shallow, or
initially-deep-and then shallow calling depth).  Many lisp and
especially scheme programs do not have this kind of execution trace.
Newsgroups: comp.arch
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Subject: Re: Rambus
Date: Fri, 10 Apr 92 02:59:58 GMT
Organization: School of Computer Science, Carnegie Mellon


lamaster@viking.arc.nasa.gov (Hugh LaMaster -- RCS) writes:
>... long vector sustainable performance.  Looking
>at vector add (most data moved/MFLOPS),

>Extrapolating to a RAMbus-based system:
>
>500 MB/sec/(8 bytes/word)/(3 Words/FLOP) = 20 MB/sec.
>.75-.90 * 20. MB/sec = 15.6 - 18.75.  So, the back-of-envelope
>calculation for a RAMbus-based system would put the expected
>performance on this test at ~15-20 MFLOPS.

The 500 MB/s figure is during bursts.  With the current generation
Rambus DRAMs, and assuming sense-amp cache hit, read overhead is 48
ns, write overhead is 16 ns.  Assuming 32 B accesses, reads take
48+2*32 = 112 ns, for an actual bandwidth of 286 MB/s.  Nothing that
I've read indicates support for critical-word-first, so access
latency is most-or-all of that 112 ns.

Your long-vector-add benchmark can at most do 4 FLOP in 112+112+80 =
304 ns, ie 13 MFLOPS. Increasing the access size helps incrementally:
64 B/access allows 16 MFLOPS, etc. However, bigger access size gives
bigger access latency, which is already un-cache-like.

The promised 18 Mbit DRAMs will supposedly halve the overhead,
getting closer to your 20 MFLOPS figure. Using 2 or 4 rambuses in
parallel would allow correspondingly more, at the price of the
processor needing a rather wide cache line. Wide lines are only wins
when programs have very sequential access patterns. Cray can assume
that, but MIPS can't.

A 150 MHz processor sees 112 ns as 17 clocks: allowing critical-word-
first, as 10 clocks: and if the overhead does indeed get halved, as 7
clocks.  Well, 7 is getting to be a cache-like number, I suppose.
But it's still a little high, and 200 MHz is coming, so I expect
hot processors will still need copious SRAM.

>Is RAMbus just a single-CPU solution, or can
>it be used to produce a multiple-CPU server with high internal bandwidth?

The first implementation allows two masters on the bus, and any
access siezes the bus until it completes.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Xref: sparky comp.arch:4891 comp.lang.lisp:1351
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Ideas for new LISP Machines
Date: 10 Apr 92 10:34:44 GMT
Organization: Department of Computer Science, U of Copenhagen

markt@harlqn.co.uk (Mark Tillotson) writes:

>And finally I would put a plea in for flexible addressing mode on
>RISCs, of the form:
>[Rb + Ri<<n + d]   Base register plus scaled index plus displacement (signed)
>The key point is that the scaling should be by a power of 2 that is
>specified in the instruction, (here n), NOT implied by the size of
>operand.  This means that you can represent integers with low-order
>zero tag bits and still use them directly to address vectors of bytes,
>words, or doubles...  Of course n is signed too, so the shift is
>either way!

The closest I have seen to this on a RISC is the ARMs addressing
modes, where the following format (taken from a posting by Colin
Plumb) is used:

IPUBWLssssdddd222222222222 - Load/store - d <-> [s +/- 2]

If I=1, src2 is an immediate value, of the form rrrriiiiiiii, and the
value is the zero-extended byte i rotated right 2*d bits.  If I=1,
src2 is either ssssstt0rrrr, register r shifted (type t) by s bits (tt
= 00 for LSL, 01 for LSR, 10 for ASR, 11 for ROR), or ssss0tt1rrrr,
where ssss is the register holding the shift count.  (One extra cycle
for this form.)

The flag bits mean the following:
L - 1=load, 0=store
W - if 1, write result of address computation back to src1 register
B - 1=byte, 0=word
U - 1=ALU computes src1+src2, 0=ALU computes src1-src2
P - 1=src1 op src2 used as memory address; 0 = src1 used as memory address,
    and src1 op src2 only used for writeback (post-indexing).

Thus it can do either [Rb + d] or [Rb + Ri<<n], both not both in one
instruction. Using an arithmetic instruction and then a load/store
would do the trick.

	Torben Mogensen (torbenm@diku.dk)
From: smith@sctc.com (Rick Smith)
Newsgroups: comp.arch
Subject: Re: Voice Recog. on Desktop
Date: 9 Apr 92 19:49:03 GMT
Article-I.D.: sctc.1992Apr9.194903.15465
Organization: SCTC

sysmgr@king.eng.umd.edu (Doug Mohney) asks:

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

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

I worked on speech recognition about 15 years ago and Back Then the
estimates were about the same: "just a few more years..." The basic
problem hasn't gotten easier, though the cost of the processing you
need has gotten cheaper.

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

I haven't heard more than anecdotal evidence of general purpose speech
recognition systems. There have been effective applications of special
purpose speech systems for almost 20 years now. It'll be quite a while
before speech systems can compete with typists working from dictaphone
tapes.

Good speech recognition relies heavily on matching patterns.
Back Then we built custom autocorrelation circuits and used lots
of pipelining (processors were expensive and slow). The pattern
matching was the big bottleneck. 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. 

Rick.
smith@sctc.com        arden hills, minnesota
Newsgroups: comp.arch
From: rcain@netcom.com (Robert Cain)
Subject: Whence Andy?
Date: Fri, 10 Apr 92 05:25:35 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

When Andy Heller, spearhead of the IBM RS/6000 system, was politically
offed he quit IBM and a year or so later appeared as CEO of a new company
that, believe it or not, was named HAL.  Does anyone know what has come
of that startup?  It was heavily funded by a major Japanese firm and
he was real secretive about the product except that it was SparkLike.
-- 
Bob Cain    rcain@netcom.com   408-358-2007

"There are some strings.  They're just not attached."
                                                    Victoria Roberts
From: pendecot@armltd.uucp (Philip Endecott)
Newsgroups: comp.arch
Subject: Re: And now for something completely different...
Date: 8 Apr 92 14:28:27 GMT
Organization: Advanced RISC Machines Ltd


Travis C Hayes writes :

> 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?
  
Yes.  ARM does, and I imagine we're not the only ones.  The ARM
microprocessors have itterative multipliers which take between two and
seventeen cycles, depending on the position of the most significant bit set
in the multiplier.  Multiplication by any value in the range 4^(m-1) to
4^m -1 takes m internal cycles, plus one read to fetch the opcode.

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

You have a non-trivial problem here in detecting when the special cases
occur.  I often think that it would be worth detecting multiplication by -1
as a special case, as on ARM this takes the full 17 cycles.  In software, we
can do tricks like this, which use whichever value is smallest as the
multiplier :

  CMP   Rx, Ry       ; set condition codes depending on values of Rx and Ry
  MULGT Rz, Rx, Ry   ; if Rx is largest, use Ry as multiplier
  MULLE Rz, Ry, Rx   ; if Ry is largest, use Rx as multiplier

Whether this is any good in a particular case depends on the range of values
that Rx and Ry take, and the relative cycle times for internal cycles (fast)
and opcode fetches (maybe slower).

> Travis C. Hayes
> University of New Hampshire
> Computer Science Sophomore


-----------------------------------------------------------------------

Philip Endecott                      email : pendecot@armltd.co.uk
Advanced RISC Machines Ltd           Phone : +44 223 813000
Swaffham Bulbeck                     Fax   : +44 223 812800
CAMBRIDGE
CB5 0NA UK
Newsgroups: comp.arch
From: dow@nova2.stanford.edu (Keith Dow)
Subject:  Generic Top Secret Microprocessor Development Plan
Organization: Stanford University
Date: Thu, 9 Apr 1992 05:32:32 GMT


Since every company likes to keep its future plans secret, but every
one is doing pretty much the same thing, I have developed a generic 
top secret microprocessor development plan for them.


1992 Design a 64-bit microprocessor or start the design of one.

1993 64-bits, superscalar and 100Mhz (or more) at 3.3 volts.

1994 Improve the I-O by using Rambus or some other similar technology.

1995 Multi-chip module time as speeds approach 500Mhz.

1996 Discover that real people use computers, so add dsp and graphics
     acceleration to the MCM. 

1997 Add functions to handle 3-D virtual reality displays, plus
2000 neural network features.

1999 Add to the MCM a massively parallel neural network implemented
2005 in subthreshold logic to save power.

Please feel free to comment.
From: davidsen@yeti.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 9 Apr 92 15:05:13 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Apr8.214050.8967@adobe.com>, zalman@adobe.com (Zalman Stern) writes:

|  The new Cyrix chip does implement the entire i486 architecture. (If it  
|  doesn't, then Cyrix is being misleading.) In common parlance, people don't  
|  distinguish between the architecture (called i486) and the implementations  
|  (80486DX, 80486SX, CY486SLC, etc...). The computer buying public really  
|  doesn't care about the i486 architecture. To them, "486" means "fast" or  
|  "sleek and sexy."

  The things which distinguish the 486 from 386 are (a) slightly
diferent instruction set, and (b) integral FPU. While the integrated
cache and better instruction timing are performance boosters, adding
those features will not make a chip a 486, nor let it run 486-only
software.

|  The notion that computer performance be determined analytically (say by  
|  using relevant benchmarks) is alien to most of the PC world. Similar  
|  differences in performance to those of the various i486 chips can occur  
|  because of differences in the cache and I/O subsystems. Should we shoot  
|  the marketeers for calling a slow badly designed system a 486?

  Sounds good to me, can we televise it on pay-per-view to scare some of
the other sleazy marketers?
-- 
	- 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
Newsgroups: comp.arch,comp.ai