HDTenEightyP/NetNews huggingface dataset:
From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: Superscalar vs. multiple CPUs ?
Date: 27 Dec 92 20:12:57 GMT
	<PCG.92Dec23144916@decb.aber.ac.uk> <Bzpzwq.18q@news.udel.edu>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth

On 23 Dec 92 16:17:13 GMT, mccalpin@perelandra.cms.udel.edu (John D. McCalpin) said:

mccalpin> (Piercarlo Grandi) writes:

solman> At any rate, I would claim that improvements in processor
solman> performance should only be concerned with apps which are
solman> presently processor limited, and many of these general purpose
solman> codes just aren't.

pcg> Uhm, memory is so cheap that many "general purpose" applications
pcg> nowadays can be made entirely core resident, and a core resident
pcg> program is 100% CPU bound.  for example I see most compiles on my
pcg> machine are CPU bound; except for reading in the source and writing
pcg> out the code there is no IO activity whatsoever.

mccalpin> I disagree with this distinction.  A core resident program can
mccalpin> be very seriously *memory* bound if the processor is spending
mccalpin> most of its time locked down waiting for cache misses to be
mccalpin> filled.

Ah, of course, this is the next problem that a hyperscalar architecture
has got to solve. Given the less than impressive rate of improvement in
memory speeds, most fast CPUs today are memory starved, as you comment
on later.

This is another reason for which I think hyperscalar is premature:
a vector instruction has the very nice property that it implies a very
definite memory access pattern, as compared with a loop that does the
same thing. And many important applications have FIFO data reference
patterns, for which predictive memory accesses are essential, and
adaptive ones, like those implied by a cache, are fatal:

mccalpin> Many "cpu-bound" programs spend half or more of their time in
mccalpin> this state, and it is very easy to accidentally build a
mccalpin> program which spends 90% of its time waiting for cache line
mccalpin> refills.
--
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
From: ecf_stbo@jhuvms.hcf.jhu.edu (When I boot to device appear to me these a messages it is)
Subject: Re: VMS vs "Unix"
News-Software: VAX/VMS VNEWS 1.41    
Organization: The Johns Hopkins University - HCF
Date: Wed, 23 Dec 1992 20:32:00 GMT

In article <1992Dec23.195640.17777@crd.ge.com>, davidsen@crd.ge.com (bill davidsen) writes...
>  joesvax::a$physical_disk$name_here_like_dra0:[dir.dir.dir]filename
> 
>may work from anywhere on the net, but you need to know the node name,
>physical device name, and lots of syntax with variable numbers of
>colons, and [names] as well.

It's very easy for the system manager can set up logical names to make
this transparent to users. 



Tom O'Toole - ecf_stbo@jhuvms.hcf.jhu.edu - JHUVMS system programmer 
Homewood Computing Facilities, Johns Hopkins University, Balto. Md. 21218 
>Here comes a jet ski.
>weuh weeuhh weeuhh weeuhh WEEUHH WEEUHH WEEUHH WEEUHH weeuhh weeuhh weeuhh weuh
Newsgroups: comp.arch
From: wayne@backbone.uucp (Wayne Schlitt)
Subject: Re: 100 Mips Intel NeXT (processor comparison)
Organization: The Backbone Cabal
	<1992Dec31.013141.132685@zeus.calpoly.edu>
	<1992Dec31.022317.17674@wam.umd.edu>
Date: Thu, 31 Dec 1992 13:49:58 GMT

In article <1992Dec31.022317.17674@wam.umd.edu> rsrodger@wam.umd.edu (Yamanari) writes:
> >
> >Don't be surprised if CPU's start coming out with 1 meg of onboard cache
> >within the next year...
> 
> 
> 	Is this really likely, given the complexity (according to 
> 	net rumor) already involved in fabricating the Alpha?


