HDTenEightyP/NetNews huggingface dataset:
From: schow@bqneh3.bnr.ca (Stanley T.H. Chow)
Subject: Re: MVC and MVCL (was Re: RISC Mainframe)
Organization: Bell Northern Research Ltd, Ottawa
Date: Sat, 25 Jul 1992 17:39:12 GMT

In article <l6rkltINN88q@spim.mips.com> mash@mips.com (John Mashey) writes:
>In article <1992Jul20.154604.12548@bcars64a.bnr.ca> schow@bqneh3.bnr.ca (Stanley T.H. Chow) writes:
>
>>Clearly then, you belong to the compile-code-for-each-different-machine
>>school of administration. I think I will start a disk drive company to
>>supply your disk requirements :-)
>
>1) Some systems support dynamic-linked shared libraries for a lot of
>other reasons; that's one way to do it.

Why not look at H/W as "dynamic-linked shared libraries" that is bound
by the H/W :-)

>2) if it really makes a difference, it's not all that hard to have
>a function that checks once to see which machine is there, andthen choose
>one of several versions of the code, 8after* checking to see that the
>move-length is long enough to be interesting.

But the problem is that the one must have thought of checking for all
the different combinations at the time before generating the binary. If
binary compatibility is important, the binaries that the system must 
run whill have been generating with none of the checks. (Murphy's law
says binaries that you don't care about will have all possible checks
already present, but you could just easily rebuilt them).

--
Stanley Chow            InterNet: schow@BNR.CA
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
(613) 763-2831
Me? Represent other people? Don't make them laugh so hard.
Newsgroups: comp.arch
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: BUSES
Organization: Keith's Computer, Hope Mills, NC
Date: Mon, 27 Jul 92 19:13:47 GMT

In article <1992Jul23.191927.1181@pcnntp.apple.com> pauls@apple.com (Paul Sweazey) writes:
>In article <1992Jul23.092211.18462@nuscc.nus.sg> eletanjm@nuscc.nus.sg 
>(TAN JIN MENG) writes:
>>[Bus Speed & Efficiency ??? ...]
>
>Over the last decade or so processors, RAM, and disk storage have all 
>increased in speed or capacity by two or three orders of magnitude.  Where 
>have buses gone during the same period?  Not very far, not in real-world, 
>affordable systems.  This imbalance has turned modularity into a myth.  If 
>add-in hardware were both blindingly fast and incredibly cheap then 
>modular computers might be a much more interesting market.

Is it not also true however, that the current disk devices can't even
swamp an ISA bus?  The average desktop doesn't have multiple striped
disks and whatnot.

Even the new crop cannot swamp an EISA bus.  Video may soon go another
route, we will see.  Memory is already localized, as part of the CPU on
most products, with a SIMM pinout becomming a local memory bus of sorts.

Someone please correct me if I'm wrong, but I think the inherent problem
with a 'bus' of any description is the delay while the electrons take a
torturous route across the copper foiling, and thru the connectors and
buffers from the CPU to whatever card.  As clock speeds of CPU chips
go up, it just takes too long for the information to run accross the
conductors.  Now how are we going to design a bus that makes the
electrons move quicker across the wires?  

IMHO the only way to solve this is to have seperate input and output
"busses" that allow for multiple electrons to be traveling across the
"wires" at the same time.  Seperate because you can be sending fetch
requests off of one side while yanking them in on the other.

ramble, ramble, ramble on...
-- 
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: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Date: 28 Jul 92 15:47:08 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Jul25.121952.17315@darkcube.radig.de>, vhs@darkcube.radig.de (Volker Herminghaus-Shirai) writes:

| DEC, MIPS and Motorola started with a cleaner, more future-oriented design
| in the first place. Of Motorola and DEC I know they also abandoned instructions
| that weren't used very much, replacing them with emulation libs. This kind
| of compatibility is OK, it's the 100%-stick-to-fouled-up-design-and-make-
| everyone-believe-this-is-the-only-way-to-go that's not..

  Seems to me that DEC started emulating the instructions nobody used
right about the time the DEC C compiler starting using them. I'm not
joking, several people in DEC have told me this, and I believe I read it
in some  various net discussion at the time.

  If you look at the block diagram (_EE Times_ I think) it looks like
