HDTenEightyP/NetNews huggingface dataset:
From: preston@miranda.cs.rice.edu (Preston Briggs)
Subject: Re: 64 bit Alpha AXP -vs- 32 bit computers
Organization: Rice University, Houston
Date: Tue, 17 Nov 1992 17:14:19 GMT

kneuper@chpc.utexas.edu (Stephen Kneuper) writes:

>I'm trying to figure out why I want to go to a 64 bit machine Alpha
>AXP system instead of continuing to run 32 bit machines (RS6K, Sun).
>
>Outside of the numerical analysis issues,

Durn...  And after all the nice debate over 32x32 => 64.

Another nice use is to speed up bit-wise computation.
For example, many compilers do lots of data-flow analysis,
summarizing results in long bit vectors; say, O(1000) bit chunks.
It's surely faster to AND and OR these things 64 bits at a time,
not to mention the reduced fetches from cache.

Preston Briggs
Newsgroups: comp.arch
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Re: Registerless processor
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 17 Nov 1992 04:29:35 GMT

Darren R. Davis (drdavis@u.cc.utah.edu) wrote:
: I have been pondering an idea for a machine architecture.  A processor
: that has no registers.  I am familiar with some architectures that have
: done this.  My twist on this theme is to have a very large cache on chip
: for memory locations (effectivelly becoming registers).  This goes
: against the RISC idea of having very large register sets with load store
: instructions.  This machine would just reference memory, and the most
: common addresses becoming cached internally to the processor giving very
: fast access.  Does anyone know of such a machine, and what are your
: thoughts on this kind of architecture.  I envision the cache being

I have been thinking about this for some time now.
First, you have broken the law as stated by H&P book.
The major problem that you have to face is the large number of address bits,
required to access your data. 32-bit per operand is rather large.

To solve this you have 2 choices:

i) stacks,
ii) data compression,


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.arch
From: andy@research.canon.oz.au (Andy Newman)
Subject: Re: Re: DEC Alpha AXP System Performance
Organization: Canon Information Systems Research Australia
Date: Wed, 18 Nov 1992 23:53:03 GMT

cag@hpfcso.FC.HP.COM (Craig Gleason) writes:
>When are marketeers going to stop projecting the limits of what engineers
>can do, and just let us get on with doing it?
They'll stop when there's no money in it.
-- 
Andy Newman (andy@research.canon.oz.au)
Newsgroups: comp.arch
From: blair@snogum.enet.dec.com (Blair Phillips - Digital)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Reply-To: Blair.Phillips@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Wed, 18 Nov 1992 22:55:30 GMT


In article <1992Nov18.180357.3105@sparky.imd.sterling.com>, yankus@IMD.Sterling.COM (Mike Yankus) writes:
>
>In article <1992Nov16.231949.1214@ryn.mro4.dec.com> Blair.Phillips@cao.mts.dec.com writes:
>>
>> ...
>>Most real programs will use the runtime libraries for string manipulation, and
>>anyone serious about speed won't access single bytes very often, even on a VAX,
>>so trading off the byte access against cycle time is beneficial in almost all
>>cases except artificial benchmarks (e.g. Dhrystone).
>
>You are forgetting about a large volume of programs which mainly do
>nothing but character manipulation.  These include editors, compilers,
>mail handling, and the very programs which do the posting and reading
>of News.  I would consider a machine which does not have efficient
>character handling capability a step backwards of about 30 years.
>Is this really the case with the Alpha?
>--
The SPECmark benchmarks include the GNU C compiler compiling itself, and other
programs which do a lot of character manipulation. Alpha systems do very well
on these benchmarks.

The Dhrystone "benchmark" is almost entirely character manipulation, and is
small enough to fit in cache. It is close to the worst case for the Alpha
design decisions.

The Dhrystone MIPS numbers for various Alpha systems range from 134 to 202.2,
scaling very closely with the clock speed. I'm not sure how this compares with
HP and IBM.

