HDTenEightyP/NetNews huggingface dataset:
From: simonich@croatia.eng.hou.compaq.com (Chris Simonich)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Organization: Compaq Computer Corp.
Date: Wed, 16 Dec 1992 16:00:54 GMT

In article <1992Dec15.205639.25591@super.org> rminnich@super.org (Ronald G Minnich) writes:
>
>Actually, seems to me they could look at SCI. Except they want low cost.
>But if the CMOS chips for SCI pan out, maybe they will meet the cost 
>range.

We have received this response from several people.  We 
disagree.  For one SCI had a physical topology (a ring) that 
is not suitable for expansion I/O.  Yes, we know you can run 
the ring to and from the same board and create a topology 
that looks like the Anet (Compaq Proposal) topology but then 
you begin to loose much of the cost advantages.  We took a 
long look at SCI before we created our proposal.  We ran 
into lots of problems trying to allow different speed rings 
to work together and the biggest problem was that we didn't 
like having to have bi-polar transceivers.  When we started 
to recast the thing for CMOS implementation we ran into 
protocol inefficiencies and, well, it just didn't seem to 
work out the way we need it to.  The major thing turned out 
to be that SCI and the Compaq proposal (we call it Anet 
around here) were trying to solve different problems with 
cost, not bandwidth, being the major one.  The fact that the 
'C' in SCI stands for coherent I think brings out one of the 
differences in approach.  We needed an I/O interface and 
coherency in the I/O subsystem was something that we were 
trying to eliminate.  The address bandwidth required to 
maintain coherency in the I/O subsystem is prohibitive.

Don't get me wrong, we think that from a technical point of 
view SCI is neat.  It just seems to be intended for a 
different part of the system architecture.  We would welcome 
any comments you have to the contrary.  When/if you respond, 
tell us how we can make an SCI, I/O subsystem as cheap as an 
Anet, I/O subsystem.
--
======================================================
Christopher Simonich        simonich@twisto.compaq.com
Compaq Computer Corp.       [713] 374-1898
======================================================
Xref: sparky comp.arch:11679 comp.lsi:746
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: specks for the intel P5
Organization: Intel Corp., Hillsboro, Oregon
	<id.1UJV.ZIE@ferranti.com> <1992Dec8.045715.5648@wam.umd.edu>
	<Bz1w3v.3KL@dscomsa.desy.de>
Date: Sat, 12 Dec 1992 22:55:48 GMT

    Intel published a press release to the group a while back. They have got as far
    as chosing a name, it is to be called the Pentium. 

Being picky, let me note that *Intel* did *not* publish a press
release to the group.

*I*, as a private citizen, copied an Intel press release to this
group.

The difference is very important. 

--

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: jdd@cdf.toronto.edu (John DiMarco)
Subject: Re: "Open Systems" (was Re: Comparison of Alpha, MIPS and PA-RISC-II wanted)
Organization: University of Toronto Computing Disciplines Facility
Date: Tue, 15 Dec 1992 00:13:28 GMT

In <id.G6TV.801@ferranti.com> peter@ferranti.com (Peter da Silva) writes:

>In article <jdd.724102048@cdf.toronto.edu> jdd@cdf.toronto.edu (John DiMarco) writes:
>> This leads to the following definition: "Openness" is essentially a measure
>> of the minimum migration cost of replacing a system with another from a 
>> different manufacturer.

>That's far too simple. I can replace a network of VAXen running Ultrix on
>DECnet more easily than I can replace a network of Suns running SunOS if my
>application is using DPS or NeWS (respectively), since DPS is available from
>more sources, but I can integrate an RS6000 in the Sun network a lot more
>easily than I can integrate it in the Ultrix network.

Good point. Certainly ease of replacement varies from case to case. Comparing
the "openness" of two options isn't always an easy exercise. 

>If I have a network of DOS machines running Novell it's going to be really
>painful to provide Usenet news to these seats, and moderately painful just
>to give them file-level access to my VMS based VAXen, but if I'm running
>OpenNET it'll be quite easy... but OpenNET is only available from one vendor.