If "onboard" means "on the motherboard", then yes, I would expect that
some of the high end alpha systems will probably have 1MB of cache.
If "onboard" means "on the chip", then no, you will not see cache
sizes like that for at least 5 years.  The standard DRAM is 4Mbit,
which is .5MByte, so fabrication techniques aren't even up to having
that much memory along with a cpu on a chip, let alone having that
memory be fast SRAM.   (what's the current SRAM density nowadays
anyway?)


-wayne
Newsgroups: comp.arch,comp.sys.intel
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: Superscalar vs. multiple CPUs ?
Organization: Massachusetts Institute of Technology
Date: Wed, 23 Dec 1992 16:46:17 GMT

In article <PCG.92Dec23144916@decb.aber.ac.uk>, pcg@aber.ac.uk (Piercarlo Grandi) writes:

|> On a micro level, I am skeptical; there are clearly stretches of code
|> that can be micro parallelized, even vectorized (flow analysis has been
|> vectorized in some Cray compilers, as it is about sweeping boolean
|> matrixes), but overall the processing mustr be sequential. It also
|> depends on the language; for example in C it is conceivable that every
|> function in a source file be compiled in parallel. But this I would
|> regard as macro level parallelism.

We seem to be saying the same things only you keep on talking about macro-level
parallelism as though it would be difficult to exploit, and I feel that the
existence of macro-level parallelism justifies increased superscalarity. It
is my contention that as processors continue to get more and more hyperscalar,
they will be increasingly able to exploit macro-level parallelism without the
help of smart compilers (which will, no doubt continue to improve.) In a
hyperscalar chip it will be necessary to implement tagging and/or scoreboarding
protocols to control resource allocation and make sure that none of the data
gets mixed up. Once this overhead is paid, the protocols can be altered to find
macro level parallelism on their own with very little additional cost in either
performance or area.

Jason W. Solinsky
Xref: sparky comp.arch:11979 comp.sys.dec:6635 comp.sys.sgi:18360 comp.sys.hp:14395
Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 29 Dec 92 02:29:35 GMT
Distribution: world
Organization: The Wolery

zrepachol@cc.curtin.edu.au writes:
> > 		*Volume 6B*
>                          ^
> Perhaps you could tell the nice reader what else is in vol 6.

Oh alright.  6A is the other *File System* book, including:

	Guide to File Applications
	ANALYZE/RMS
	CONVERT
	File Definition Language
	and the National Character Set stuff (why?  I dunno.)

All good clean RMS stuff.  To get into the stuff the previous poster 
described as the "file system", you have to head for the I/O User's 
book.  ("User's"?  That one is one of the more formidable volumes....)

> But U*** still loses because it has no way of telling the application what
> TYPE of file structure it is...

Exactly.  Well, you can pull kludgery with magic numbers....

> Never a truer word spoken... The intertwining of the C language and Unix IO
> is a *HUGE* mistake.

I personally believe VAXCRTL is a serious impediment to DEC's claims of 
"openness" in VMS.  Life's too short to have to go re-implementing half
the RTL whenever you try to get anything done because the standard stuff
is too slow, too buggy or more often than not, both.

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: knowles@FNALNI.FNAL.GOV
Newsgroups: comp.arch.bus.vmebus
Subject: MVME117-3 does SCSI?
Date: 25 Dec 1992 02:50:53 GMT
Organization: Fermi National Accelerator Lab
Reply-To: knowles@FNALNI.FNAL.GOV
NNTP-Posting-Host: fnalni.fnal.gov

Hello All:

     I am experimenting with a MVME117-3 and am trying to coax
the SCSI port to work.  I have the 117bug up and its version 0.7
(The manual shows version 1.1) and when I try to access the SCSI bus
I get a bus error.

     Is there some setup that should be performed?  I tried the
CMOS command but the firmware sez ?what? so I presume some of the
SCSI functionality was in development during version 0.7.  Can
someone give me a shove in the right direction on this?

Thanks in advance and regards

Rich Knowles       knowles@fnalo.fnal.gov      Fermilab
From: meindert@inducom.nl (Meindert Kuipers)
Newsgroups: comp.arch.bus.vmebus
Subject: Re: VME sources - VME Buyers Guide
Date: 24 Dec 92 08:59:46 GMT
Organization: Inducom Systems BV, Oss, Netherlands

