HDTenEightyP/NetNews huggingface dataset:
From: tcmay@netcom.com (Timothy C. May)
Newsgroups: comp.arch
Subject: Re: Computer architects forced to change careers. NOT!
Date: 10 Sep 92 04:51:15 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

zeke@fasttech.uucp (Bohdan Tashchuk) writes:

: Take a look at the history of the Intel 432. Was there ever a computer
: architecture that was a worse disaster?
: 
: And yet, those most directly responsible were (at least initially) allowed an
: almost completely free hand to architect what eventually became the Intel 960.
: The proprietary crud that was left in the 960 after some sanity prevailed
: became the cornerstone of BiiN's non-contribution to the computer industry.
: 
: Probably $100e6 down the drain between the 432 and BiiN. Not even taking into

Ironically, I just posted a few thoughts on the 432 over in
comp.sys.intel just yesterday. You might want to take a look. While
the 8800/432/Gemini/Biib/960 saga is a long and convoluted one (and is
arguably not over yet, as the 960 has gotten a lot of design wins), I
think you're being simplistic in your characterization.

: 
: 	The concept of reward for a job well done and punishment for an abject
: 	failure doesn't exist in many high-technology companies.

Not true. Successes are rewarded, failures aren't. People leave
companies, etc. But companies like Intel---and I was at Intel from
1974 to 1986---don't shitcan engineers just because an effort failed!
Mistakes are made, that's the nature of high tech. 

: 	The 432 should be studied in all engineering schools as an example of
: 	how NOT to design and implement a computer architecture.
: 
: 	When screwups like this happen, a LOT of people get hurt in the
: 	resulting layoffs that endear the company to Wall Street.

I agree the 432 should be studied. I'm surprised that none of the
principals (one of whom later started Intel's iPSC supercomputer
effort, which is doing very well) has written a detailed case history
of what went wrong and what went right.

As for your next comment, are you suggesting that with more careful
planning mistakes can be eliminated? In any case, I don't recall
seeing massive layoffs at Intel at any time.

--Tim

-- 
..........................................................................
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
Newsgroups: comp.arch,comp.parallel
From: bh@nissen.asd.sgi.com (Bent Hagemark)
Subject: Re: sgi/sun shared memory machines question
Apparently-To: comp-parallel@Pa.dec.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Distribution: usa
Date: Fri, 11 Sep 1992 22:38:02 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.

Someone told you very wrong.  All processors peruse the run queue.
Any process runs on any processor unless you explicitly assign
a process to a processor and/or restrict a processor to run only
certain processes.

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

Simultaneous writes from different threads of a parallized process
are not prevented.  (Threads are known to the kernel and each
has its own pid, kernel supported stack, etc).  Harware spinlocks
are avaliable to user-level programs directly or through a couple
of different MP programming interfaces to provide serialization
if that's desired.

Bent




Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Design Cycle Times
Organization: Massachusetts Institute of Technology
Date: Sat, 12 Sep 1992 00:56:55 GMT

In article <1992Sep10.142410.3351@terminator.cc.umich.edu>, sarr@sinshan.citi.umich.edu (Sarr J. Blumson) writes:

|> Computer architects are SUPPOSED to design for process technology that
|> will exist when the architecture is built, not what is available when
|> they start.

Moving away from little technical details, Have there ever been any
microprocessor design efforts based primarilly on design cycle time. I don't
mean efforts which thought about it, but efforts where the architecture was
actually governed by design cycle time considerations. It seems to me that
with speed doubling every year or so, that the ideal effort aught to be
focused around reducing the design time.

It seems to me that the ideal effort would begin by designing a microprocessor
with a lot of room (logistically, not area-wise) for future additions. They
wouldn't even bother laying it out, but would let the computer do that and
immediatelly send it out for a quick fab run. Naturally the die size would
be huge, but its only a first run and you can afford a really low yield. While
that was gone, some people could go to work at hacking the circuits, while
others could start laying out the circuits which appear to be finished.

The first fab run would get back within a couple of weeks, since this design
cycle time consciencous team would have made special arrangements with the
process people for a quick turn around time. Despite this, the team may already
have found a bug with their original design. Not to worry though, before the
last run gets back, send out a new one. Its only $100K. The testing, redesign
and layout would all go on simultaneously. Naturally a really large amount of
effort would be wasted, but you are left with two advantages. 1) Your time to
market is going to be greatly reduced (but they try to do this with your
typical process anyway.) and 2) After you have a selable product, there is no
need to take the design team apart. Why introduce a new chip every three years
with twice the power when you can introduce a new chip every three months with
a 20% increase. Don't even bother making them instruction set compatible. Just
include a program which will instantly transform a program for one chip to
another. This might make copyright protection a little difficult, but that's
not your job. Let William Henry Gates the Nerd worry about that.

