HDTenEightyP/NetNews huggingface dataset:
From: blair@snogum.enet.dec.com (Blair Phillips - Digital)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Keywords: Alpha, AXP, SPEC, DEC, INTEGER
Reply-To: Blair.Phillips@cao.mts.dec.com
Organization: Digital Equipment Corporation
Date: Mon, 16 Nov 1992 23:19:49 GMT


In article <1710@niktow.canisius.edu>, pavlov@niktow.canisius.edu (Greg Pavlov) writes:
>
>In article <jdd.721687838@cdf.toronto.edu>, jdd@cdf.toronto.edu (John DiMarco) writes:
>> In <1698@niktow.canisius.edu> pavlov@niktow.canisius.edu (Greg Pavlov) writes:
>> 
>> >  The SPECint92 values seem somewhat low, in terms of processor MHz.  Any 
>> >  known reasons why ?  Essentially, our R3000-based systems, at 40 MHz, 
>> >  have a SPECint92 (measured by DEC) that is apx. 40% of an ALPHA-based 
>> >  system at 133 MHz.
>> 
>> There are two ways of making processors fast. One is making them do more
>> per clock cycle. The other is making them run at a higher clock rate.
>> 
>  Of course.  But you are summarizing my question, not answering it.  
>
I'm tempted to say: 
"Go read Hennessy & Patterson, then you will see that John DiMarco *does*
answer your question"

However...

The major design decisions in the Alpha AXP architecture were biased towards
high clock rates rather than high SPECmarks/MHz. The decisions were simulated
using real code traces to validate the choices.

A good example is the lack of 8 and 16 bit load and store instructions.
Providing these would have added a complex multiplexor in the critical path
from the internal cache to the register file. It would have forced either a
longer cycle time, or an extra cycle for *all* load/store instructions.
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).

At the other extreme, it would be possible to implement most of the VAX or 
M68xxx instructions in a single cycle, but your cycle time would be measured in
microseconds rather than nanoseconds! You would get a really terrific
SPECmark/MHz ratio, even if the absolute SPECmark was << 1.0

Patterson & Hennessy have lots of examples of these sort of tradeoffs, if you
are interested.

The question is not 
"Why does chip XYZZY have a higher SPECmark/Mhz than an Alpha AXP chip?"
but
"Why can't chip XYZZY run at a high enough clock rate to give the same SPECmark 
as an Alpha AXP chip?"

So far, the HP PA-RISC architecture is the only microprocessor architecture
that is close.
--
----------
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: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
Date: 15 Nov 92 23:56:38 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Nov12.220301.23915@fcom.cc.utah.edu> caperkin@ursa11.law.utah.edu (Charles Perkins) writes:
>The following article brings to mind an interesting question...
>How small can we make a (reasonably useful) CPU?
>
>Assuming good density, how many of the above could we put on a chip
>using today's processes (We can make 16 Megabit dram chips... but dram is
>very regular.)
>
>How many transistors would it take to make a minimally sized 32-bit chip?
>Optimized for transistor count, not cycle speed, op-code simplicity, or
>speed of design.

Well, the processors in MasPar's new MP-2 go 32 to the chip, for a
total of 1 million transistors (Parallelogram 48).  I know that's not
exciting by your standards but it's a real 32-bit commercial CPU,
albeit as part of an SIMD array.

Damon
-- 
Damon Hart-Davis                          Internet: dhd@exnet.co.uk, d@hd.org