From article <aaron.725124823@sparc-12>, by aaron@blink.att.com (Aaron Chesir(x1530)):
> Folks,
> 	According to Cahner's Publishing, the VME Bus Buyer's Guide is no longer
> being published. The company told me the other day that the publication was
> an economic loss for the publisher. HOWEVER, a condensed version of the buyer's
> guide is available in the August issue of Control Enginering magazine, also
> published by Cahner's.
>
If this VMEbus Buyers Guide is the same as the one published by the magazine
'VMEbus Systems' then I can only say that I have filled out the forms for our
products about one and a half month ago.
Of course, the VITA still publishes its Product Directory twice a year.

Why do not all VMEbus manufacturers, or at least those who are on the net,
post a description of all their products, if the charter allows this. If the
users of this newsgroup agree on a layout we could all easily 'grep' on
keywords and find out about products that we need.
Or better, maybe someone has a PD database program which is already used for
this purpose and would like to share it with the net.
I have a description of our products readily available in a file and can post
or mail it if people are interested.
BTW, which VMEbus manufacturers are on the net? Is VITA on the net?

--
Meindert Kuipers             PO Box 627, NL 5340 AP  OSS       /\    /~~~\
meindert@inducom.nl          Phone: (31)4120-51055            /--\  |     |
AcQuisition Techonoly BV     Fax:   (31)4120-51050           /    \  \__\/
******  Manufacturers of M-modules and VMEbus boards                C     \
From: knowles@FNALO.FNAL.GOV
Newsgroups: comp.arch.bus.vmebus
Subject: MVME410
Date: 21 Dec 1992 17:59:52 GMT
Organization: Fermi National Accelerator Lab
Reply-To: knowles@FNALO.FNAL.GOV
NNTP-Posting-Host: fnalo.fnal.gov

Hi All:

Is there anyone out there who might have a copy of the
MVME410 users' manual?  I've spoken to my local MOTO
sales office but they say its too old for them to
have records on.

Even a poor copy is better than no info at all.

Worst comes to worst, does anyone know the parallel
port pinouts?

Thanks in advance

Rich Knowles      knowles@fnalo.fnal.gov     Fermilab

Newsgroups: comp.arch.bus.vmebus
From: aaron@blink.att.com (Aaron Chesir(x1530))
Subject: Re: VME sources - VME Buyers Guide
Organization: AT&T
Date: Wed, 23 Dec 1992 15:33:43 GMT

Folks,
	According to Cahner's Publishing, the VME Bus Buyer's Guide is no longer
being published. The company told me the other day that the publication was
an economic loss for the publisher. HOWEVER, a condensed version of the buyer's
guide is available in the August issue of Control Enginering magazine, also
published by Cahner's.


Aaron Michael Chesir
aaron@blink.att.com	..att!blink!aaron
AT&T Bell Labs
Dept BL0-54374	1-(908)-949-1530
101 Crawfords Corner Road
P.O. Box 3030
Holmdel, NJ 07733-3030
Room HO3C-206
FAX 1-(908)-949-1342"


Xref: sparky comp.arch.bus.vmebus:112 comp.sys.sun.hardware:6492
From: els@icf.hrb.com (Eric L. Schott)
Newsgroups: comp.arch.bus.vmebus,comp.sys.sun.hardware
Subject: Re: Need address of Sky for VME Vector accelerator board.
Date: 23 Dec 92 16:35:27 GMT
Organization: HRB Systems, Inc.

In article <HCOBB.92Dec21124529@fly2.berkeley.edu>, hcobb@fly2.berkeley.edu (Henry J. Cobb) writes:
> 
> 	Or other open VME vector accelerator products.

