HDTenEightyP/NetNews huggingface dataset:
From: j-grout@uxa.cso.uiuc.edu (grout john robert)
Subject: Re: A Little History
Reply-To: j-grout@uiuc.edu
Organization: University of Illinois at Urbana
Date: Fri, 21 Aug 1992 22:10:33 GMT

smith@sctc.com (Rick Smith) writes:

>While it's nice to have history provide the personal touch
>(associating a person with a concept) history is especially
>significant in computer architecture because many of the concepts
>don't really become obsolete.  It's amazing how much of it is
>independent of the implementation technology. In other words, things
>that worked in tube machines are still being used in VLSI. Sometimes
>the only published example of a technique is a historic example, since
>today's vendors don't always describe things in as much detail as we
>might need. In other cases, "everybody" knows about various classic
>examples (Illiac IV for multiprocessing, Cray for vector registers,
>B5000 for "thunks") and the peculiarities of the implementation point
>the rest of us in particular directions as a result.

>What goes around comes around. So it's good to know what's coming.

In "What's All This about Gallium Arsenide", a presentation Seymour
Cray made to Supercomputing (in Orlando, FL), he talked about how he
learned to build reliable computers out of unreliable semiconductors
in the 1950's (use diode-transistor logic)... then startled his
audience by telling him that he reused that knowledge in the Cray-3
(because gallium arsenide is unreliable than more conventional
semiconductors)... everyone laughed when they realized just _why_
he'd been telling us about these experiences of his from the 1950's.

-- 
John R. Grout
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

Xref: sparky comp.arch:8931 comp.lang.c:12418 comp.programming:2353 comp.unix.programmer:4332
From: jott@crash.cts.com (Joan Tine)
Newsgroups: comp.arch,comp.lang.c,comp.programming,comp.unix.programmer
Subject: Sorry, but...
Summary: Obfuscated C Code entries of time past...?
Date: 17 Aug 92 08:15:08 GMT
Followup-To: comp.lang.c
Distribution: usa
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA


I've waited, read the FAQ, and tried not to trouble the newsgroup, but
I don't seem to be able to find any information about the National
Obfuscated C Contest, such as: where are the results posted, when 
each year do they come out, and what newsgroup carries them?

I've only got one year's entries, and they were wonderful.  I'd like
to complete my collection of them, but I don't see them on this
group...and I think it's been over a year since I started reading
it...but not every message, so mea getmaxx() culpa if I should already
know.  If it's the kind of question that everybody knows the answer to,
then please don't anyone post a reply, deluge my mailbox with it, and
I'll summarize and post it myself, thanks.  I'm not on a system that
allows me to telnet or cu, so messaging a server is about as interesting
as I can get with the software...I just don' know who's keeping the
keys to the kingdom.

Sorry if this is a stupid message.

Joan
Newsgroups: comp.arch
From: jg@crl.dec.com (Jim Gettys)
Subject: Re: PA-RISC Virt Addr > 32 bits (was Re: Caches and Hashing)
Organization: DEC Cambridge Research Lab
Date: Thu, 20 Aug 1992 21:06:12 GMT

In article <baQk02L41el501@JUTS.ccc.amdahl.com> haw30@macaw.ccc.amdahl.com (Henry A Worth) writes:
>In article <1360024@aspen.NSA.HP.COM> morris@aspen.NSA.HP.COM (Dale Morris) writes:
>> 
>> Although the user-visible virtual address space in current PA-RISC
>> products is 32-bit, PA machines actually implement a larger virtual
>> address space (48 bits in the snakes workstations).  This large global
>> address space is used by the OS in many ways to improve performance.
> 
>   Is the >32 bit virtual addressing strictly limited to the OS, or is 
>it possible for user processes to map multiple address spaces and use
>"far pointers"?  If not, is there any announced intent to provide 
>such features in future OS's?  Likewise, does anyone know if >32 bit 
>virtual addressing in user processes is (or will be) supported in OS's
>for the MIPS R4000 or IBM RS6000 (and, of course in a few years there will
>be the SPARC-64, late to the party again ;-) )?  
>

This message composed on a Digital Alpha workstation running OSF/1
with full 64 bit support.

More need not be said.
				Jim Gettys


