HDTenEightyP/NetNews huggingface dataset:
From: mchst12@cislabs.pitt.edu (Mark Hahn)
Newsgroups: comp.arch
Subject: some details on Pentium.
Keywords: RISC Pentium (tm)
Date: 9 Nov 92 02:11:31 GMT
Reply-To: mchst12@pitt.edu

There was some recent discussion of how Pentium works.  As it happens, Intel
honcho David House was here (well, CMU, actually,) this Monday.  Along with 
lots of razzle-dazzle about how good and important multimedia is going to be,
he talked about Pentium.  He showed something that looked like a die photo,
but some major blocks were suspiciously undetailed.  This discussion is
entirely from memory.

40% of the chip is separate but coherent I and D caches.  Another major chunk
is the FPU, of course.  The ALU is 2-way superscalar, but more of a master-
slave organization, which shows in its obviously asymmetrical appearance.  
A relatively minor block is dedicated to 'complex' behavior.  'Complex' in 
the context of x86 instructions means stuff like "rep movs{bwd}" for 
block moves, and, presumably, all the baroque Multix-ish OS-support stuff.  
These operations are accomplished by a special unit that composes them from
'simple' operations.  House said that in the 486 this is implemented via
microcode, but hardcoded in the Pentium.  You have to remember that the x86
provides no memory-memory operations except the block move mentioned above
and a couple of read-modify-write thingies.  That's right: x86 is mostly
load/store.  Of course, it's got variable-length instruction coding, two
different layers of memory protection, and too, too few registers, so noone 
is ever going to call it a RISC.

To restate: Pentium is organized like a modern RISC, but with a microscopic
register set, variable-length instructions and a little 'stunt-box' on the
middle-right to compose complex operations.

regards, Mark
From: jcallen@marley.think.com (Jerry Callen)
Newsgroups: comp.arch
Subject: MIPS R4400
Date: 6 Nov 92 13:52:00
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: comp
NNTP-Posting-Host: marley.think.com


The Nov 2 issue of EE Times contains an article on the new MIPS R4400
chip. Quick summary:

- 2.3 million transistors (vs 1.1 million(?) for the R4000)
- .6 vs .8 micron process
- 75MHz external clock, 150MHz internal
- 3.3V and 5V versions available
- I and D caches doubled to 16K each, still direct mapped.
- MIPS has sample silicon from at least one source, and
  expects sampling this quarter and production chips in
  early 1993.

The die photo looks a lot like the R4000 die photo, but with
noticably larger caches. The article notes that much of the R4000
design was reused (no surprise).

The article mentions that a "large write buffer" was added. Could
someone from MIPS comment on the size of the buffer, and the implications
for the memory system?

Also, where are all the extra transistors going? I believe I've read in
posts by John Mashey that the R4000 uses about 600k transistors for
everything except the cache, which suggests that the two 8K caches on the
R4000 use about 500K transistors, so I might (naively) expect the two 16K
caches on the R4400 to use about a million. Did the write buffer consume
700K transistors?!?

The article also says that MIPS is predicting performance at 75MHZ,
based on simulations, to be:

	SPECint89 = 95
	SPECfp89  = 126

[I was surprised to see MIPS use SPEC 89 numbers...]

--
-- Jerry Callen
   jcallen@world.std.com           (preferred)
   jcallen@think.com               (OK, too)
   {uunet,harvard}!think!jcallen   (if you must)
Newsgroups: comp.arch
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Integers implementation
Organization: Purdue University Statistics Department
Date: Fri, 6 Nov 1992 16:03:23 GMT

In article <1992Nov6.144502.17520@osf.org> fabre@gr.osf.org (Christian Fabre) writes:

>I have a question about integers representation.

>Most of today architecture use 2's complement scheme to represent
>signed integers. About other possibilities, like 1's complement,
>I have the following questions:

> - What are their advantges ?
> - What are their drawbacks ?
> - Are they usefull for any given set of aplications ?
> - Are they likely to pop-up in future processor design ?

>Any input welcome, please reply by news.

For 2's complement, the advantages are simplicity of multiple-precision,
and this can take many forms, including size expansion, and the fact that
there is only one 0.  This last is a real problem for the others.