Public-access UNIX (Suns), news and mail for UK#5 per month.  FIRST MONTH FREE.
[1.35] Cheap Sun eqpt.  UUCP news/mail feeds.  Tel/Fax: +44 81 755 0077.
Xref: sparky comp.arch:10954 comp.lang.misc:3808
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 20 Nov 92 21:13:10 GMT
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: mbk@lyapunov.ucsd.edu's message of 19 Nov 1992 07:34:08 GMT

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

   : Feel free to design a computer language for mathematics.  Don't pretend
   : that other computer languages (least of all C) exist to serve you.

   Well, when he expresses some notion of what he wants to do, without specifying
   it the way computer scientists want to hear, he gets the third degree.  The
   point is that the computer scientists have the abilities and facilities to
   do what he wants (that he probably doesn't), but too many seem profoundly 
   unsympathetic to even his most basic motivations and they go tell him to jerk
   off.

Software companies will produce programming languages that the market
wants. Computer scientists will produce programming languages
incorporating features that they think the market will want 10 or 20
years from now. Rubin's ideal language isn't being produced partly
because he is asking for conflicting constraints to be satisfied, and
partly because people like him have evidently failed to convince
others that the features they want are useful and cost-effective.

   As an example, consider a Connection Machine---it's hardware is so fundamentally
   different, and so to even have a chance of writing intelligent programs, it's
   essential to be able to express these fundamentally new methods in software.
   (And yes, they do it.)  Herman's point is that more computers than you think
   may need this, especially as supercomputer-research-type stuff starts coming
   down to earth.  We don't want 87 completely different dialects of C, or tricky
   obscure code that compiles into something simple. We accept the necessity
   of hardware dependence, but we want it tamed, rather than excommunicated.

That's the goal of everybody. Now, if you have a solution to this
problem, by all means, let us know about it. So far, all the proposals
I have seen on this newsgroup came down to "I want to be able to mess
up the lexer/parser in arbitrary ways by defining my own syntax"
(which has nothing to do with taking advantage of hardware), and
"wouldn't it be nice if I could express the following machine-specific
feature so that it runs fast on every machine" (which is obviously a
contradiction).

					Thomas.
Newsgroups: comp.arch,comp.lang.misc
From: wolpers@i11s10.ira.uka.de (Andreas Wolpers)
Newsgroups: comp.arch,comp.benchmarks
Subject: Lisp performance (on Sparc SS2, SS10-30, HP720)
Date: 16 Nov 1992 11:54:03 GMT
Organization: University of Karlsruhe, FRG
Distribution: world
NNTP-Posting-Host: i11s10.ira.uka.de

Hello everybody,

I'm having a minor problem on which I would welcome any comments:
Since I'll have some money to spend real soon now, I've been pondering
whether we should switch from Sun to HP. The usual benchmark results
suggest that a change might result in faster execution of our pet
program, a large "theorem prover" written in Lisp.

From the SpecInt92 results, one should expect a performance increase
of about a factor of 2 when switching from a SS2 to either s SS10-30
or HP720. Unfortunately, on both machines turned out to but just
30% faster than a SS2 when running our system (for which ps NEVER
shows a resident set under 3-4 MB, not even on an 8MB machine).

Any explanations at hand? Did we encounter a bottleneck between
CPU and memory, or what? What performace should I expect from
a SS10-41 or SS10-52 (which have a larger cache, but still not 
large enough to hold the Lisp's resident set. And if I'm not
mistaken, the large cache results in a longer time spent for
non-cache memory accesses (6 cycles instead of 3)). What 
performace should I expect from a HP735?

I can buy enough memory so that disk speed is no criterion.
Should I wait for machines with 8MB of cache? Should I shoot myself?
Should I give YOU the money? :-)

Sigh,

Andreas
-- 
Andreas Wolpers
e-mail: wolpers@ira.uka.de
phone:  49-721-608-3977
fax:    49-721-697760
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: Mon, 16 Nov 1992 13:44:54 GMT

In article <Bxs63J.BxA@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:
>In article <BxpprG.HKu@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
>>And how would you handle cases where operations have multiple results,
>>of different types?  This should have been in all programming languages
>>on day 2, and is now only clumsily handled in some.  How would you 
>>handle simple operators which those who produced the languages either
>>did not understand, did not think important, or just plain ignored?	

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

>Or you put these features in the library.  (Just like RISC.)

>Which is what C does.