-- 
Digital Equipment Corporation
Cambridge Research Laboratory
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: question on computer systems using Alpha ... (cooling)
Date: 22 Aug 92 18:11:36 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Aug19.094652.11356@mole-end.matawan.nj.us> mat@mole-end.matawan.nj.us writes:
>In article <JAN.92Aug14135936@pallas.neuroinformatik.ruhr-uni-bochum.de>, jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>>    Why doesn't anyone (to my knowledge!) use heat pipes, and/or stirling
>>    engines for cooling big chips like the alpha?
> 
>> Look at the design of the GC machines from parsytec. ...
>
>> Actually, cooling shouldn't be much of a problem  ...  For a 16k
>> processor GC machine, parsytec expects it to dissipate about 430kW.
>> Sounds like a lot? Now look at a 400 horse power truck motor. 400 hp
>> is roughly equivalent to 300kW, and the motor dissipates at least
>> twice that in heat (efficiemcy is around 30%).  No problem, all you
>> need is a nice 60 km/h air flow into your computer room...
>
>But much of the truck's waste heat goes out the exhaust pipe.  I don't
>know of any way to pull the heat out of either the bitbucket or the
>power line.

Well, I think we should add a new UNIX character-special device, /dev/heatsink.

(B^>)

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.24|| Cheap Sun eqpt available.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || US high-perf motor groups.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
From: marc@watson.ibm.com (Marc Auslander)
Newsgroups: comp.arch
Subject: Re: 32 => 64 Transition
Date: 19 Aug 92 22:03:00 GMT
	<1992Aug11.125326.16719@email.tuwien.ac.at> <id.UHAS.9TA@ferranti.com>
Organization: IBM T.J. Watson Research Center, Hawthorne, New York
Disclaimer: This posting represents the poster's views, not necessarily those of IBM

The intent of ANSI C appears to be that int is the "natural"
arithmetic of the machine.  This is reflected in the integer promotion
rules, which promote to int but NOT to long.  Thus,

        int i,j;
        long k;
        k=i+j;

is defined to do its arithmetic in int, producing an int result, and
then convert to long at the assignment.  If i+j overflows (as int) the
results are undefined.  The idea clearly is that compilers shouldn't
be forced to use the possibly less efficient long arithmetic on ints.
Only by making int 64, or by changing the role of int in defining the
way expressions are evaluated, can we avoid this and other anomalies.

--


Marc Auslander       (IBM)<marc@marc.watson.ibm.com>      914 784-6699
                     (Internet)<marc@watson.ibm.com>
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: PALcode instructions vs TRAP instructions
Date: 17 Aug 92 10:17:35 MDT
Organization: Utah State University

In article <Bt4Grs.2Ap@exnet.co.uk>, dhd@exnet.co.uk (Damon) writes:
> In article <1992Aug16.195833.58188@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>>
>>The problem with wild pointers should be solved as soon as the OS is up far
>>enough to initialize the page tables. If the page tables don't include the
>>console memory, the OS can't get at them.
> 
> Mmm.  But waht about bugs (eg wild pointers) in the OS?  I mean, am I missing
> something, or don't OSes still have bugs in them?  B^>/2

Yes, but on a VAX or (possibly) an Alpha, the opportunity for a bug to 
happen that corrupts the console data is small and limited to the
bootstrap. Yes, you can have wild pointers in the OS, but unless it's in
the bootstrap it's not going to corrupt the memory reserved for the
console and PALcode.

Roger Ivie
ivie@cc.usu.edu
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: question on computer systems using Alpha ...
Date: 12 Aug 92 17:25:56 GMT
Article-I.D.: cs.1992Aug12.172556.91192
Organization: School of Computer Science, Carnegie Mellon


hallam@zws010.enet.dec.com () writes:
>the chip itself can drop 36 watts, I think the problems cooling the chip
>will be challenging enough without getting hung up about power suplies.

What problems?

I've held an Alpha (+heatsink) in my hand, and I have no trouble
believing DEC when they say they can put it in a (quiet) desktop
unit. In fact, the original demo was just that.

The cooling guys at DECWRL estimated that they could cope with a 140
watt chip with a 12 cm high cooling tower and two 6 cm fans. On a
desktop. [Not a pizza box, of course: probably something more along
the lines of the Indigo.] One odd wrinkle: the tower loses cooling
ability if it isn't vertical, so there's a sensor and a power cutoff.