the CISC execution unit is a small part of the chip which is mainly
RISC, cache, and memory control. I assume that if the chip is ever
produced that there will be a new version of UNIX to use the RISC, and
DOS will run beneath. Perhaps there's even hope that the "386 CPU" on
the diagram could run in protected mode with some higher part of the
memory access system keeping it from using most of the physical memory.
-- 
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: krish@ledzep.asd.sgi.com (Krishnan Sridhar)
Newsgroups: comp.arch
Subject: Trap Barrier Instructions
Date: 31 Jul 92 20:05:01 GMT
Distribution: usa
Organization: Silicon Graphics, Inc.


As I understand it, a trap barrier instruction (as in alpha and
possibly other architectures I am not aware of) is used
to force a precise trap/exception to take place, when the basic
exception handling mechanism itself is defined to be imprecise.

Questions:

	(1) Is this correct?

	(2) If so, how does it work? (How does putting this
		instruction in the instruction stream enable the CPU
		to preserve the exact state when the exception occured?)

Another related question: For machines which support only imprecise
exceptions, how do you *fully* recover from that state when you don't know
what caused it?


Thanks in advance!!

- Krishnan
Newsgroups: comp.arch
From: gumby@Cygnus.COM (David V. Henkel-Wallace)
Subject: Proposal: Computer History Project
Organization: Cygnus Support, Palo Alto, California
Date: 30 Jul 92 14:29:13

   Date: Fri, 24 Jul 1992 14:46:43 GMT
   From: stewart@crl.dec.com (Larry Stewart)

					 Thus students will be
   able to actually sit down and use TENEX running on an emulated
   PDP-10, or Bravo on a Xerox Alto, even when no more PDP-10's or
   Altos exist.

Note that the Alto had a nova emulation mode, so you'll have to
emulate the emulation.

(And anyone who wants to run Bravo can just run Microsoft Word, but it
 would be nice to run Laurel for old times' sake).
Newsgroups: comp.arch
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project, & backwards compat
Date: 31 Jul 92 18:18:39 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


In article <id.RSXR.X1@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>
>Waxing analogical... who would want to drive a 1920-era car?

Well, let's see.  Would you want to drive a 1920-era car to work everyday,
or for all the other things you use a modern car for?

On the other hand, would you have shows where people come from miles around
to view old software being run?  Would you have large gatherings where
people are drawn together only by their common interest in running old
software? For that matter, what will you do when you run old software?
Will groups of friends gather to write new 1401 assembler programs?

But then comparing an old computer to an old car is stretching the
analogy anyway; because a car is a personal possession whereas most of
the old computers were not.  Maybe a better analogy is a 1920s army
tank or airplane.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle
Newsgroups: comp.arch
From: jjsmith@nyx.cs.du.edu (Jonathan J. Smith)
Subject: Re: Cached DRAM from Mitsubishi
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Wed, 29 Jul 92 23:32:44 GMT

In article <1992Jul29.224223.22285@beaver.cs.washington.edu> noah@cs.washington.edu (Rick Noah Zucker) writes:
>In article <1992Jul29.214908.7876@trantor.harris-atd.com> dwilliam@jabba.ess.harris.com (David Williams) writes:
>>   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)
>
>	This is a little unclear, and if you have more detailed
>information, please clarify my point.  You say that 70 ns after a cache
>miss, the SRAM can start doing stuff, but the DRAM is busy for another
>210 ns.  Does this mean that you will get your data in 70 ns, but the
>DRAM is busy for another 210 ns because it has to write back the data you
>just read out?  Or does it mean that you can initiate another request in
>70 ns?  That is, you can make another request to the chip, which will be
>satisfied if it is in the cache.
>
>						Rick Noah Zucker
>						noah@cs.washington.edu


From what I got out of the article, the dram reads an entire column of data from dram into the cache when a miss occurs.
so that providing that the next read is within that column it can read in 70ns.

Jonathan
Newsgroups: comp.arch
From: knauer@cs.uiuc.edu (Rob Knauerhase)
Subject: Re: What's in a name?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 28 Jul 1992 01:13:58 GMT