The alternatives I have seen are  1's complement and sign-magnitude.  The
advantages are that negation is very much simpler, as is absolute value.
Since the negative of a negative number is always positive, it does not
have the problem which 2-s complement machines have, that the negative 
of the most negative number comes out negative.  

Each of them has advantages and disadvantages in multiple precision. 
Notice that floating point is almost always sign-magnitude.  
-- 
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: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha AXP System Performance
Organization: Digital Equipment Corporation
Date: 10 NOV 92 16:07:05    


In article <BxIJxr.GD5.1@cs.cmu.edu>, nickh@CS.CMU.EDU (Nick Haines) writes...
> 
>Two questions:
> 
>	- how much do these machines cost? What's the SPEC/$?

DEC 3000 Model 400 AXP starts at $15K
DEC 3000 Model 500 AXP starts at $39K
DEC 4000 AXP starts at about $70K
DEC 7000 AXP starts at about $150K
DEC 10000 AXP starts at about $300K

My numbers may be off by a small amount, but are in the right ballpark.

>	- is the dropoff in SPEC/MHz due to smaller caches?

Yes. The 2 workstations use a 512KB cache. The DEC 4000 AXP has 1 MB. The
2 larger systems use 4 MB.

Dileep
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: IEEE used for Dollars and Cents
Organization: Keith's Computer, Hope Mills, NC
Date: Thu, 05 Nov 92 13:33:22 GMT

In article <1917307@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>kludge@grissom.larc.nasa.gov (Scott Dorsey) writes:
>> dollars and cents.  Why bother?  Use a fixed point format with two or three
>> digits after the decimal place.  You save storage space (why store an exponent
>> since it's going to be the same three values everywhere?), you save compute
>
>Except that most machines only handle 32 bit or less integers cleanly, and
>with two decimal places that's only up to $21,474,836.47 (assuming signed
>integers).  Alas, totals frequently exceed that amount (and even
>transactions in some applications).
>
>Machines that can handle 64 bit integers cleanly will make this problem
>largely go away.  8-)

A pretty darn big assumption that you only need 2 or 3 decimal places of
precision in a financial calculation.  We have some 4 decimal place
multiplication here.

Why doesen't someone build a bcd or bcddouble type INTO the 'C' compiler
with a higher order than float.  Numbers could be 8 or 16 bytes, 2 bytes
of sign/exponent, and eith 7 or 15 bytes of mantissa, (14 or 30
*DECIMAL* as in BASE 10 places of precision).

Why don't *I*?  Well,  I started to once, but the compilers are changing
faster than I can code.
-- 
Keith Smith          uunet!ksmith!keith            5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...
From: ajayshah@almaak.usc.edu (Ajay Shah)
Newsgroups: comp.arch
Subject: Re: News Release - Pentium - "INTEL UNVEILS NAME FOR ITS FIFTH GENERATION COMPATIBLE MICROPROCESSOR"
Date: 10 Nov 1992 14:14:14 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: almaak.usc.edu

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

>  What Intel marketing is doing is dangling the product just out of
>reach to discourage major users from scraping DOS and Intel and going to
>a reasonable workstation to get affordable performance. Just as IBM

IMHO the sickest case of "dangling a nonexistent product" is Windows
NT.  It's how Microsoft manages to flog revenues out of the dead
horses of DOS and Windows.  Apparently even OS/2 is a "better OS" than
Microsoft's offerings, whatever that means.

>  And when it comes out and vendors are charging $2k per chip because
>everyone's on allocation Intel will promise to ramp up production, just
>as they did with the 486. And just like the 486 the actual price drop
>will come when AMD releases a faster cheaper 486, and not a moment

Does anyone know more about how the new MicroSPARC CPU costs only
$180 in 10k qtys?  It features an incredibly high level of integration.

Is it just a case of Intel being a stinking monopoly?

        -ans.
-- 
Ajay Shah, (213)749-8133, ajayshah@usc.edu
Newsgroups: comp.arch,comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: gotos in hardware
Organization: Purdue University Statistics Department
Date: Sat, 7 Nov 1992 13:25:41 GMT

In article <1992Nov6.111616.109@turtle.fisher.com> ferris@turtle.fisher.com writes:
>Since this discussion is posted in comp.architecture shouldn't we be
>discussing the possibility of a goto-less object code?

