HDTenEightyP/NetNews huggingface dataset:
From: dcp78804@csie.nctu.edu.tw (78.10.11-82.8.7)
Subject: Ask for detail information about ALPHA AXP ...
Organization: Computer Science & Information Engin., Chiao-Tung U, Taiwan, ROC
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 19 Nov 1992 02:09:24 GMT


Dear Everybody,

	Can anyone post (or email to me) the more detail information or
	description about DEC Alpha AXP systems and SUN SPARCstation 10?
	Show me where to get these information, otherwise.  Thanks in
	advance.

	Information required includes:
	. architecture description, such as number of processors, cache
	  sizes, ...
	. performance measures, such as peak performance, sustained
	  performance, SPECsuite measures, ...
	. more and more, if you have.

	Thanks again.
--
--------------------------------------------------------------------------
NAME	Yuh-Horng Shiau
EMAIL	dcp78804@csunix.csie.nctu.edu.tw
SNAIL	Institute of Computer Science and Information Engineering
	National Chiao Tung Uni., Hsinchu, Taiwan 30050, Republic of China
PHONE	886-35-712121 ext 3740
--------------------------------------------------------------------------
Newsgroups: comp.arch
From: gerhard@netmbx.netmbx.de (Gerhard Hoffmann)
Subject: Re: DEC Alpha architecture issues
Organization: netmbx, Berlin, Germany
Date: Mon, 23 Nov 1992 04:42:26 GMT


In article <By4pEI.8r5.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>andrew@megadata.mega.oz.au (Andrew McRae) writes:
>>If it looks like microcode, smells like microcode ... Why call it PALcode?
>
>Because it doesn't even vaguely resemble microcode.
>
>- PALcode is fetched from the I-cache, not from ROM.

This doesn't mean anything. Early low-end /360 machines had their 
microcode in main store, and still it was microcode.

>....

#  Gerhard Hoffmann            #     phone: +49  30  782 02 33             #
#  Gleditschstr. 79            #     fax:   +49  30  782 02 63             #
#  D1000-62 Berlin, Germany    #     on the air:  dk4xp                    #
#  gerhard@netmbx              #     in the air:  D-1441 , D-KICK          #
-- 
#  Gerhard Hoffmann            #     phone: +49  30  782 02 33                 #
#  Gleditschstr. 79            #     fax:   +49  30  782 02 63                 #
#  D1000-62 Berlin, Germany    #     on the air:  dk4xp                        #
#  gerhard@netmbx              #     in the air:  D-1441                       #
Newsgroups: comp.arch
From: odkahn@eos.ncsu.edu (OPHER DANIEL KAHN)
Subject: Hardware support for atomic operations ?
Organization: North Carolina State University, Project Eos
Date: Sat, 21 Nov 1992 17:31:46 GMT

I am interested in primitives that support mutual exclusion in hardware, such
as the Test-And-Set and Swap instructions which are atomic.  I am especially
interested in any such new primitives that may have been developed in the
last few years.  If you know of any good references I would appreciate
some e-mail!
-- 
 Opher D. Kahn 
Xref: sparky comp.arch:10957 comp.lang.misc:3811
From: peter@ferranti.com (peter da silva)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Xenix Support, FICC
Date: Mon, 16 Nov 1992 22:34:50 GMT

In article <Bxr8vG.IpI@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
> There are many macro processors out which at least handle some
> problems with macro name first, but apart from compilers, I know of none
> which would allow someone to write (Bob Silverman's notation) 

> 	c = a ** b

> and have it translated into 

> 	c = doubmult(a,b).

The macro language used in Jeffrey Kingston's text formatting package "LOUT"
can do the trick, though it seems to be pretty tightly coupled to the text
package. I don't know his current net address, but the Lout documentation
gives:

	Jeffrey H. Kingston
	Basser Department of Computer Science
	University of Sydney 2006
	Australia

Or you could try mailing postmaster@basser.{edu,oz}.au...
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
From: sproven@cs.strath.ac.uk (Simon B Proven IE91)
Newsgroups: comp.arch
Subject: Re: integer distance or sqrt
Date: 18 Nov 92 15:39:17 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <1992Nov17.143914.19700@mcs.drexel.edu> dmagagno@mcs.drexel.edu (David Magagnosc) writes:
>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?

I wrote a FP library last year on the ARM(2/3) and tried both the Newton
method and the long division type method.  With a good approximation from
the Newton method I was getting 6,000 or so sqrts per second on an 8MHz
ARM2.  My implementation of the long-division type algorithm got about
30,000 sqrts per second.

QED? :)

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

Yes - in the fp library, the routine gets 24 bits of output from 24 bits
of input, by assuming that there are another 24 0s tagged onto the input.