In <kitchel.711899554@moray> kitchel@moray.dpsi.com (Sidney W. Kitchel) writes:
>mkahn@hopi.sedona.intel.com (Mitch Kahn) writes:
>>Intel boxes will still be the cheapest MIPs on the planet. 
>	WRONGO!!!! As of now, the cheapest MIPS on the planet come
>from MasPar Computer Corp. The MasPar MP-1 offers them at $50 / MIPS.
>You should ask Intel when you are going to get a 200 MIPS box for
>$10,000.

Perhaps by "MIPS" Mitch was referring to MS-DOS Instructions Per Second?
That is after all what the majority of people seem to want.  [1/2 :)]

Of course, if P5 does turn out to be 100 MIPS, you might soon be able to get
two boxes for $10K -- 100MIPS + 100MIPS = 200MIPS, right? (oops, wrong thread)

Rob
--
Rob Knauerhase           University of Illinois at Urbana-Champaign
knauer@cs.uiuc.edu       Dept. of Computer Science, Gigabit Study Group
knauer@knauer.intel.com  Intel Multimedia Software Technology Group (summer)
"There's no place like $FC58!"
From: narad@nonsequitur.Eng.Sun.COM (Chuck Narad)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 28 Jul 92 17:16:49 GMT
Reply-To: narad@nonsequitur.Eng.Sun.COM
Organization: Sun Microsystems
NNTP-Posting-Host: nonsequitur

In article 92Jul28085651@maui.linus.mitre.org, bds@maui.linus.mitre.org (Barry D. Smith) writes:

>2) What exactly is a "superfast sub-imbecile?"
>

That's the best defintion I've heard for a computer...
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
From: dhd@exnet.co.uk (Damon)
Subject: Re: dinosaur horsepower
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Wed, 29 Jul 1992 13:48:02 GMT

In article <1992Jul28.155852.23608@sctc.com> smith@sctc.com (Rick Smith) writes:
>I was a fan of papertape myself. (5 points: can you spot the pun?)

No, but I'm sure I'll burst out laughing when you list out the hole joke.

(NOTE FOR THR HUMO(U)R-IMPAIRED: THERE ARE THREE (3) PUNS IN THE ABOVE
 SENTENCE.  THIS EXPRESSION INTENTIONALLY BLANK.)
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.21|| ALL MAIL FREE.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || Hotrod motor groups soon.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Request Info Re Bus Trends & Intel 486s
Keywords: Intel 486 Bus
Date: 27 Jul 92 16:35:36 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <id.TJRR.XR8@ferranti.com>, peter@ferranti.com (peter da silva) writes:

| Why is it that backplanes aren't more common on the desktop? Even for the PC
| world, they're available (under the ugly name "passive motherboard"), and until
| the IBM-PC came out they were the norm for multi-board systems (you had either
| single-board CPUs or S100 or equivalent). The only exception was the Apple II,
| and then the IBM-PC. Is it just tradition or is there something that makes a
| motherboard system inherently better?

  If you are not upgrading the system often, a motherboard is a lot
cheaper and more reliable. With reliability related to number of
connections, having the CPU plug in on a board adds room for problems,
take space, adds cost, etc. Also, a backplane normally has boards at
right angles to the plane, and that makes the total package larger than
the tiny "pizza box" configurations.

  A backplane would be fine if we could only agree on how large it
should be ;-) I can't see less than 64 bits data, 48 bits address, and a
32+32 bit set of lines for video adaptor(s). Add control lines and get a
large connector.

  Price performance brought motherboards into favor, and will probably
keep them there in the desktop market.
-- 
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.
Newsgroups: comp.arch,alt.folklore.computers
From: prp@SSD.intel.com (Paul Pierce)
Subject: Re: Proposal: Computer History Project
Keywords: software, history, computer
Reply-To: prp@SSD.intel.com (Paul Pierce)
Organization: Intel
Date: Wed, 29 Jul 1992 01:51:01 GMT

In article <1992Jul24.144643.19792@crl.dec.com>, stewart@crl.dec.com (Larry Stewart) writes:
|> Here is the beginning of an idea.  Let's kick it around and build on it.
|> 
|> THE COMPUTER HISTORY PROJECT
|> 


