HDTenEightyP/NetNews huggingface dataset:
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: <None>
Date: 12 Dec 92 15:24:03 GMT
Organization: Rutgers University Department of Computer Science

History repeats itself?  Many early RISC designs chose to expose timing and
pipeline constraints to the software.  It was up to software not to access
data before it arrived, for example.

Successive generations of RISC designs have moved that responsibility back to
hardware.  The original Stanford MIPS had no pipeline interlocks at all - if
the software didn't play by ALL the rules, it got nonsense.  The first
generation of the commercial MIPS architecture cut the constraints down to
two:  You had to wait one extra cyle before trying to use the results of a
load or a multiply, if I remember right.  The second generation of commercial
MIPS has even added hardware interlocks for those.

Delayed branches were a great idea for a while, but recent designs, such as
Alpha, have eschewed them.

The IBM RS/6000 design has NO "correctness" constraints - the RISC-style
optimizations are important for performance, but even without them the program
runs.

Now we are trying the same thing with memory consistency.  Ten years from now,
will we be looking back at those funny experiments of the early '90's that
(a) made the machines such a bitch to program; and (b) didn't really help
beyond a generation or two of design anyway?
							-- Jerry
Newsgroups: comp.arch,comp.sys.intel
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: Metaflow Technologies Inc.
Date: Thu, 17 Dec 1992 20:49:10 GMT

In article <PCG.92Dec13164348@aberdb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:
|> rschnapp> Don't forget about out-of-order (i.e., dataflow) execution
|> rschnapp> techniques.  You can gain plenty of additional fine-grain
|> rschnapp> parallelism.
|> 
|> Ah, there are indeed many interesting tricks to support high levels of
|> micro parallelism *in the implementation*. To me the really interesting
|> problem is not how to do it, though, it is whether it is worth doing it,
|> and for which classes of codes.
|> 
|> I have yet to find evidence that *general purpose* codes have an
|> intrinsic degree of micro parallelizable operation (let's call it
|> superscalarity) that makes it worthwhile to have a degree of parallel
|> *instruction issue* within a single stream not greater than 2-4.

...which is why I pointed out a paper you might wish to refer to.
There have been several studies indicating that there is plenty of
capacity for fine-grain parallelism in common programs.

Most of the SPEC '89 programs, for instance, benefit substantially from
out-of-order execution.  Supposedly, these ARE representative of
"typical" programs.  One of the nice things about out-of-order
execution is that you get the benefits of improved instruction
scheduling without having to recompile.
-- 

...Russ Schnapp
BIX: rschnapp           Email: netcom!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: hsandhu@sys.toronto.edu (Harjinder S Sandhu)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Keywords: mp shared-memory parallel multiprocessor risc smp
Date: 11 Dec 92 18:15:42 GMT

chased@rbbb.Eng.Sun.COM (David Chase) writes:
>I've had this nagging suspicion for about a year that people building
>MP's were working awfully hard to maintain coherency where it just
>didn't matter.  Given that most of the programming languages tell you
>to lock your data if it is shared, the "we're guarding against this"
>examples always looked like buggy programs to me.  People have been
>working on this at Rice, I know, and at least one other place that I
>cannot recall right now.
 
  Along the same lines, we have implemented and experimented with
a software coherence strategy based on the notion that applications
explicitly lock/unlock shared data. It requires no hardware or 
compiler support, but does rely on the programmer to program "correctly". 
This is described in a paper that will be appearing in the 1993 ACM SigPlan
Symposium on Principles and Practice of Parallel Programming in May:
"The Shared Regions Approach to Software Cache Coherence on
Multiprocessors". It will also be made available via ftp soon; send mail 
if you are interested.

    _harjinder

--------------------------------------
  Harjinder  hsandhu@cs.toronto.edu
  Computer Systems Research Institute
  University of Toronto
--------------------------------------
--
 
Newsgroups: comp.arch
From: lfm@pgroup.com (Larry Meadows)
Subject: Re: Any use for Branch if Even/Odd ?
Date: Mon, 14 Dec 1992 16:20:59 GMT
Organization: The Portland Group, Portland, OR

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

