HDTenEightyP/NetNews huggingface dataset:
From: lbarroso@pollux.usc.edu (Luiz Barroso)
Newsgroups: comp.arch
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Date: 11 Dec 1992 13:49:35 -0800
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: pollux.usc.edu
Keywords: mp shared-memory parallel multiprocessor risc smp

David Chase - chased@rbbb.Eng.Sun.com - mentions the abstract of a
recent seminar by an IBM person which includes:

>		Data Merging for Shared-Memory Multiprocessors
> <stuff deleted>
>shared data between synchronization points.  Our delayed consistency
                                                  ******* ***********
>mechanism allows arbitrary use of data blocks between synchronizations.

That "delayed consistency" looks very familiar to me. 
You might want to take a look at the following paper published in 1991:

Michel Dubois et al., "Delayed Consistency and Its Effects on the Miss
Rate of Parallel Programs", SUPERCOMPUTING'91, ACM/IEEE, Albuquerque.

It describes how consistency can be delayed, the hardware support necesssary,
and shows how it can reduce the miss rate of parallel programs. 

--Luiz Barroso
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Heat Output of New uPs
Date: 11 Dec 92 16:05:00 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 9 Dec 92 20:11:11 GMT, YOUNG@tattoo.cs.widener.edu (Rob Young) said:

YOUNG> In <1992Dec9.155802.29342@sequent.com> thall@sequent.com writes:

thall> Any ideas for (safely) implementing a laptop based on one of these
thall> chips?  If I remember correctly, I think 10-20 watts was about the
thall> heat output of the Kenner Easy-Bake Oven.  I can't picture putting one
thall> of those on my lap for a 2-3 hour plane trip.

As to hot things to keep on one's lap, I'd have some other things in
mind myself. :-)

YOUNG> Good point.  You think 20 watt Alphas would cause problems.  What
YOUNG> about a 60 watt Alpha: [ ... ] IBM has the 601, DEC has a low
YOUNG> wattage Alpha.  But these aren't 150+ Specmark chips.  Heat
YOUNG> increases with clock rate. ..  Where is this leading to???

Well, for the travelling manager that needs to be always prim and up
to date, a combined hairdrier/notebook appliance. Concentrate on your
spreadsheets in the calm moments just after a relaxing bath... :-)

For the up and coming English manager, a combined kettle and
wordprocessor. Write up that presentation while your water is getting
ready for your favourite tea!
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
From: toon@moene.indiv.nluug.nl (Toon Moene)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 12 Dec 92 14:47:30 GMT
Organization: Moene Computational Physics, Amsterdam, The Netherlands

In article <endecotp.723992157@cs.man.ac.uk> endecotp@cs.man.ac.uk (Phil  
Endecott) writes:
> Can anyone think of a use for the branch if even and branch if odd
> instructions on the Alpha?  I'm completely baffled.
> 
> --Phil.

Hmmmm, you've never been exposed to VMS, I'd say :-)
The correct wording, however, is: branch on low bit clear/set :-) :-) :-)
--
Toon Moene (toon@moene.indiv.nluug.nl)
Kantershof 269, 1104 GN  Amsterdam, The Netherlands
Tel.: + 31 20 6982029; Fax: + 31 20 6003411
No Disclaimers; a NeXT at home protects against this occupational hazard.
Organization: Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Date: Tue, 15 Dec 1992 06:34:18 -0500 
From: Sean McLinden <sean+@andrew.cmu.edu>
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
	<1992Nov29.201544.1@vxcrna.cern.ch>

>I don't reagard it a "real" UNIX, then again I wouldn't buy a "real" UNIX,
>1970s software technology is not something I would want to buy today.

[And here I was beginning to like you because you commented, correctly, that
BSD was still in demand. Oh well.]

Statements like the above excerpt I would expect from Bill Gates but not from
a real programmer. To say that you wouldn't use Unix because it is 1970s
technology is a bit like saying you wouldn't speak French (or English or...)
because it is centuries old. What we call Unix, today, is hardly anything
like what came out of AT&T Bell Labs in the early days and is even a long
way from early System V and BSD 4.2 of a few years (well, maybe more than
a few) ago. Like most modern languages, Unix has survived because it is
dynamic and accommodating and while it is hardly the perfect operating
system (though most people's complaints, including your references to 'ls'
have more to do with the command shells than the kernel architecture) it is
not the dinosaur that the NT zealots makes it out to be. 