>
>D. Magagnosc
>-- 
>496620796F752063616E207265616420746869732C20796F752063616E206265636F6D65206120
>636F6D70757465722070726F6772616D6D657220616E6420676574206120676F6F64206A6F622E

mad@bike
-- 
* Simon Proven -  Secretary, University of Strathclyde Green Group *
* sproven@cs.strath.ac.uk             REAL (tm) peeps ride bike :) *
Newsgroups: comp.arch
From: murphy@rock.enet.dec.com ()
Subject: Re: DEC Alpha architecture issues
Reply-To: murphy@rock.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Mon, 23 Nov 1992 22:04:30 GMT


In article <1992Nov23.180432.26829@ryn.mro4.dec.com>, bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
|> Newsgroups: comp.arch
|> Path: ryn.mro4.dec.com!wrksys.enet.dec.com!bhandarkar
|> From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
|> Subject: Re: DEC Alpha architecture issues
|> Message-ID: <1992Nov23.180432.26829@ryn.mro4.dec.com>
|> Sender: news@ryn.mro4.dec.com (USENET News System)
|> Organization: Digital Equipment Corporation
|> References: <1992Nov19.204209.6619@nntpd.lkg.dec.com> <DOCONNOR.92Nov20095251@potato.sedona.intel.com> <1992Nov20.183610.12796@crl.dec.com>
|> Date: 23 NOV 92 13:04:41    
|> 
|> 
|> >In article <DOCONNOR.92Nov20095251@potato.sedona.intel.com> doconnor@sedona.intel.com (Dennis O'Connor) writes:
|> >>
|> >>Sounds like a microcoded instruction to me. Except, of course, that
|> >>there's no guarantee of what PALcodes are available on a particular
|> >>system, and that the microcode may be external to the chip.

PALcode works very similar to the BIOS routines in the IBM PC.  Macrocode that
handles traps and special operations etc...

Murph
From: dan@cae.prds.cdx.mot.com (Dan Breslau)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: none
Date: Wed, 18 Nov 1992 16:50:04 GMT

hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

>In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>>In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>> But it is.  The operations often use register arguments and the results
>>> are wanted in registers.

>>What's a register? Most modern compilers ignore "register", or use it as a
>>hint "this is a frequently used value".

>Maybe that is one reason for such poor object code.  Most modern architectures
>REQUIRE that arguments are in registers.  This should be well known; no matter
>how well loads or stores can be integrated into the code, they certainly add
>an instruction issue.

>So, assuming that addition takes one cycle, a = b + c takes one cycle if
>only registers are used, but four cycles otherwise.

[...]

>An include file should be considered as part of the program.  The programmer
>decides explicitly which ones to include.  By a subroutine, I normally mean
>one compiled separately, and with object code linked at run time, or when
>an object file is being produced, by the loader.  Inlining requires that
>the compiler introduce instructions directly into the compilation as it
>does when it is handling the user's code.  The current inlining is a special
>case of what I would like to accomplish with the macro processor I have
>called for; I would allow macros applied to macros, etc.  Inlining corresponds
>to a subset of what a more powerful #define would handle.  But since it is not
>under the control of the programmer, it becomes part of the language.

Herman, please.  Audit some undergrad courses in computer architecture & compilers.
Then you can come back and resume your endless spiel, but at least you'll
have some idea what you're talking about.

Geesh.  Most of us don't spend time and bandwith flaming on sci.math.stat
about Gaussian normal distributions...

Dan Breslau
dan@codex.com
Speaking for myself, at most...

Xref: sparky comp.arch:10871 comp.lang.misc:3759
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 18 Nov 92 01:44:11 GMT

: From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
: Message-ID: <Bxpoy9.GD6@mentor.cc.purdue.edu>
::: Nobody except a computer programmer can read it at all!
:: The similar complaint that "those statisticians and their screwey
:: sums-over and chi-squares and their standard deviations!  [...]"
:: [...] is false.
: Students in statistics courses have little problem with the notation
: you have mentioned

So, Herman agrees with me about statistics notations.  I wonder what
reasons he might have to continue to DISagree with me about programming
notations, since students in computer courses have little problem with
the notations taught therein.

: A biologist does not need so much to be fluent in statistical jargon
: to work in population genetics as to learn basic probability, and some
: basic statistics, 

But if that biologist is going to talk to statisticians about novel
applications and novel methods, it *will* be necessary to learn more
than these rudiments.  Similarly, if a statistician attempting to
help this biologist needs to develop new computer applications beyond
canned applications, that statistician will have to learn more than
is common about computer jargon.

::: And what is one supposed to do if the hardware operations wanted are
::: not even expressible in the language?
:: Use another language (or implementation).
: Bob Silverman and those working with him use huge gobs of computer time.
: They cannot get the language or implementation needed. 

Nonsense.  Assembly language *at* *least* has direct access to all of
the hardware operations.  If no assembler exists for the machine, I'm
sure that one could be built quickly and cheaply.  And with infix
operator syntax if desired.

If Herman means he can't get a custom-designed language system for
peanuts, somehow I'm not surprised, and I doubt that the reason is
some conspiracy of language implementors to deny him the tools he wants.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch,comp.lang.misc
From: bruce@cs.su.oz.au (Bruce Janson)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Reply-To: bruce@cluster.cs.su.oz (Bruce Janson)
Organization: Basser Dept of Computer Science, University of Sydney, Australia
Date: Wed, 18 Nov 1992 17:06:34 GMT

In article <id.QT0V.CHJ@ferranti.com> peter@ferranti.com (peter da silva) writes:
>..
>The macro language used in Jeffrey Kingston's text formatting package "LOUT"
>can do the trick, though it seems to be pretty tightly coupled to the text
>package. I don't know his current net address, but the Lout documentation
>gives:
>
>	Jeffrey H. Kingston
>	Basser Department of Computer Science
>	University of Sydney 2006
>	Australia
>..

Try "jeff@cs.su.oz.au".
lout can be obtained by anon ftp from cluster.cs.su.oz.au, get pub/lout.tar.Z.

Cheers,
bruce.

Bruce Janson					Email:	bruce@cs.su.oz.au
Basser Department of Computer Science		Phone:	+61-2-692-3423
University of Sydney, N.S.W., 2006, AUSTRALIA	Fax:	+61-2-692-3838
Newsgroups: comp.arch
From: rsnider@xrtll.uucp (Richard Snider)
Subject: Re: Registerless processor
Organization: WCOM Public Access Unix - Toronto
Date: Thu, 19 Nov 1992 01:32:49 GMT

In article <1992Nov13.181654.11692@fcom.cc.utah.edu> drdavis@u.cc.utah.edu (Darren R. Davis) writes:
>I have been pondering an idea for a machine architecture.  A processor
>that has no registers.  I am familiar with some architectures that have
[...]
>fast access.  Does anyone know of such a machine, and what are your
>thoughts on this kind of architecture.

The PDP-10 could fall into this classification without too much arguing.
It had its set of 16 general purpose registers defined simply as the
first 16 locations in memory.  Naturally, they implemented the the
"registers" as logic (register files) rather than core (in the first
ones).  The secret way to get your program to run really fast in
a tight loop was to load it into the registers (up to 16 instructions)
and then jump to one of the registers......

Ok, so its not so fast nowadays....   .....but still kinda neat


                                           ...Rich
                                           rsnider@xrtll
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: DEC ALPHA Performance Claims
Date: 18 Nov 92 22:35:41 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1992Nov16.123221.9069@qb.rhein-main.de>, vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:

| > I'd like to hear from RISC architects and implementers on this topic. Given
| > all the touted advantages of RISC, why aren't they blowing Intel away?
| 
| Too many computer-illiterates getting caught by M$'s and intel's
| marketing hype.

  How about this: people are buying the hardware which runs the software
they want to use, and which is cost effective. In the real world the
cost of solution of a problem is the issue. As long as vendors insist on
packaging a product at $399 for DOS and $7000 for workstations the high
end will stay with Intel for many problems (unless you need a LOT of
power).

  Just because people don't do what you think they should doesn't mean
they're confused, it may mean you don't understand their problem. If the
software I need to run will run on an Intel machine (or perhaps only an
Intel machine), if I didn't go with Intel I wouldn't just be "computer
illeterate," I'd be stupid.

  Of course Intel may have opened the door by not shipping the P5 when
they said they would. Not only are lots of people unhappy because they
now have to use another vendor to get the performance they need, but
software has been ported from DOS to other systems because there was
(and is) no faster chip.

  I think Godot would have been a better name for the P5 then Pentium,
but by 1995 production quantities should be available.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
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: Fri, 20 Nov 1992 13:33:15 GMT

In article <PRENER.92Nov20014621@prener.watson.ibm.com> prener@watson.ibm.com (Dan Prener) writes:
>In article <1992Nov19.034325.3864@technix.mn.org> bret@technix.mn.org (Bret Indrelee) writes:

>>    In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>>    >In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>>    >> But it is.  The operations often use register arguments and the results
>>    >> are wanted in registers.

>>    >What's a register? Most modern compilers ignore "register", or use it as a
>>    >hint "this is a frequently used value".

>>    >And how is an inline library part of the language more than a subroutine
>>    >or an include file?

			............................

>Which leads to the optimization issue.  Compilers don't have to be
>completely pessimistic about what might be changed by pointer references.
>With a suitable definition of what it means for a variable to have its
>address taken, pointer references can only change those variables that
>have had their addresses taken.

>So, while it is true that register variables may lead to better optimization,
>that is because they never have their addresses taken.  So, with a compiler
>that keeps track of which variables have their addresses taken, the
>performance improvements resulting from the use of register variables remain,
>even after you delete the "register" declaration.

On most machines, one can do little with objects not in registers other than
read them, either placing the results in registers, or using the results as
instructions.  This means that it something is not in a register, using it
means first reading it.  If it is not kept in a register but stored, this
applies to using it again.  Some machines even restrict register movement;
memory access is unlikely to ever compete favorably with computation again.

If hardware/software designers and compiler writers would take the position
that load/store generally means waste unless the stuff being loaded/stored
is large, we may not have too much of a problem.  But there is one problem
with registers; I know of no current machines on which much use can be made
of the ordering of registers.  There have been a few machines on which 
registers WERE addressable, and this has considerable advantages.  

Some of the posters have suggested having a struct as a return when multiple
returns are wanted.  This is quite difficult to manage in a register file,
precisely because of the non-addressability.  It would even be a problem if
registers were addressible, because the locations wanted are unlikely to be
in a "struct" format.
-- 
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)
From: wilken@endive.eecs.ucdavis.edu (Kent Wilken)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 14 Nov 92 20:33:30 GMT
Organization: U.C. Davis - Department of Electrical Engineering and Computer Science

