HDTenEightyP/NetNews huggingface dataset:
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Cached DRAM from Mitsubishi
Date: 31 Jul 92 14:20:03 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

One implication of all this is that in future designs memory may
provide a data available signal, and be variable speed. This is an
interesting concept, and somewhat reminds me of the AT bus with a "0ws"
line to indicate zero wait state memory. I could envision all memory
being 0ws, with a latch logic something like "if dav not active on next
clock raise wait and hold until dav."

Of course the "wait" would be the bus interface unit, and not the CPU
itself, hopefully. Not too different from what we have in some systems
today, except the wait would originate on the memory chip rather than
the support logic.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
From: cmhui@cucs18.cs.cuhk.hk (Hui Chau Man)
Newsgroups: comp.arch
Subject: How to get Dhrystone and Linpack?
Date: 22 Jul 92 03:15:59 GMT
Organization: Faculty of Engineering, The Chinese U. of Hong Kong

Dear Netters,

I am designing an i860 processing board. 

I see in many magazine that Dhrystone and Linpack are used in
benchmarking hardware performance. Actually, what is Dhrystone and
Linpack?

How can I get them running on my machine to do the benchmarking?

Thanks in advance


C.M. Hui
Dept. of Computer Science
The Chinese University of Hongkong
Shatin, N.T.
Hongkong

Internet: cmhui@cucs18.cs.cuhk.hk
FAX: (852) 6035024
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Organization: Intel Corp., Hillsboro, Oregon
Date: Fri, 24 Jul 1992 02:18:43 GMT

    Maybe true. But for a user, should he buy one $2000 21064 chip or another
    two $1000 CY7C601!?

This is a rather bogus discussion.

The assumption seems to be implicit that, given the same technology,
etc., a 64 bit architecture implies twice the performance of a 32 bit
architecture.

That's blatantly untrue, since the overwhelming majority of applications
fit quite nicely into 32 bit address and data quantities, so from this
point of view 32 = 64.

There may be some applications that can benefit from >32 bit virtual
addresses, e.g. the 40 bit virtual addresses of the MIPS R4000. I'm
tempted to say that this implies 32 = 4/5 40, but of course there is
overhead in evaluating extended precision arithmetic. The overhead may
be more than 2x.  But then you have to downgrade that by the ratio of
time spent manipulating such addresses.

Finally, there are some applications that benefit from simply having
larger integers.  John Mashey has mentioned robotics as one such area
(although I have talked to robotics manufacturers who take a
completely different approach). But, once again, you have to prorate
the speedup according to the importance of the code being executed.


Look:
    Whether you will see a speedup between a 32 bit and a 64 bit 
    microprocessor depends on your applications and OS.

    I am 100% certain that none of the applications or OSes
    I am using *today* would be speeded up by 64 bits.

    Some of the applications I will want to use in a few years
    will undoubtedly run faster (or, more likely, be easier to code)
    because of 64 bits -- like the oft-awaited global flat namespace.
    But I won't hold my breath (at least not until ISDN).

Rephrasing the question above:

    But for a user, should he buy one 64 bit chip or 2 32 bit chips?

As:

    But for a user, should he buy one 64 bit chip or 2 32 bit chips
    (assuming both are implemented in comparable technology)?

The present day answer is probably:

    If you can save money, and if you don't need >32 bit virtual addresses
    because the applications that use them aren't developed yet,
    then you are probably better off buying the cheaper 32 bit chip.



--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch
From: panter@micor.ocunix.on.ca (Bill Panter)
Subject: Re: Proposal: Computer History Project
Organization: M.B. Cormier INC., Orleans (Ont)
Date: Thu, 30 Jul 1992 21:15:02 GMT

Anyone interested in pursuing this project might want to attend the
upcoming Reverse Engineering conference.  See comp.org.ieee for details.

Bill Panter (panter@micor.ocunix.on.ca)

Newsgroups: comp.arch
From: jjackson@carlrs6000.carl.ua.edu ()
Subject: Availability of RISC simulators? 
Organization: The University of Alabama, Computer Architecture Research Lab 
Date: Thu, 30 Jul 1992 17:57:43 GMT