>Apollo in my view were the only UNIX vendor to realize that they had to put
>work into the basic operating system. They had ACLs, shared libraries and many
>other essential features five years ago.

They are essential for some tasks and totally unnecessary for others. It
depends upon the environment in which you operate. Unix didn't, originally,
have ACLs because the people for whom it was implemented didn't need it.
They had a different concept of a programming environment than you do.

>What I find disgusting about UNIX is that it has *never* grown any operating
>system extensions of its own, all the creative work is derrived from VMS,
>Multics and the operating systems it killed.

So? If originality was important Microsoft would still be a niche vendor.
First of all, your statement was inaccurate and inflammatory. More to the
point, it is meaningless. I mean, who cares. How many people have ported
VMS to their boxes? How many open systems are being developed in Multics?
What is the point?

Unix (whatever that is) is not just an operating system, it is has been the
seed of a marvelous technosocial experiment which is still being carried out.
It isn't fair to say that Unix isn't everything...it wasn't intended to be.
But I doubt that the world would have evolved on a production basis the 
concept of horizontal integration of systems without something like Unix to
make it possible.

Sean McLinden
From: rob@rjck.UUCP (Robert J.C. Kyanko)
Newsgroups: comp.arch
Subject: Re: Which would give better floating point performance?
Distribution: world
Date: Thu, 17 Dec 92 01:10:29 GMT
Organization: RJK Enterprises

scott@ryptyde.cts.com writes in article <1992Dec16.063018.6239@ryptyde.cts.com>:
> 
> Hi all,
> 
> 	I'm trying to figure out which one of these configurations would
> yield the best floating point performance.  
> 
> 
> An i486DX/33 + Weitek 4167, or i486DX2/66 with no additional processor.
> 
> Any experiences, references, and opinions are welcome.

IMHO, it depends upon what you're doing.  The Weitek is only going to help you
with math intensive applications that also take advantage of this chip.  I
think the 486DX2/66 will give you almost equal performance in a real
application anyway; plus you get double the integer performance with this part.
I'd go with the 486DX2/66.  But other opinions will vary based upon their
needs.
--
I am not responsible for anything I do or say -- I'm just an opinion.
             Robert J.C. Kyanko (rob@rjck.UUCP)
Newsgroups: comp.arch
From: fineberg@wilbur.nas.nasa.gov (Samuel A. Fineberg)
Subject: Re: ILIAC and old parallel machines
Organization: CSC, NASA Ames Research Center, NAS Division
Date: Fri, 11 Dec 92 23:15:00 GMT
Reply-To: fineberg@nas.nasa.gov

In article <mcdonald.604@aries.scs.uiuc.edu>, mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
|> In article <mcdonald.603@aries.scs.uiuc.edu> mcdonald@aries.scs.uiuc.edu (J. D. McDonald) writes:
|> 
|> 
|> >Do you mean the Illiac IV? Presumably, yes.
|> 
|> >It was an odd multiprocessor beastie.
|> 
|> Sorry folks, for all those horrible typos. I was stupid to do it while
|> needing to run to a meeting. 
|> 
|> It was a wonderfully quaint machine and I loved it a lot. Quaint,
|> and baroque.
|> 
|> Doug McDonald
They have some peices of it on display at the CCF here.  The funny part is that
I heard they had to break it apart with sledge hammers to get it out of the
door when they were dismantleing it.

Sam
Newsgroups: comp.arch,comp.misc
From: scott@ryptyde.cts.com (Scott McClure)
Subject: Which would give better floating point performance?
Organization: Ryptyde TimeSharing, San Diego, CA
Date: Wed, 16 Dec 1992 06:30:18 GMT
Summary: 486DX/33 + Weitek 4167 faster than 486DX2/66?
Keywords: Weitek, Intel, 486, 4167

Hi all,

	I'm trying to figure out which one of these configurations would
yield the best floating point performance.  


An i486DX/33 + Weitek 4167, or i486DX2/66 with no additional processor.

Any experiences, references, and opinions are welcome.

Thanks in advance,

Scott
 