>I think even C is starting to bloat, but it is still quite honest in
>relegating special features---that won't be used/available on *nearly
>every* machine or in *a lot* of code---to the libraries.

>So, returning multiple answers in C is easy if ugly.  Use pointer
>arguments, or return a structure or point to one.  It needn't be
>expensive at run time.

But it is.  The operations often use register arguments and the results
are wanted in registers.  To avoid real problems with separate compilations,
it would be necessary to have a substantial inline library, which is really
a part of the language installation.  I have not seen any implementation of
C which allows a register struct, although I suspect that there are such.
But if the registers wanted are not adjacent, I can see a real problem.
-- 
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
From: dipirro@star.dec.com (Steve DiPirro)
Subject: Re: DEC Alpha architecture issues
Organization: Digital Equipment Corporation
Date: Wed, 18 Nov 1992 20:55:44 GMT


In article <1992Nov18.112407.2518@doug.cae.wisc.edu>, keiths@cae.wisc.edu (Keith Scidmore) writes...
>2. The Alpha architecture also includes a feature they call PALcode that
>   allows the chip to have a sort of rom-bios.  Why is it useful to have
>   this feature?  Supposedly Operating systems can make use of this for
>   the implementation of certain system calls.

PALcode allows for the implementation of uniprocessor-atomic
"instructions" which are actually a sequence of Alpha instructions.
It allows the architecture to remain pure RISC and not compromise
performance to implement some complex instructions. This was very
useful in the port of VMS to Alpha.

Take the VAX REI instruction as an example. This is a very complex
VAX instruction and is implemented in PALcode on Alpha (for VMS).
So there is no need to burden the base architecture with the
implementation of an REI instruction. Instead, you have a "subroutine"
of sorts which executes in the special PALcode environment.

Very few PALcode instructions were actually needed to port VMS to
Alpha, but some we could not do without (without considerable work,
that is).

PALcode is also a convenient place to handle device interrupts and
exceptions and provide the expected OS interfaces at that level.
Specific OS knowledge can also be built into PALcode, such as pagetable
formats, etc. allowing such things as TB invalidates to be handled
by PALcode. For VMS, PALcode also handles unaligned data reference
fixups, providing an optional exception through the SCB when one occurs.

------------
Steve DiPirro        dipirro@star.dec.com
                     --or-- ...!decwrl!star.dec.com!dipirro
                     --or-- dipirro%star.dec@decwrl.dec.com
------------
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: Re: Registerless processor
Date: 20 Nov 92 23:46:10 GMT
Organization: Rutgers University Department of Computer Science

In article <DERAADT.92Nov19231103@newt.newt.cuc.ab.ca>, deraadt@newt.cuc.ab.ca
(Theo de Raadt) writes:
| In article <BxxwAq.G8C@xrtll.uucp> rsnider@xrtll.uucp (Richard Snider)
| writes:
|    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
| 
| PDP11 registers map into the memory address space as well.

No; this is false.  The registers are NOT in the memory address space in the
sense you are talking about.

On SOME PDP-11 models, it was possible to access the registers via addresses
in the I/O page.  I/O page addresses do not correspond to "memory", and it is
quite reasonable to have some of them "loop back" into the processor,
providing access to internal processor state.  That's just what happened in
this case.  Access to the registers via I/O space could be slow, was cumber-
some, and was in general restricted to OS code (since normal user code could
not be given access to I/O page addresses - that would give it complete
control over every device in the system.)

|							     There are two
| banks of 8 registers, though which can be accessed depends on a bits in
| the status register.