This is interoperability (in this case, between VMS and DOS boxes), not
openness. Let's not confuse the two. 

John
--
John DiMarco                                              jdd@cdf.toronto.edu
Computing Disciplines Facility Systems Manager            jdd@cdf.utoronto.ca
University of Toronto                                     EA201B,(416)978-1928
Newsgroups: comp.arch
From: cmiller@croatia.eng.hou.compaq.com (Craig Miller)
Subject: Re: Compaq's Proposed Scalable I/O Architecture
Organization: Compaq Computer Corp.
Distribution: usa
Date: Wed, 16 Dec 1992 21:17:40 GMT

In article <1992Dec15.212901.12236@bcars64a.bnr.ca> schow@bcarh2d8.bnr.ca (Stanley T.H. Chow) writes:
>
>Also, it is not clear how this would be "inexpensive" or be
>compatible to existing PC software (I am assuming that you
>want to run existing PC software).
>

To address the issue of cost:

Anet (Compaq proposal) requires only 12 signals to interconnect a channel.
When one develops a system around Anet, the number of signals is reduced
signifigantly relative to other proposed I/O standards.  This translates into
reduced pin count for implementation ASICs, reduced board layout costs, etc.
For example, a PCI ethernet chip will fit in a 100 pin PQFP.  The same
implementation using the Anet interface fits in a 32-pin PSOP.  The nice
thing is that 32-pin PSOPs are used for DRAMs so they are dirt cheap.  This is only one example, cost savings continue to appear as one studies an actual implementation. 
 

On the issue of compatibility:

Anet is in fact compatible with current x86 software, but we really don't care.  The current model allows well behaved x86 applications to simply upgrade their device driver model (or in the case of Windows, provide a new driver for the shell).  Old apps that are register specific are not supported, but are considered irrelevent with the current trends in operating system software. 


------------------------------------------------------------------------------
-  Craig Miller                        InterNet:  cmiller@twisto.compaq.com  -
-  Strategic Technology Development       phone:  (713)374-0930              -
-  Compaq Computer Corporation                                               -
-  Houston, Texas                                                            - 
------------------------------------------------------------------------------
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC assemblers question
Date: 18 Dec 92 01:46:01 GMT
Organization: Auspex Systems, Santa Clara

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

Code in assembler language, or code that was part of an assembler?

I'm not sure whether the original poster was talking about the former,
or the latter; they're not necesarily equivalent (the assemblers I've
used for the past 10 years or so have all been written in C...).

You've responded to the former, and others have responded to the latter,
so hopefully the original poster's question has been answered, no matter
which they were asking about....
Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: USA vs. World (was Yanks vs. Brits)
Organization: Massachusetts Institute of Technology
Date: Sun, 20 Dec 1992 23:17:33 GMT

In article <1992Dec19.174528.638@oucsace.cs.ohiou.edu>, dneedham@oucsace.cs.ohiou.edu (Douglas Wade Needham) writes:
|> I started to mail it, but felt strong enough to go through the hassle of
|> turning my reply into a followup...
|> 
|> It might be "Here we go again", but it is a valid point.  While I am,
|> as you say, a "Yank" like the gentleman at microsoft, I too have found
|> it very frustrating...to put it very simply...IT MAKES NO () SENSE!!!
|> Just like the measurements system that the USA uses.  And just as the
|> rest of the world uses MKS or some derivative of it, the majority of
|> the world to my knowledge uses YY/MM/DD, DD/MM/YY or something of that
|> nature, and NOT the XX/DD/XX form that we use predomanately here.
|> 
|> Maybe the US should take the hint, jump on the band-wagon and ride along
|> with the rest of the world.  Otherwise, the USA will end up like the brother
|> who decided to walk to the town in the next county rather than hitch up the
|> wagon and ride there.  If the first brother does not get on the wagon, who
|> gets to town first (reguardless of whether or not the first brother can
|> beat-up the second)???
|> 
|> The UK went to metric, abandoning the measurement system US civilians use.
|> This also should say something.
|> 
|> NUFF SAID!!! Besides, this is not the best news group for it.