I am interested in compiling a list of all RISC simulators which run under some
form of UNIX O.S. (preferably BSDish) and are available at no cost (or minimal
cost) to .edu types. An X interface to these simulators would also be nice.
I am aware of the SPIM (and XSPIM) simulator (MIPS R2000) written by J.R. Larus at
Wisconsin-Madison, generic DLX, and I have heard of a simulator for the AMD 29K. 

I'm sure there must be some other simulators (at least of the instruction set 
architecture, ISA) for most RISC machines ...  i.e. i860, i960, MC88K, Alpha?, 
RS/6K?, SPARC?, MIPS R4000?

I intend to these simulators in a graduate RISC class I am teaching this Fall 
so the need is kinda urgent.

The people at MIPS went overboard in their support for me the last time I taught 
this class, and consequently the portion of the class covering the MIPS processors 
was the most complete, thanks in part to some Hennessy/Patterson class notes that 
the MIPS people provided and the SPIM simulator.

My need for Sparc and RS/6K simulators is minimial as I have that hardware here at UA.

How about a strong response from the .com people.... do you have ISA simulators 
(or even small prototype boards) that you might be willing to make available to aid in
teaching this subject matter to students.

I will be happy to compile a list of all sources and post to comp.arch if anyone 
else is interested.  Please email your responses to jjackson@tiger.carl.ua.edu
or phone me at (205) 348-2919.

-------------------------------------------------------------------------------
David Jeff Jackson                         Internet: jjackson@tiger.carl.ua.edu
Electrical Engineering                                          (130.160.48.25)
The University of Alabama                The Computer Architecture Research Lab
Phone: (205) 348-2919

I'm just an assistant professor.... I'm not allowed to have opinions, only write
papers about them.
-------------------------------------------------------------------------------
Newsgroups: comp.arch
From: gints@roadkill.esd.sgi.com (Gints Klimanis)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Silicon Graphics, Inc.
Date: Thu, 30 Jul 1992 06:37:23 GMT

In article <id.GQWR.83D@ferranti.com>, peter@ferranti.com (Peter da
Silva) writes:
|> Yes, I quite agree, different problem spaces demand different
|> algorithms for
|> solution. However, and this is the key point, it is (in 1992)
|> extremely rare
|> that you encounter a constraint on the problem space due to the
|> hardware that
|> has any significant effect on the choice of algorithm. Things like
|> 64K segment
|> limits, massively parallel hardware, or the absence of a FPU... yes.
|> Things

Well.  I find myself thinking about the MIPS R4000 in my digital audio
signal processing.   Simple things like the tiny 8K instruction and data
caches really put limits on what you can run at the pipeline rate.  The
16 floating point registers for mips2 chips imposes severe limits on all
sorts filter implementations.  The limits of new devices are still there
TODAY.
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: sysmark@helios.physics.utoronto.ca (Mark Bartelt)
Subject: dinosaur horsepower
Reply-To: mark@cita.toronto.edu
Organization: University of Toronto Physics/Astronomy/CITA
Date: Tue, 28 Jul 1992 13:07:41 GMT

Larry Stewart's proposal regarding the computer history project prompts
me to offer a suggestion for something I'd like to see:  A compendium of
old machines, and just how fast (well, slow) they were compared with the
systems we use today, and how much they cost when they were new.

A couple days ago I was explaining to my seven-year-old how much things
have changed (cost, size, speed) since I first started using computers
(1964, on an IBM 709 (the vacuum-tube predecessor of the 7090 and 7094)),
and although I could give her a good idea of how *large* the beast was,
I realized that I really couldn't give even a vague estimate of relative
computational power.  (And I haven't the foggiest idea how much it cost!)

I suppose if I rummage around in my parents' attic, I may be able to find
the box of cards containing the source code from my first computationally
intensive program (I think there's still a functioning card reader in our
building!), or at least a listing (do I *really* want to type in 1500 lines
of Fortran?), and run it on a Sparcstation or a Personal IRIS, and get some
feel for relative performance (I think at least some of my old output from
1964 are compile/load/run jobs, which reported elapsed time).

But, in general, I think it would be fun to see MIPS/MFlops (KIPS/KFlops?
IPS/Flops?) values (at least, moderately authoritative ballpark estimates)
for some of the machines we grew up with.

By the way, if the history project does succeed in emulating some of the
older machines, will it also provide an emulator for an 026 keypunch? ;-)

