HDTenEightyP/NetNews huggingface dataset:
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha AXP System Performance
Organization: Digital Equipment Corporation
Date: 12 NOV 92 09:26:25    


In article <martin.721554717@bert>, martin@math.rwth-aachen.de (  Martin Schoenert) writes...
>In front of me I have  Digital Equiment Germany's announcement of the new
>systems for  ``Forschung und Lehre'' (research and education).   For  one
>thing it doesn't mention the first  three  models at  all.  Also it gives
>the following numbers
> 
>    DEC 3000 AXP Model 500
>        SPECint92        66
>        SPECfp92        118
> 
>    DEC 3000 AXP Model 400
>        SPECint92        59
>        SPECfp92        103,5
> 
>Any idea why the numbers are smaller?  (Is it  because we are ``Forschung
>und Lehre'', or is it because we are in Germany, or what? ;-)
> 
They are based on older versions of the compilers, libraries, etc.

/d
Xref: sparky comp.arch:10440 comp.lang.lisp:2819
From: cgay@ilix.cs.uoregon.edu (Carl L. Gay)
Newsgroups: comp.arch,comp.lang.lisp
Subject: Re: Symbolics & LISP machines
Date: 6 Nov 92 06:13:52 GMT
Reply-To: cgay@cs.uoregon.edu
Organization: CS Dept, University of Oregon


   From: jcooley@world.std.com (John Cooley)
   Date: Wed, 4 Nov 1992 18:56:06 GMT

   > From: storm@cs.mcgill.ca (Marc WANDSCHNEIDER)
   > Subject: LISP Machine
   > 
   > 	Howdy!  We are about to embark on a project to study associative
   > memory schemes, and were wondering if anybody knew where we might be able
   > to find some papers or books on the LISP machine..?  Our Local Library's
   > CD ROMs or Computers couldn't find anything on it.

"Symbolics Architecture", IEEE Magazine, Jan 87.
"The Symbolics I-Machine Architecture", ICCD Prceedings, 1987
"The Symbolics Ivory Processor",           "              "

"NS: An Integrated Symbolic Design System", ULSI 85, Proceedings of
the IFIP TC 10/WG 10.5 International Conference an VLSI, Aug 1985.

   Marc, you may want to look up a Massachusetts based company called
   "Symbolics".

   A lot of what I know about them is quite old.  
   [...]
   They also used to make and sell their own hardware that was
   optimised to run LISP code as efficiently as LISP code can be run.

Still do.  Have just recently come out with the NXP1000.  I don't know
much about it except I believe it's a desktop machine and runs Lisp
pretty fast (somewhere in the range of a Sun 4 I believe, but with a
much better development environment).  Symbolics' number is 800-394-5522.

   I remember the name "LISP BOOM" for some reason.
					   - John Cooley
					     ESNUG Moderator

I don't know why.  :-)

-Carl
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 14 Nov 92 00:46:16 GMT
Organization: Auspex Systems, Santa Clara

>>>This SSD chip is due in 1996.  I wonder if it's really the Pentium?
>>
>>I've heard claims of a 64-bit member of the x86 family; *if* the chip
>>has a new instruction set, perhaps they'll have the x86 instruction set
>>as the 32-bit instruction set, and some new instruction set as the
>>64-bit instruction set.
>>
>>Doesn't sound like the Pentium, in any case.
>
>Well, why not?

If it doesn't run x86 code, like the chip you spoke of, it ain't
Pentium, which *will* run x86 code, from everything I've heard (in fact,
I've not heard that it'll run any other code, except perhaps with the
aid of simulators or binary-to-binary translation, but hey, most people
are trying to run x86 code on *their* chips, so...).

I've not heard anything to make me believe Pentium will run x86 code in
some simulation mode, either; from everything I've heard, it's an engine
intended to run x86 code, even though there may be something inside it
that "looks", in some sense, like a RISC.

And if it *does* run x86 code, well:

>If Intel delays the Pentium until 1994 it would be due
>at about the same time.

1994 and 1996 are "about the same time"?
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha AXP System Performance
Organization: Digital Equipment Corporation
Date: 10 NOV 92 16:26:47    