Mercury and CSPI make competing products.  I have used both Sky and
Mercury.  The differences in raw CPU power are minimal.  However,
both have widely different OSs and VMEbus throughput rates.  Shop
with care in mind with your requirements.
-- 

Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  "As we acquire more knowledge, things do not become more comprehensible
   but more mysterious."                  Albert Schweitzer, "Paris Notes"
Newsgroups: comp.arch.bus.vmebus
From: martineau@MacMartineau.ccr.hydro.qc.ca (Alain Martineau)
Subject: double ethernet
Followup-To: comp.arch.bus.vmebus
Organization: Hydro Quebec
Date: Mon, 28 Dec 1992 13:05:56 GMT

I am looking for a VME system along with operating system that supports the
use of a dual redundant ethernet with TCP/IP or DECnet. Motorola CPU
preffered.

Alain Martineau
Hydro Quebec
amartineau@nccr.felix.hydro.qc.ca
Newsgroups: comp.arch.bus.vmebus
From: tanimori@kekvax.kek.ac.jp
Subject: Re: Looking for high-res timer board
Reply-To: tanimori@kekvax.kek.ac.jp
Organization:  KEK, Tsukuba, Japan
	<1992Dec18.165248.11076@ee.ubc.ca>
Date: Sun, 27 Dec 1992 07:18:08 GMT

In article <1992Dec18.165248.11076@ee.ubc.ca>, markm@ee.ubc.ca (mark milligan) writes...
>In article <9212171639.AA21526@stork.cs.rochester.edu>, bukys@cs.rochester.edu writes:
>> We're looking for a high-res VME timer board.
>> It will be stuck in a multiprocessor and will get frequent memory-mapped
>> reads from heavily instrumented code.  Therefore, the ideal candidate
>> would be something like:
>> 	32-bit counter, accessed D32.
>> 	No state to maintain between accesses (so I don't have to
>> 	make the multiple processors do mutual exclusion just to
>> 	look at the timer).
>> 
>> Alternatively, can anyone recommend a D32 VME prototype board
>> onto which we could paste our own counter circuit?
>> 
>> Liudvikas Bukys
>> bukys@cs.rochester.edu
> 
>We are using the XYCOM-085 VME prototype board. I only allows 16 bit 
>data accesses (A16/D16 and A24/D16) but is easy to use.
> 
>Contact Xycom at
> 
>750 North Maple Road
>Saline, Michigan 448176
>(313) 429-4971
From: miket@frog.CRDS.COM (Michael C Tiernan)
Newsgroups: comp.arch.bus.vmebus
Subject: Re: VME sources - VME Buyers Guide
Date: 24 Dec 92 14:24:35 GMT
Organization: Charles River Data Systems

aaron@blink.att.com (Aaron Chesir(x1530)) writes:
 > Folks,
 >	According to Cahner's Publishing, the VME Bus Buyer's Guide is no
 > longer being published. [...]

	There's always the VITA VME Compatible Products Directory for
	$44.95 from VITA, VFEA International Trade Association.

		VITA
		10229 North Scottsdale Road, Suite B
		Scottsdale, AZ.   85253
		P: (602) 951-8866

	Good luck.
-- 
<< MCT >>  Michael C Tiernan. - GEnie:M.Tiernan - AOL:M Tiernan/BCS Mike 
UUCP = alfalfa!pro-angmar!m.tiernan OR miket@frog.UUCP
      It's too bad that it takes almost half of our life
	to realize that it was a "Do-It-Yourself" project.
Newsgroups: comp.arch.bus.vmebus
From: michael@chg.mcd.mot.com (Michael Bodine)
Subject: Re: MVME410
Organization: Motorola Computer Group, Schaumburg, IL
Date: Tue, 22 Dec 1992 15:28:07 GMT

knowles@FNALO.FNAL.GOV writes:
>Is there anyone out there who might have a copy of the
>MVME410 users' manual?  I've spoken to my local MOTO
>sales office but they say its too old for them to
>have records on.
>...
>Worst comes to worst, does anyone know the parallel
>port pinouts?
Rick, sorry!  Some offices still have that manual, but someone took our
file copy in your local office and failed to return it.  Rather than
calling all over the country to find someone willing to stand at the Xerox
machine, here's your pinout:

Connector J1
Pin	Signal	Descr
1	PXCB2	INPUT PRIME low lvl output, clears print buffer and inits dvc
3	GND	
5	PXCB1	FAULT - low lvl in; paper empty, deselect, etc.
7,41,45,49	Reserved
9	PXPB7	
11	PXPB6	
13	PXPB5	
15	PXPB4	
17	PXPB3	
19	PXPB2	BUSY - input indicating printer cannot rcv data
21	PXPB1	OUT OF PAPER - hi lvl in
24	PXPB0	SELECT - hi lvl in
25	PXPA7	PD8 data out from PA7
27	PXPA6	PD7
29	PXPA5	PD6
31	PXPA4	PD5
33	PXPA3	PD4
35	PXPA2	PD3
37	PXPA1	PD2
39	PXPA0	PD1
43	PXCA2	DATA STROBE - output clocks data, active lo, 1 us wide
47	PXCA1	ACK - low lvl in, indicates character ready or end of op'n
8		No connect
All other evens	Ground

Note that the descriptions are based upon use of the parallel pins to
drive a Centronix-style printer port.  Based on the above and a simple
program to play with the PIA, you should be able to nail down everything
pretty simply.  The pinouts on the other connector are the same, but,
obviously, attached to the other PIA.
-- 
[  Michael Bodine, michael@chg.mcd.mot.com, Dial: (708) 576-7840, FAX: x8875  ]
[  Motorola TSD; Loc IL38; 1100 Woodfield; Suite 334;  Schaumburg, Il  60173  ]
Newsgroups: comp.arch.bus.vmebus
From: rld@well.sf.ca.us (Rick Davis)
Subject: Question regarding VME test platform
Summary: Off the shelf or roll your own?
Keywords: VME,embedded system,manufacturing
Organization: Whole Earth 'Lectronic Link
Date: Sat, 26 Dec 1992 20:29:45 GMT

  	I'd like to know what some of people's favorite platforms are
for 6-U VME board test setups.  There are a number of boards
out there set up to run VxWorks, PSOS, or other kernels
with complete networking support,SCSI ports, 
and embedded real-time OSs built in, while there are others which
are considerably less expensive, but offer progamming libraries and
sample applications to support software development albeit without
alot of the bells and whistles.   Which one more closely fits the 
needs of in-house board test? 
	While the integrated soloution may save development time,
it may be underutilized in a non-networked serial control sort
of environment, and may also have a long start-up time between
power cycles if a serial download and/or network boot is involoved.
On the other hand, if development support is available, the
lower priced board may be more closely suited to the needs of
manufacturing test, those being at least:
	1) ease of use
	2) low purchase cost
	3) PC control
	4) programmability
	5) all control in ROM.

Thanks for the comments in advance, and if there is interest I 
will summarize in early Jan. 

Sincerely;
Rick Davis



Xref: sparky comp.arch.bus.vmebus:109 comp.sys.sun.hardware:6451
From: hcobb@fly2.berkeley.edu (Henry J. Cobb)
Newsgroups: comp.arch.bus.vmebus,comp.sys.sun.hardware
Subject: Need address of Sky for VME Vector accelerator board.
Date: 21 Dec 92 12:45:29
Organization: /rubin/hcobb/.organization
NNTP-Posting-Host: fly2.berkeley.edu


	Or other open VME vector accelerator products.
--
	Henry J. Cobb	hcobb@fly2.berkeley.edu	SFB Tyrant
	"Once it becomes possible to do something, it gets very difficult to
undo it.  Whether its automobiles, computers or nuclear weapons, invention has
always been the mother of necessity."
Newsgroups: comp.arch,comp.dcom.lans,comp.dcom.servers,comp.client-server,comp.parallel
From: vrao@cse.uta.edu (Vinay Pundalika Rao)
Subject: Network Simulator for datalink protocols and routing algorithms
Apparently-To: comp-parallel@uunet.uu.net
Organization: Computer Science Engineering at the University of Texas at Arlington
Date: Tue, 22 Dec 1992 01:50:18 GMT