-- 
INTERNET:  scott@ryptyde.cts.com                     | "Nuke the homeless gay
ARPANET:   ryptyde!scott@nosc.mil                    |  baby whales for Jesus!"
UUCP:      {crash, nosc}!ryptyde!scott               |    - bumper sticker
From: weaver@jetsun.weitek.COM (Michael Gordon Weaver)
Newsgroups: comp.arch
Subject: Re: Logic Minimization Algorithms
Date: 16 Dec 92 17:58:05 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <1992Dec15.024904.22554@amd.com> roberts@angelo.amd.com (Dave Roberts) writes:
>
>I couldn't think of a more appropriate news group to post this in, so
>here goze:
>
>What sort of algorithms are typically used to minimize logic equations
>specified in high level hardware description languages (PAL software,
>Verilog, etc.)?
>
>I've read and understand Quine-McClusky, and doodled around with
>implementing my own versions.  It seems to work well except for the
>final step: choosing a set of prime implicants from the set that you
>just produced (by reductions of the form x * y + x * ~y = x, for those
>of you who don't remember.  Prime implicants are those product terms
>that can't be reduced any further by the application of the above
>identity).
>
Quine-McClusky is not used in CAD because you cannot handle logic
equations of the size that people want to do. Current methods 
are called algebraic, implying that the equations are never
fully expanded. 

Automatic translation from logic equations to gates has become popular
in the last few year and you will find a number of papers on the
subject in conference proceedings. Try Design Automation Conference
(DAC) proceedings, or International Conference on Computer Aided
Design (ICCAD) proceedings. Keywords to look for are Logic Synthesis,
Logic Minimization.


Michael Weaver.
From: john@gu.uwa.edu.au (John West)
Newsgroups: comp.arch
Subject: Re: specks for the intel P5
Date: 20 Dec 1992 13:02:06 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: mackerel.gu.uwa.edu.au

awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:

>This is not quite true.  Intel has presented limited P5 details at Hot-Chips
>and at the Microprocessor Forum.  Pentium will be a Superscalar
>implementation of the X86 instruction set.  It is a single integrated CPU -
>not a RISC chip with a 386 tagged on.  It will run 368 and 486 user code as
>is.

Someone posted some numbers here a while back. A 33MHz external/66MHz internal
part was claimed to run at 30-40 MIPS. Meaningless enough for you?
Sounds about right. Superscalar, and they still can't get 1 instruction/cycle.

John West
--
For the humour impaired: Insert a :-) after every third word
Newsgroups: comp.arch
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: Multiprocessors
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Sun, 13 Dec 1992 03:38:16 GMT

In article <Bz5s9F.J32.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay)
writes:

|>xm9@sdcc12.ucsd.edu (richard g. adair) writes:
|>>Even though a 730 will toast an 8 processor SGI!
|>
|>Never fear. SGI has promised a machine with 32 R4400's. Of course, HP
|>has promised a 16 CPU machine. It's finally about time to multithread
|>those codes, folks.

There are good reasons to multithread on single processors. All those programs
that make you wait while they do some low grade calculation or garbage
collection routine.


|>Oddly, although Crays have been multiprocessors for years, a lot of
|>programs only use one Cray processor. This is often largely a
|>function of incentive. One installation offered a big budget break to
|>parallel applications, and sure enough, almost everything suddenly
|>turned out to be parallelizable.

The big question is cost. If you do everything in single threads or using
trivial parallelism each processor requires enough memory to hold the trivial
partition of the problem. Programs like GEANT have trivial parallelism at the
event level which requires a database of >32 Mb. If you can split at a level
requiring only 1Mb then you can run 16 times faster for the same cost.

The reason is that 1Mb is approx same transistors as a processor (a bit more
actually...) So instead of 32Mb and 1 processor you can have 16 Processors with
1Mb ea.

The argument works better when you stick the processor on the same chip as the
RAM, no external memory bus at all, just an FDDI/HIPPI/whatever interface. that
means massive savings in production costs - none of those fiddly wires to put in
place... And in addition everything is onchip - no offchip penalty.


--

Phill Hallam-Baker
Newsgroups: comp.arch
From: zs@munta.cs.mu.OZ.AU (Zoltan Somogyi)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 15 Dec 1992 07:08:33 GMT

chased@rbbb.Eng.Sun.COM (David Chase) writes:
> We describe an efficient software cache consistency mechanism for shared
> memory multiprocessors that supports multiple writers and works for
> cache lines of any size.  Our mechanism relies on the fact that, for a
> correct program, only the global memory needs a consistent view of the
> shared data between synchronization points.  Our delayed consistency
> mechanism allows arbitrary use of data blocks between synchronizations.