In article <BxIM38.L9F.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes...
> 
>So, we now have non-simulated non-prototype-system numbers for the
>DEC 21064 chip and the HP 7100 chip.  The result is that the HP at 99
>MHz has about the SPECs of a 21064 at 160 MHz. 
> 
>DEC wins the performance-at-any-price race with a 200 MHz offering,
>with 1.33 x the SPECs of the hottest HP.
> 
>The performance-at-a-price race is closer. The 99 MHz HP 735 is $35k
>versus $39k for a 150 MHz Alpha. Practical issues (like ship dates
>and configuration details) dominate the technical issues here.  Which
>is sort-of the message that DEC and HP want you to hear, since they
>plan to migrate the technology into cheaper boxes.
> 
>Damn that's fast. 
>-- 
Don't forget about the 108 SPECmark89 DEC 3000 Model 400 AXP priced at $14,995!

/dileep
Newsgroups: comp.arch
From: NetCmmnd@boole.uucp (System Administrator)
Subject: MIPS and MHz
Summary: How does a non superscalar get more than 1 instruction per cycle?
Keywords: RISC, MIPS, cps
Organization: Boole & Babbage, Inc.
Date: Thu, 12 Nov 1992 18:34:24 GMT

I Sun has just announced some new workstations based on
a microSPARC(tm) chip running at 50MHz and producing 
59.1 MIPS.  I know the problem with MIPS but 

How can a non-superscalar implementation at 50MHz run 59.1 MIPS?
I thought the holy grail of RISC was 1 instruction retired per cycle
and that this is never attained (much less exceeded) in a non-
superscalar implementation.

MIPS is probably the most misleading term in the field but
what on earth can they mean?

John Ahlstrom
Boole & Babbage
408-524-3307

I can neither confirm nor deny that these questions
are interesting to anyone else.
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: MIPS and MHz
Keywords: RISC, MIPS, cps
Date: 12 Nov 92 23:39:18 GMT
Article-I.D.: cs.BxMn1J.GB3.2
Organization: School of Computer Science, Carnegie Mellon

NetCmmnd@boole.uucp (System Administrator) writes:
>How can a non-superscalar implementation at 50MHz run 59.1 MIPS?
>I thought the holy grail of RISC was 1 instruction retired per cycle
>and that this is never attained (much less exceeded) in a non-
>superscalar implementation.

Correct, for reasonable measures of MIPS.

However, "Dhrystone 1.1 MIPS" have ceased to be reasonable.  The
"MIPS" is calculated by assuming that the VAX 11/780 was 1 MIPS, and
then taking an execution-time ratio versus a historical VAX value.

As compilers have improved (and have acquired Dhrystone-1.1-specific
optimizations), the D-MIPS ratings have inflated beyond reason.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
Newsgroups: comp.arch
From: liuxia@wam.umd.edu (New VaxHacker)
Subject: 286 chip
Organization: University of Maryland, College Park
Date: Fri, 6 Nov 1992 16:57:46 GMT

Please forgive my illiteracy in this area.  I am seeking help
for my friend who doesn't have internet access. He needs to
find company that builds the whole 286 motherboard into one
small chip. He mentioned one company called 'AMPRD'
might deal with this but he could not find any info about this
company.  

Any pointers to this AMPRD or other manufacture that makes
this thing is greatly appreciated.

Please send me email to liuxia@wam.umd.edu.

Thanks.

Liu Xia

Newsgroups: comp.arch
From: solman@athena.mit.edu (Jason W Solinsky)
Subject: Re: fiber/silicon and Thz clocks?
Organization: Massachusetts Institute of Technology
Date: Fri, 13 Nov 1992 13:16:26 GMT

In article <1992Oct31.000805.2898@sics.se>, craig@sics.se (Craig Partridge) writes:
|> 
|> Hi:
|> 
|> Here's a futuristic question I'm puzzling over.
|> 
|> It has been asserted that there's an impending fiber/silicon bottleneck
|> in data communications.  The argument says, in short, that we can signal
|> far faster in a fiber than we can hope to get the electronics going in
|> silicon, and we have to study that problem.  So I'm polling this group
|> of silicon experts to see what you think.
|> 
|> At its very best (wind-aided, etc.) a fiber could conceivably achieve a
|> transmission 40 terabits/second (40 Thz).  My understanding is that the
|> key problem is figuring out how to clock bits that fast into silicon.
|> 
|> My immediate reaction is that I would expect there might be some way to
|> make this fly.  For example, 1 terabit per second, on an 128-bit wide
|> bit path is about a 0.1 ns clock cycle, which is only a modest improvement
|> over what DEC reputedly hopes to achieve for Alpha clock cycles in the
|> future.  Now going serial to parallel would presumably require some pico-second
|> logic somewhere, but maybe that's possible.

