HDTenEightyP/NetNews huggingface dataset:
From: hrubin@mentor.cc.purdue.edu (Rubin Herman)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 14 Sep 92 01:10:56 GMT
Organization: Purdue University Statistics Department

In article <9225808.14389@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

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

>Well, that may not necessarily be the case.
>If those few man-years of microcoding slavery mean that your product takes
>six months longer to get to the market then it may not be worth the effort.
>As the technology improves processing power is almost doubling every year,
>so in those six months, your competition may well introduce a machine that
>is 30-40% faster, so your +25% is now looking more like -5% or -10% (to
>pluck a few figures out of the air).

This doubling is for the minis and micros, which are finding it possible to
come closer to the speeds of fast mainframes.  The speed improvement from 
the CRAY 1 to their latest machines is more in using multiple processors,
but this will eventually run into physical limits.  The switching time has
only tripled in a dozen years; there may be breakthroughs, but another 20
doublings may very well reach basic physical limits in size, speed, and
number of processors.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: tcmay@netcom.com (Timothy C. May)
Subject: Re: Multi uP P5 systems
Date: Mon, 14 Sep 92 17:06:27 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

davidsen@ariel.crd.GE.COM (william E Davidsen) writes:
: | On a tour of a major MB manufacturing plant my friend showed me what they
: | were working on in the design lab.  It was an EISA board with sockets for
: | four P5 chips!  He said the P5 has features that make it very easy to
: | design multi-CPU boards.  
: 
:   I hate to say this, but what is anyone going to plug into the sockets?
: 
:   Rumor of the day: Intel has dropped the P5 design as unmanufacturable
: and is redesigning the chip in 4000 angstrom biCMOS to improve yeild.
: They will never sell commercial quantities of the P5 as it has been
: shown.
: 
:   The Intel presentation at FORUM seemed to hint at this, and I've heard
: other things, would someone from Intel care to deny this? 

I think a more plausible reason for the delay was the sudden
disappearance of AMD as a short-term threat to the 486 pricing
structure. This gives Intel several additional months, at least, to
sell 486s at a higher price than would be likely if the P5/586 was
shipping. (Cyrix may be a more realistic threat, but their full-blown
486 clone is not yet announced, is it? I'm unsure about their situation.)

And the several extra months can always be used to ramp up volumes,
further test and tweak the design ("tweak" as in minor steppings,
_not_ major redesigns). Without a lot of market pressure to announce
(and what some users _want_ is not the same thing as real market
pressure), why should Intel announce?

The 3.5 million transistor P5 is, from reports, built on the same
process as the 3 million transistor 860XP, so presumably Intel has had
an estimate of expected yields for at least a year.

In any case, the announcement is still reported to be coming soon, so
we'll all know the truth soon enough. (This also goes against the
"complete redesign" rumor, as such a redesign would mean a _much_
longer delay. Finally, these things have a way of reaching the stock
market very quickly, to wit, if the P5 was in real trouble, I doubt
Intel stock would be near its all time high, at $65+)

-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^756839 | RSA MailSafe Public Key: by arrangement


Xref: sparky comp.arch:9424 sci.math:11475 comp.lang.misc:3079 comp.lang.fortran:3559 comp.edu:1662
From: david@donald.concordia.ca (David Gaudine)
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 15 Sep 92 13:17:30 GMT
Followup-To: comp.arch
Organization: ORGANIZATION!! HERE? You must be kidding

In article <1992Sep9.215657.18399@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:

>[All this presupposes that long is twice as long as int. As you noted,
>that is a very non-portable assumption in C --- it's not even certain,
>I think, that there are integers of more than one size. For some uses
>it would be nice if thing were different ... but they aren't.]

The only guarantee is:  short <= int <= long

On a PC (most compilers) short = int = 2, long = 4
On most UNIX workstations (I think) short = 2, int = long = 4
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: Re : Single Transistor Clock - ALPHA
Date: 11 Sep 92 16:44:06 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Sep8.201415.8422@cs.yale.edu> ewing-martin@yale.edu writes:
>
>In article <1992Sep8.091816.22659@rkna50.riken.go.jp>, wong@rkna50.riken.go.jp (Wong Weng Fai) writes:
>...
>|> 
>|> 	1. I guess whether its a single transistor or not depends on how you
>|> count. But is this huge "thang" responsible for the infamous "oven-toaster"
>|> effect of the 21064 ? Will pumping the clock speed higher melt the chip ;-) ?
>|> 
>
>In CMOS and other high-impedance technologies, the transistors are driving
>mainly capacitive loads.  Each change of state requires Q=1/2 CV**2
>increment of energy, and the current and power drain scale pretty much
>linearly with clock rate.   (Conversely the drain goes nearly to zero at
>low clock rate.)
>
>The melting point of Si is pretty high, but the thought of a CPU glowing
>cherry-red appeals to me.  (The days of 304 TLs and other big glass RF power
>tubes are gone forever. :-)

I'd have thought the possibility of increasing the diffusion speed of
the dopants to something that would kill the chip quickly, or of
buckling and cracking the chip, would be much higher...

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.
Newsgroups: comp.arch
From: erb@netcom.com (Elizabeth R. Brown)
Subject: Multi uP P5 systems
Date: Fri, 11 Sep 92 21:15:29 GMT
Organization: Netcom - Online Communication Services (408 241-9760 guest)


Well, I'm back.  Asia was great.  Prepair for hot rumor mongering.

On a tour of a major MB manufacturing plant my friend showed me what they
were working on in the design lab.  It was an EISA board with sockets for
four P5 chips!  He said the P5 has features that make it very easy to
design multi-CPU boards.  I asked him what software was able to take
advantage of this type of system, but he said he couldn't tell me, but
he said it was *not* UNIX.  He also said they are working on an 8-CPU design.

Talk about an up-gradable mother board!  Buy it with one P5, then add
more as the budget allows.

My question is still: What software will be able to take advantage of
this?  A version of Mach?  Solaris?  OS/2?  Has anybody heard anything
about this?

---->erb<----

Newsgroups: comp.arch,comp.lang.misc
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Keith's Computer, Hope Mills, NC
Date: Tue, 15 Sep 92 02:29:40 GMT

In article <BuJnA9.JCA@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Rubin Herman) writes:
>In article <9225808.14389@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:

[Microcoding Effort vx. CPU speed doubling]

>This doubling is for the minis and micros, which are finding it possible to
>come closer to the speeds of fast mainframes.  The speed improvement from 
>the CRAY 1 to their latest machines is more in using multiple processors,
>but this will eventually run into physical limits.  The switching time has
>only tripled in a dozen years; there may be breakthroughs, but another 20
>doublings may very well reach basic physical limits in size, speed, and
>number of processors.

Oh, Oh, Now you've done it.  You told some hot shot engineer He can't
make the machine run faster.  Of course they'll prove you wrong if they
throw enough money at it.  It wouldn't suprise me in the least to be
buying 2 Ghz CPU's in 5 years.  The days of anything but
"microprocessors" are gone.  Takes too long for the 'lectric to come off
the chip.  All future CPU's will be fabricated on the same silicon. 
-- 
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 ...
Newsgroups: comp.arch
From: gillies@m.cs.uiuc.edu (Don Gillies)
Subject: Re: Computer architects forced to change careers. NOT!
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Sat, 12 Sep 1992 03:19:44 GMT

vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>Whatever else it's faults or virtues, the 432 demonstrated that the
>kitchen sink design school doesn't work, that anybody can add features
>to anything, but that the real work and value is in leaving the
>right things out.

Yes, when you think about it, the VAX went one step to far in
complexity, and the 432 went about 5-6 steps too far in complexity
(Bob Colwell, no flames, please).  Intel has made some big goofs
(trying to make the '286 run multics, trying to do the '432).  If
anything, these big goofs have galvanized the industry to run in the
other direction.