The bottom line is, in a world that can cool Crays, a lightbulb's
worth of power isn't the end of the world.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: hallam@zeus02.desy.de (Phillip M. Hallam-Baker)
Subject: Re: question on computer systems using Alpha ...
Reply-To: hallam@zeus02.desy.de
Organization: DESY ZEUS Central Data Acquisition
Date: Mon, 17 Aug 1992 06:38:35 GMT

In article <1992Aug12.172556.91192@cs.cmu.edu>, lindsay+@cs.cmu.edu
(Donald Lindsay) writes:

|>hallam@zws010.enet.dec.com () writes:
|>>the chip itself can drop 36 watts, I think the problems cooling the chip
|>>will be challenging enough without getting hung up about power suplies.
|>
|>What problems?
|>
|>I've held an Alpha (+heatsink) in my hand, and I have no trouble
|>believing DEC when they say they can put it in a (quiet) desktop
|>unit. In fact, the original demo was just that.
|>
|>The cooling guys at DECWRL estimated that they could cope with a 140
|>watt chip with a 12 cm high cooling tower and two 6 cm fans. On a
|>desktop. [Not a pizza box, of course: probably something more along
|>the lines of the Indigo.] One odd wrinkle: the tower loses cooling
|>ability if it isn't vertical, so there's a sensor and a power cutoff.

Yep, but the original question was about fitting alpha into existing
racks. Obviviously cooling that amount is quite possible. However it
will be difficult to do this in a VME crate. If like us you have almost
a thousand VME type (or similar) crates you can see why we would not be
too happy to have to junk them just to upgrade the processor. 12cm is
space for 8 cards. What is critical in our environment is not CPU power
but CPU per unit volume, we can parallelize and use T9000 technology
instead of alpha.

If you have the luxury of starting from a clean sheet of paper with no
historical design restrictions then the 3.5 volt power line is no
problem at all - simply add an extra power rail, put the complexity in
the power supply. We butcher VME anyway to add non standard power rails
to supply ADCs and exotics, adding an alpha heat sink will be a problem,
perhaps adding a large plate extending the entire surface area of the
card would be sufficient - we won't want more than an alpha power per
card.

>The bottom line is, in a world that can cool Crays, a lightbulb's
>worth of power isn't the end of the world.

But the problem is not the power itself but the power density.
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch,alt.folklore.computers,vmsnet.pdp-11
Subject: Re: Unnormalized FP and a PDP-11 bug (Re: Algorithm for bit finding)
Date: 12 Aug 92 11:55:53 GMT
Followup-To: comp.arch
Organization: Rutgers University Computing Services

In article <BsKqyz.JLB@watcgl.uwaterloo.ca>, awpaeth@watcgl.uwaterloo.ca
(Alan Wm Paeth) writes:  [Describes problme on PDP-11 with using FP operations
to copy non-FP data, because the FP unit would normalize the values.]

There've been a number of responses to this, including responses from people
who I KNOW are familiar with PDP-11 (and VAX) format FP numbers, and they all
neglect to point out a fundamental flaw with the story as told:  The format
uses a hidden bit representation, so the in-memory value is NOT "normalized"
(in the sense that the most significant STORED bit is 0 about half the time).
An FP unit that tried to "normalize" a value like this to get rid of the 0
top bit would not be doing the FP arithmetic of this universe.

What probably was REALLY going on was that some data consisted of "false
zeros" - a zero sign bit, zero exponent, and non-zero significand.  I don't
have a 11/45 manual handy, but my 1979 PDP11 Processor Handbook does,
indeed, not explicitly state that a "false zero" will be converted to a
"true zero" (all zero bits) by a LDF or LDD.  (On the other hand, a sign bit
of 1 with an exponent or 0 - "-0" or "undefined variable" in -11 terminology,
"Reserved Operand" in VAX terminology - can trap during a load, so a prudent
ISP abuser might suspect that something might happen to "false zeros".)

							-- Jerry