In article <BxL3IH.KtH.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>In article <15445@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>Hmm.  As I remember, somebody from DEC at a session on topics such as
>>OSF/1-on-MIPS on Tuesday night at the San Antonio USENIX claimed that
>>HP-PA was "out of gas"; ...
> ...
>
>What he may have meant, is that HP won't be able to use offchip
>primary cache much longer. That was difficult at 66 MHz, and is
>really impressive at 100 MHz. Even HP can't do it at 200 MHz, surely. <---
> ...
>
>Don		D.C.Lindsay 	Carnegie Mellon Computer Science

A person from HP previously addressed your incredulity regarding 
the feasibility of 200MHz off-chip caches:

#From: linley@hpcuhe.cup.hp.com (Linley Gwennap)
#Newsgroups: comp.arch
#Subject: Re: Re: Offchip Primary Cache
#Message-ID: <32580093@hpcuhe.cup.hp.com#
#Date: 5 Mar 92 21:46:37 GMT
#References: <1992Mar03.233219.176162@cs.cmu.edu#
#Organization: Hewlett Packard, Cupertino
#
#(Donald Lindsay) discusses HP cache access rates:
#> I'm impressed that HP can do it at 100 MHz. Can you do it at 200 MHz?
#
#There is no reason to believe that 200 MHz will not be possible. 100 MHz
#primary caches on the PA7100 are accomplished with standard PCB technology,
#ceramic PGA packaging, and off-the-shelf 9ns TTL I/O SRAMs. SRAMs get 
#faster every year, multichip modules are getting cheaper, ECL I/O circuits
#are well understood, future VLSI technologies will improve timing 
#overhead, etc, etc.  Two years ago these same discussions were taking place
#about whether external primary caches could ever run at 50 MHz.
#
#Some of the work going on to define new high-speed I/O protocol standards
#for DRAM and SRAM memory devices also look interesting for application
#in future cache memory designs. 
#


