HDTenEightyP/NetNews huggingface dataset:
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: dinosaur horsepower
Date: 28 Jul 92 14:48:02 GMT
Followup-To: comp.arch

From article <Bs3oGt.6vp@helios.physics.utoronto.ca>,
by sysmark@helios.physics.utoronto.ca (Mark Bartelt):
> 
> 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.

The IBM 701, in 1953, had a fundamental machine cycle time of 12us.  A
memory to accumulator add took 5 cycles (60us) and a multiply took 38
cycles.  IBM claimed an average instruction execution rate of 14,000
instructions per second.  This machine had a 36 bit word.

The 701 was a first generation machine (vacuum tubes, williams tube
memory).  The main memory could be expanded 2K words, and this memory was
advertised as a high speed large capacity memory.

The DEC PDP-8, in 1965, had a 1.5us memory cycle time, so it took 3 us to
do a single 12 bit memory to accumulator add (1.5us for the instruction
fetch and 1.5us for the operand fetch and add).  You could say that this
was a 1/3 MIP machine, but if you want any precision, you'll have to do an
extended precision add.  A memory to memory 24 bit add on this machine
takes 7 instructions.  A similar 36 bit add takes at least 11
instructions.

The PDP-8 was a second generation machine (transistorized, discrete
components, core memory).  The maximum memory capacity of the architecture
was 32K 12 bit words.  Although it was a small inexpensive system,
by the standards of its day, the speed of the logic was very typical of
the times.

					Doug Jones
					jones@cs.uiowa.edu
Newsgroups: comp.arch
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: BUSES
Organization: Nanyang Technological University - Singapore
Date: Thu, 30 Jul 1992 13:07:20 GMT

In article <1992Jul28.180537.14749@StarConn.com> jpp@StarConn.com (John Pettitt) writes:

: 
: On a more normal level an ISA bus will peak out at around 3.3 MB a
: second half duplex (600 ns per transaction 2 bytes per).  In the real
This is the standard memory cycle at 8Mhz with a certain wait state. Surely
600nS transaction time is too conservative. Today, static RAM can operate at
20nS access time.
	For a sequential access mode, there is no address setup time. The 
transaction time is determined by the access time and propagation delay
from card to microprocessor. This technique is called the synchronous 
mode for the EISA. At 33Mbyte /second, that makes the transaction time to be
121 nS for a 32-bit wide transfer. For a 16-bit wide ISA, the skewing effect
should be smaller so let us assume that the transaction time be 110nS. That
makes the peak transfer rate to be 18Mbytes/second.
	The 18Mbytes/s figure assumes that there is no-wait state inserted by
the PC chipset, using the 0WS, and no address setup time is necessary because
the transfer is sequential and the address is generated by the ISA card itself.
	The card vendor must design the transfer protocol himself, unlike
EISA, which is standardised. The advantage is huge because of the large 
number of ISA machines.
	The card which needs these high speed would be the communication cards,
video cards and harddisk controller cards.

My question is: Has anybody tried to experiment with the 0WS signal of the ISA?
If they have, may I know the problems which are faced?

I'm not interested in theoretical discussion because I had asked the same
thing but am not satisfied with the answers or suggestions.

Since John Pettitt mentioned that he is a retired I/O system designer, maybe
someone else may volunteer. If John Pettitt had done some experiments with
the 0WS, it would be nice to hear his views.

Thank you for any comment.

--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Fri, 24 Jul 1992 10:04:01 GMT
Subject: Re: Re: What's in a name? (cross-posted to SGI since mentioned)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch

In article ... glew@pdx007.intel.com (Andy Glew) writes:

   12 years ago, my dream was to build cheap high performance RISC
   processors that brought really high performance computing power to the
   masses. My parents (non-computer nerds) in particular.

   Through all of those years, there was never built a cheap high
   performance computer system using a RISC that my parents would want to
   use.  (Sure, I know about the BBC Micro - I mean *use*, not play
   with.) All of the RISC companies concentrated on high margin
   workstations that only companies and universities could purchase.