The money was well-spent, if only because it taught the whole rest of
the industry not to make similar KICE (keep it complex, einstein)
design decisions.

Don Gillies - gillies@cs.uiuc.edu - University of Illinois at Urbana-Champaign


-- 



Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Are 64 Int or FP registers useful?
Organization: Intel Corp., Hillsboro, Oregon
Date: Thu, 10 Sep 1992 03:34:51 GMT

    Can somebody provide me with comments or references to pros and
    cons of having a large register set on-chip. Lets say 64 Int and
    64 FP registers be it 32-bit or 64-bit.

THere is a fairly recent paper by some fellows at HP, entitled
something like "Graphics Extensions to the HP Precision Architecture",
where they described increasing the number of single precision FP
registers to 58 by placing two SP numbers in one DP register.  They
said that some 3D graphics inner loops have more than enough live
variables to benefit.

I believe that it was a COMPCON paper. Sorry, no more accurate
reference: if you saw the pile of papers "to be filed" in my office,
you'd understand.


--

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: brent@uwovax.uwo.ca (Brent Sterner)
Subject: Dick Sites: I cannot email to you (Was:alpha/vector)
Organization: University of Western Ont, London
Date: Thu, 10 Sep 1992 13:35:26 GMT

In article <1992Sep4.120503.1@uwovax.uwo.ca>, brent@uwovax.uwo.ca (Brent Sterner) writes:
>    Not sure why this crossed my mind, but I'm curious about how well
> the alpha architecture might support vector processing.  I'm familiar

   I received email from Dick Sites on this issue.  I tried to reply to
   him at the address provided in his email to me.  The following was
   attached to the bounced message:

]   ----- Transcript of session follows -----
]421 sousa.ltn.dec.com..ether... Deferred: Host is unreachable
]
]   ----- Unsent message follows -----
]From: "Brent Sterner (UWO CCS)" <brent@uwovax.uwo.ca>
]To: sites@sousa.ltn.dec.com (Dick Sites)
]Date: Fri, 4 Sep 92 15:52:30 EDT
]Subject: Re: alpha and vector processing...
]In-Reply-To: <9209041929.AA01417@sousa.ltn.dec.com> of Fri, 4 Sep 92 15:29:11
]    -0400
]Message-Id: <0715621950@uwovax.uwo.ca>
]
   Dick, where ever you are, could you emeil to me again, and include
   a return address where I can hit you?  Thanks,  b.
--
Brent Sterner                       Manager, Academic Technical Support
Fast:       <BRENT@uwo.ca>          <129.100.2.13>
Telephone:  (519)661-2151 x 6036    Fax:   (519)661-3486
Slow:  Computing & Communications Services, Natural Sciences Building
       The University of Western Ontario, London, Ontario, Canada  N6A 5B7
Newsgroups: comp.arch,comp.parallel
From: dre@ember.Eng.Sun.COM (David R. Emberson)
Subject: Re: sgi/sun shared memory machines question
Followup-To: comp.arch,comp.parallel
Summary: Sun MPs can run parallel codes.
Organization: Sun Microsystems Inc., Mountain View, CA, USA
Distribution: usa
Date: 11 Sep 1992 21:25:34 GMT

In article <1992Sep11.121830.17069@hubcap.clemson.edu>, zilla@nj.nec.com (John Lewis) writes:
> Someone told me that the SGI multiprocessor machines cannot run
> different unix processes on different processors; they can only
> run a single (but possibly parallelized) process at a given time.
> The reason was said to be that the machines do not implement
> any mechanism for simultaneous writes.
> 
> Is this correct?  If so, how are simultaneous writes from
> different threads of a parallelized process prevented?
> 
> Is the new sun multiprocessor (4/690?) similar?

This sounds bogus to me.  All Sun MP machines (4/6xx, SS10, and futures) can
run different processes simultaneously and also run parallelized codes.  I
think your friend is confusing "simultaneous writes" with synchronization.
I believe the SGI machines do something funky to implement barriers (like
put them in a special portion of memory with hardware support) because the
R3000 has no synchronization primitives.  This is not a problem on the Suns
since Sparc has the hooks in the architecture.  R4000 fixes this omission.

			Dave Emberson
			dre@Eng.Sun.COM