Anyway, I'm interested in any architectural efforts where concerns related to
these were the PRIMARY FACTOR governing architectural decisions.

Jason W. Solinsky
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops (LONG)
Date: 9 Sep 92 12:17:01 GMT
Organization: Department of Computer Science, U of Copenhagen

schow@bqneh23.bnr.ca (Stanley T.H. Chow) writes:
>We must handle the cases where a speculative load into a caller-save
>register is not finished by the time the subroutine wants to write
>into that register (I assume the old operation is discarded and the
>new write goes into the pipeline rightaway).

One would hope so. As a reality check, I looked at the 21064 data
sheet (it was handy). As far as I can see, destination conflicts do
stall the pipeline on that chip. Of course, currently, compilers have
no reason to write the same register twice without intervening reads,
so chip designers have no reason to build a preemption mechanism.

>Given that we want to scoreboard the trap-bits, I suggest the simple
>solution is to have a new instruction that saves a single register
>(both content and trap-bit) into two words.

A more radical solution: Put the flags in the memory system! Given a
CPU/memory interface that only supports aligned 64-bit register loads
and stores (not too far from some current RISCs), it would be easy to
add some extra bits to both registers and memory words. This looks
very much like earlier tagged architectures, except that the extra
information is the history of a value instead of its type.

I agree with the point raised by Anton Ertl, that trap bits on source
operands should not unconditionally cause a trap, but should propagate
to the result instead, because this allows the compiler to move a
greater part of an expression. This also solves the subroutine problem
--- register saves do not trap.

As a further elaboration, the single trap bit might be extended into
several ``status'' bits, such as carry and overflow for integer
registers, and inexact, overflow, and so on for floating point. The
compiler could then generate an instruction to branch/trap to an error
handler on exactly those bits that the language semantics indicate.

If zero and negative flags are added, the test instruction turns into
a general conditional branch mechanism. And to please the LISP people,
we could add one or two user defined flag bits.

On super-scalar processors, it should be possible to let the test
instructions issue in parallel with almost anything else, so that they
can be hidden in the latency of arithmetic instructions.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.arch
Subject: Re: Computer architects forced to change careers. NOT!
Date: 11 Sep 92 17:28:49 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <1992Sep10.194733.8001@boole.uucp>, John@boole.uucp (John Ahlstrom) writes:
> ...
> >Take a look at the history of the Intel 432. Was there ever a computer
> >architecture that was a worse disaster?
> 
> 		Was there any "new technology" required "to be invented on
> 		the spot by the" logic designers, circuit designers, process
> 		engineers (the analog to the construction engineers)?
> 
> 		I think the problem was what was seen as the requirements
> 		for the machine.  Particularly very small-grained security
> 		and the religious refusal to use faster mechanisms (e.g. jsr
> 		rather than protected call) even when they existed.  Other
> 		things like bit addressability were so new technology (cheap
> 		ram) would NOT have to be invented on the site by construction
> 		engineers.*


The talks at SOSP and the INTEL Traveling Road Show were exciting.
Then I got manuals, and found that of the many different, redundant,
and contradictory operating system mechanisms that I, at least, knew
about back then, the 432 seemed to implement each and every one.

I've forgotten the details, but I remember running around, waiving the
manuals and challenging people to think of a queueing, scheduling,
messaging, or exclusion mechanism that was not all but completely
implemented in the silicon.  And this was years after the Needham-Lauer
dichotomy was popular.

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.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.arch,comp.lang.misc
From: mch@regent.e-technik.tu-muenchen.dbp.de (Michael Hermann)
Subject: Re: Computer architects forced to change careers. NOT!
Organization: Technical University of Munich, Germany
Date: Thu, 10 Sep 1992 11:25:04 GMT

zeke@fasttech.uucp (Bohdan Tashchuk) writes:

> ...

>	The 432 should be studied in all engineering schools as an example of
>	how NOT to design and implement a computer architecture.

Wouldn't it even better to teach how to foresee the success/failure
of a computer architecture? 