As far as I know, no PDP-11 ever built had TWO banks of registers.  The
machines that had multiple banks had THREE of them, one each for user,
supervisor, and kernel modes.  (The earliest machines, if I remember right,
didn't even implement two modes of operation.  The machines that implemented
multiple banks were late enough to also implement the three modes.

Even the earliest multi-mode machines, however, had separate stack pointers
for the two modes.  The stack pointer was in a register (R6).

| 
| I wonder how this was implimented? I guess that in the early PDP11's the
| registers did not exist at all.

You guess dead wrong.

|				  But certainly they must have fixed that
| in later versions. Was it possible to run programs out of the registers
| on a newer PDP11?

Running programs out of I/O space was generally unsupported, and that's where
the registers appeared.  It MIGHT work, though I'd guess not.  If it DID work,
it would be slower than running from real memory.

							-- Jerry
From: je@unix.brighton.ac.uk (John English)
Newsgroups: comp.arch
Subject: Re: Registerless processor
Date: 19 Nov 92 11:52:58 GMT
Organization: University of Brighton, UK

eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
: 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,

The Inmos Transputer has very few registers (you still need a program
counter, don't you?) but has 4K of onboard memory. One of the registers
is a workspace (aka stack frame) pointer, and offsets 0 - 15 can be accessed
by a 1-byte instruction (4 bit opcode, 4 bit offset) with every extra 4 bits
of offset costing an extra byte. Does this fit the bill?
Also see "Register Allocation for Free: the C Machine Stack Cache" by
Ditzel & McLellan (ACM ASPLOS I, Mar 1982) which makes some good points
about registers vs. caches.
-- 
-------------------------------------------------------------------------------
John English			| "Yes, understanding today's complex world of
Dept. of Computing		|  the future IS a little like having bees live
University of Brighton		|  in your head... but, there they are..."
Janet: je @ unix.brighton.ac.uk	| "People who live in windowed environments
Fax:   0273 642405		|  shouldn't cast pointers"
-------------------------------------------------------------------------------
From: walter@zarquon.Eng.Sun.COM (Walter Bays)
Newsgroups: comp.arch
Subject: Re: MIPS and MHz
Date: 16 Nov 1992 18:30:44 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: walter@zarquon.Eng.Sun.COM
NNTP-Posting-Host: zarquon

In article 8937@odin.corp.sgi.com, mash@mash.wpd.sgi.com (John R. Mashey) writes:
>CFP92: Apogee C & FORTRAN 0.82 Alpha with integrated Kuck (for Classic & LX)
>	Sun C & FORTRAN 3.0 Alpha + Kuck (for SS10s) 
>...

Also:
	Sun C & FORTRAN 2.0.1 (Solaris 1 and Solaris 2) available now
	Apogee C & FORTRAN 1.0 (Solaris 1) available now
	8 or 10 other compilers listed in recent UNIX World and SunWorld articles

>Hence:
>	If you want best Dhrystone- MIPS rating, use Apogee C
>	If you want best SPECint92, use Sun C in 5/93
>	If you want best SPECfp92, use Apogee (soon, for low-end), or
>			Sun (in 5/93 for SS10s)
>	If you want best LINPACK, use Apogee (soon)

No, I cannot recommend a compiler for you, but if you want the best
performance for *your* application, you have several compilers to
choose from.

Or if you want the best development environment, you have several
compilers to choose from.  Or support for the most languages, or best
support library availability, or the most robust code, or lowest price, ...

For hardware, the standard benchmarks give you an initial filter of
systems based on performance before making a final selection based on
your application performance, plus other factors.  However for
software, in the X86 and SPARC worlds where there are several competing
compilers, you can also use standard benchmarks as an initial filter if
performance is most important to you.  Of course if another factor is
most important you'll use that to filter instead.

Actually, for most systems now you do at least have two choices of
compiler - the other being Gnu.

The analogue between software and hardware extends to buying system A
now with the expectation of upgrading to system A1 later - you like
current performance plus growth path.  You can also buy compiler B now
with the expectation of upgrading to version B1 later.

---
These are my personal opinions, not those of Sun or SPEC.
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

Xref: sparky comp.arch:10750 comp.lang.misc:3692
From: davis@passy.ilog.fr (Harley Davis)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 15 Nov 92 15:47:26 GMT
	<BxLupy.M9K@mentor.cc.purdue.edu>
Organization: ILOG S.A., Gentilly, France
In-reply-to: hrubin@pop.stat.purdue.edu's message of 12 Nov 92 13:27:33 GMT


In article <BxLupy.M9K@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   >: There is a price for programming for clean code;
   >: in most cases the benefits far outweigh the price; sometimes they don't.

   There is a price for programming in what the languagists think is
   clean code.  Nobody except a computer programmer can read it at
   all!

There is a price for programming in what the Rubinist thinks is clean
code.  Nobody *at all* can read it!

-- Harley Davis
--

------------------------------------------------------------------------------
nom: Harley Davis			ILOG S.A.
net: davis@ilog.fr			2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66			94253 Gentilly Cedex, France
Newsgroups: comp.arch
From: jcooley@world.std.com (John Cooley)
Subject: E-mail Synopsys Users Group (ESNUG)
Organization: The World Public Access UNIX, Brookline, MA
Date: Wed, 18 Nov 1992 09:22:13 GMT


  If you're using the Synopsys Design Compiler and/or their ATPG product, you 
  might be interested in joining the E-Mail Synopsys Users Group (ESNUG).

  What we are is a group of hardware designers from all over the world who
  wish to trade experiences, bug reports and the techniques that we've
  found that work best in getting a design from a behavioral description
  to a final fully tested product.

  A Sample of What We Discuss:

	- Known Synopsys Compiler Bugs    - Implementing Boundry Scan

	- Mentor related issues    - EDIF related issues

	- Hierarchical Compliations   - design_analyzer   - JTAG

	- How Various ASIC Vendors Model Their Macros.   - Clock Constraints

	- Using ATPG Tools   - The Best Way To Write State Machines in Verilog

	- Using VHDL   - System Simulation vs. Synopsys Friendly Code

	- Clever Workarounds to Known Pitfalls   - Testing Strategies

  In order to insure an open discussion, but yet keep our respective managers
  happy in having our company's projects remain SECRET, submissions to be 
  posted to the ESNUG mailing list can be stripped of identifying engineers 
  and company names if so requested.

  In addition, to further secure privacy and to avoid e-mail headers that
  are hundreds of names long, each mailing is a batch of singlely addressed 
  e-mail letters.

  If you know of anyone who may be interested in this, please give them
  my e-mail address (jcooley@world.std.com or jcooley@miracle.com) or you can 
  send me their address!
					- John Cooley
					  ESNUG Moderator

 ===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
 with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
 ===========================================================================
      !!!     "It's not a BUG,    | Preferred Address: jcooley@world.std.com
     /o o\  /  it's a FEATURE!"   |    Backup Address: jcooley@miracle.com
    (  >  )                       |              (508) 429-4357
     \ - /       |   Snail Mail: P.O. Box 6222, Holliston, MA 01746-6222
     _] [_       |     "This here ain't no one's opinion 'cept my own."


Newsgroups: comp.arch
From: luis@tds.kth.se (Luis Barriga)
Subject: Which shared memory multiprocessor workstations are available?
Organization: The Royal Institute of Technology, Stockholm, Sweden.
Date: Wed, 18 Nov 1992 18:54:27 GMT

We are considering in purchasing a multiprocessor workstation with
shared memory for parallel simulation purposes. So long we have heard
of Sun Sparc 10 series and IRIS from Silicon Graphics.

- Are there any other comecially available workstations of this type?

- Anybody who can share his/her experience with such WS's? Praises and
  critics are appreciated.

--
+------------------------------------+------------------------------------+
+     Luis Barriga                   + The Royal Institute of Technology  +
+   Research Engineer                +     Dep. of Teleinformatics        +
+                                    +    Computer Systems Division       +
+ e-mail: luis@it.kth.se             +        P.O. Box 700 43             +
+ tel: +46-8-790 90 25               +       S-100 44 Stockholm           +
+ fax: +46-8-24 77 84                +            SWEDEN                  +
+------------------------------------+------------------------------------+