Someone connected with the Computer Museum in Boston was looking into the idea of
preserving software a couple of years ago. I don't know what became of that
investigation, it would be a good idea to check with them.

I think the proposal has a great deal of merit, especially since it
includes the essential elements to preserve the most important aspect of historic
software, the ability to run it on later machines. Key to that is machine and/or
OS emulators, well defined storage formats for obsolete media,

and **documentation**.

To make preserved software accessible, you need something like step-by-step
instructions for bringing it up on the emulator so that it is not necessary to
relearn everything about the old machine in order to run the software.


I have an IBM 709/7090/7094 emulator in progress, along with diagnostics and
the IBSYS operating system to verify its accuracy. (Currently, they verify its
inaccuracy.) It follows the style Doug was talking about, attempting to
reproduce the feel of the machine and run the real OS in addition to merely
running the same application software.
I think that this is the better approach, rather than an OS emulator,
especially for the oldest machines with lights and switches and clunky IO devices.

For the 7090 emulator I have defined some storage formats for 7-track tape
and 80-column cards which preserve things like parity and record length.
They might be a good starting point for saving images of these media.

A "treasure trove" of fun old software to preserve would be the SHARE and
DECUS libraries. Do IBM and DEC maintain copies of these back into the early
days? If not, I know of a company that recently had the SHARE library for
the 7090 family.

Other projects I am aware of include emulators for the IBM 1401, 1410, and 650.
There are Z80 and IBM/370 simulators (which include OS simulation) for the PC.
And of course there are several PDP-8 simulators.

So who's in charge, Larry?
-- 
Paul Pierce			prp@ssd.intel.com
Intel
Newsgroups: comp.arch
From: repass@futserv.austin.ibm.com (James Repass)
Newsgroups: comp.arch
Subject: Re: Graphics Systems
Date: 20 Jul 92 20:04:01 GMT
Reply-To: repass@futserv.austin.ibm.com (James Repass)
Organization: IBM Corporation, Advanced Workstation Division



CPU <-> Bus <-> Display Adapter (DA)
CPU <-> Bus <-> DA with memory
CPU <-> Bus <-> DA with memory and processing (CPU)
CPU <-> Bus <-> DA with memory and CPU
CPU <-> Bus <-> DA with memory and CPU <-> Bus <-> Display Adapter
                                  /                             /
  /------------------------------/                             /
 /                                                            /
/                                   /------------------------/
CPU <-> Bus <-> Display Adapter (DA)


Where will it END?
Where WILL it end?


Thanks,        Jim Repass  | Internal - jim@repass.austin.ibm.com
  ____         IBM-AWD-FST |     VNET - REPASS@AUSTIN
   / . __      Austin, Tx. | Internet - repass@futserv.austin.ibm.com
(_/ / ///      Int.ZIP 9461| Phone    - (512)-838-8507 (tie)-678-8507
_____________________________________________________________________ 
I speak, therefore I am.
I do not speak for the company, it does not speak for me!
From: ak@ananke.stgt.sub.org (Andreas Kaiser)
Newsgroups: comp.arch
Subject: 64-bit CPU vs 2 x 32-bit CPUs 
Distribution: world
Date: Sun, 26 Jul 92 23:49:03 GMT
Organization: ananke


In article <l7133mINN75s@spim.mips.com> mash@mips.com writes:

  > 3) The main reason is to get more address sapce (conveniently).
  > There are not a *huge* number of these things; however, the ones that
  > are there are *extremely* important to the people who use them, as they
  > are things like:

Large applications are one reason, shared libraries (DLLs) and shared
memory mappings are another. Implementing shared libraries or shared
memory can enforce a global allocation mechanism, with all DLLs and all
shared memory areas in the system having system-wide unique virtual
addresses. Otherwise at least shared libraries could not be shared
(relocation) with all processes. And this limitation can be exceeded
quite soon (within some years) in a pure 32-bit virtual address range.

And there are memory mapped files as filesystem implementation
technique. You clearly need more than 32-bit addressed virtual memory
to implement memory mapped files. IBM added some kind of segmentation
to the RS/6000, but 64-bit addressed virtual memory is easier to
handle.

