HDTenEightyP/NetNews huggingface dataset:
From: endecotp@cs.man.ac.uk (PB Endecott (PhD SFurber))
Newsgroups: comp.arch
Subject: Statistics for data dependencies needed
Date: 17 Nov 92 12:51:54 GMT

I'm looking for statistics about what proportion of instructions use as
operands the results of immediately preceding instructions, preferably for
optimally reordered code and subdivided into loads and computes.  I want to
compute the benefit of various forms of register forwarding.

Does anyone have these figures, or references to where I can find them ?

Many thanks,

--Phil.
From: walter@zarquon.Eng.Sun.COM (Walter Bays)
Newsgroups: comp.arch
Subject: Re: Fujitsu VPP500 vector parallel machine
Date: 16 Nov 1992 17:26:52 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: walter@zarquon.Eng.Sun.COM
NNTP-Posting-Host: zarquon

In article 1473@news.media.mit.edu, elwin@maidavale.media.mit.edu (Lee W Campbell) writes:
>How does it do on benchmarks like big linpacks, or preferably, SPECrate?
>Is Fujitsu a member of SPEC?

Yes, they are a member, though they have not published results to date.

---
Walter Bays                                         walter.bays@eng.sun.com
Sun Microsystems,  2550 Garcia Ave.,  MTV15-404,  Mountain View,  CA  94043
(415) 336-3689     SPEC Steering Committee Chairman      FAX (415) 968-4873
From: kaiser@mammal.vbo.dec.com (Peter Kaiser)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 22 Nov 92 11:05:35 GMT
Reply-To: kaiser@uniriv.vbo.dec.com
Organization: DEC Technology Integration Group


--
In article <1992Nov22.043852.764@megadata.mega.oz.au>,
andrew@megadata.mega.oz.au (Andrew McRae) writes:

> If it looks like microcode, smells like microcode ... Why call it PALcode?

Because it isn't microcode: it's the same instruction set, operating under
slightly different conditions.  A car driving down a road in a snowstorm
still isn't a snowplow.