I haven't seen this mentioned -- in VMS Fortran, logicals are TRUE if odd
and FALSE if even.  Someone said that BLISS was the same way.  Of course,
this gives fits when mixing Fortran and C, or trying to retain VMS Fortran
compatibility on non-VMS systems.
-- 
Larry Meadows		The Portland Group
lfm@pgroup.com
Newsgroups: comp.arch
From: timhu@ico.isc.com (Timothy Hu)
Subject: Re: Date request
Organization: Interactive Systems Corp., Boulder CO
Date: Wed, 16 Dec 1992 18:21:10 GMT

The convention MM/DD/YY probably came about because when we mention a
date the long way, we say: December 16, 1992. Maybe the MMDDYY
convention was done to keep things in the same order.

Us crazy Americans!

Newsgroups: comp.arch,comp.lsi,comp.arch.storage,ba.seminars,comp.compression,comp.multimedia,su.events
From: freeman@cis.Stanford.EDU (Martin Freeman)
Subject: UPDATE CALL FOR PARTICIPATION: HOT CHIPS SYMPOSIUM V
Originator: freeman@cis.Stanford.EDU
Organization: Center for Integrated Systems, Stanford University, California
Date: Thu, 17 Dec 92 17:38:13 GMT


		     HOT CHIPS SYMPOSIUM V
		Stanford University, Stanford, CA
		       August 8-10, 1993


		    CALL FOR CONTRIBUTIONS
	                  
	General Chair:      John Hennessy, Stanford University
	Program Co-chairs:  Ruby Lee, Hewlett-Packard Company
			    Teresa Meng, Stanford University




HOT CHIPS is back once again! Sponsored by the IEEE Computer Society
Technical Committee on Microprocessors and Microcomputers, Hot Chips V
is a conference that consists of presentations on high-performance
chip and chip-set products, and related topics. This conference is
directed particularly at new and exciting products. The emphasis is on
real products, not academic designs. Participants will not be required
to prepare written papers. The proceedings will consist of copies of
the slides to be presented.

Contributions are solicited in the following areas:

* RISC and CISC Processors             * JPEG, MPEG and H.261 Chips

* Floating Point Processors            * Personal Communications Devices     

* Embedded CPUs                        * Media Processors                        
* Graphics, Image and Video Chips      * Neural Chips                 

* Interconnection Chips                * Compiler Issues with Hot Chips      

* Network Chips                        * Benchmarking/Performance Evaluation  

* Cache and Memory Chips               * Low-Power Design

Proposals should consist of a title, an extended abstract (1-5 pages) 
describing the product or topic to be presented, and the name,
title, address, phone number, fax number, and electronic mail address
of the presenter. If this is a not yet announced product, and you would
like the submission kept confidential, please indicate it; we will do
our best to maintain confidentiality. Submissions can be made by hard
copy, fax, or electronic mail, by Friday, March 12, 1993 to:

                HotChips V
                c/o Ms. Lilian Betters
                CIS 036
                Stanford University
                Stanford, CA. 94305
                Tel: (415) 725-3651
                Fax: (415) 725-6278
                Email: hotchip@tilden.stanford.edu

For further general information about the symposium, contact John Hennessy
at (415) 725-3712 or jlh@vsop.stanford.edu. For further information
about submissions, contact Ruby Lee at rblee@nsa.hp.com, or Teresa Meng at 
teresa@tilden.stanford.edu.


Newsgroups: comp.arch
From: daniel@clsi.COM (Daniel S. Barclay)
Subject: Re: Date request
Organization: CAD Language Systems Inc.
	<1992Dec14.134109.3367@fasttech.com> <1992Dec16.171133.2856@lsl.co.uk>
Date: 18 Dec 92 15:58:09