Xref: sparky comp.arch:10838 comp.lang.misc:3741
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: 17 Nov 92 22:24:32
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Nov13.200222.23955@sal.wisc.edu> <id.OS0V.0DI@ferranti.com>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: peter@ferranti.com's message of Mon, 16 Nov 1992 21:56:36 GMT

In article <id.OS0V.0DI@ferranti.com> peter@ferranti.com (peter da silva) writes:

   In article <1992Nov13.200222.23955@sal.wisc.edu> alan@sal.wisc.edu (Alan Watson) writes:
   > >Quite a few modern microprocessors have hardware to do 32 x 32 bit 
   > >multiplies and 64 bit / 32 bit divides.  I know of no HLL that will
   > >allow me to write code to access these instructions. For example,
   > >suppose I want to compute A*B/C exactly, where A,B, C are 32 bit
   > >ints and C > A and C > B.  How do I do this in a HLL ?

   In Forth: A B C */ (this is actually 16 * 16 / 16 -> 16, but equivalent
		       operations exist for 32-bit operators in modern Forths)

   > This is a compiler issue, not a language issue; many compilers provide
   > access to system-specific operations.

   No, it's a language issue. Forth, as implemented on an 8-bit CPU with no
   hardware multiplier, provides this routine.

I somehow don't follow your reasoning. If _some_ FORTH implementations
provide a particular machine specific feature, then it's "in the
language", while if _some_ C implementations provide the same feature
then it's merely "in specific implementations"? I think you are
measuring with different yardsticks here.

Modern implementations of C provide sophisticated "asm" interfaces,
just like modern implementations of FORTH provide machine-specific
operators.

					Thomas.
Newsgroups: comp.arch