However, if you write your own character manipulation code in C, and compile it
without optimization, you will probably get slower results than on another
architecture with similar performance and with byte load/store instructions.
Of course, right now, you can't buy another (microprocessor) machine with
similar performance...(HP is not shipping yet, I believe)
--
----------
Blair Phillips					Blair.Phillips@cao.mts.dec.com
Digital Equipment Corp (Aust) P/L		Phone: (+61 6) 2754874
Canberra, Australia				FAX  : (+61 6) 2473654
{Any opinions expressed are my own, not those of Digital Equipment Corporation}
From: cleary@cpsc.ucalgary.ca (John Cleary)
Newsgroups: comp.arch
Subject: Re: integer distance or sqrt
Summary: using table look-up helps
Date: 18 Nov 92 03:23:10 GMT
Organization: University of Calgary Computer Science

>bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
>> I first considered asking for a integer sqrt, but maybe if the context is
>> known a better answer can be given.  This program is normally run on a
>> machine with no floating point hardware so I would like to get rid of
>> floats entirely.
>
>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?
>
>Thanx,
>Cliff

Here at Calgary some years ago Geoff Wyvill greatly spedup the
'C" sqrt function on a Sun/3 by doing a table lookup on the high-order
16(approx) bits and then doing a single Newtons step.  This ran roughly
10 times faster than the standard one (less code too!!).  I presume
that a similar trick would work in this case.
-- 
John Cleary
University of Calgary.
cleary@cpsc.ucalgary.ca
Xref: sparky comp.arch:10764 comp.lang.misc:3704
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 13 Nov 92 14:40:57
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov5.202412.7266@linus.mitre.org>
	<1992Nov10.153705.27804@yrloc.ipsa.reuter.COM>
	<1992Nov12.131856.12605@linus.mitre.org>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: bs@gauss.mitre.org's message of Thu, 12 Nov 1992 13:18:56 GMT

bs@gauss.mitre.org writes:
> rbe@yrloc.ipsa.reuter.com writes:
> > Optimization before design is usually a bad idea. 
>
> Spouting aphorisms adds little to this discussion. Especially since you
> are assuming facts not in evidence. (i.e. you are assuming that the
> optimization came before the design).

What Rubin codes in the privacy of his own VAX is his own business.

But he is trying to use his code as an example to convince the rest of
us that we should pay for our computer manufacturers to incorporate
"get bit from bitsream" and "generate exponential rv" instructions,
and to add all sorts of bells and whistles to our programming
language. If he wants to make such an argument convincingly, he has
to write clear, readable code.

In fact anybody who wants to make such an argument to add hairy
features to a programming language in order to achieve higher
performance has to do more than just present a piece of code. He
really should present:

 * a straightforward, readable, clear implementation of the
   piece of code containing the alleged bottleneck so that
   people know what the problem is

 * a realistic (or at least believable) driver that uses the code

 * actual profiling information using the driver that demonstrates
   that the alleged bottleneck actually uses up a significant amount
   of time

 * some readable discussion, analysis, and evaluation of the results;

   in the case of hardware features, this should include:

   + a discussion of several known architectures, cycle times, cost of
     additional hardware/VLSI real estate, etc.;

   in the case of software features, this should include:

   + a discussion of why optimizers can't currently handle this case,

   + how the feature interacts with the optimizer--does it perhaps
     inhibit other optimizations?,

   + why other language constructs can't handle it,

   + statistics (or at least a believable argument) from actual
     programs that show that the feature is used frequently enough
     that it warrants incorporation into the language (occasional
     hacks can be put into assembly language),

   + considerations of syntax, considerations of scoping and
     referential transparency, etc.

Such a discussion serves to try to convince others not only that the
feature is worthwhile to consider, but also that the proponent has
actually the knowledge and experience to make an informed proposal.

Anything else is just handwaving and doesn't convince me.

					Thomas.
Xref: sparky comp.arch:10783 comp.lang.misc:3714
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 16 Nov 92 14:01:38
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: mbk@lyapunov.ucsd.edu's message of 16 Nov 1992 04:13:47 GMT