> (`A rose is a rose by any other name'?)

Back to your Shakespeare to check this quotation, Andrew: "That which we
call a rose by any other name would smell as sweet." :-)

___Pete

kaiser@uniriv.vbo.dec.com
+33 92.95.62.97, FAX +33 92.95.52.00
Newsgroups: comp.arch
From: hamilton@robin.rtp.dg.com (Eric Hamilton)
Subject: Re: Hardware Support for Numeric Algorithms
Date: Thu, 19 Nov 92 14:25:40 GMT
Organization: Data General Corporation, Research Triangle Park, NC

In article <1992Nov17.203633.23955@sei.cmu.edu>, firth@sei.cmu.edu (Robert Firth) writes:

|> list all the problems!  What I'd like to add, though, is the comment
|> that, in most of the situations where C got it wrong, its predecessor,
|> BCPL, got it right...
|> 
Demonstrating, once again, that ornamentation is dangerous.

-- 
----------------------------------------------------------------------
Eric Hamilton				+1 919 248 6172
Data General Corporation		hamilton@dg-rtp.rtp.dg.com
62 Alexander Drive			...!mcnc!rti!xyzzy!hamilton
Research Triangle Park, NC  27709, USA
Newsgroups: comp.arch
From: chris@suite.sw.oz.au (Chris Maltby)
Subject: Re: DEC Alpha AXP System Performance
Organization: Softway Pty Ltd
Date: 19 Nov 92 05:26:24 GMT

Volker Herminghaus-Shirai writes:

>Alan Watson writes:
>> Nah, the real reason is that European computers run 16% slower because
>> European power arrives at 50 Hz, as opposed to 60 Hz over here. 
>
>But at 220 Volts vs. 110 in the US, we can execute two instructions
>simultaneously ;-)

Yes, not only two instructions, but you get 20% more time between clocks
to do useful work (:-). Thus a total of 240% faster! Of course, in
Australia we use 240V, which adds a wee bit more..

Chris
-- 
Chris Maltby - Softway Pty Ltd		Internet: chris@softway.sw.oz.au

PHONE:	+61-2-698-2322	"I'm waiting for X-Windows to become just that;
FAX:	+61-2-699-9174	 Ex-Windows" - A McGrath.
Newsgroups: comp.arch
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: Re: integer distance or sqrt
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Mon, 16 Nov 1992 11:01:02 GMT

In article <CLIFFC.92Nov15184340@miranda.rice.edu> cliffc@rice.edu (Cliff  
Click) writes:
> bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
> > I first considered asking for a integer sqrt, but maybe if the context is 
> 
> I sent him an integer square root code using Newton's Method.  I've done 
> this problem before and I'm sure there are better methods out there.  Does 
> somebody want to post/email something better than Newton's?

Try this one:

Heron(x)   {Fast integer squareroot routine}
   IF x <= 64 THEN
      y = 2 + (x >> 3)  {shift right 3 times}
   ELSE
      IF x <= 1024 THEN
         y = 8 + (x >> 5)
      ELSE
         IF x <= 8192 THEN
            y = 32 + (x >> 7)
         ELSE
            IF x <= 32767 THEN
               y = 64 + (x >> 8)
            ELSE
               y = 128 + (x >> 9)
            ENDIF
         ENDIF
      ENDIF
   ENDIF
   root := (y + x DIV y) >> 1

This algorithm is faster than Newton's Method, as it only
consists of compares, adds and shifts, and no loops :) Oh
yes, and a single integer division.

I found it some years ago in a german magazine called "MC."
It was dubbed "Heron's Algorithm." As you can see it is a
16 bit implementation. Does anybody have further information
about this algorithm? (like, how to extend it to 32 bits.)

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Date: Fri, 20 Nov 1992 17:01:10 GMT
Organization: School of Computer Science, Carnegie Mellon


woodacre@mips.com (Michael Woodacre) writes:
	[ in reference to PALcode ]
>Can you explain how this is different from kernel code with interrupts
>disabled on any other risc processor?

Think of it as a supervisor state. This state doesn't just have
interrupts disabled:  it also has direct access to a large variety of
implementation-specific internal registers. For example, TLB reloads
are done by PALcode, whereas the "normal" code in the OS need only
know architectural things (things that remain constant across
implementations). 

Also, PALcode can be entered from user state - you don't need to do a
system call, with its heavy-duty state-change overheads.
-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
Newsgroups: comp.arch,comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Purdue University Statistics Department
Date: Sun, 22 Nov 1992 13:38:51 GMT

In article <7958@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
>In article <TMB.92Nov20140542@arolla.idiap.ch> tmb@idiap.ch writes:
> > I think it might well be worth trying to standardize an interface to
> > arithmetic that provides you with access to the low-level arithmetic
> > primitives that you need. However, in order to make your code truly
> > portable, you will need to come up with an interface that takes into
> > account that there are machines with odd word sizes. Such a facility
> > needs to have a much more abstract and much more task-specific than a
> > general facility for accessing "low-level features". That is precisely
> > why I think that Rubin and Silverman are barking up the wrong tree.

	[Excellent discussion by Dik Winter of some of the problems deleted.]

>As I said, I do not know what the real solution is, it is certainly not
>as clear-cut as Herman thinks.

I never said that the solution is clear-cut.  I do not think we are 
anywhere near a passable solution.  What others and I, looking at this
problem, have suggested is that improved access to the hardware, and 
improved means of communicating to the compilers, assemblers, etc., 
be provided, with as much flexibility as possible.  

Since the problem is that complicated, the means of communication must be
greatly enhanced.  My suggestion for a versatile macro processor has not,
as far as I can tell, been met by what has been suggested.  The macro
processor I have in mind is one where I can write out a transformation,
describe it, and you can take my description, modify it slightly to your
environment, and implement it in your production of code.

Full efficiency of code can be attained by hand-optimization, with whatever
aid one can get from computers, for a given machine.  But there are aspects
of a program which are at least partially portable, and certainly more 
comprehensible in some other form than assembler, especially the current
assemblers.  The improvements can only be made incrementally, and whenever
some aspect of the problem is considered, complications are likely to arise.


-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)
Newsgroups: comp.arch.bus.vmebus
From: murphyn@rtsg.mot.com (Neal P. Murphy)
Subject: Re: vmebus ethernet boards
Keywords: vme ethernet
Organization: Motorola Inc., Cellular Infrastructure Group
Date: Sat, 21 Nov 1992 20:10:15 GMT

pusateri@duke.cs.duke.edu (Thomas Pusateri) writes:

>I am looking for vmebus ethernet boards. I know of the motorola
>mvme330. Anyone know of any others?

There is the MVME374, that runs up to ~300kB/s. A newer one is the
MVME376 (Interphase Hawk?) that runs up to maybe 500kB/s.

An alternative would be to use the MVME147 CPU with on-board Ethernet
and SCSI. This Ethernet interface runs up to ~250kB/s. The newer
Motorola CPU boards (MVME167, '040, and MVME187, 88100) also have
on-board SCSI-II and Ethernet and can drive Ethernet at up to 645kB/s
(over a TCP/IP socket).

The 374 and 147 have been available for a while, so you might be
able to find them used at a reasonable price.

The 376, 167 and 187 boards are newer, faster and likely harder to
find used, and probably would cost more than a student can afford.

NPN
Newsgroups: comp.arch.bus.vmebus
From: cipolla@seiko.enet.dec.com (Bruno Cipolla)
Subject: Parallel interface for Fbus+ needed
Organization: Digital Equipment Corporation
Date: Fri, 20 Nov 1992 16:49:30 GMT

I'm looking for a parallel board for the Futurebus+, we need to 
get 10-15 Mbytes/sec onto a Cobra (DEC 4000/600 Alpha)

can anyone help me??

Bruno 
Newsgroups: comp.arch.bus.vmebus
From: harry@neuron6.jpl.nasa.gov (Harry Langenbacher)
Subject: vme bus i/o speed question
Summary: how does vme speed compare to isa (in a sun 3/160)
Keywords: speed isa
Organization: JPL Pasadena CA
Date: Sat, 21 Nov 1992 00:18:25 GMT

I have to build a "neural-net co-processor" board that will
plug into a sun 3/160 VME back-plane. My consultant says that
the VME bus i/o rates will be slower than on an 8mhz ISA (pc-at) bus
(which is ~8 Mb/sec), because the sun 3/160 won't support burst mode
VME transfers.

How fast can I transfer data w/o burst mode on the VME bus ?
(Obviously I'm looking for ballpark figures.)

What computers (esp. sun) can do VME i/o faster (burst mode?) ?

I built a VME card before, and it worked fine, but I was never
concerned about the data throughput. I switched to ISA bus cards
because it seemed simpler, and because PC-clones are so cheap and
everyone has one, and proto-cards are so easy to get, but now my
sponsor wants VME cards, so ...

	Thanks for reading,
			Harry
-- 
Harry Langenbacher 818-354-9513 harry%neuron6@jpl-mil.jpl.nasa.gov
Concurrent Processing Devices Group, FAX 818-393-4540
JPL,  M/S 302-231, 4800 Oak Grove Dr, Pasadena CA 91109        USA
Newsgroups: comp.arch.bus.vmebus
From: jartsu@vipu.hut.fi (Jartsu)
Subject: Re: vmebus
Followup-To: comp.arch.bus.vmebus
Reply-To: Jari.Lehto@hut.fi
Organization: Helsinki University of Technology, Finland
Date: Sat, 21 Nov 1992 02:29:34 GMT

In article <yatesbd-191192204110@pharm15.med.upenn.edu> yatesbd@pharm.med.upenn.edu (Brian Yates) writes:

> What kind of machines (mainframes, microcomputers) commonly use VMEbus, and
> what OS's are best suited to the 68000 series in this architecture?

Atari TT and MegaSTE have VMEbus. At least with TT, main applications
are hi-end graphics-adapters, TCP-IP interfaces, multiport serial
interfaces and similar.

--
*******************   "Jartsu"   **********************
***********   Jari                 Lehto   ************
****************   "I hate MS-DOS"   ******************
*****   Finger jartsu@vipu.hut.fi for more info   *****
Newsgroups: comp.arch.bus.vmebus
From: schultz@halley.est.3m.com (John C. Schultz)
Subject: Re: vmebus
Followup-To: comp.arch.bus.vmebus
In-reply-to: yatesbd@pharm.med.upenn.edu's message of 20 Nov 92 01:42:27 GMT
Organization: 3M Company, 3M Center, Minnesota, USA
Date: Sat, 21 Nov 92 22:00:26 GMT

most bus extender companies can translate about any bus to VME.  For
example Bit 3 and Performance Technologies both make ? to VME
convertors. 
--
   John C. Schultz   +1 (612) 733-4047   schultz@halley.serc.3m.com
   How to include the taste of Glendronach in a multi-media system?
From: dstewart+@cs.cmu.edu (David B Stewart)
Newsgroups: comp.arch.bus.vmebus
Subject: Re: vmebus
Date: 22 Nov 92 19:14:57 GMT
Article-I.D.: cs.By4tGx.7u6.1
Organization: The Robotics Institute, Carnegie Mellon University

In article <7gqq1mn@quantum.on.ca> danh@quantum.on.ca (Dan Hildebrand) writes:
>In article <k2.722425529@woodstock> k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
>I've heard from some sources that 486-based VME boards are becoming more
>popular than the 680x0-based boards for a number of reasons. The reasons I've
>heard relate to a 486/66 outperforming the 68040, the boards being less
>expensive because of being able to use commodity gate arrays from the PC
>world, and having a wider software base to draw from.
>
>Can anyone confirm or refute this ?
>
>What are the comments from people using 486-VME boards ?

I don't like using any processor that does not use the big-endian format, which
is the endian format of the VMEbus.  

Although I have not used the 486-VMEbus boards, I have used other CPU boards
which use the same endian format of the 486.  I have yet to see a VMEbus board
which uses little endian format to work completely transparently over the
VMEbus, thus eliminating the need for byte swapping in software.  Generally,
these boards will perform some amount of byte swapping in hardware, but if you
use transfers of multiple sizes, then it doesn't work.  For example, the board
might do 32-bit byte swaps in hardware; however, if you are transferring a
string (i.e. byte-transfers), but to speed up the transfer you group these
strings into 32-bit unsigneds, then you must do the byte swap in software.
This is a big software pain, as you can no longer use data-type-independent
transfer mechanisms (e.g.  bcopy or DMA).  Instead, your copy mechanism must be
aware of the type of each piece of data, and perform any byte or word swapping
whenever necessary.  This also reduces your performance dramatically, as almost
every data item now has software overhead associated with it.  The performance
impact is especially severe multiprocessor applications which rely heavily on
interprocessor communication over the VMEbus.

Unless someone can give me a solution that makes this byte swapping issue
completely transparent and without loss of performance (I have yet to see such
a solution), I would much prefer sacrificing performance, and use an MC68040
which gives me no such software headaches.

If I really wanted more performance on a VMEbus, then I think a better choice
would be to go with something like the SPARC-II or 88000, which both have the
same endian format as the VMEbus.  These are just as fast or faster than the
486, and they do not cause a software nightmare in communication code.

~dave

-------------------------------------------------------------------------------
David B. Stewart  - email: <dstewart@cmu.edu>            The Robotics Institute
snail mail:       - ECE Dept., Carnegie Mellon University, Pittsburgh, PA 15213
Current Projects: - Chimera 3.0 Real-Time Operating System
		  - Reconfigurable Sensor-Based Control Systems
Newsgroups: comp.arch.bus.vmebus
From: danh@quantum.on.ca (Dan Hildebrand)
Subject: Re: vmebus
Date: Sun, 22 Nov 92 14:56:57 GMT
Organization: Quantum Software Systems

In article <k2.722425529@woodstock> k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
>There are also some systems from MIPS, and CDC with VME Bus.

I've heard from some sources that 486-based VME boards are becoming more
popular than the 680x0-based boards for a number of reasons. The reasons I've
heard relate to a 486/66 outperforming the 68040, the boards being less
expensive because of being able to use commodity gate arrays from the PC
world, and having a wider software base to draw from.

Can anyone confirm or refute this ?

What are the comments from people using 486-VME boards ?



-- 
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8
Newsgroups: comp.arch.bus.vmebus
From: skwong@cuse1.se.cuhk.hk (Wong Sai Kee (Graduate Assistant))
Subject: Re: quick question
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Distribution: usa
Date: Sun, 22 Nov 1992 14:10:47 GMT

lark@solbourne.com (Daniel Larkin) writes:



>Hello,

>A quick question; what does VME stand for?
Something like :- Versa Module Europe card profile.
skwong@se.cuhk.hk
Newsgroups: comp.arch.bus.vmebus
From: alexs@microware.com (Alex Stagg)
Subject: Re: vmebus ethernet boards
Keywords: vme ethernet
Organization: Microware Systems Corp., Des Moines, Iowa
Date: Mon, 23 Nov 1992 16:12:45 GMT

In article <murphyn.722376615@marble>, murphyn@rtsg.mot.com (Neal P. Murphy) writes:
...
|> The 374 and 147 have been available for a while, so you might be
|> able to find them used at a reasonable price.
...

If anyone has any used MVME147 cards for sale, I would be interested 
in hearing about it.

Alex Stagg, Microware Systems Corporation
alexs@microware.com - 515/224-1929
Newsgroups: comp.arch.bus.vmebus
From: walker@superboy.jsc.nasa.gov (Cybernetic Samurai)
Subject: Re: quick question
Reply-To: walker@superboy.jsc.nasa.gov
Organization: NASA Johnson Space Center
Distribution: usa
Date: Fri, 20 Nov 1992 14:56:29 GMT

In article <1eiqbaINNobi@stan.Solbourne.COM>, lark@solbourne.com (Daniel Larkin) writes:
|> 
|> 
|> Hello,
|> 
|> A quick question; what does VME stand for?


Since this is sure to be a FAQ, and I have found that there are few who
know this I am responding by posst rrather than e-mail.

VME = Versa Module European

-- 
Doug                   

Ask not what your country can do for you, but what you can 
do for your country.  - JFK
From: gold@saturn.sdsu.edu (Dan Gold)
Newsgroups: comp.arch.bus.vmebus
Subject: Re: vmebus ethernet boards
Date: 20 Nov 92 20:24:22 GMT
Organization: San Diego State University, College of Sciences
NNTP-Posting-Host: saturn.sdsu.edu
X-Newsreader: TIN [version 1.1 PL7]

Thomas Pusateri (pusateri@duke.cs.duke.edu) wrote:
: I am looking for vmebus ethernet boards. I know of the motorola
: mvme330. Anyone know of any others?
: 
: I would prefer to buy them used since I am still a student.

Sure, just about every major VME vendor makes them.
The mvme330 is really the old CMC ENP-10, you could talk to CMC
and see if the price is any different than Mot.  Also look
at the mvme376, Mot's model for the Interphase v/3207 Hawk
dumb ethernet card.  I think Interphase sells them for about $1500.00
or so.

Those are just a couple, don't forget SBE, Formation, PEP etc...
Best bet would be to consult your local VMEbus product guide
or call your local rep and see what they sell. And of course 
cocomp.sys.m68k sometimes has stuff for sale...m

     Dan

usual disclaimer to all above applies...
Newsgroups: comp.arch.bus.vmebus
From: heiby@chg.mcd.mot.com (Ron Heiby)
Subject: Re: vmebus
Organization: Motorola Computer Group, Schaumburg, IL
Date: Fri, 20 Nov 1992 16:35:10 GMT

yatesbd@pharm.med.upenn.edu (Brian Yates) writes:

>What kind of machines (mainframes, microcomputers) commonly use VMEbus, and
>what OS's are best suited to the 68000 series in this architecture?

The Motorola Computer Group produces a full line of VMEbus based
computers using the MC68000 family and MC88000 family processor
architectures.  These are available with various enclosures with 3, 6,
12, and 20 VMEbus slots.  These systems are used in office
environments (handling electronic communications, software
development, document preperation, etc.), on the factory floor, and
embedded into other products (like medical imaging systems and postal
sorting equipment).

On the 68K architecture, we provide UNIX System V Release 3 operating
system software and our VMEexec real-time multi-processing
environment.

On the 88K architecture, we provide UNIX System V Release 3.2, UNIX
System V Release 4 MP, and VMEexec software.

Third-party software vendors provide other operating system software
(mostly real-time kernels, mostly 68K), libraries, and application
packages.

Whether to use a UNIX-based OS or a real-time OS depends on your
application.  Some of our customers use both, having a cpu in the
chassis running UNIX and one or more cpus in the chassis and/or in
other chassis running a real-time kernel (like that provided by
VMEexec).  You can get pretty wild with the flexibility of
configuration possible with an IEEE standard bus like that provided by
VMEbus (ANSI/IEEE Std 1014-1987).
-- 
Ron Heiby, heiby@chg.mcd.mot.com	Moderator: comp.newprod
"The centipede has a thousand legs, but he cannot tapdance."
Newsgroups: comp.arch.bus.vmebus
From: walker@superboy.jsc.nasa.gov (Cybernetic Samurai)
Subject: VME = Versa Module Eurocard 
Reply-To: walker@superboy.jsc.nasa.gov
Organization: NASA Johnson Space Center
Date: Mon, 23 Nov 1992 14:09:27 GMT


I stand corrected.

-- 
Doug                   

Ask not what your country can do for you, but what you can 
do for your country.  - JFK
From: philb@cats.ucsc.edu (Philip Brown)
Newsgroups: comp.arch.bus.vmebus
Subject: Re: vmebus
Date: 21 Nov 92 20:13:48 GMT
Organization: University of California, Santa Cruz
NNTP-Posting-Host: si.ucsc.edu


jartsu@vipu.hut.fi (Jartsu) writes:

>In article <yatesbd-191192204110@pharm15.med.upenn.edu> yatesbd@pharm.med.upenn.edu (Brian Yates) writes:

>> What kind of machines (mainframes, microcomputers) commonly use VMEbus, and
>> what OS's are best suited to the 68000 series in this architecture?

>Atari TT and MegaSTE have VMEbus. At least with TT, main applications
>are hi-end graphics-adapters, TCP-IP interfaces, multiport serial
>interfaces and similar.



Gee., no-one's mentioned SUN yet!!! I suppose this is because their new
lines use their "SBus". but the old sun 3 line uses a VME bus. and they
are still putting out recent versions of SunOS for it. last I checked,
they definately has SunOS 4.1.1 for the sun3

-- 
  --------------------------------------------------
"How do I love sea? Let me count the waves.." |philb@cats.ucsc.edu
P.Anthony, "The Colo(u)r of her panties"      |philb@soda.berkeley.edu
Newsgroups: comp.arch.bus.vmebus