Did the Archimedes come too late, then? ``MIPS for the masses'' was, I hear,
the internal slogan of the ARM development team. [Of *course* I'm biased. We
started at home on the Beeb and now run two Arcs. But at least one parent has
become computerised on the basis of cast-off Beebs!]
--

Regards,    | ``In fingers of trees, and valleys of gold    | Judy Tzuke
Kers.       | I watch as you outshine the charlatan foe.''  | Higher & Higher
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project, & backwards compat
Date: 29 Jul 92 01:12:46 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <LYNCH.92Jul28122313@flubber.cc.utexas.edu> lynch@ccwf.cc.utexas.edu (Tom Lynch) writes:
>  Modern computers are so much faster than historic machines that
>  it is possible to emulate the instruction set and I/O systems
>  of a historic machine at full speed.
Wasn't this sort of what IBM did in the early 360s that emulated the 1401,
etc.?

Whether we re-implemented a historic machine in new hardware or ran
an emulator on a modern machine, there are very few people who would
want to run old software.  I love to wax nostalgic about what fun some
old machines were; but when I think of what I use computers for today
it is so different from what we used them for then...
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
From: dbg@slacvm.slac.stanford.edu (David Gustavson)
Newsgroups: comp.arch
Subject: Re: what is a non-split transaction bus called?
Date: 28 Jul 92 03:07:25 GMT
Followup-To: comp.arch
Distribution: na
Organization: SLAC

In article <1992Jul24.011046.12931@beaver.cs.washington.edu>,
noah@cs.washington.edu (Rick Noah Zucker) wrote:
> 
> 
> 	I was writing something and wanted to refer to a bus that did
> not use split-transactions.  I realized that I did not know the adjective
> for such a bus.  One person I asked locally said, "That's simply a bus.
> If it is split-transaction, then you need to say so".  Someone else said
> she uses the term "hold the bus" protocol, but admitted that that is not 
> a technical term.  I have seen the term continuous connect used, but
> thought that there must be something better.  What do you call it?
> 
The IEEE standards seem to be adopting "unified transactions" for those
that are not split, at least in an environment that permits both kinds.

--------------------------------------------------------------
-- David B. Gustavson, Computation Research Group, SLAC, POB 4349 MS 88,
    Stanford, CA 94309   tel (415)926-2863  fax (415)961-3530
-- What the world needs next is a Scalable Coherent Interface!
-- Any opinions expressed are mine and not necessarily those
   of the Stanford Linear Accelerator Center, the University, or the DOE.
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: Scheduling in Shared Memory Multiprocessor Systems
Date: 27 Jul 92 10:58:06 MDT
Organization: Utah State University

In article <1992Jul24.183213.9699@elroy.jpl.nasa.gov>, david@elroy.jpl.nasa.gov (David Robinson) writes:
> Isn't this an artifact of the Vax architecture having 32 hardware
> queues and instructions to manipulate them?  Have most BSD vendors
> kept this structure or gone with something radically different?

The VAX can handle as many queues as you have memory for. It does, however,
have only 32 interrupt priority levels.

Roger Ivie
ivie@cc.usu.edu
Newsgroups: comp.arch
From: sysmgr@king.eng.umd.edu (Doug Mohney)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Date: Thu, 23 Jul 92 16:19:00 GMT
Organization: Computer Aided Design Lab, U. of Maryland College Park
Reply-To: sysmgr@king.eng.umd.edu

In article <MKAHN.92Jul22091003@hopi.sedona.intel.com>, mkahn@hopi.sedona.intel.com (Mitch Kahn) writes:

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

Only reason why the 386 to 486 migration is occuring (IMHO) is marketing-driven
than anything else. Profit margins on selling a '386-33 or 40 just aren't
there, so selling '486-SuX or full-4s keeps total system price up.

The speed is nicer to have too, especially if you choose to inflict Windows on
your PC... :)


   Previous signature chastized by Canadian Grad Student who flayed the United
   States as a bully from his bastion of free speech in Pittsburgh, PA. 
                    Yes, fact IS stranger that fiction.     
  -- >                  SYSMGR@CADLAB.ENG.UMD.EDU                        < --