>I believe that it is possible at the micro-code level but not at the
>machine level. However, I can envision something like:

			.................................

Now I raise the question as to why anyone would want to do this?  The only
answer I can think of is that it would eliminate the possibilities of coding
for speed, and lighten the load on compilers.

Since computing relative to memory access was speeded up about 30 years ago,
there have been various amounts of look-ahead and scheduling.  A goto, with
no intervening possible exits, should be handled in such a way that that
the hardware starts getting the code at the new location early, so that
there are no unnecessary delays.  It could even issue instructions from
that "new" code in the same way it does from current code.  The "structured"
approach, where unconditional transfers are not the rule, prevents this
type of optimization.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: BCD Addition
Date: 8 Nov 92 23:51:51 GMT
Organization: Auspex Systems, Santa Clara

>>To be more precise: PA-RISC maintains carry bits for each BCD digit,
>>which allows BCD addition/subtraction using a decimal correct
>>instruction after each normal ADD/SUB. (It has IDCOR to re-bias
>>intermediate results, and DCOR to un-bias final results.)

	...

>Which probably explains why HP is doing well in the business markets.

It might, or it might not.  It depends on how much it speeds BCD
arithmetic up.

There may be other explanations (I assume here that HP-PA machines are,
in fact, doing better in business markets than other RISC machines; I'd
have no problem believing it's true, but I have no evidence for or
against that claim).

For example, other vendors of RISC machines may simply not be aiming
very hard at that market; IBM may or may not want to have RS/6000's
competing with 3[679]0's and S/38s or AS/400's, and DEC may have
considered DECstations to be for technical markets and VAXes for
commercial markets.

Sun hasn't any non-SPARC machines with which SPARC machines might
compete, but Sun hasn't been in the business market as long as HP.

>I find it amusing that probably WAY more than half of the CPU cycles
>expended on this globe are probably for some business purpose,

Are there any benchmarks for commercial code (e.g., the US Steel COBOL
benchmarks?) that are considered to give numbers that indicate how well
a machine will execute commercial code and, if so:

	how well do HP-PA machines do on them relative to
	SPARC/POWER/MIPS/Alpha/etc. machines?

	how does the relative performance of the PA machines relative to
	the others compare to their relative performance on other
	benchmarks and applications?  (I.e., a 100 MHz PA7100 machine
	will probably outdo a 25 MHz 7C601 SPARC machine or a 25 MHz
	R2000 machine on COBOL benchmarks, but it'll probably out do
	them when running compilers, engineering applications, etc. as
	well.)
Xref: sparky comp.arch:10539 comp.unix.bsd:8631 comp.os.linux:16103
From: tgcpwd@rw9.urc.tue.nl (Wim van Dorst)
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
Subject: Re: IDE faster than Mips SCSI disk
Date: 9 Nov 92 08:30:26 GMT
Reply-To: tgcpwd@urc.tue.nl
Followup-To: comp.arch
Organization: Eindhoven University of Technology, The Netherlands

Klaus Steinberger writes:
>	1520363 bytes/second for writing the file
>	1736771 bytes/second for reading the file

Others have written results for ordinary 386s with plain IDE disk
in the range of 200-500 kB/s. I tried it at my home PC and I got
similar results. 

However, I always thought that those VAX/VMS machines at work were
awfully slow. So I tried iozone there too. It compiled without a
glitch, and gave results in various machines (workstations up to
large VAX-6410s) with various disks (RA type, RF type, other) 
results in the range 15-40 kB/s. 

What does this mean: Are the disks really that slow? Is the VMS
version of iozone different? Is the OS that significant?

Since this threads seems to acknowledge the presence of people
knowledgeable on hard disk, I thought I might as well ask this.