Mark Bartelt                                                  416/978-5619
Canadian Institute for                               mark@cita.toronto.edu
Theoretical Astrophysics                             mark@cita.utoronto.ca

"Clothes not busy being worn are busy drying."   -   Dylan, on laundry day
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 24 Jul 92 17:02:49 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul21.040216.13502@primerd.prime.com>, danw@hobbes.prime.com (Dan Westerberg) writes:

| If we were to say to our customers that their software would no longer be
| compatible with a new machine, we would quickly lose our installed customer
| base.  At that time, it would make sense for a customer to begin investigating
| the benefits/tradeoffs associated with switching operations to an alternative
| hardware platform (be it another proprietary system or a Unix system).  

  Dan makes a great point here, backward compatibility is only an issue
if you are running proprietary software. For the person who has source
to his software, compatibility within an o/s (like UNIX) means
recompilation. To someone who is running software without source (most
commercial packages), the cost of changing processors is far higher. The
cost of upgrading the o/s may be pretty high, too.

  Backward compatibility is very much a customer issue. As long as the
cost of the total system hardware and software is lower through backward
compatibility, the customer will want it.

  And to the extent that this affects purchasing decisions and forces
processors to comform to user's wishes, it's an architectural issue.
Perhaps we've beaten it to death, though.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
From: daryl@hpcuhe.cup.hp.com (Daryl Odnert)
Date: Fri, 24 Jul 1992 15:49:20 GMT
Subject: Re: Code Repositioning on MIPS Systems?
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.arch

> According to the information I've been sent via e-mail, MIPS has a
> postprocessor tool called "cord" which can reposition the procedures
> within an executable file so that run time cache conflicts will
> be reduced.  The positioning is guided by information in "feedback
> files" which are generated by the "prof" command with the -feedback
> option.

I've received word that there is also a tool called "cord2" for MIPS
which performs a similar function at the basic block level.  I haven't
yet heard of any technical references that describe this product.

Daryl
Newsgroups: comp.arch
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: Wed, 22 Jul 1992 17:42:59 GMT
Organization: U of Toronto Zoology

In article <ADAMS.92Jul21011202@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de> adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
>>   The theory behind things like bcopy boxes is that CPU cycles are slow
>>   and costly compared to memory cycles.  Not any more, they aren't.
>
>... when were CPU cycles slower than memory cycles? 

Basically, in the old days.  For example, microcode made sense when the
CPU was slow enough that using a memory to control it wouldn't slow it down.
Not any more.

>Most literature I know of claims CPUs to be ten times faster than
>memory...

*Today*, yes.

>This makes dedicated DMA-engines valuable, as they work
>parallel to CPU and issue transfers only during bus idle states, 
>just grabbing  the rest of memory bandwidth, but not more.

Uh, where do you find idle states?  If the CPU is that much faster than
the memory, it wants all the memory bandwidth it can get, and the memory
designers sweat and strain to give it more.  You get idle states only
when the CPU is *slow*, so it can't use the full memory bandwidth.

Dedicated DMA engines make sense if

	1. the CPU can't move data around at full memory speed
	2. normal execution doesn't use the full memory bandwidth
	3. interrupt overhead is too high for timely device handling
	4. bad hardware design cripples CPU data movement

It should be easy to see that as the CPU gets faster, it *can* move data
around at full speed, and it wants all the bandwidth it can find (adding
caches helps some, but doesn't solve the problem).  Item 3 can still be
an issue, particularly on old architectures with clunky interrupt handling,
or in applications with really ferocious data-movement requirements.
Item 4 is constantly with us, its latest instantiation being caches that
can't be bypassed (or can't be bypassed without a major performance hit).
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
From: weicker@sinix.UUCP (Reinhold Weicker)
Newsgroups: comp.arch
Subject: Information about Dhrystone and Linpack
Date: 31 Jul 92 15:46:11 GMT
Organization: SNI AG Muenchen, STO XS

This is an answer to the posting of C.M. Hui (Chinese University
of Hongkong), 22 Jul 1992:

> I see in many magazine that Dhrystone and Linpack are used in
> benchmarking hardware performance. Actually, what is Dhrystone and
> Linpack?

> How can I get them running on my machine to do the benchmarking?