snail@lsl.co.uk writes:
> In article <1992Dec14.134109.3367@fasttech.com>, zeke@fasttech.com (Bohdan Tashchuk) writes:
> > A 10/21/92 semi-official net posting on NextStep claims it runs on SXs:
> 
> Hi folks, this is not a flame, just a request.
> 
> The date above refers to 21 November 1992. That may seem obvious to some of
> you. Lets switch the 21 to an 8. In America the date is now 8 November 1992. In
> the UK the date in now 10 August 1992. Some places have dates as Year/Month/Day
> too. It would be more clear if everyone wrote the month name as a name (until
> 2001 anyway). ie: 21/NOV/92.
> 
> The above aside, I'm always puzzled as to how the American date convention
> started: Mont/Day/Year is neither LSB or MSB, where as Day/Month/Year and
> Year/Month/Day have obvious reasoning behind them.

I thought I heard that there is an ISO date format of YY/MM/DD.  I like that
and YYMMDD; they sort (lexicographically and mathematically) into 
chronological order.  (Which is consistent with times as HHMMSS.)
--
------------------------------------------------------------------------------
Daniel S. Barclay                    --who's still searching for a good 
CAD Language Systems, Inc.           signature, not liking any of his recent
Suite 101, 5457 Twin Knolls Rd.      feeble attempts to improve on the whiny:
Columbia, MD  21045  USA             Why can't _I_ think of a good signature?

Newsgroups: comp.arch
From: r80144@cc.ee.ntu.edu.tw ()
Subject: Who has simulators?
Organization: NTUTaiwan
Date: Wed, 16 Dec 1992 06:26:13 GMT

Hi,
	I am a graduated student at NTU in Taiwan. I very need a simulator for shared memory multiprocessor that can get performance informances of a program, such as Cerberus simulator created by Engene D. Brooks. If anyone has the simulators or knows how to get copies of them, please e-mail me a message. If you e-mail me something, I appreciate you very much.

				Thanks,
				Jia-Jenn Yu
				r80144@cs.ee.ntu.edu.tw
Organization: SAS Institute Inc.
Date: Fri, 18 Dec 1992 09:55:28 EST
From: <SNOSZB@vm.sas.com> (Sanjeev Banerjia)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
 <1992Dec15.042513.23969@gandalf.ca> <1992Dec15.155425.25217@convex.com>
 <MEISSNER.92Dec17110628@tiktok.osf.org>

Copy-on-write is the default for address space sharing between Mach threads
(and spawned tasks also, maybe?) so no, it is not just NeXT-specific.

Sanjeev
Newsgroups: comp.arch,comp.sys.mac.hardware,comp.sys.ibm.pc.hardware,comp.sys.intel
From: peter@ferranti.com (peter da silva)
Subject: Re: User visible pipelines vs. user visible memory coherency.
Organization: Xenix Support, FICC
Date: Tue, 15 Dec 1992 02:54:00 GMT

[DEC dumping branch delay slots]

In article <1992Dec14.030757.14209@adobe.com> zstern@adobe.com (Zalman Stern) writes:
> Without any real compelling arguments that I've heard.

I think the theory is that if they're going to have a bunch of instruction
prefetching anyway, it's not a win, and they expect more rather than less
instruction reordering in silicon in the future.
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
From: keith@ksmith.uucp (Keith Smith)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus
Date: 20 Dec 92 21:21:05 GMT
Organization: Keith's Computer, Hope Mills, NC

What sort of transmission medium and CONNECTORS do we have in mind here?

Fibre is, well, Not ideal for short runs IMHO, like runs between a
floppy disk drive, and cpu would seem painful.  Small 25 pin D-sub style
connectors or even 50-pin ribbon with interleaved ground would seem more
well suited for short runs