I would suggest that there are two problems with this method of figuring.

1) The terabit per second firgure that is creating the bottleneck is in a
single fiber. Your clock rate will have to be determined for a 1 bit wide
path. Then you get a 1 ps clock. Even SFQ logic won't do that.

2) You have either accidentally decided to believe DEC marketing propaganda
that claims that they will be clocking Si circuits at 10 GHz, or the 10 GHz
figure is what they expect the Alpha architecture to be clocked at at the end
of its lifetime which, in an atempt to bring a little humor into all of our
lives, has been estimated at about 25 years.

Jason W. Solinsky
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 6 Nov 92 16:40:41 GMT
Organization: Intel i960(tm) Architecture
NNTP-Posting-Host: potato.intel.com
In-reply-to: vhs@rhein-main.de's message of Fri, 6 Nov 92 09:20:12 GMT


vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
] I was wondering lately...
] Wasn't one of the principles of RISC the principle of putting as much work
] as possible from execution to compile time?

A better idea is to have the compiler do what it can do well, and let
the hardware do what it can do well. For example, compilers can do
register lifetime analysis well, but hardware does a much better
job handling interlocks from operations with variable completion times.

] Under this assumption, how does e.g. SuperSPARC fit this principle? As far
] as I know the processor does a lot of cross-checking between pipelines,
] squashing instructions depending on non-trivial conditions, etc. Is that done
] just to maintain compatibility with previous implementations?

It's an implementation trying to be a correct interpretter of it's ISA
( Instruction Set Architecture ). Otherwise, binaries for one Sparc
might not work on another Sparc.

] Could, theoretically, the most recent compilers take care of this
] at compile-time, thus eliminating the need for run time
] checking (again theoretically since people want to run their old code).

Depends. Generally, scoreboarding in the hardware produces better
performance ( when coupled with compiler reordering of the instructions
to minimize time spent waiting for results ) than adding the worst-case
number of No-ops ( which will vary from system-to-system ).

] Wasn't the architectural(?) definition of using exactly one delay slot
] extremely short sighted, taking into account the much longer pipelines in
] current implementations?

Gack. Are we talking branch delays or load result-ready delays ? Longer
pipelines often don't affect the branch anyway ( if it's done in
it's own peice of special hardware ) altho pipelining the I-Cache
or instruction decode will. It all depends. Personally, I don't
like architecturally-defined delay slots anyway : there are usually
ways to get rid of them ( speculative issue for branches, load
queues with hardware interlocks for loads ).


] Aren't pipelines necessary so that instructions that take several cycles
] (i.e. "complicated" instructions) can be issued one per cycle?

Pipelines trade thruput for latency at the cost of complexity.

] Wouldn't it conform more to the RISC principle to keep instructions so
] simple that they only *need* one cycle to execute and concent rate on a *fast*
] memory interface instead?

Actually, one of the claimed advantages of RISC architectures is that
they are easy to pipeline. A machine with a 5-stage pipeline, if you
took the pipelining out, would probably issue instructions at 1/3rd
or so of it's original rate, due to it needing a much slower clock.

] Will RISC go the way that CISC went?

RISC (in micros) went there (pipelined) first, actually.
--
Dennis O'Connor			doconnor@sedona.intel.com
Newsgroups: comp.arch,comp.lang.misc
From: rob@pact.nl (Rob Kurver)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: PACT, Delft, The Netherlands
Date: Fri, 13 Nov 1992 22:17:05 GMT

In <1992Nov13.155126.3660@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:

>Herman is bemoaning the fact that quite often a computer HAS hardware
>to execute some particular instruction that he likes, but that HLL's
>do not allow him access to it.

[ .. ]

>I would like to see a language that has a feature that will allow
>me to (say) define new operators that use specific machine instructions.

Many modern C compilers have powerful assembly insert mechanisms which
allow you to make use of the more esoteric machine instructions, when
available.  Examples that come to mind are the GNU C compiler and
our own PACT Parallel C compiler for the transputer.  We use this
in our runtime and headers to keep things portable yet get the most
out of the architecture (e.g. use 32x32->64 bit multiply instruction
when available, or an emulation function when not).

I'd expect this to work even nicer when combined with classes and
operator definitions in a language like C++.

Rob