:::::::::::::::::::: subnet:  ak@ananke.stgt.sub.org
:: Andreas Kaiser :: fidonet: 2:241/7220.9
::::::::::::::::::::
Newsgroups: comp.arch
From: chip@chinacat.unicom.com (Chip Rosenthal)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Organization: Unicom Systems Development, Austin, TX
Date: Thu, 23 Jul 1992 07:54:43 GMT

In article <MKAHN.92Jul22091003@hopi.sedona.intel.com>
	mkahn@hopi.sedona.intel.com (Mitch Kahn) writes:
>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 would imply that the 486 layout is not pad constrained.  I would
have assumed it is because...well...it *always* seems to work out that
way.  Can anybody comment?  What are the current 486DX and 486SX die
sizes.

-- 
Chip Rosenthal  512-482-8260 | Let the wayward children play.  Let the wicked
Unicom Systems Development   | have their day.  Let the chips fall where they
<chip@chinacat.Unicom.COM>   | may.  I'm going to Disneyland.  -Timbuk 3
From: lynch@ccwf.cc.utexas.edu (Tom Lynch)
Newsgroups: comp.arch
Subject: Re: Proposal: Computer History Project, & backwards compat
Date: 28 Jul 92 17:23:13 GMT
Organization: The University of Texas at Austin
In-reply-to: stewart@crl.dec.com's message of 24 Jul 92 14:46:43 GMT



  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.  Thus students will be
  able to actually sit down and use TENEX running on an emulated
  PDP-10, or Bravo on a Xerox Alto, even when no more PDP-10's or
  Altos exist.

This sounds like an argument for backwards compatibility.

-tom                                    Nothing is Absolute!
lynch@ccwf.cc.utexas.edu                Absolutely.
From: misha@ai.mit.edu (Mike Bolotski)
Newsgroups: comp.arch
Subject: Re: Running Sum Adders
Date: 23 Jul 92 01:41:58 GMT
Organization: MIT Artificial Intelligence Laboratory
In-reply-to: ronus@eecg.toronto.edu's message of 21 Jul 92 23:46:23 GMT

>>> On 21 Jul 92 23:46:23 GMT, ronus@eecg.toronto.edu (Ron White) said:

Ron> Hi.  I have a paper that mentions the use of a: "running sum
Ron> adder commonly found parallel processing units".  The paper
Ron> doesn't go into any more detail and doesn't list any references
Ron> w.r.t. this type of parallel adder.  Could someone point me to a
Ron> reference that will explain the operation of a "running sum
Ron> adder" ?

I'll bet they're referring to a carry-save adder.  You can look
that up in any text on computer arithmetic.


--
Mike Bolotski          MIT Artificial Intelligence Laboratory
misha@ai.mit.edu       Cambridge, MA 02139     (617) 253-8170
From: culter@convex.com (Brad Culter)
Newsgroups: comp.arch
Subject: Re: What's in a name?
Summary: citation required
Date: 24 Jul 92 16:45:44 GMT
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1992Jul21.040216.13502@primerd.prime.com> danw@hobbes.prime.com (Dan Westerberg) writes:
>In article <1992Jul20.092822.7666@spool.cs.wisc.edu>, mfrank@wilma.cs.wisc.edu 
>(Matt Frank) writes:
>> 
>> Backwards compatability has always been a particular pet peeve of mine, so I
>> feel the need to add my two cents worth.  I have two specific problems.

	I can't recall where I read the following, perhaps it was a signature
	line in a note in this group? I don't recall the exact wording
	but it's relavent to the point that Mr. Westerberg makes.

	"The reason God was able to create the entire universe in 6 days
	was because He had no installed base."


	Does anyone know who said this first?


Brad Culter
Newsgroups: comp.arch
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Scheduling in Shared Memory Multiprocessor Systems
Organization: Massachusetts Institute of Technology
Date: Sat, 25 Jul 1992 14:15:16 GMT

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 has queue management instructions and a find-first-bit
instruction that scans 32 bits.

The BSD port to the IBM RT used 16 run queues, because the RT
find-first-bit instruction only scans 16 bits.

--
    John Carr (jfc@athena.mit.edu)