(My favorite story of a simliar problem is on the CDC 6000 series.  They
use 1's complement arithmetic, and when you load a B register, you can't
really load a constant - you load contant plus some other B register.  No
problem:  B0 is always 0, so you add it.  Except that in one's complement
there is also -0 (all 1 bits), and the arithmetic unit tries very hard never
to generate -0 as an output.  In fact, 0+(-0) is 0.  So you can't load -0 that
way!  The trick is to realize that the REAL identity for addition on this
machine is -0, and get that into a register (using bit-wise operations) for
use in place of 0 when loading data that isn't really numbers.)
From: jcooley@seqp4.sequoia.com (John Cooley)
Newsgroups: comp.arch
Subject: A Little History
Date: 21 Aug 92 17:56:46 GMT
Organization: Sequoia Systems Inc., Marlboro, Mass.

> From: jesup@cbmvax.commodore.com (Randell Jesup)
>
> finally pushed me over the edge.  What I'm proposing is to split comp.arch,
> in an attempt to move the discussions of computer architecture history into
> a separate group.  I'm sure there will be some overlap, and discussions that

>       There have been recurrent long discussions/reminiscences of ancient
> general volume level is increasing with the internet population, in any case
> it has become a problem IMHO).

I disagree.

Since the majority of us are more or less technonerds who've devoted a
good chunk of our professional lives to advancing technology; I think
it doesn't hurt to get a little history every now and then.

There seems to have been an almost Stalinist approach to writing
most college textbooks on physics, programing and electronics with the
goal of purging practically all references to the people who did the original
research.  We seem to have multiple generations of scientists & engineers
who now know more about the fictional world depicted in Star Trek than, say,
the stories of the people who created radio, TV, transistors and microchips.

I thought it was sad that, as an electrical engineer, I never even heard
one iota about all the stories and legal battles the inventors of AM and
later FM radio went through with each other until a recent broadcast of
a show on PBS called "Empire of the Air".  Why wasn't I taught this somewhere
in school?  I could give you an almost complete lecture with equations as
to the technical differences of AM and FM modulation; but ask me one history
question before this show aired and I wouldn't have known a thing!

I think one of the reasons engineers are pretty much talked about
as "resources" instead of professionals by their managers is because we're
taught to concentrate more on "things" instead of "people".  (Yet, in the
engineering work world, it's typically politics that cause engineers the most
headaches in pursuing a goal; not the technology.)