--
     PACT                   Rob Kurver
    Foulkeslaan 87         rob@pact.nl
   2625 RB Delft     ph: +31 15 616864 
  The Netherlands   fax: +31 15 610032
From: john@gu.uwa.edu.au (John West)
Newsgroups: comp.arch
Subject: Re: Integers implementation
Date: 8 Nov 1992 05:42:08 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: mackerel.gu.uwa.edu.au

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

>>Most of today architecture use 2's complement scheme to represent
>>signed integers. About other possibilities, like 1's complement,
>>I have the following questions:

>> - What are their advantges ?
>> - What are their drawbacks ?
>> - Are they usefull for any given set of aplications ?
>> - Are they likely to pop-up in future processor design ?

Well... its considerably easier to look to the past. The PDP-1 was a 
1s complement machine. I'm sure there were others.

>For 2's complement, the advantages are simplicity of multiple-precision,
>and this can take many forms, including size expansion, and the fact that
>there is only one 0.  This last is a real problem for the others.

Also, the circuits for addition are a lot saner. I don't know of any nice
way of adding 1s complement or sign-magnitude.

>The alternatives I have seen are  1's complement and sign-magnitude.  The
>advantages are that negation is very much simpler, as is absolute value.
>Since the negative of a negative number is always positive, it does not
>have the problem which 2-s complement machines have, that the negative 
>of the most negative number comes out negative.  

But then there are 2 0s. This can make life unpleasant.

Of course, it is not inconcievable that some application will pop up just
begging for 1s complement.

John West
--
For the humour impaired: Insert a :-) after every third word
Newsgroups: comp.arch,comp.lang.misc
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Re: A challenge to the anti-goto (C code included!)
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 5 Nov 1992 20:37:59 GMT

In article <1992Nov3.053951.7786@cognos.com> alanm@cognos.com (Alan Myrvold) writes:
:In article <BwxsF6.3DF@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
:>Put in any short code you want for the ...   I doubt that the code
:>as written is legal C with the missing parts inserted.
:>
:>extern B;
:>n = 0; m = 0; b = B;
:>{goto start;
:> case 1:	n += 1;
:> case 3:
:
:There are always these goals when programming:
:   1) The program should communicate its intention clearly to a human reader
:   2) The progran should communicate its intention efficiently to the machine
:   3) The program should be portable across hardware / software changes
:Given the code fragment you posted, I would suggest, Dr. Rubin, that you 
:spend less time on #2, and more time on #1.  
:
I would suggest Mr. Myrvold, that you attend to your business and let
Dr. Rubin attend to his.
 
Stop telling him what his business should be. You assertion:

"There are AWAYS"

is dogmatic and wrong, because not everyone has the same objectives
as you. Dr. Rubin's main rule is:

"The code should run as fast as possible"
 
For him, all other considerations are secondary. Who are you to tell
him what his priorities should be?

Just to further contradict your dogma, let me point out that portable
code for doing multiple-precision arithmetic that runs well on one
architecture can run like total dogshit (pardon my vulgarity) on 
another. Sometimes, portability is a very minor issue. The absence or
presence of a single machine instruction can sometimes give dramatically
different results.

There are times when readability, portability, and ease of maintenance are
of primary importance. There are times when they don't matter at all. Stop
pretending that they are the end-all of good coding.


--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.arch
Subject: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Date: 8 Nov 1992 08:16:44 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley
Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
NNTP-Posting-Host: 128.3.112.15

In article <1917307@zl2tnm.gen.nz> don@zl2tnm.gen.nz (Don Stokes) writes:
>... most machines only handle 32 bit or less integers cleanly, and
>with two decimal places that's only up to $21,474,836.47 (assuming signed
>integers).

Signed integers are not an absolute must, but precision greater than
one penny is; most businesses seem to keep records to five digits or so.

>Machines that can handle 64 bit integers cleanly will make this problem
>largely go away.  8-)

Hm, my kitchen arithmetic says that 2^64 only represents 1844 trillion
dollars in mills.  At its current growth rate, the U.S. national debt
will exceed this well within the next century.  Of course, by then the
nation itself will be completely bankrupt, so this will not matter. :-)