From: spot@CS.CMU.EDU (Scott Draves)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 24 Jul 92 01:09:54 GMT
Article-I.D.: cs.1992Jul24.010954.265191
	<1992Jul22.170228.424@darkcube.radig.de>
	<DOCONNOR.92Jul23085513@potato.sedona.intel.com>
Organization: School of Computer Science, Carnegie Mellon University
Originator: spot@HOPELESS.MESS.CS.CMU.EDU

>>>>> On 23 Jul 92 15:55:13 GMT, doconnor@sedona.intel.com (Dennis O'Connor) said:

Dennis> Perhaps Volker Herminghaus-Shirai is smarter than all those
Dennis> customers : maybe his freely-given opinion is somehow more
Dennis> important than the "voting with their wallets" millions of PC
Dennis> buyers have done.  But it's not important to Intel's bottom
Dennis> line.

he probably is.  :)/2

in any caes, he has the source code to the programs he depends on;
compatibility is only a compile away.  selling binaries is the
problem.
-- 
			l2o
Scott Draves		gso
spot@cs.cmu.edu		ddn
Newsgroups: comp.arch
From: mfterman@phoenix.Princeton.EDU (Mutant for Hire)
Subject: Re: What's in a name?
Reply-To: mfterman@phoenix.princeton.edu (Mutant for Hire)
Organization: Mutant for Hire, Inc.
Date: Tue, 28 Jul 1992 18:14:48 GMT