People who have don't want to "waste time" reading occassional bits of history
can very easily skip over these headers; that's why we use readers to
go through newsgroups.

 ===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
 with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
 ===========================================================================
      !!!     "It's not a BUG,    |           jcooley@sequoia.com
     /o o\  /  it's a FEATURE!"   |         jcooley@sds.sequoia.com
    (  >  )                       |        "Yes, We make trees here!"
     \ - /       |
     _] [_       |        "This here ain't no one's opinion 'cept my own."
 
Newsgroups: comp.arch
From: hart@cp4.cp.bell-atl.com (Rod Hart - Director Minicomputer Techn. Support)
Subject: 386bsd on tape wanted
Organization: C & P Tel. Co. - Minicomputer Techn. Support Dist.
X-Newsreader: Tin 1.1 PL5
Date: Tue, 18 Aug 1992 01:54:00 GMT
From: rw@dcs.ed.ac.uk (Robert Walker)
Newsgroups: comp.arch
Subject: DETAILS OF ARCHITECTURES WANTED!
Date: 20 Aug 92 13:32:41 GMT
Organization: Department of Computer Science, University of Edinburgh


   I am just entering my final year at uni and am doing a project somewhere
(???##!!) in the field of Computer Architecture.

   I would be very grateful to get the addresses of some FTP sights containing
as much detail as possible regarding the pipelines of common RISC architectures/
their implementations.

   For example: MIPs R3/4/6000, i860, Sparc architecture, M88x00, Alpha, etc.

   I know of some of the companies, which have designed these chips/
architectures, will be loath to `give anything away' regarding low-level
design decisions. But postscript copies of manuals which describe even some
basics, such as how many pipestages these processors have, would
be helpful!

   Email straight to me!

      Rob

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

      Email at: rw@uk.ac.ed.dcs
Xref: sparky comp.arch:8887 alt.folklore.computers:12509 comp.benchmarks:1300
From: mitch@novavax.UUCP (Mitch Silverman)
Newsgroups: comp.arch,alt.folklore.computers,comp.benchmarks
Subject: Re: the four-color theorem (was: Re: dinosaur horsepower)
Date: 12 Aug 92 22:42:41 GMT
Reply-To: mitch@novavax.nova.edu (Mitch Silverman)
Followup-To: alt.folklore.computers
Organization: Nova University, Fort Lauderdale, Florida

In article <1992Aug12.150356.25725@schaefer.math.wisc.edu> wilson@math.wisc.edu (Bob Wilson) writes:

>What the proof is really belongs in some other group, but since it
>is popular to talk these days about proofs which are only
>probabalistically "true" it seemed appropriate to show why this
>is not one of them. This is possibly relevant to this group since
>many of the places such proofs ARE being used is in connection with
>properties of computing systems.

Well, I disagree, at least as far as comp.benchmarks and alt.folklore.computers.
I for one would like to see a bit more about the proof (though your
explanation above is perfectly lucid), such description being an excellent
example of computer folklore.
 
And as for comp.benchmarks--think of what a good PC benchmark a four-color
theorem prover might make--in five or ten years.  (If that long.)

Mitchell L. Silverman
Student, New College of the University of South Florida
mitch@cfraix.cfr.usf.edu
mitch@novavax.nova.edu
 
Newsgroups: comp.arch
From: bad@flatlin.ka.sub.org (Christoph Badura)
Subject: Re: Why would you like a debugger (Was: What would you like in a debugger?
Organization: Guru Systems/Funware Department
Date: Sun, 16 Aug 1992 00:25:24 GMT

In <1241@esl.ESL.COM> davida@barney.esl.com (David Alexander) writes:
> Then we had our weekly meeting, and as we're talking, Prof. Knuth
>is flipping through my WEB source which he had never been shown before, and
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That may very well be the explanation.

>about 40 pages into the listing, in the middle of our discussion, he says,
>"By the way, here's your NIL pointer error..."  Of course he was correct.

One of the problems in debugging your own programs is that you *know*
what the program text looks like. I once spent three days chasing the
following bug:

for i := left to right do;
	something_or_other;

For three days I didn't see the semicolon after the do, I knew there
wasn't one.

The previous two times I used a debugger, I was tracking down compiler
errors.

Since the I haven't found debuggers to be very useful. Many were
inadequate for the problem (conditional breakpoints are a *must*),
they don't give you a clue as to where you are in the source (adb).
Some were to buggy to be useful (sdb comes to mind). I am pleased with
gdb, though.
-- 
				Christoph Badura  ---  bad@flatlin.ka.sub.org

ISO? Nicht immer, aber immer M-vfter.
From: haw30@macaw.ccc.amdahl.com (Henry A Worth)
Newsgroups: comp.arch
Subject: PA-RISC Virt Addr > 32 bits (was Re: Caches and Hashing)
Date: 20 Aug 92 19:54:21 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <1360024@aspen.NSA.HP.COM> morris@aspen.NSA.HP.COM (Dale Morris) writes:
> 
> Although the user-visible virtual address space in current PA-RISC
> products is 32-bit, PA machines actually implement a larger virtual
> address space (48 bits in the snakes workstations).  This large global
> address space is used by the OS in many ways to improve performance.
 
   Is the >32 bit virtual addressing strictly limited to the OS, or is 
it possible for user processes to map multiple address spaces and use
"far pointers"?  If not, is there any announced intent to provide 
such features in future OS's?  Likewise, does anyone know if >32 bit 
virtual addressing in user processes is (or will be) supported in OS's
for the MIPS R4000 or IBM RS6000 (and, of course in a few years there will
be the SPARC-64, late to the party again ;-) )?  

- Thanks

--
Henry Worth
No, I don't speak for Amdahl... I'm not even sure I speak for myself.
Newsgroups: comp.arch
From: mat@mole-end.matawan.nj.us
Subject: Re: question on computer systems using Alpha ... (cooling)
Summary: A note on dissipation
Organization: :
Date: Wed, 19 Aug 1992 09:46:52 GMT

In article <JAN.92Aug14135936@pallas.neuroinformatik.ruhr-uni-bochum.de>, jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>    Why doesn't anyone (to my knowledge!) use heat pipes, and/or stirling
>    engines for cooling big chips like the alpha?
 
> Look at the design of the GC machines from parsytec. ...

> Actually, cooling shouldn't be much of a problem  ...  For a 16k
> processor GC machine, parsytec expects it to dissipate about 430kW.
> Sounds like a lot? Now look at a 400 horse power truck motor. 400 hp
> is roughly equivalent to 300kW, and the motor dissipates at least
> twice that in heat (efficiemcy is around 30%).  No problem, all you
> need is a nice 60 km/h air flow into your computer room...

But much of the truck's waste heat goes out the exhaust pipe.  I don't
know of any way to pull the heat out of either the bitbucket or the
power line.
-- 
 (This man's opinions are his own.)
 From mole-end				Mark Terribile

 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