In article <1e775rINNslq@network.ucsd.edu> mbk@lyapunov.ucsd.edu (Matt Kennel) writes:

     Prof. Rubin wants to use a syntax which cannot be parsed with the
   "standard" tools of compiler contruction kits.  Think of 
   the old standbys "lex 'n' yacc"---he essentially wants something in
   which the "tables" themselves could somehow be altered using langauge
   statements.  Maybe the world doesn't revolve around statically generated
   context-free unambiguous grammars.

   Too many computer scientists think that "syntax is trivial" or "syntax
   is uninteresting", which it may be to the inside of a compiler, but isn't
   to ordinary users.

Far from it. In fact, a lot of research in computer science is
directed at coming up with ways of letting people specify syntax and
syntactic transformations as conveniently as possible. Reality is that
this is a hard problem. That's why there are only compromises
available.

The available compromises are the following:

 * Programming languages themselves nowadays only let you specify very
   limited syntactic extensions, because such extensions are difficult
   to scope properly (mind you, the computer and the parser have no
   problem with this, it is the humans that can't deal with it).  This
   isn't the result of some kind of "language fascism", but of market
   forces: languages that have allowed more general syntactic
   extensions simply never caught on, presumably because such
   extensions were causing more hassle than they were worth.

 * Some programming languages use limited syntax but allow very
   general transformations (e.g., Lisp macros).

 * There are a number of general-purpose tools for writing systems
   that perform syntactic transformations (yacc, TXL, Prolog, ...).
   Such systems let you express just about any syntax you might want
   to, but because they are so powerful, they are more difficult to
   use.

Now, there is certainly room for improvement, so if you don't like
what you are getting right now, maybe you can come up with something
better.

					Thomas.
Newsgroups: comp.arch
From: imohamme@ho08.eng.ua.edu (Imadulla S. Mohammed)
Subject: Re: gotos in hardware
Organization: The University of Alabama, Tuscaloosa
Date: Mon, 16 Nov 1992 05:05:15 GMT

Newsgroups: comp.arch
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
Summary: 
Expires: 
Followup-To: 
Distribution: 
Organization: The University of Alabama, Tuscaloosa
Keywords: 


Newsgroups: comp.arch
Subject: information about the Latest RISC chips 
Summary: 
Expires: 
Followup-To: imohamme@ho08.eng.ua.edu
Distribution: 
Organization: The University of Alabama, Tuscaloosa
Keywords: 

Hi

	I would like to have information about the latest SUN,HP and IBM Risc chips. If anybody knows where i can find the above information. Please send me an
email at the above address.  Any help will be appreciated


yours
imad
From: dmagagno@mcs.drexel.edu (David Magagnosc)
Newsgroups: comp.arch
Subject: Re: integer distance or sqrt
Date: 17 Nov 92 14:39:14 GMT
Organization: Drexel University

This reminds me of something I came up with not long after the
Midatlantic ACM Region Programming Contest last year.  One of the
problems involved computing square roots by the long division-like
method (which they claimed we all learned in elementary school).
I translated it to binary, applied the techniques used for division,
and came up with a sort of non-restoring square root.

Now, the convergence is linear (2 bits of input for 1 bit of output
per iteration), but it uses only elementary operations like shifts
and adds, so its run time should be comparable to a single division.
Newton's method, on the other hand, typically uses division on
every iteration.

So, the real question is, has someone done something like this before?
How does it really compare for smallish (under 32 or maybe even 64
bit) square roots?

Oh yes, it can also be extended very easily to compute fixed point
square roots of integers -- as many bits as you like.

D. Magagnosc
-- 
496620796F752063616E207265616420746869732C20796F752063616E206265636F6D65206120
636F6D70757465722070726F6772616D6D657220616E6420676574206120676F6F64206A6F622E
Newsgroups: comp.arch.storage
From: girling@cs.sfu.ca (Doug Girling)
Subject: RFI: CD ROM
Organization: CSS, Simon Fraser University, Burnaby, B.C., Canada
Date: Fri, 20 Nov 1992 23:34:54 GMT


Pre-appologies if there's a better newsgroup to post this to but...

I'm curious if there is a FAQ or if anyone here can direct me to a list of
publishers of the CD ROMs themselves?  Everyone who sells CD-ROM drives
offers a package deal on some subset of fairly generic and/or useful
CD-ROMs at time of purchase, but where to go from there for the more
obscure stuff?

Prethanks,
Doug
-- 
------------------------------------------------------------------------------
Doug Girling, Lab Engineer	  Voice: (604)291-4428  FAX:   (604)291-4951
(par escargot): School of Engineering Science, Simon Fraser University
     		Burnaby, B.C. V5A 1S6 CANADA
From: mike@starburst.umd.edu (Michael F. Santangelo)
Newsgroups: comp.arch.storage
Subject: Adaptec 1542B[K] Questions
Keywords: Adaptec
Date: 19 Nov 92 19:52:26 GMT


Being a supposedly tried and true PC SCSI controller that is universally
supported by '386 BSD UNIX systems, how good is this SCSI controller
really?  What SCSI controller chip does it use?  How smart is it (what
microprocessor does it use and what does it use it to do)?  What's the
upper limit on xfer rate?  How many I/Os can it do per/sec?  Also,
I have seen 1542B and 1542BK, any difference?

Thanks!
--
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.storage
From: keith@ksmith.uucp (Keith Smith)
Subject: Re: Query: Solid State SCSI Systems 
Organization: Keith's Computer, Hope Mills, NC
Date: Mon, 16 Nov 92 16:10:20 GMT

In article <1992Nov10.021022.14711@news.arc.nasa.gov> lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:
>In article <1992Nov9.203919.9793@nntpd.lkg.dec.com>, cassidy@esd55.enet.dec.com (Charlie Cassidy) writes:
>|> 
>|> We are showing the following products at COMDEX next week.  We also
>|> announced today the EF5x family of DSSI SSDs for Digital's VAX and ALPHA AXP 
>|> systems.  Please contact me or visit us at the Digital's OEM booth on the Comdex
>
>
>I guess this seems like an excessively "Commercial" posting for
>this newsgroup.  I think it belongs on biz.dec.announce, or

Perhaps, But Someone asked last week about who made SSD's so give 'em a
teensie break this time

So what is the average COST/MB on these guys, and where does it start?
-- 
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.storage
From: mdl@cypress.com (Matt Landrum)
Subject: R/W Optical Jukebox, primarily for archive and multi-site use
Organization: Cypress Semiconductor Southeast Design Center
Date: Wed, 18 Nov 1992 18:38:17 GMT

I need to purchase a r/w optical jukebox for use on a Sun network.
The primary purpose of this jukebox will be for archives.  The
secondary purpose is for cheaper, on-line storage.  For an optical
jukebox to be useful to us, it must have most (if not all) of the
following capabilities:

1) For purposes of archive, it should be possible to remove a disk or
disks, send them to one of our other sites, and have them placed
on-line in a jukebox ready to go.  So, it should also be easy for me
to walk up to the jukebox and grab the correct disks.  It is my
understanding that packages like AMASS can not provide this
capability.  If I can't find a system like this, I might as well buy a
high capacity tape drive, save my money, and sacrifice on-line access.