Newsgroups: comp.arch
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Subject: Re: Computer architects forced to change careers. NOT!
Organization: University of Michigan, CITI
Date: Thu, 10 Sep 1992 14:24:10 GMT

In article <1992Sep9.213319.7894@fasttech.uucp> zeke@fasttech.uucp (Bohdan Tashchuk) writes:
>In <1992Sep9.061933.28304@news.eng.convex.com> culter@convex.com (Brad Culter) writes:
>
>>	I.M. Pei is a world-renowned architect who also has
>>	a reputation for designing buildings that nearly can't
>>	be built, often requiring new technology to be invented
>>	on the spot by the construction engineers. I think if
>>	a computer architect did this, she or he would be forced
>>	to change careers.
>
>Not that I can tell.
>
>	The concept of reward for a job well done and punishment for an abject
>	failure doesn't exist in many high-technology companies.
>
Computer architects are SUPPOSED to design for process technology that
will exist when the architecture is built, not what is available when
they start.

I assume you would prefer an environment in which architects design
things that they know can be built with technology that is on the
shelf when they start.  The way American car companies in the 1950s
and 60s did.  

Go take a look at some of Pei's buildings; they do get built and are
some of the architectural triumphs of the late 20th century,
(Sarr Blumson)
Newsgroups: comp.arch,comp.lang.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: "Training" of programmers
Organization: Xenix Support, FICC
Date: Tue, 8 Sep 1992 18:40:11 GMT

In article <1992Sep4.151001.9886@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
> This problem is pervasive.  Each generation sees a new and more monstrous
> bloat in the size and cycle consumption of what I still think of as basic
> system software - device drivers, editors, compilers, linkers.  And the
> reason the programmers are so profligate of resources is that they have
> never been taught that resources matter - they are told that, in computer
> science, "everything is virtual", and all resources are infinite and free.

Agreed. Because they never have to deal with an environment where this isn't
true.

> There is no technical perception of the machine as a real engine, with
> finite capability, and no aesthetic perception that economy of means is
> one of the cardinal qualities of good engineering.

I think that this is only part of the problem. The other part is that they
are never required to make do with less than the best. How many people
graduated this year have ever used a machine that enforced a significant
constraint on resource use? Even on non-virtual systems, buying more memory
is considered the fix of choice. I'm considered a bit of a fossil because
none of my personal computers has more than 4M, and that only because I'm
running a multiuser BBS under UNIX. And that's a relatively old, small,
version of UNIX... it's smaller than OS/2!
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
From: peter@ferranti.com (peter da silva)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Xenix Support, FICC
Date: Fri, 11 Sep 1992 17:23:35 GMT

In article <1992Sep9.215657.18399@odin.diku.dk> thorinn@diku.dk (Lars Henrik Mathiesen) writes:
> >> The use of these features is portable.

> >Pretty much.

> Peter, didn't you follow comp.lang.c when this was last hashed out?

No, I quit following comp.flame.c some time ago.

> In C, multiplication of two integer values gives a result of type
> integer, and many compilers will be oh-so-careful and produce a
> ``correct'' integer-size result, which is then carefully sign-extended
> to a long.

Then bitch to the vendors. That may be technically legal but it's evil
and rude. There's a lot of that going around, but it's still evil and
rude.
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
Xref: sparky comp.arch:9359 sci.math:11264 comp.lang.misc:3024 comp.lang.fortran:3518 comp.edu:1624
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 9 Sep 92 21:56:57 GMT
Organization: Department of Computer Science, U of Copenhagen

>hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>> There has been discussion on some of these groups about the lack of nxn -> 2n
>> multiplication, where n is the integer word size;
>> But I know of no HLL which allows writing this.

peter@ferranti.com (peter da silva) writes:
>C:
>	int a, b;
>	long c;