cliffc@rice.edu (Cliff Click) writes:
>This sounds like an paraphrase of Ervan Darnell's thesis proposal here
>at Rice.  IBM funds a lot of Rice research, so this might be where IBM
>is coming from.  Send replies to ervan@cs.rice.edu.  Of course, I've
>been wrong before (and I haven't checked with Ervan on this).

This idea is quite old. It was the subject of a tech report six years ago:

%A D. Abramson
%A K. Ramamohanarao
%A M. Ross
%T A software controlled cache coherence policy,
using selectively clearable cache memories
%R Technical Report 86/18
%I Department of Computer Science, University of Melbourne
%C Melbourne, Australia
%D 1986

The paper was difficult to publish, as it seems to have been ahead of its time.
It finally appeared as

%A D. Abramson
%A K. Ramamohanarao
%A M. Ross
%T A scalable cache coherence mechanism
using a selectively clearable cache memory
%J Australian Computer Journal
%K acj
%V 21
%N 1
%D February 1989
%P 2-12

Zoltan Somogyi <zs@cs.mu.OZ.AU>
Department of Computer Science, University of Melbourne, AUSTRALIA
Newsgroups: comp.arch,comp.parallel
From: dfk@wildcat.dartmouth.edu (David Kotz)
Subject: question about DMA devices
Apparently-To: comp-parallel@rutgers.edu
Followup-To: comp.arch
Summary: can they do scatter/gather?
Originator: dfk@wildcat.dartmouth.edu
Keywords: DMA, scatter/gather
Organization: Dartmouth College, Hanover, NH
Date: Fri, 18 Dec 1992 16:59:15 GMT

I have a question about DMA devices, specifically for networks and disks.

Do you know if it is possible (and if so, common) for a DMA device to
support scatter/gather? In particular, I'm trying to model a
multiprocessor interconnect network interface, and it would be very
helpful if I could avoid packetization by specifying the addresses and
lengths of my message header and message body, for the network DMA to
pick up. I'm guessing that this is not usually an option.

Also, in a disk interface, can it read in a whole track but scatter
the blocks to different locations in memory? I'm guessing that this
kind of thing is more common.

Thanks,
dave
-- 
-----------------
Mathematics and Computer Science
Dartmouth College, 6188 Bradley Hall, Hanover NH 03755-3551
email: David.Kotz@Dartmouth.edu    or   dfk@cs.dartmouth.edu
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Date: 15 Dec 92 03:58:49 GMT
Article-I.D.: cs.BzA8E4.4EJ.2
Organization: School of Computer Science, Carnegie Mellon


rminnich@super.org (Ronald G Minnich) writes:
>Currently there are four RS6000s (980s ?), with 128 Mb each, with a crossbar,
>and eight shared memory modules. First cut of the crossbar was done
>with Xilinx; later cuts are custom. 

This sounds awfully like the Genesis project out of IBM Austin.

Do they still broadcast the I/O interrupts? Did they ever build the
test-and-set chip?
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 12 Dec 92 15:45:54 GMT
Organization: Rutgers University Department of Computer Science

Some conditions can be tested very cheaply, others on more expensive.

On the VAX, you could test the bottom bit of any value (in register or in
memory) in a single short instruction using BLBS/C (Branch on Low Bit
Set/Clear).  You could test ANY bit in a longword with a single slightly
more expensive instruction (BBS/BBC - Branch on Bit Set/Clear; you specify
the bit number).  Any other tests are done through the condition codes, so
require two instructions, nominally a TST of the appropriate kind and a
branch.

As others have noted, the low bit is used in VMS to signify truth/falsity
or success failure.  C is the only language I can think of that explicitly
defines false as zero and true as non-zero; using 0 and 1 is a much more
common representation for a Boolean value.  (-1 and not -1 are another
reasonable alternative on a two's-complement machine; 0 and -0 are reasonable
on a 1's complement machine.  Either of these might be - and has been -
simplified into <0 for true, >=0 for false - i.e., test the TOP bit.)

In addition, there are many cases in which you with to indicate not just
success or failure, but further status information.  As also already noted,
the standard VMS representation of a status uses the bottom bit for
success/failure and the rest of the value for an explanation.

The VAX hardware was designed along with VMS, and this representation was
chosen with the knowledge that the hardware would provide a very cheap low-
bit test, and vice versa.  VAX programmers know this, and, for example, when
setting aside a series of status bits in a longword, try to store the most
commonly tested one as the bottom bit.

Put it all together, and "test bottom bit" is a very high frequency operation
in running VMS code.  It's also an easy instruction to implement in hardware.
Hence, it's a natural for inclusion in the Alpha instruction set.

BTW, this should again prove that you have to be careful about what you are
designing "objectively" for.  If you start with a sample of Unix systems
running C code, you are unlikely to find much demand for a cheap low-bit
test.  That doesn't meant that such an instruction wouldn't carry it's own
weight - just that it would not do so in a job mix similar to the ones you
studied.
							-- Jerry
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 13 Dec 92 22:50:23 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <GJR.92Dec11231116@chamarti.ai.mit.edu> gjr@zurich.ai.mit.edu writes:
>Another place where it is useful is to test packed booleans.
>On most machines, the word containing the packed boolean would have to
>be masked, but the mask generation might take multiple instructions.
>Having branch-on-low-bit, you only need to shift before branching.

Nah.  Only `and with 1' and then use branch-on-zero.  One more
instruction.  There might be a delay for the result to come back from
the ALU if you can't interleave other instructions...

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Newsgroups: comp.arch
From: rminnich@super.org (Ronald G Minnich)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Organization: Supercomputing Research Center (Bowie, MD)
Date: Tue, 15 Dec 1992 13:09:34 GMT

In article <BzA8E4.4EJ.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>This sounds awfully like the Genesis project out of IBM Austin.
They called it Junior.
>Do they still broadcast the I/O interrupts? Did they ever build the
>test-and-set chip?

They did not mention I/O. I asked them about whether they had a 
test-and-set built into the memory system;
they were not very specific but it sounded like it was there.
ron

-- 
you want windows? I got windows. 4608 by 3600,    | rminnich@super.org
16 channels of sound, 4' by 6'. Fun.              | (301)-805-7451 or 7312
Most abused words: open, scaleable, [more later]  |
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: dfox@quack.sac.ca.us (David Fox)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 19 Dec 1992 17:29:54 UTC

In article <BzGn32.37C@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
>I disagree. It passed it's sell by date years ago. 
>
Well, no one said you had to buy it, then.  The free unix OSes for the
386, for example, are very modern, very powerful.  You could go with
DOS, but it's crippleware by comparison.  

>The kernel is a major factor in determining how useful the system is. Only AT&T
>had the capability to introduce a shell to replace the standard ones that could
>have achieved a degree of acceptance. 

What about GNU?  They wrote BASH, not AT&T.  And BASH is a lot better in
my opinion than the other shells out there.  
>
>If UNIX was ever allowed to become the sole O/S it would halt O/S deelopment
>completely. The only effort UNIX has ever made is in catching up.
>
How could it possibly, when *source code* is freely available to anyone
for 386BSD and Linux? 

>There were other choices. PICK for instance was a very highly regarded system
>but was killed through over agressive attempts to control it. Imagine a world in
PICK didn't use EBCDIC, and it's not a bad OS.

I can imagine a world with EBCDIC as opposed to ASCII is prominent.  I
realize EBCDIC does have some problems that ASCII doesn't have, and
ASCII is of course more prevalent. In and of themselves, a machine
using an EBCDIC character set isn't really better or worse than a
machine using an ASCII character set.  But the traditional EBCDIC
machines, of course, have been IBM mainframes running (pick one)
DOS/VSE, OS, OS/MVS, etc.  They are horribly patched together operating
systems, IMHO.  They don't hold a candle to Unix in terms of
user-friendlyness, simplicity, and sheer power.
Newsgroups: comp.arch
From: andy@SAIL.Stanford.EDU (Andy Freeman)
Subject: Re: Any use for Branch if Even/Odd ?
Organization: Computer Science Department,  Stanford University.
Date: Mon, 14 Dec 1992 20:36:31 GMT

In article <id.08RV.WYB@ferranti.com> peter@ferranti.com (peter da silva) writes:
>Close. As I recall, DEC is very fond of using even/odd for true/false values,
>and the VMS interface definition has a lot of even/odd status returns, so it's
>likely these instructions are to make it run VMS real good.

Does anyone know why they preferred even/odd to >=0/<0?  Sometimes one
has to test the sign bit, so why not use it whenever one can use any
bit to split things into two classes?

-andy
--
Newsgroups: comp.arch