2) At minimum, directories should span both sides of the the media and
multiple disks.  It would be nice if files could as well.  For our
designs, 300 (or 500) Mb/side is not useful without this capability.

3) The filesystems on the optical media should be accessible across
the Sun network via NFS.  You should be able to use regular unix commands
to archive the data (tar, dump, cp, etc.)

3) There should be some sort of winchester cache to prevent mechanical
"thrashing" of the jukebox, and to speed read access through indexing.
I'd like the system to use my existing disk.

5) The jukebox shouldn't choke if I remove a disk (that isn't
mounted), place unformatted media on-line, or place write-protected
media on-line.

6) The system should be reliable.  It should have a fairly large
installed base with some satisfied users.

7) It would be nice if the system would allow multiple platters to be
mounted.


If I can find something that would satisfy number 1 and 6, I would
be happy.


thanks in advance
--matt
--


Matt Landrum                    | mdl@cypress.com
Cypress Southeast Design Center | office: (601) 324-4609, FAX - 4614
1 Research Blvd, Suite 200      | "There's a fine line between 
Starkville, MS  39759           |  stupid and clever" -- Spinal Tap


Newsgroups: comp.arch.storage
From: michelotto@vaxfpd.pd.infn.it (Michele Michelotto)
Subject: exabyte jukebox with random access (Exb10i)
Reply-To: michelot@dxcern.cern.ch
Organization: CERN - European Laboratory for Particle Physics
Date: Mon, 16 Nov 1992 11:03:10 GMT