There is a newsgroup specifically devoted to benchmarking issues:
    comp.benchmarks
"Answers to frequently asked questions" are posted there regularly,
including questions like the one asked here.

However, I'll try to give a short answer:

- Dhrystone is a synthetic benchmark program intended to represent
  system programming (no floating-point)
- Linpack is a "kernel benchmark", i.e. code that is likely to be
  used in many applications of a certain type (here: matrix
  operations). It is extracted from a library (package, hence the
  name) containing linear algebra programs.

More information about Dhrystone, Whetstone and Linpack is given in
the following article:
    Reinhold P. Weicker: An Overview of Common Benchmarks
    Computer (IEEE) 23,12 (Dec. 1990), pp. 65-75
The article also names "mail servers" from where you can get the
source code, in the pacific region: netlib@draci.cs.uow.edu.au
Send mail there, with just the words "send index from benchmarks",
and you receive further instructions. [I didn't check this mail
server recently, I hope the information is still correct.]

The problem with all short benchmarks, inluding the two mentioned
above, is:
- They are so small that at least the code fits completely even
  in small caches; the memory system is not tested adequately;
- Compiler writers can tune their compilers to any benchmark
  if the benchmark becomes really popular; of course, this is
  much easier for small benchmarks.
Therefore, for serious benchmarking, consider the SPEC benchmarks
or (for purely numeric programs) the PERFECT benchmarks. Even
though I wrote Dhrystone, I am now active within SPEC. Benchmarks
like Dhrystone can still be useful for "controlled experiments"
(e.g. in a simulator where you vary the system parameters), but not
for the generation of "magic numbers".
-- 
Reinhold P. Weicker, Siemens Nixdorf Information Systems, STM OS 32
Address:    Otto-Hahn-Ring 6, W-8000 Muenchen 83, Germany
E-Mail:     weicker@ztivax.zfe.siemens.de
Disclamer:  This is just my opinion, not my company's or SPEC's
From: limes@ouroborous.Eng.Sun.COM (Greg Limes)
Newsgroups: comp.arch
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 23 Jul 1992 18:25:35 GMT
Organization: Sun Microsystems, Inc.
NNTP-Posting-Host: ouroborous

In article <1992Jul23.145502.20975@ncrcae.ColumbiaSC.NCR.COM> Jeff.McElroy@ColumbiaSC.NCR.COM writes:
| So, how many processors can take and service interrupts?  

Two answers, as usual ;-)

First answer: All CPUs can accept and service interrupts,
without regard to which CPU initiated the action that
eventually triggered the interrupt. The same chip that handles
MBus arbitration handles distribution of the interrupts; an
internal register tells it which CPU gets them.

Second answer: Only one CPU at a time can receive interrupt
requests from devices in the system, and the software design of
the 4.1.2mp kernel requires that device interrupt service
routines execute within the single lock, so only one CPU at a
time will be inside interrupt service routines.
From: mkahn@hopi.sedona.intel.com (Mitch Kahn)
Newsgroups: comp.arch
Subject: Re: Request Info Re Bus Trends & Intel 486s
Date: 22 Jul 92 16:10:03 GMT
Organization: /eng/eng3/mkahn/.organization
In-reply-to: rjmartin@extro.ucc.su.OZ.AU's message of 15 Jul 92 09:16:13 GMT

rjmartin@extro.ucc.su.OZ.AU (Trilogy Business Systems) writes:

 Summary: I need some info re alternative Bus designs & Diffs Between 486s
] Keywords: Intel 486 Bus
] Posted: Wed Jul 15 04:16:13 1992
] Nntp-Posting-Host: extro.ucc.su.oz.au
]
] I am seeking some information concerning 2 different subjects.
]
] The first is cocerning 486 Chips.
]
SImply stated:

A 486DX50 is faster than a 486DX2-50. The DX50 has a 50MHz bus and 50MHz core.
The DX250 has a 50MHz core and a 25MHz bus. SOunds like the salesman is
either ignorant or out to screw you. Actual performance numbers were posted
by the x86 guys a few weeks ago in comp.sys.intel.

]
] Secondly are the 486SX chips just 486DX chips that fail the co-processor
] certification (and 487's that same that fail the CPU test), in the same
] way that the old single sided disks (remember them ??) were double sided 
] disks that failed certification on one side ? 