Current 32-bit microprocessors are capable of handling 64-bit quantities
moderately well.  Current versions of GCC support them directly.  64-bit
integer arithmetic is well on its way to becoming established practise.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
Newsgroups: comp.arch
From: martyi@nubbins.wpd.sgi.com (Marty Itzkowitz)
Subject: Re: MINIMUM instruction set
Reply-To: martyi@sgi.com
Organization: Silicon Graphics, System Software Division
Date: Fri, 13 Nov 1992 17:12:53 GMT

>Well, it's certainly practical.  The PDP-8, for example, had a total of
>seven instructions, and while it wasn't any speed demon and wasn't the
>best machine to program that I can think of, it worked and plenty of them
>were sold.

The PDP-8 had seven OPCODES, not seven instructions.  Two of them,
OPR and IOT were microcoded, and so it had many more instructions than
that.  By the above logic all RISC machines have only one instruction because
the instructions are, after all, just microcoded words.

As a humorous aside, judicious use of the OPR microcde on some of the PDP-8
machines, could even generate a  CISCy "set accumulator to 2" instruction =
	CLA CLL CML  RTL
This worked on a PDP8/S in run mode, but, oddly enough, not in single step. I
never tried it on the other PDP-8 flavors.

	Marty Itzkowitz
Newsgroups: comp.arch,comp.lang.misc
From: hasty@netcom.com (Amancio Hasty Jr)
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
Subject: Re: IDE faster than Mips SCSI disk
Date: 6 Nov 92 15:45:56 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

Could someone with a fast IDE drive and VESA local bus IDE controller
run  IOZONE. I heard of upto 20MB/s data transfer on a local bus 
system. I was going to check-it out the system but they sold out.


Amancio
Newsgroups: comp.arch,comp.unix.bsd,comp.os.linux
From: mccalpin@perelandra.cms.udel.edu (John D. McCalpin)
Subject: Re: DEC ALPHA Performance Claims
Summary: oops, minor correction
Organization: College of Marine Studies, U. Del.
Date: Fri, 13 Nov 1992 11:25:34 GMT

In article <BxM8xv.EFI@news.udel.edu> mccalpin@perelandra.cms.udel.edu (John D. McCalpin) writes:
>----------------------------------------------------------------------
>It is also interesting to note that the DEC AXP 3000/500 at 150 MHz
>has almost identical LINPACK 100x100 and LINPACK 1000x1000 numbers
>with the IBM RS/6000-970 at 50 MHz.   Prices are similar, with DEC
                 ^^^^^^^^ [should be RS/6000-560]
>appearing to have a slight edge: $39k vs ~$55k.
>----------------------------------------------------------------------
Sorry that I don't have the HP numbers handy....
-- 
--
John D. McCalpin                        mccalpin@perelandra.cms.udel.edu
Assistant Professor                     mccalpin@brahms.udel.edu
College of Marine Studies, U. Del.      John.McCalpin@mvs.udel.edu
From: kc@dcs.ed.ac.uk (Kenneth Cameron)
Newsgroups: comp.arch
Subject: Re: ************* Architecture Project HELP ************
Date: 11 Nov 92 21:42:58 GMT
Reply-To: kc@dcs.ed.ac.uk (Kenneth Cameron)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

In article <1992Nov9.195547.10130@cc.umontreal.ca> cholette@JSP.UMontreal.CA (Cholette Martin) writes:
> I have a class in computer architecture, and I have to make an oral
> and written presentation for my class project. I can choose whatever
> subject I want ( subject to approval of course ) that is related to
> comp. architecture. My oral presentation must be between 30 - 50 minutes,
> and the written report must be 10-20 pages. I am a 3rd year comp. sci.
> student. 
>
> Does anyone have any suggestions as to which topic I should choose?
> I am looking for something recent and hopefully " cool and interesting "
> I would prefer to do it on a topic that is relatively unknown, hence
> my difficulty in finding a subject. I would appreciate any insight!

A quick straw poll here in the final year CS hardware labs at Edinburgh
yielded the following topic suggestions:

     1. Data flow machines
     2. Systolic array processing
     3. Decoupled architectures.

And if you don't already have it, get hold of a copy of Hennesay and Patterson.
It will prove a useful source of references.

> Thanks a million!
Your welcome. Good luck.

> Martin Cholette
> cholette@jsp.umontreal.ca
--
Kenneth@Edinburgh.ac.uk                                         kc@dcs.ed.ac.uk
4th Year Honours Student, Dept of Computer Science, The University of Edinburgh
Project: Acceleration of Constructive Solid Geometry Using a Custom VLSI Device
Newsgroups: comp.arch