For those Americans who are unaware, we are now a metric nation. The congress
decreed that starting in 1988 we should start using metric and that after a
certain date (I believe Dec. 31, 1992) All government transactions must be
conducted using metric. The last SBIR pre-solicitation announcement (and
probably a whole bunch of other recent government documents) mentioned this
and said that instructions on how to deal with it will be forthcomming.

Jason W. Solinsky
From: mike@starburst.umd.edu (Michael F. Santangelo)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 13 Dec 92 22:48:31 GMT


Ah!  The first time I had heard me mention of a TLB in Telnet 808x
processors was now in this thread.  Did the '386 have a TLB?  How
big is/are the TLB (for the '486 and the '386 if it has one)?

--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@cbl.umd.edu
Computer & Network Systems Director   +           mike@kavishar.umd.edu
UMCEES / CBL (Solomons Island)        + BITNET:   MIKE@UMUC
University of Maryland                + Voice:    (410) 326-7237 (direct)
                                      +           (410) 326-4281 x237

Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Logic Minimization Algorithms
Organization: Rice University, Houston
Date: Tue, 15 Dec 1992 18:27:47 GMT

roberts@angelo.amd.com (Dave Roberts) writes:
>
>I couldn't think of a more appropriate news group to post this in

comp.compilers comes to mind :-)

>What sort of algorithms are typically used to minimize logic equations
>specified in high level hardware description languages (PAL software,
>Verilog, etc.)?
>[...]
>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?

Here's one, which has many pointers further back.

  author="Kurt Keutzer and Wayne Wolf",
  title="Anatomy of a Hardware Compiler",
  pages="95--104",
  journal=sigplan,
  year=1988,
  month=jul,
  volume=23,
  number=7

It's in the Proceedings of the SIGPLAN '88 Conference on
Programming Language Design and Implementation.

Preston Briggs
From: keith@ksmith.uucp (Keith Smith)
Newsgroups: comp.arch
Subject: Re: IBM AS/400 is the world's slowest computer
Date: 20 Dec 92 22:11:03 GMT
Organization: Keith's Computer, Hope Mills, NC

In article <1992Dec18.165950.15013@webo.dg.com> lewine@cheshirecat.webo.dg.com writes:
>IBM is currently running full-page Ads that claim "The AS/400
>is the world's most powerfull computer with the industry's best
>price/performance(*)"
>
>"(*) According to the TPC-C benchmark results published through
>     12/3/92"
>

Yea, I laughed so hard my sides ached!

>IBM does not point out the the AS/400 is the only computer with
>TPC-C results published as of 12/3/93.  The AS/400 is also the
>world's slowest and most expensive computer by the same benchmark.

Dog slow.  But to the people who buy them they don't care.  The fact is
the AS/400 runs their apps that they have ported up from S/3 cards for
the last 20 years, and they are too lazy to try something different, so
they pay, and pay, and pay....

>
>Do people fall for this stuff?  IBM claims that the AS/400 is the
>best selling mid-range system in the world, so someone must fall
>for it.

Compile time for a 1000+ line program on a 486/33 w/8MB RAM using UNIBOL
RPG was about 8 times faster than an AS/400 B20 with 8MB RAM.  Seconds
as opposed to minutes.  Again, IBM will hold your ignorant MIS
departments hands from purchase, to setup to delivery.  All they'll have
to is write even more indicator mad code that takes forever to run, that
will of course require an even bigger AS/400 (or perhaps a 486/33 with a
better compiler ...)

If you own one, pray no one nukes the New England plant where all 100 or
so people that know AS/400 internals work.

>--------------------------------------------------------------------
>Donald A. Lewine                (508) 870-9008 Voice
>Data General Corporation        (508) 366-0750 FAX
>4400 Computer Drive. MS D112A
>Westboro, MA 01580  U.S.A.
>
>uucp: uunet!dg!lewine   Internet: lewine@cheshirecat.webo.dg.com