The 486SX used to have a dead (or disabled FPU). They now have no FPU at all.
When the production ramp warranted, the FPU was removed to save on die cost.
This is an all pervasive technique in the semicon industry. 

]
] Thirdly what in user terms are the major advantages of the P5 over the current
] 486 chip, will the 486 go the way of the 386, or will they become seperate 
] product lines ?


The P5 will have very significant performance advantages over the 486 family.
I would expect a similar 486->P5 migration as we are seeing now with the
386->486. But it won't happen until about 1994. (My opinion)

]
] My second major question concerns bus structures. It seems to me that the EISA
] bus is too slow for any of the major changes happening to desktop computing,
] all the companies I know of making multi-processor machines are using a 
] proprietry bus due to the relatively slow speed of EISA and Microchannel.
] HP seem to have implemented a multi-proceesor machine over it PA bus, but
] I don't see this as a major desktop bus architecture in the years to come.
] DEC have Turbo-channel, but I heard that even that has a limited life. I
] have heard that IEEE are in the process of defining something called FutureBus
] but at the rate that concensus seems to take, this will be

There are two local bus standards currently in the wings. VESA and PCI.
PCI (from Intel) has not been formally announced but has been in the 
press quite a bit lately (check PC Magazine this month).

]
--
|  Mitch Kahn              | "I hope you know that this will go down on |
|  mkahn@sedona.intel.com  |  your permanent record..."                 |
*************************MY OWN OPINIONS*********************************
Newsgroups: comp.arch
From: ronus@eecg.toronto.edu (Ron White)
Subject: Running Sum Adders
Organization: University of Toronto
Distribution: na
Date: 21 Jul 92 23:46:23 GMT

Hi.

I have a paper that mentions the use of a: 

"running sum adder commonly found parallel processing units".

The paper doesn't go into any more detail and doesn't list 
any references w.r.t. this type of parallel adder.

Could someone point me to a reference that will explain
the operation of a "running sum adder" ? 

Thanks 

Ron White

ronus@eecg.toronto.edu

Newsgroups: comp.arch
From: dwilliam@jabba.ess.harris.com (David Williams)
Subject: Cached DRAM from Mitsubishi
Keywords: yow!
Organization: Harris Information Systems Division, Melbourne, FL
Date: Wed, 29 Jul 1992 21:49:08 GMT

   I was flipping through the May issue of Electronic Design, and an
ad from Mitsubishi caught my eye.  They have a DRAM chip now available
with built-in cache.  This looks interesting - a 1M by 4 DRAM with a 
built-in 4K by 4 SRAM cache.  Apparently, the chip has an internal bus
that lets the SRAM cache do a line copy to/from the DRAM portion at
64 bits.  (16 x 4bit internal bus)  Speed is claimed to be 10ns when a
cache hit occurs, 70ns in case of a miss (actually, a miss causes a 
280ns DRAM cycle, but the SRAM can start doing stuff again in 70ns while
the DRAM is busy)

   The reason I bring this up is the recent discussion about high-bandwidth
main memory systems.  At 10ns, this critter has a seriously fast
cycle time.  For a minimum system, you'd use 8 of them to get a 8M x 32bit
memory array, which gives you a 32K x 32bit (128K x 8) cache.  What kind
of performace could we really expect from this configuration?  Aren't most
secondary caches quite a bit larger than this?  I guess I need to go do
some simulation. 

   I guess the performance is really going to depend on the hit rate of
the cache, but this thing looks like an excellent candidate for burst mode
access.  If no miss, the cycle can be 2-1-1-1, and if a miss, we have to 
add 60ns for the first access (4-1-1-1 ?) since the DRAM has to load the
cache line to the SRAM inside the chip.  An aside - with 8 chips, this
is the equivalent of a 512-bit load from main memory to cache in 70ns,
since each chip loads 64 bits internally.

   Anyone have any more information on this type of device?


      Dave Williams                                              My 
        dwilliam@jabba.ess.harris.com                         opinions	 
           "Huh?  What?  Could you repeat the question?"        only.  

-- 
      Dave Williams                                              My 
        dwilliam@jabba.ess.harris.com                         opinions	 
           "Huh?  What?  Could you repeat the question?"        only.