>	c = a * b;

>I've used [this] on the PDP-11, and gotten the expected 2x2->4
>multiply in the generated code.

>> The use of these features is portable.

>Pretty much.

Peter, didn't you follow comp.lang.c when this was last hashed out?
In C, multiplication of two integer values gives a result of type
integer, and many compilers will be oh-so-careful and produce a
``correct'' integer-size result, which is then carefully sign-extended
to a long.

(Note that the 2x2->4 multiply will give the correct result if it fits
in an int, and since an integer overflow causes undefined behaviour, a
Standard C implementation is _allowed_ to use the 2x2->4 to implement
the code above. However, I think that many implementors will choose to
define that overflow produces the low-order bits of true result, and
so they will have use 2x2->2 and sign extend.)

On the other hand,
	c = (long)a * b;
is guaranteed to give the same result as 2x2->4. Complain to your
vendor if such an instruction exists and the C ``optimizer'' does not
use it.

[All this presupposes that long is twice as long as int. As you noted,
that is a very non-portable assumption in C --- it's not even certain,
I think, that there are integers of more than one size. For some uses
it would be nice if thing were different ... but they aren't.]

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Xref: sparky comp.arch:9392 comp.lang.misc:3055
From: eburk@sfsuvax1.sfsu.edu (Eli Burk)
Subject: sources of info about arch.
Originator: eburk@sfsuvax1.sfsu.edu
Organization: San Francisco State University
Date: Sun, 6 Sep 1992 21:44:21 GMT


-- 
..out in the street, with your cheap fur on, or maybe your plastic raincoat
and your plastic shoes, they look good too, standing in the snow you're young-
er than you look, {fall in love with me} 2X, how i wish you would...[Iggy Pop]
eburk@futon.sfsu.edu -or- eburk@sutro.sfsu.edu -or- eburk@sfsuvax1.sfsu.edu
Newsgroups: comp.arch
From: schow@bqneh23.bnr.ca (Stanley T.H. Chow)
Subject: Re: trapping speculative ops (LONG)
Organization: Bell Northern Research Ltd, Ottawa
Date: Fri, 11 Sep 1992 14:37:05 GMT

In article <1992Sep11.074838.26488@email.tuwien.ac.at> anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
>In article <id.G_3T.SH1@ferranti.com>, peter@ferranti.com (peter da silva) writes:
>|> Isn't this (extra bits for exceptions) basically the whole point of NaNs and
>|> Infinities in IEEE FP? Is the IEEE method inadequate, or would it be reasonable
>|> to simply ignore FP interrupts and check for NaNs (assuming integer arithmetic
>|> has low enough latency it isn't a problem)?

Yes, the ideas are basically the same. IEEE method is inadequate for
integer - which value would you like to use for NaI? :-) The IEEE stuff
is wider in scope in that infinities are propagated, etc. while the
trap bits are more narrowly focus.

>On a superscalar machine even a one-cycle latency is a problem.
>However, integer arithmetic causes no exceptions (in C), so what's the
>real problem? Loads.

Surely you jest! C is not the whole world. Many languages and 
applications want to see interger overflow/underflow. Come to think
of it, your paper mentions this (but I havn't had time to read it yet).
Loads are certainly a problem.


--
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.
From: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: Indexing in microprocessors
Date: 7 Sep 92 10:15:34 GMT
Organization: Advanced RISC Machines Ltd

richard@aiai.ed.ac.uk (Richard Tobin) writes:

>Fast memory for the registers was an optional extra on the PDP10, so
>it might not do you much good.

Last time this thread went around, it was mentioned that although the
feature was optional, it wasn't clear that ANY systems were bought without it.

Note this was true for the KA series only; the KL series used real registers-
but it may be true that code in the registers ran SLOWER than out of the cache,
since the cache was designed to be the usual case.-- 

----------------
Allen J. Baum		Apple Computer		baum@apple.com, abaum@armltd.co.uk
Newsgroups: comp.arch