My Idea of *IDEAL* for *ANY* machine would be a system of snap-together
lego (tm) style blocks with an arbitrary length bus.  Blocks would have
a defined size (Say 6" square?) one block being a "mother-block"

2 - tier "mother" block

    +---+
   /   /|
  /   / |
 /   /* |    Single tier blocks
+---+ * |       +---+       +-------+
|   | * |      /   /|      /       /|
|   |   |     /   / |     /       / |
|   | * |    /   /* |    /       /* |
|   | * +   +---+ * +   +-------+ * +
|   | */    |   | */    |       | */
|   | /     |   | /     |       | /
|   |/      |   |/      |       |/
+---+       +---+       +-------+

* = BUS PINS

Each block could be snapped on or off the "bus" at will with all the
neccessary connection pins / controls on the front or back edges of the
block.  Blocks should/could be stackable, with larger blocks obviously
on the bottom of a stack.

The Blocks could interconnect in any manner, even see-saw if neccessary,
and could be fastened together with simple snap-latches (No fripping
screws).  One could just snap on whatever one needed, out to shoebox
length or stak on top, or whatever.

Juice could/should be supplied by the mother block, with perhaps the
keyboard interface.  The Thickness of a block can be arbitrary in say
increments of 1 inch.  Cooling if needed should be provided
independently in the blocks that require it by small fans, etc.

Adding a disk drive would involve snapping on a disk block.  New video
block?  Snap it on.  CPU?  Snap it on.  Floppy? Tape?  Snap, snap.

This type of arrangement would also allow connection of say a ribbon
cable to another set of blocks.

<SIGH>  not in my lifetime I suppose.
-- 
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: rgupta@leland.Stanford.EDU (Rajesh Gupta)
Subject: Re: Logic Minimization Algorithms
Organization: CIs, Stanford University, CA 94305, USA
Distribution: world 
Date: Tue, 15 Dec 92 22:56:25 GMT

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:
> 
	comp.lsi.cad would be a more appropriate newsgroup.

> 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).
> 
...
> 
> So I guess my question is, how are these problems overcome?  Do people
> use other algorithms than Quine-McClusky instead that don't suffer
> these problems?  If so, what are they?
> 
> Does someone have references of articles that describe this stuff?
> Articles themselves?
> 


QM uses enumeration to achieve optimum. A number of heuristics
achieve near optimal solutions using algebraic methods. Most common
being the espresso-style heuristics which attempts to utilize implicit 
don't-cares (either by tautology-checking or by using approximate
don't-care sets) to perform logic minimization. 

Two-level logic synthesis is a fairly well-developed field. You may 
want to check out the following monograph 

Brayton, Sangiovanni et al
	"Logic Minimization Algorithms for VLSI", Kluwer Academic, 1984 (I think)


or there is a tutorial paper in IEEE Proceedings Feb 1990.


> What about publicly available source code that implements the various
> algorithms?

Espresso and its cousins are publicly available. (Espresso: UCB, 
Bold: Colorado, Boulder).

> 
> Thanks for any help people can give to satisfy my curiousity.
> 
> Dave Roberts



Rajesh Gupta

725-3647 CIS 18					rgupta@momus.stanford.edu


Newsgroups: comp.arch
From: norm@netcom.com (Norman Hardy)
Subject: Re: RISC assemblers question
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Thu, 17 Dec 1992 21:12:51 GMT

In article <Dec.17.10.16.36.1992.17493@cadenza.rutgers.edu> masticol@cadenza.rutgers.edu (Steve Masticola) writes:
>Hi,
>
>I've met a couple of people who have attempted to write assemblers for
>RISC machines, who say that it's a difficult job. Can someone give me
>an inkling as to why?
>
I have written much assembler code for each of several RISC machines starting 
with the CDC 6600 and most recently for the Motorola 88K. For the first few 
weeks the 6600 seemed alien but thereafter I decided that I preferred 
programming it to most other machines. My only advice is be sure to have an 
assembler whose notation makes it clear where a given register is modified. I 
have not measured productivity but it seems commensurate with "normal" 
machines.
Newsgroups: comp.arch
From: hallam@zeus02.desy.de (Phill Hallam-Baker)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Reply-To: Hallam@zeus02.desy.de
Organization: Deutsches Elektronen Synchrotron, Experiment ZEUS bei HERA
Date: Sat, 19 Dec 1992 19:38:55 GMT

In article <1992Dec18.150228.8274@cis.uab.edu>, hyatt@cis.uab.edu (Robert Hyatt)
writes:

|>>Consider any application written for a line mode terminal using FORTRAN I/O.
|>The
|>>portability of these programs was pretty much setttled a long time ago. On
|>the
|>>other hand any code using a windows system soon becomes a porting hazard. On
|>>UNIX there are even difficulties in porting code from one UNIX system to
|>another
|>>of the model and from the same vendor. This is because sysops tend to want
|>to
|>>split up large libraries amongst disks and UNIX does not provide a mechanism
|>>like logical names which allow a user to virtualize a disk system to make it
|>>look like something else. Logical links don't count in this regard, they
|>affect
|>>the system environment.
|>>
|>
|>I don't understand the "logical links don't count"......  we use 'em for
|>exactly this purpose.  When Sun puts something somewhere that we don't
|>like (don't have room in that partition, etc.) we move that "thing" and
|>symbolic link to it.  We've never had any problems with X, openwin, etc.
|>in this environment.....

Try using them without system privs. 

There is no way of making a UNIX machine look as if it configured in one way to
one program but in quite a different way to another program. If you have more
than 20 people on a cluster you will realize why it is impossible to give root
privs to everybody. Even if people know what they are doing it is not acceptable
to have one person interfere with the environment of another person.


|>>
|>>UNIX is a single user system too. The only evidence of a multiuser capability
|>is
|>>
|>
|>This is news to us.  We have been using unix boxes for multiple users for 15
|>years.  Unix is as multi-user as any O/S I have used.  (this includes running
|>X over async modem lines if you want....)  We have students doing program
|>development, email, compiling, remote machine access, distributed processing
|>using domain sockets and/or RPC's, etc.

Having beds for rent does not mean that a bordello is a hotel.

A multiuser machine should be just that, it should allow multiple users to
access it without interfering with each other. We have already noted the
difficulties caused by the file system. In addition to this inadequate resource
monitoring means that the scheduler is practicaly useless, any user can simply
spawn tasks to increase the proportion of CPU alloted to their needs. 

If your definition of multiuser capability is low enough to incorporate UNIX
then W/NT will come close. From multiprocess to multiuser the transformation is
mainly in providing a more sophisticated filestore. Untill there are
applications to support the new file store multiuser W/NT will be irrelevant.
Once that happens you can be pretty sure that Microsoft move in that direction.
If they don't Borland, Norton or someone else will.


--

Phill Hallam-Baker
Newsgroups: comp.arch
From: gordie@kaleida.com (Gordie Freedman)
Newsgroups: comp.arch
Subject: Real UNIX? (Was Re: Comparison or Alpha, MIPS and PA-RISC ...)
Date: 18 Dec 1992 21:51:49 GMT
Organization: Happy hacker bait and tackle shop
Distribution: world
Reply-To: gordie@kaleida.com
NNTP-Posting-Host: moon.kaleida.com

In article u600WBO40k2xV@andrew.cmu.edu, Sean McLinden <sean+@andrew.cmu.edu> () writes:
>>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

I think that is what the original poster meant ... It seems to me he was saying
"real" UNIX is one of those early incarnations, as opposed to a more modern
UNIX. I don't remember whether he implied he would buy a "modern" UNIX though ...

Personally, I wouldn't speak English like they did centuries ago, but I do speak 
it in the current dialect (roughly speaking). I use a modern UNIX but if a SUN or
a NeXT came with a "real" UNIX from the '70s they might have a bit of a problem
selling them.

--------

Gordie Freedman
gordie@kaleida.com

These are not even real opinions so don't go blaming Kaleida for them
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Elegance vs Speed (was re: Comparison of Alpha ...)
Date: 10 Dec 92 14:39:58 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 8 Dec 92 00:00:21 GMT, gordie@kaleida.com (Gordie Freedman) said:

gordie> On a NeXT, learn how to use the dictionary, spell-checker, etc.
gordie> in one app and you know how to do it for them all.

Amazing! We already had all this in Multics... What has happened in the
past 25 years? :-)
--
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
Newsgroups: comp.arch