-- 
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 ...
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 19 Dec 92 16:22:24 GMT
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 13 Dec 92 05:00:19 GMT, johnl@iecc.cambridge.ma.us (John R. Levine) said:

(somebody)> NeXTStep is said to not run on the Cyrix 486 chips because
(somebody)> "they are not real 486's".  No one has come up with a
(somebody)> reliable reason _why_ NeXT doesn't think they are "real
(somebody)> 486's" or why NeXTStep won't run on them.

The most probable reason seen so far is that there are some small
supervisor state differences between the Cyrix and the Intel part.  If
so, I would venture that it is about enabling (and then flushing at the
right moment) the cache on the Cyrix.  It is not necessary to do so, but
if one does not (and one has to do so on most old 386-like motherboards
on which the Cyrix part is usually mounted) then performance is little
better than with a 386.

johnl> I don't have any real data, but I expect the problem is that the
johnl> Cyrix chip doesn't have a floating point unit.

No, this cannot be the reason. As a rule the Cyrix 486DLC CPU chip is
sold with the Cyrix Fasmath (a 387) coprocessor, the combo being touted
quite reasonably as a 486DX equivalent.

Moreover NeXTStep is said to run on the 486SX Intel chips, and those
don't have a corprocessor either.

FUD, FUD. Ah Intel, Intel. :-)
--
Piercarlo Grandi, Dept of CS, PC/UW@Aberystwyth <pcg@aber.ac.uk>
  E l'italiano cantava, cantava. E le sue disperate invocazioni giunsero
  alle orecchie del suo divino protettore, il dio della barzelletta
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Organization: I.E.C.C.
Date: 13 Dec 92 00:00:19 EST (Sun)
From: johnl@iecc.cambridge.ma.us (John R. Levine)

>NeXTStep is said to not run on the Cyrix 486 chips because "they are
>not real 486's".  No one has come up with a reliable reason _why_ NeXT
>doesn't think they are "real 486's" or why NeXTStep won't run on them.

I don't have any real data, but I expect the problem is that the Cyrix
chip doesn't have a floating point unit.  Next's own systems have all
had standard FPUs, and reviews of NeXTStep say that it won't run on a
486SX, only a DX.  Display Postscript apparently does a lot of floating
arithmetic, so I'd imagine the performance hit for simulated FP could be
severe.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
From: moss@cs.cmu.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: Relatively long cycle time in 486 LOOP instruction
Date: 17 Dec 92 12:31:24 GMT
Article-I.D.: CRAFTY.MOSS.92Dec17073124
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

A guess as to why a decrement-and-branch instruction might take longer than
you expect is that if the processor is pipelined, they may stall instruction
issue until this instruction has resolved whether or not it is going to
branch. I don't know the instruction set in detail, but if these are
instructions where the branch target is in a register or computed (i.e., not
absolute in the instruction, or PC relative), you can also lose cycles in
getting the branch target fetched.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: <None> (Should be Open Systems, bloody NEWS system...)
Organization: University of Alabama at Birmingham
Date: Fri, 18 Dec 1992 15:02:28 GMT

In article <BzGL07.2wK@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
>In article <1992Dec14.191335.2834@lsl.co.uk>, snail@lsl.co.uk writes:
>
>|>In article <jdd.724022716@cdf.toronto.edu>, jdd@cdf.toronto.edu (John DiMarco)
>|>writes:
>
>|>> My basic point is this: A system's "openness" is a measure of its 
>|>> replaceability by a system from another vendor. By this standard, VAX/VMS
>|>is
>|>> not very open, and random-workstation/UNIX-variant is more but not
>|>completely
>|>> open.
>|>
>|>I'll go along with that.
>
>
>Complete codswallop. By this definition the most "open" system is a house brick.
>It is trivial to port any application that runs on a house brick to any other
>system.
>
>Functionality also comes into it. If people write programs that require high
>levels of functionality from an O/S then they are going to be less portable.
>Does this mean that the O/S should as a result be regarded as being better if it
>provides less features?
>
>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.....

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