Hi Netters,
	I wanted a network simulator which allows me to change the
datalink,transport or network protocols and algorithms and watch the 
performance etc. I am looking for some public domain software that 
has these capabilities. 
        I will be grateful if you could kindly let me know of an existing
simulator and where to acquire it from.

Thanks in advance

Vinay Rao
(vrao@cse.uta.edu)


Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Xenix Support, FICC
Date: Thu, 24 Dec 1992 21:33:07 GMT

In article <BzrtBq.5FL@usenet.ucs.indiana.edu> mdchaney@fractal.ucs.indiana.edu (M Darrin Chaney) writes:
> I agree, but there is a bit to be said for the environment.  With a straight
> off the tape VMS system, you have a real editor,

Really? Where is it hiding? All I can find are EDT, EVE, and TECO. Are you
talking about TECO?
-- 
Peter da Silva                                            `-_-'
Ferranti International Controls Corporation                'U` 
Sugar Land, TX  77487-5012 USA
+1 713 274 5180                            "Zure otsoa besarkatu al duzu gaur?"
Newsgroups: comp.arch
From: alvitar@xavax.com (Phillip Harbison)
Subject: A reminder about posting to comp.arch (last mod 06/14/90)
Reply-To: alvitar@xavax.com (Phil Harbison)
Organization: Xavax
Date: Fri, 1 Jan 1993 08:00:03 GMT
Followup-To: poster
Summary: Stop, Think, Observe, Plan
Keywords: Netiquette

This article is posted monthly in the hope that it will encourage
proper use of comp.arch.  Your cooperation will help improve the
signal to noise ratio of comp.arch, making the newsgroup more
valuable to readers.

1) Consider using mail instead of posting a followup article.  If
   your response is of limited interest to anyone other than the
   author, then please use mail instead of posting a followup.  A
   mail message goes to a small number of machines, while an
   article consumes communication and storage resources at
   thousands of sites.

2) Exhaust local sources of information before posting a question
   to comp.arch.  It makes little sense to waste the communication
   and storage resources of thousands of sites, not to mention the
   time of thousands of comp.arch readers, when the answer to your
   question may be as close as your bookshelf.  Do read the manual.

3) If you raise new topics, make sure the subject corresponds to your
   comments.  However, do not needlessly change or amend the subject
   line, as some news readers allow a user to skip an entire thread
   based on the subject line.

4) Consider limiting the distribution of your article.  Announcements
   such as user group meetings may be of interest only to a limited
   geographic area.  Check with your local news administrator to see
   what regional or local distributions are available.

5) Quoting portions of the base article is encouraged.  It helps the
   reader to understand the context of your comments, especially if
   the reader has not read the base article.  However, you should
   include only as much of the base article as is necessary to convey
   the context of your comments.  Use an editor to remove unnecessary
   portions of the base article.

6) Make sure your article is related to computer architecture.

7) Computer nostalgia has a place on the net, but that place is not
   comp.arch.  If you are discussing architectural features of past
   generations of computers, then comp.arch is appropriate.  However,
   the prescribed place for computer nostalgia is alt.folklore.computers.

8) Sale advertisements and product announcements are not appropriate
   for comp.arch.  There are specific groups for these purposes.  Try
   misc.forsale, misc.forsale.computers, and comp.newprod.  Also, keep
   in mind that news articles are distributed by various services which
   forbid use for personal gain.  Sites which use these services often
   selected newsgroups such as comp.arch assuming a high information
   content and no personal gain use.  Please do not make their life
   more difficult by posting advertisements and product announcements.

-- 
*realName: Phil Harbison
*mailAddress: Xavax, PO Box 125, Shokan, NY 12481
*eMailAddress: alvitar@xavax.com
*phoneList: <home>: 914-657-8645  <work>: 914-385-2881
Newsgroups: comp.arch