Met vriendelijke groeten, Wim `Blue Baron' van Dorst
-- 
---------------------------------------------------------------------
Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
(-: baron@clifton.hobby.nl  tgcpwd@urc.tue.nl  WvD@Akzo.400net.nl :-)
---------------------------------------------------------------------
Newsgroups: comp.arch
From: mash@mash.wpd.sgi.com (John R. Mashey)
Subject: Re: RTX and SC32
Organization: Silicon Graphics, Inc.
Date: Fri, 6 Nov 1992 02:45:02 GMT

In article <CLIFFC.92Nov5101357@miranda.rice.edu>, cliffc@rice.edu (Cliff Click) writes:

|> 
|> And now a soapbox:
|> 
|> Compiler technolgy is driven by computer archetectures.
|> If a big-name company produced a blazing stack machine and handed a few
|> out to CS departments doing compiler research, compiler researchers 
|> (like myself, hint, hint) would find the moral equivalent of the
|> "graph coloring register allocator" for stack machines.

1) Big-name companies have produced stack machines, including Burroughs
B5000 & its A-series descendents, HP3000, and Tandem.
2) With the exception of the Burroughs, which lives on as the A-series,
the others have gone away, or are in the process of being migrated elsewhere.
3) Compiler technology now drives computer architecture as much as the
reverse; much of the current RISC generation was driven/designed by
optimizing compiler people.
4) This is an architectural style that has been known & familiar for a long
time ... nevertheless, it has failed to win many converts outside of a
few niches, and some people who've had huge investments in it have chosen
to switch.

5) For a general-purpose systems architecture, you need to do integer
arithmetic, floating-point, virtual-memory-management, run "large" programs,
and support a wide variety of common languages.  It can be very
misleading to compare transistor counts for implementations of
architectures that have all of these things, with ones that don't have
all of these.  For example, it is quite easy to prove that PDP11s were
"better" than VAXen  (denser code & data fof same problems, after all);
of course, life was really tough if you had more than 64KB of data.

6) In many cases, an architectural family that spans a wide range is
less efficient than an architecture targeted to a narrow target.  Sometimes
the narrow one is enough better that it wins ... but other times, the
broader ones are good enough, even at the narrow one's target, that the
broader one wins on the basis of software commonality.  After all,
there are lots of flavors of X86s & 68Ks, and there are already RISCs
whose family extends from $15 chips into high-end chips that power
mainframe-like systems ....

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311
Newsgroups: comp.arch,comp.lang.misc
From: sakkinen@jyu.fi (Markku Sakkinen)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: University of Jyvaskyla, Finland
Date: Thu, 12 Nov 1992 11:06:05 GMT

In article <martin.721555689@bert> martin@math.rwth-aachen.de (  Martin Schoenert) writes:
> ...
>bs@gauss.mitre.org (Robert D. Silverman) continued:
>
>    Needless to say, there are people who have to worry about speed FIRST,
>    and that other considerations are (almost) irrelevent.
>
>rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) replied:
>
>    Are you saying that speed is more important than correct answers? 
>    {I don't think so, but I though I had better ask.}
>
>No, I don't think that this is what Bob is talking about.  However in the
>area of integer factorization correctness is easy to achieve, because you
>can  check your answers  so easily.   But  reasonable  efficiency can  be
>*very* difficult to obtain.

As somebody already remarked, that is what Silverman _wrote_ but probably
not what he _meant_.

Correctness must be important even for these special problems.
Suppose that you get an answer after burning some hundreds of MIPS-years,
and the easy check shows that the answer is wrong.
If a correct but "inefficient" programme would have needed only twice
as much resources for the computation, your choice to run the incorrect
but "inefficient" programme was obviously bad -- if this is more or
less a one-shot job.

The economy becomes different if the software can be sufficiently
tested on small problems, or if it is to be used without further
modifications to solve a lot of huge problems, once it is correct.

----------------------------------------------------------------------
Markku Sakkinen (sakkinen@jytko.jyu.fi)
       SAKKINEN@FINJYU.bitnet (alternative network address)
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
----------------------------------------------------------------------
Newsgroups: comp.arch
Newsgroups: comp.arch
Subject: Re: More Alpha AXP Performance Numbers
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Date: Fri, 13 Nov 1992 19:42:54 GMT
Organization: School of Computer Science, Carnegie Mellon


solman@athena.mit.edu (Jason W Solinsky) writes:
>why aren't there any multi-processing configurations available?

The initial desktop model is uniprocessor, but the high end model has
up to 6 CPUs. Some intermediate models have 2 CPUs.

>Based on this data, it is extraordinarily unclear why somebody would
>be willing to go for the 10000 box when the 3000 delivers better than
>half the performance at a TINY fraction of the price.

Probably for the same reason one would buy an Amdahl - big IO, big
memory, big caches, and presumably, big transactions/second on the
TPC benchmark. In short, the top of the line is a mainframe, not a
supercomputer. DEC can fit 1 GB of DRAM in the deskside model:  the
bigger model probably has more than that in its *minimum*
configuration. 

The cycles side of the computing world is getting noticeably flatter.
The 360 series spanned a very large performance range, but now the
chip on your desk (be it HP or DEC) can be a derated copy of the
engine in the vendor's "mainframe". HP makes the difference more
obvious by having a different OS for the "business" versions, but
Cobol compilers notwithstanding, it's the same chip. 

This is, of course, a tremendous price break to people who want the
MIPS/MFLOPS but not the memory and IO. We are in luck.  But didn't
Seymour Cray say that the processor is the easy part?
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch,comp.lang.forth
From: peter@ferranti.com (peter da silva)
Subject: Re: What's RIGHT with stack machines
Organization: Xenix Support, FICC
Date: Mon, 9 Nov 1992 16:28:34 GMT

In article <MIKE.92Nov9004026@guam.vlsivie.tuwien.ac.at> mike@vlsivie.tuwien.ac.at (Michael Gschwind) writes:
> But what do you do when you get to things like CSE? DUP
> DUP SWAP SWAP ROT? Hardly efficient! 2 memory accesses for DUP, 4 for
> swap, 6 for ROT.

Let's see, with a 16 element stack buffer, 0 or 1 memory access for dup
(mostly 0), and 0 for swap or rot.

> Once again, with technology of 10 years ago, they were nice,
> but it does pay to allocate registers and do scheduling, AND WE HAVE
> THE TECHNOLOGY NOW to do it.

If you can afford to compile your code for each new processor, yes. Otherwise
you have to assume that most code will use the scheduling that was best for
the first generation of the chip. Outside of engineering-class workstations
(a vanishingly small proportion of the total end-user micro market: PCs and
game machines clobber it by orders of magnitude) this is the normal case,
and in embedded systems (almost all the rest of the market) it's highly cost-
effective to minimize code size: ROMS are slow and expensive.

I predict that before too long all high performance commodity micros will do
scheduling at runtime.
-- 
% Peter da Silva % 77487-5012 % +1 713 274 5180 %
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.arch,comp.lang.misc
From: sabry@rice.edu (Amr Sabry)
Subject: Re: A challenge to the anti-goto
Originator: sabry@datura.cs.rice.edu
Reply-To: sabry@rice.edu (Amr Sabry)
Organization: Rice University
Date: Thu, 5 Nov 1992 20:44:02 GMT


In article <Bx8x1y.C2@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
|> In article <1992Nov5.111943.21554@harlqn.co.uk> daveb@harlqn.co.uk (Dave Berry) writes:
|> >It's easy to get rid of these gotos.  Every goto can be replaced by a
|> >tail-recursive function call.  This can be compiled into the same machine
|> >code. 
|>
|> This is only part of the challenge.  The other part of the challenge is
|> to do this in such a way that the resulting code will be at least nearly
|> as efficient.  In order to accomplish this, one thing  necessary is that
|> every one of the function calls be a totally-non-context switching function,
|> with nothing added to the stack.  Now it matters not to me what you call
|> such a beast, BUT IT IS A GOTO.

Yes, it is a goto, and this is exactly what Berry said. A function
call in a "tail" position is a goto. Some languages require the
compiler to recognize this and some don't. However, most descent
compilers will do it anyway.

|> I have never seen ML code before.  If the above features could be added,
|> I would have no problem with it.  But, as I have pointed out, these
|> features are equivalent to reordering code, gotos, and dropthroughs,
|> and they do not seem to be provided in the language.  Would the compiler
|> do it?  If so, it meets the challenge for this code.

An example:

factorial(n, result)
	if n=0 then result
	else fact (n-1, result*n)

is compiled as if it was written like:

factorial(n,result)
label 100: if n=0 then result
	   else begin  	n = n-1
		 	result = result * n 
			goto 100

No context-switching, no stack, nothing, just a goto. 
-- 
Amr Sabry				     	    sabry@cs.rice.edu
---------------------------------------------------------------------
Man will occasionally stumble over the truth, but most of the time he
will pick himself up and continue on.-- Churchill's Commentary on Man
Newsgroups: comp.arch