Hello

I would like to use the Exabyte jukebox with random access on
Vaxstation 4000 using VMS and Decstation 5000/200 using Ultrix.
In the future I'll use Alpha workstations.

I would like to know if anybody is using this device and to know 
how it works.

I understodd that there is a device called Exb10 that cost
about 6000$ for sequential access to which you can add
an exabyte 8200 or 8500  drive.

If you want random access you spend other 1000$ to get an Exb10i

But then you must pay 3000$ for another board for Ultrix or
6000$ for a software on VMS to use it. How can it be?

--
						Ciao, Michele
******************************************************************************
* Michele Michelotto, INFN Padova, Delphi group.                             *
* Internet: michelot@dxcern.cern.ch     BITNET: MICHELOTTO@IPDINFN           *
* Tel (+39).49.844347                   HEPNET: VAXFPD::MICHELOTTO           *
*                     "Ho bevuto CHE COSA ?"   (Socrate)                     *
******************************************************************************
Newsgroups: comp.arch.storage
From: torre@mom (Patrick Torre)
Subject: LBA modes on IDE drives? 
Organization: Computone Corp., Roswell, GA, USA
Date: Fri, 20 Nov 92 19:07:35 GMT


I'm trying to find an IDE drive that supports LBA addressing mode.
Do any of the popular (cheap) drives support this mode?

(this is from the ATA spec.)

)A drive can operate in either of two addressing modes, CHS or LBA, on a 
)command by command basis. A drive which can support LBA mode indicates this in 
)the Identify Drive Information. If the host selects LBA mode in the Drive/Head 
)register, Sector Number, Cylinder Low, Cylinder High and HS3-HS0 of the 
)Drive/Head Register contains the zero based-LBA.
)
)In LBA mode, the sectors on the drive are assumed to be linearly mapped with 
)an Inital definition of:
)
)        LBA 0 = Cylinder 0/Head 0/Sector 1.
)
)Irrespective of translate mode geometry set by the host, the LBA address of a 
)given sector does not change:
)
)  LBA = [ (Cylinder * No of Heads + Heads) * Sectors/Track ] + (Sector-1) 
)
)


Any help will be appreciated,
Pat

Newsgroups: comp.arch.storage
From: michelotto@vaxfpd.pd.infn.it (Michele Michelotto)
Subject: Re: exabyte jukebox with random access (Exb10i)
Followup-To: comp.os.vms,vmsnet.misc
Reply-To: michelot@dxcern.cern.ch
Organization: CERN - European Laboratory for Particle Physics
Date: Mon, 16 Nov 1992 12:43:56 GMT



Hello

I would like to use the Exabyte jukebox with random access on
Vaxstation 4000 using VMS and Decstation 5000/200 using Ultrix.
In the future I'll use Alpha workstations.

I would like to know if anybody is using this device and to know 
how it works.

I understodd that there is a device called Exb10 that cost
about 6000$ for sequential access to which you can add
an exabyte 8200 or 8500  drive.

If you want random access you spend other 1000$ to get an Exb10i

But then you must pay 3000$ for another board for Ultrix or
6000$ for a software on VMS to use it. How can it be?

I'm mainly interested in a solution for VMS, but may be I'll forced to
use a U**x workstation to do the job.
						Ciao, Michele
******************************************************************************
* Michele Michelotto, INFN Padova, Delphi group.                             *
* Internet: michelot@dxcern.cern.ch     BITNET: MICHELOTTO@IPDINFN           *
* Tel (+39).49.844347                   HEPNET: VAXFPD::MICHELOTTO           *
*                     "Ho bevuto CHE COSA ?"   (Socrate)                     *
******************************************************************************
Newsgroups: comp.arch