>The concepts behind RISC have helped bring some sanity back into the field.

At the time RISC was (re)introduced, CISC was quite succesful. So if 
I had to expect severe punishment for an invention with uncertain
future I would probably stick with  the mainstream. And if everybody
thought that way, then there were no RISC.

But to get to something that is of more interest for me now:

Should I stick with "normal", binary computers or should I go for
fuzzy logic or should I go for neuronal nets so that in 2020 I will
be no example for students "how NOT to do that obvious blunder"?

As you may have guessed by now, I didn't recognize the 432 as a
bad design when it was developed. I didn't recognize that the 
Series 32000 was doomed for failure. I didn't recognize that the
80386 would be successful. I was late in recognizing that RISC would
have a major impact on computer architecture. 
And I still liked each of those developements (and more than those)
for some aspect beeing new and showing me alternative approaches to
get a job done. I'm glad that the companies didn't threat their
developers for having and realizing ideas with uncertain success.

Michael Hermann


Xref: sparky comp.arch:9425 comp.lang.misc:3080
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 15 Sep 92 13:40:55 GMT
Organization: Purdue University Statistics Department

In article <1992Sep15.022940.12771@ksmith.uucp> keith@ksmith.uucp (Keith Smith) writes:
>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. 

It would not make me at all unhappy if 2Ghz hardware, at any level were
produced.  It has long been theoretically possible to get at least a 
switching speed of 1Thz (1000 Ghz), and at least 10 years ago, there
was considerable talk of a superconducting computer using Josephson
diodes with a switching time of at least 200 Ghz.  Even more than 25 years
ago, there was talk of a 3-dimensional 1-inch cube with 10^11 components.
Vaporware is easy.

And miniaturization can only go so far; it takes enough molecules to have
a bi-stable switchable configuration.  We have not reached these limits yet,
but they are in sight.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: trapping speculative ops (LONG)
Organization: Xenix Support, FICC
Date: Thu, 10 Sep 1992 14:45:11 GMT

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)?
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
From: wlin@thai.csee.usf.edu (Wei Lin)
Newsgroups: comp.arch
Subject: Re: Multi threaded CPUs
Date: 4 Sep 92 21:08:39 GMT
Reply-To: wlin@thai.csee.usf.edu (Wei Lin)
Organization: University of South Florida, Department of Computer Science and Engineering


Running several instruction streams simultaneously has been mentioned for a 
long time. There are two kinds of supporting hardware architecture towards 
that. One is using multiple processors; the other is using shared pipeline(s).
Shared pipeline has another intutive apprealing is to improve the pipeline 
throughtput. However, there are some fundamental problems left in the early 
researches. 

One problem is how to control the multithreading. The earlier multithread 
machine does not have any mechanism to do that. Therefore multithreading is up
to operating system (that probablly is the only way can go.). In this case,
the overhead problem will occur again as in the other parallel architectures.
I feel a problem in the early research is lack of attention to the computation
model. That makes a difference between the current multithreaded research and
early work.

Second fundamental problem is how to support the multithreaded running
environments. Some approaches, like used in HEP, involved a lot of overhead.

The recently multithreaded architecture is influenced by dataflow computing.
As far as I know of, Peter Maurer is the first person who presented a solution
to the thread handling based on dataflow computational model. His SAM
architecture uses two special instructions to map the parallel computation
into multithreads, and no operating system overhead is involved. SAM is based
on a shared pipeline. In regarding to the multithread environment, SAM 
included a unique approach. On the other hand, MIT also did a lot of
work in this
field. Their PRISC presented an similar solution to the first problem.
ACM
Computer Architecture Symposium has a subtopic on multithreaded
architecture
from last year. Quite a few those papers are influenced by this
solution.
Perhaps, Japanese EM-1 (I am not sure whether this machine name is wrong
or
not) probablly can be refer to PRSIC like machine (maybe their work is
earlier
than PRISC. I am not sure at this point). But I do not think EM-1
architecture
is optimal. 

I have a general impression that there is a lot of problems in multithreaded
architecture that have not been touched yet. The current researches have
not got
inside of it very far. However, some of our undergoing research show 
multithreaded architecture has a great potential. 

Wei Lin
From: kers@hplb.hpl.hp.com (Chris Dollin)
Date: Mon, 7 Sep 1992 07:44:15 GMT
Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu

In article ... hallam@zeus02.desy.de (Phill Hallam-Baker) writes:

   RISC machines are fast bercause they abolish support for assembly code. On a
   RISC machine instructions are provided for the sole benefit of compilers.

Funny, that, because the RISC machine I have at home has an operating system
written primarily in assembler.

[Perhaps we Acornites could say; on the ARM, machine instructions are
provided for -- and by -- the benefit of Roger Wilson!]
--

Regards, Kers.              | ``Remember Thor Five!'' (Earthman, Come Home)
From: tsaoj@cs.tamu.edu (Jungfu Tsao)
Newsgroups: comp.arch
Subject: Need references for RTU
Date: 15 Sep 1992 18:19:29 GMT
Organization: Computer Science Department, Texas A&M University

I am posting this for a friend of mine who has no access to the net facility:

     Can anyone give some pointers to where to find introductory articles 
     regarding RTU (Remote Terminal Unit)?

I was told the RTU is usually used in Modem connection or for communication
use. Well, it may be wrong. 

Please respond through e-mail because I'm not a regular reader to this
newsgroup. Thanks in advance!
From: zilla@nj.nec.com (John Lewis)
Newsgroups: comp.arch,comp.parallel
Subject: sgi/sun shared memory machines question
Date: 11 Sep 92 05:28:09 GMT
Distribution: usa
Organization: C&C Research Labs, NEC USA, Princeton, N.J.
Apparently-To: uunet!comp-parallel

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?
Newsgroups: comp.arch
From: eburk@sfsuvax1.sfsu.edu (Eli Burk)
Subject: sources of info about arch. (repost)
Originator: eburk@sfsuvax1.sfsu.edu
Organization: San Francisco State University
Date: Sun, 6 Sep 1992 22:08:56 GMT

I'm looking for what the title suggests. Due to the sorry
state of funding for sfsu it is difficult to find "good" 
books on the subject. I don't exaggerate. Books are 
unshelved for months and there are no inter-library loans.
Ftp'able material (ie - free) would be best, but I doubt
it exists. I'd like to learn about what is current (eg
486), but I realize that what is best is not always what
is new.

** email please **



-- 
..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
From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
Newsgroups: comp.arch
Subject: Re: Intel CAD coprocessor?
Date: 10 Sep 1992 17:24:36 GMT
Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
Distribution: world
NNTP-Posting-Host: irav1.ira.uka.de
X-News-Reader: VMS NEWS 1.23

In <1992Sep9.192242.22615@eng.ufl.edu> jon@alpha.ee.ufl.edu writes:

> The Intel RapidCAD processor chipset is a replacement for the 386DX/387DX chipset.
> The DX is the operative word here: DX's (from Intel, anyway) are PGA devices 
> which are usually socketed. 
> 
> I haven't used one yet so I can't make any comments on Intel's claimed performance
> gains. If you have a 386 machine it is an alternative to upgrading to a 486, 
> however, these days, upgrading to the 486 is not a whole lot more expensive 
> (if you can migrate your memory to the new machine, that is). The RapidCAD 
> is not as fast as the 486.
> 
> Hope this helps...
>
I actually own one of those beasties. The RapidCAD is basically a 486DX without
the internal cache and with a 386 pinout. It is divided into two chips. The
first one, RapidCAD-1 contains the complete CPU+FPU and goes into the 386
socket. The second one, RapidCAD-2, is just a small PLA that generates the
Ferr signal that normally goes from a coprocessor thru the motherboard logic
(chip set) to the CPU. Floating point performance is about 70-80% of a 486DX
at the same clock speed, if you have a cache installed (I have 128 kB CPU
cache). Compared with a 386/387 combination, RapidCAD is about twice as fast
as the fastest 387 'clones'. Integer performance is about 5-35% higher (15%
average) than with a 386. The slow memory interface of the 386 and the absence
of an internal cache is a bottleneck that prevents the integer performance to
be higher. As pointed out before, the RapidCAD is usually not cost effective
compared to a 486 motherboard. However, some people may be unable to upgrade
to 486 board for various reasons, and for these RapidCAD provides the highest
performance you can get with a 386 motherboard. It also eliminates the need
for a Weitek coprocessor, as the RapidCAD provides the same level of
performance, but is supported by much more programs, since to software it looks
just like a 386/387 combination.

Norbert 
-------------------------------------------------------------------------------
Norbert Juffa       email: S_JUFFA@IRAVCl.IRA.UKA.DE        Live and let live!