In article <1992Jul25.075130.7192@spool.cs.wisc.edu>, mfrank@wilma.cs.wisc.edu (Matt Frank) writes:
>Both the Apple ][ and Mac are examples of non backwards compatible products
>enjoying great success.  So are CD players.  Although it was before my time,
>aren't CP/M, minicomputers, DB2 and UNIX other examples?

Apple ][ and CP/M are bad examples. First off, in those days,
shrinkwrapped programs were a lot more rare than they are now. The
personal computer industry was just starting then, and there was no
installed base of PCs to be compatible with. From what I recall, UNIX
came to big time success via the academic markets through cheap
licensing and people there used to writing their own code.

The Mac for one thing had Apple behind it, which while not being like
having IBM behind it, did mean that it had a small reputation.
Secondly it was being aimed not at power users who like to write their
own 1-2-3 macros, but at people scared of computers who don't have an
investment in PCs. Also "great success" for the Mac is a long term
thing, it was struggling in terms of market for many many years. It
took a lot of innovative and well written software to help push the
Mac. Anyone remember how long it took before Mac sales were larger
than Apple // sales?

As for CD players, there are oodles of technical advances over CD's
that make them far superior to records. Also note that all the
companies got together behind a single standard for the new format.

>Lots of companies have made lots of money, and stayed profitable, by
>continuously coming up with innovative new ideas.  The argument that no one
>will buy a fantastic new design unless it is backwards compatible, doesn't
>wash.

Its really a plus/minus thing. Bear in mind, that if I go over to a PC
or a Unix box, I have to throw out several hundred dollars worth of
Mac software. Now try to persuade me that its going to be worth making
the switch over to some other OS, especially if I then have to go out
and invest several hundred more dollars in new software.

The question is, are the new features worth it?

-- 
  Martin Terman, Mutant for Hire, Mad Scientist, Priest of Shub-Internet
mfterman@phoenix.princeton.edu mfterman@pucc.bitnet terman@pupgga.princeton.edu
"The parts of the universe I don't control are stomping all over the parts of
  me that control the parts of the universe I do control." - Martin Terman
Newsgroups: comp.arch
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: MP interrupt handling  was(Re: Sun 600MP Benchmark Anomaly)
Organization: University of Alabama at Birmingham
Date: Fri, 24 Jul 1992 13:34:07 GMT

In article <1992Jul20.150259.16021@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>
>
>  As a general question, which machines do this now? When GE was in the
>mainframe business we never did it, the kernel was totally shared but
>all hardware interrupts came to the same processor. I think DTSS did
>that, too, but could change the processor if the master went down.
>-- 
>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.

The Sequent systems use the SLIC bus to control interrupts.  Using this bus,
the priority of what each CPU is doing is globally available and the CPU
running the lowest priority task (usually in the kernel IDLE loop) fields
an interrupt when it occurs.

Cray has a more complex scheme concerning which cpu originated the request,
the interrupt mask of that cpu (and the others) etc.  Hopefully routing the
interrupt to the cpu that is best able to handle it.

As near as I can tell, the new SUN MP systems have symmetric hardware where
any cpu can field an interrupt, but I don't know how a SUN multiprocessor
arbitrates who (whom?) gets an interrupt when all cpus are interrupt-
enabled.  Apparently the "big lock" problem currently hangs the suns....

Bob
-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
From: henrik@mpci.llnl.gov (Henrik Klagges)
Newsgroups: comp.arch
Subject: 'Intel Delays Debut of P-5 Chip ...'
Date: 23 Jul 92 17:34:54 GMT

Wall Street Journal, Thursday 23:

'Intel delays debut of P-5 chip to refine production process & eliminate bugs'

[...] Intel originally planned to introduce the P-5 and begin limited produc-
tion in the fourth quarter of 1992. But it now plans to introduce the chip in
the first quarter of 1993, said Paul Otellini, vice president in charge of 
intel's microprocessor business.
[...] Mr. Otellini said the postponement wasn't caused by any unexpected flaws
in the P-5 or glitches in the manufacturing process, but added that it will
allow intel extra time to test the chip for possible defects.
[...] Intel is banking on the P-5 [...] to help it keep its dominant position
in microprocessors. [...] Moreover, intel badly wants to gain a foothold in the
market for powerful computers called workstations made by such companies as
IBM and HP. 

What a pity.


--

Cheers, Henrik
MPCI at LLNL
IBM Research
Newsgroups: comp.arch
From: cliffc@rice.edu (Cliff Click)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Center for Research on Parallel Computations
	<55294@mentor.cc.purdue.edu> <id.GQWR.83D@ferranti.com>
	<1992Jul30.063723.21080@odin.corp.sgi.com>
Date: Thu, 30 Jul 1992 15:09:28 GMT

In article <1992Jul30.063723.21080@odin.corp.sgi.com> gints@roadkill.esd.sgi.com (Gints Klimanis) writes:
>  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.

Block for cache & register size; do scalar renaming.  Does mongo good things
to most small number-crunching inner loops.  References are following via
e-mail.

Cliff
cliffc@cs.rice.edu

--
The Sparc ABI has the most brain-damaged calling convention I've ever seen.
Cliff Click (cliffc@cs.rice.edu)  |  Disclaimer:  My lawyer made me say it.
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Newsgroups: comp.arch
Subject: Re: Jump tables for shared libraries
Date: 30 Jul 92 16:30:48 GMT
Organization: University of Michigan, CITI

In article <1992Jul30.151301.27595@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>
>  A recent post to comp.os.linux indicated that there would be a change
>to jump tables for the shared libraries in the next release. WHile I
>understand the convenience features of jump tables, it would seem that
>there would be a better way to avoid relinking programs, which would
>avoid the overhaed of the indirection.
>
>  Two thoughts come to mind. The first is to have some form of runtime
>loader, which would do the linking at image activation time, rather than
>at image store time. This would cause startup overhead, but would avoid
>runtime overhead due to the indirect. The second would be to have the
>jump table in unmapped memory, and have the o/s catch the call, modify
>the image in memory to use the real address, and then restart the
>program at the point of the call. This moves stuff down into the kernel,
>and imposes a trap for each point in the image at which a library call
>occurs.
>
Whether these are cost wins or loses depends on your model of program
behavior.  Both of these are expensive compared to a single
indirection, so if the call is only going to be executed once (eg a
traditional UNIX tool which does something simple and exits) or if the
linking will have to be redone every time the code is paged out
(because the code is in a nominally read only segment and so is reread
on page in and never paged out) you might actually lose.

>  My personal preference is to not have the jump table, and if I have to
>relink programs when I upgrade my library, so be it. It's not that big a
>deal, and programs without source (not in the linux world) could be
>distributed as archives of objects and linked by the end user. This can
>be automated with a tiny shell script.
>
This requires either very sophisticated users or application programs
that KNOW they are using shared libraries, which ones, and how to
check whether they've been updated.



(Sarr Blumson)
Xref: sparky comp.arch:8430 alt.folklore.computers:11445 comp.benchmarks:1214
From: sog@craycos.com (Steve Gombosi)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: Dinosaur noises (was: Re: dinosaur horsepower)
Date: 29 Jul 92 19:20:50 GMT
Organization: Cray Computer Corporation

In article <kitchel.712420361@moray> kitchel@moray.dpsi.com (Sidney W. Kitchel) writes:
>dpbsmith@world.std.com (Daniel P. B. Smith) writes:
>
>>Along the same lines, I, for one, would certainly pay good money for a
>>recording of dinosaur NOISES.
>>The waltz-time 407 (kchunk-Pink kchunk-Pink glup kchunk-Pink kchunk-Pink glup)
>
>	Some fairly early computers came with speakers. One of these
>was the CDC 1604. Most operators kept the volume way down, but I can
>recall going into the machine room at Sunray DX Oil ca. 1965 and
>hearing the science-fiction-esque music of the CDC beast.

An FM radio tuned to ~105 (doesn't even have to be too close ;-) )
will produce similar effects in the presence of an older (9.5ns) Cray X-MP ;-). 

Steve
Newsgroups: comp.arch
From: Josef Moellers <mollers.pad@sni.de>
Subject: Re: What's in a name?
Date: Thu, 30 Jul 1992 07:18:13 GMT
Organization: Siemens Nixdorf Info.Sys. AG, Paderborn, Germany

In <1992Jul24.170249.26032@crd.ge.com> davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

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

There's more to this than just the executables. But even then,
recompilation isn't so very simple. Things that spring to my mind are:
word size, signed vs. unsigned characters (in case Your compiler changes
with the hardware, which it usually does), pointer alignment ...
Then the differences in the operating system that might/will change.
Perhaps the new architecture doesn't support Your ancient language
("Soory sir, wo don't do FORTRAN/IV any more")?

The next, perhaps even more important, issue is the vast amount of data
that You have on your disks/tapes/wherever. You'll have to convert these
too, which may really be a pain in the a**.

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

Everything in a commercial company is a customer issue, if You want to
stay in business!

>  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.
-- 
| Josef Moellers		| c/o Siemens Nixdorf Informationssysteme AG  |
|  USA: mollers.pad@sni-usa.com	| Abt. STO-XS 113	   | Riemekestrasse   |
| !USA: mollers.pad@sni.de	| Phone: (+49) 5251 835124 | D-4790 Paderborn |
Newsgroups: comp.arch
From: puri@enel.ucalgary.ca (Ruchir Puri)
Subject: Microprogrammers Help Re. Large Size Horizontal Microcodes
Date: Thu, 30 Jul 92 20:12:13 GMT
Organization: ECE Department, U. of Calgary, Calgary, Alberta, Canada
Keywords: Micoroprogramming, Control Memory, Microcode, Horizontal organization.

Hi there!
	I am working on an algorithm for "optimal minimal encoding" of
Horizontally organized microcodes in Control Memory. 
	To test the effectiveness of my algorithm I require large size 
microcode examples. Although I have tested the algorithm on randomly 
generated graphs, I will like to test it on real microcde examples.

I will appreciate your help if you can provide me some large size 
(large no. of MOs) microcodes.

Thanks a lot for your time and help...

--Ruchir Puri
  (puri@enel.ucalgary.ca)


-- 
Ruchir Puri                    VLSI Gp., Dept. of Elect. & Computer Engg.
puri@vlsi.enel.UCalgary.CA     The University of Calgary, CANADA - T2N1N4
403-220-4870 (Dept Ph.)        403-284-5825 (Home Ph.), 403-282-6855 (Dept FAX)