-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
Xref: sparky comp.arch:11697 comp.arch.storage:861
From: mike@cbl.umd.edu (Michael Santangelo)
Newsgroups: comp.arch,comp.arch.storage
Subject: ?Concurrent DMA possible on smarter PC buses (EISA/MCA/Localbus)
Date: 16 Dec 1992 13:43:59 -0500
Organization: University of Maryland, Chesapeake Biological Laboratory
NNTP-Posting-Host: cbl.umd.edu
Summary: Can multiple controllers do simulateous DMA to main memory on a PC?
Keywords: EISA,MCA,Localbus,VESA,PC,IBM,smartIO

Can EISA, MicroChannel, or the new VESA LocalBus on PC's allow
multiple controllers plugged into them (say two smart bus mastering
SCSI disk controllers on one of these buses) xfer data simultaneously
to main memory (DMA)?

Here's the example: say I have two SCSI controllers on an EISA, and
an EISA based ethernet controller, can more than one of these
interfaces be doing a DMA data transfer on the bus at the same time
to main memory (say, interleaving their I/O)?  Or is it the case
for all of them (if any can do please specify) that only one
controller can be doing I/O at a time to main memory (DMA) before
anothere can?  How about if a system has an EISA and a VESA LocalBus
and there is a smart disk controller in the VESA LocalBus and an
EISA based ethernet controller on the EISA bus, can both be doing DMA
to main memory?

Thanks in advance for any input.



-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Michael F. Santangelo                 + Internet: mike@cbl.umd.edu
Computer & Network Systems Director   +           mike@kavishar.umd.edu
UMCEES / CBL (Solomons Island)        + BITNET:   MIKE@UMUC
Newsgroups: comp.arch
From: zstern@adobe.com (Zalman Stern)
Subject: Motorola 68040 MOVE16 instruction.
Organization: Adobe Systems Incorporated
Date: Wed, 16 Dec 1992 23:13:37 GMT

Are there any known errata relating to the use of MOVE16 instruction on the  
68040? Specifically in a Macintosh Quadra 700 or 950? In particular can I  
issue a number of MOVE16's back to back and expect it to work correctly?

(Please respond via email. I'll summarize if there is interest.)
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: <None> Should be Open Systems (Bloody NEWS....)
Date: 14 Dec 92 18:21:08 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <Bz696B.B53@exnet.co.uk>, dhd@exnet.co.uk (Damon) writes:
> In article <1992Dec9.193616.2813@lsl.co.uk> snail@lsl.co.uk writes:
>>So: Where can you get hardware that runs SunOS?
> 
> Cray Superservers?
> Thinking Machines (thinly disguised)?
> Solbourne?
> Hyundai/Axil?
> 
> etc
> 
> Or am I missing a point here?

No I got that wrong (despite us having one of those nice 4 wheel drive Hyundai
machines here for a while). My brain was Out to lunch that sentence - it goes
all funny when people start getting evangelical about Sun or Intel, it also
goes funny when it sees hipocrits like Oral Roberts and Mrs T, but thats
another story.

Well, should be Solaris shouldn't it? Since raw SunOS gets tweaked by the
vendors (or at least I'm lead to believe it does). Why the hell would people
like Cray want to run SunOS though?
-- 
snail@lsl.co.uk      

muso/unix joke: "which debugger do you use?"
                "I use dbx..."
                "Oh really, we use Dolby C..."
Motorola inside.
From: krish@olympus.ICS.UCI.EDU (Umesh Krishnaswamy)
Subject: Cray Y-MP assembly instruction set
Newsgroups: comp.arch
Date: 14 Dec 92 22:32:26 GMT

I am looking for references which describe the Cray Y-MP assembly
instruction set (any Cray would suffice) and provide appropriate
documentation and description of the functionality of the
instructions. Any suggestions?

Thanks.
Krish.

PS: Could you'll please reply by email.
Newsgroups: comp.arch