HDTenEightyP/NetNews huggingface dataset:
From: snail@lsl.co.uk
Newsgroups: comp.arch,comp.lang.misc
Subject: <None>
Date: 10 Nov 92 16:24:01 GMT
Organization: Laser-Scan Ltd., Cambridge

In article <1ct342INNd4k@agate.berkeley.edu>, jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:
[code example deleted]
> The second piece of code is easier to understand and no slower than the
> first.  Depending on the compiler, it's likely faster.

Absolutely 

> Exactly how much duplication to tolerate can be an engineering decision.
> However, if I hear you right and you're trying to get every possible ounce
> of speed out of a single subroutine, you'd be wise to trade off an increase
> in program size for an increase in the distance between branches and a
> reduction in the number of `goto's.

There's a guy here, (as raster handling expert) and he needs to handle data in
many word sizes, but do the same operation (filtering, shearing etc) so he
has several routines and in each routine is a switch statement for each data
size. Recently the compiler fell over... the branches in the case statements
were over 32K in length! Typical of a 32 bit machine that, 16 bit branch
offsets. We had a good laugh at that. However, he's done a slight change so
that doesn't happen now, and the code performance before and after is excellent
- don't worry about large switch/case statements, if performance is what you're
*really* after.
>  As long as you don't bloat your code so
> badly that it won't fit in the on-chip cache, you can improve both the
> speed and the structure of your code this way.

Not knowing how big the cache on a MIPS R3000/SPARC 2/HP SNAKE PA CHIP/RS 6000
/ALPHA and they're all different, we just go ahead and do the code anyway.
> 
> Just my $10 worth.
> 
> ----------------------------------------------------------------------------
> Boycott redwood.  Boycott Louisiana-Pacific.  Keep the forests.  YYYYYYYYYYY
> John Hauser---jhauser@cs.berkeley.edu  YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY

Just my new 10p (horrible coin) worth
-- 
snail@lsl.co.uk      

You Have To Remember, You Need To Beleive,
The Time Has Past, Dust In The Leaves.
From: gjr@zurich.ai.mit.edu (Guillermo J. Rozas)
Newsgroups: comp.arch
Subject: Re: why no register + register addressing mode in R3000
Date: 10 Nov 92 11:12:23
Organization: M.I.T. Artificial Intelligence Lab.
Reply-To: gjr@zurich.ai.mit.edu
NNTP-Posting-Host: chamartin.ai.mit.edu
In-reply-to: endecotp@cs.man.ac.uk's message of 9 Nov 92 17:23:22 GMT

In article <endecotp.721329802@cs.man.ac.uk> endecotp@cs.man.ac.uk (PB Endecott (PhD SFurber)) writes:

|   Of course for a load, you do have two read ports available.  Would anyone
|   consider an architecture with non-symetrical addressing modes, where loads
|   can do register+constant or register+register, but stores can do
|   register+constant only?
|
|   Another feature that some processors have and others don't is
|   auto-indexing.  During loads, this requires an extra write port (or an
|   extra cycle) to put the modified value back in the register; but during
|   stores the write port is not used for data.  So how about an architecture
|   with autoindexing for stores but not for loads ?

The HP-PA (1.1) architecture has indexed integer loads but no indexed
integer stores.  It has both indexed floating-point loads and stores.
It has auto-increment on both loads and stores.

Xref: sparky comp.arch:10670 comp.benchmarks:1675
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch,comp.benchmarks
Subject: Re: DEC ALPHA Performance Claims
Date: 12 Nov 92 20:24:44 GMT
Article-I.D.: cs.BxME1C.6Gt.2
Organization: School of Computer Science, Carnegie Mellon


cmg@magnet.cray.com writes:
>      (NOTE: The performance above which is attributed to a CRAY-1 is
>      actually that of a CRAY S-MP, NOT a CRAY-1.

Yes, I screwed up. Sorry it bothered you: I hadn't posted a
correction, because that number wasn't important to my point.

>On this particular benchmark,
>we would see a 3x speed improvement attributable to software.
>The improvement of microprocessor speed of the past decade has been
>tremendous.  How much of this improvement is attributable to software?

We should get John Mashey to give us a graph of SPECmarks versus
time, chip held constant. Several chips (the 88100, for instance)
noticeably picked up speed this way.

In general, optimization has the most leverage on numerical
benchmarks, since their execution times are most likely dominated by
some smallish stretch of code. We would expect SPECint to have been
bent less than SPECfp. Of course, in real life, a lot of performance
is dominated by disk speeds and the like, so improved compiler
technology doesn't always play a role.
-- 
Don		D.C.Lindsay 	Carnegie Mellon Computer Science
From: alan@sal.wisc.edu (Alan Watson)
Subject: Re: DEC Alpha AXP System Performance
Keywords: Alpha, AXP, SPEC, DEC
Organization: Space Astronomy Lab, Madison WI
Date: Thu, 12 Nov 1992 14:37:43 GMT

In article <1992Nov12.101520.2828@crl.dec.com> jg@crl.dec.com (Jim Gettys) writes:
>In article <martin.721554717@bert>, martin@math.rwth-aachen.de (  Martin Schoenert) writes:
>> [specs for US models]
>> 
>> 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
>> 
>> [specs for German models]
>> 
>> 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? ;-)
>
>The reason is simple: folks were working on the compilers and remeasuring SPEC results
>up until the last possible moment before annoucement.  Some earlier results
>seem to have slipped through the cracks.  Of course, we continue to work
>on the compilers, and yet better results can be expected in the future :-).
>Significant improvements were made in even the last week (and weekend) before 
>annoucement.

Nah, the real reason is that European computers run 16% slower because
European power arrives at 50 Hz, as opposed to 60 Hz over here.
From: john@gu.uwa.edu.au (John West)
Newsgroups: comp.arch
Subject: Re: What's wrong with stack machines?
Date: 6 Nov 1992 02:23:56 GMT
Organization: The University of Western Australia
NNTP-Posting-Host: mackerel.gu.uwa.edu.au

lindsay+@cs.cmu.edu (Donald Lindsay) writes:

>>You have to consider stack machines according to their own strengths, not how
>>well or not well they handle non-stack language programming techniques.

>Surely typical stack-language programs can be mechanically
>transformed (recompiled) into non-stack forms.

And typical non-stack-languages can be transformed into stack forms. So?
You lose a lot of efficiency going both ways. There is no way a conventional
processor is going to run converted stack code as well as a stack machine.
Likewise, a stack machine is going to have a tough time on the converted
non-stack code.
The problem is that there hasn't been enough work done on stack languages.

John West
--
For the humour impaired: Insert a :-) after every third word
Newsgroups: comp.arch,comp.lang.misc
From: alan@sal.wisc.edu (Alan Watson)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Space Astronomy Lab, Madison WI
Date: Fri, 13 Nov 1992 20:02:22 GMT

In article <1992Nov13.155126.3660@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
> 
>Nothing so esoteric.  I get the *impression* that none of you are really
>listening to what he is saying.
>
>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 can cite one example that bothers me a lot.
>
>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 ?

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

If the compiler on your system does not provide an appropriate built-in
either persuade your compiler supplier to put it in, or pay them to put
it in, or use something like gcc or lcc and put it in yourself.

For example, on my MIPS machine I am able to access the abs.s instruction
in the following manner:

#if defined __mips && defined __GNUC__
#define __builtin_absf(y,x) \
    __asm__ volatile ("abs.s\t%0,%1 # __builtin_absf" : "=f" (y) : "f" (x));
#else
#define __builtin_absf(y,x) \
    if (x >= 0) y = x; else y = -x;
#endif
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: PA-RISC ``semantic loading'' (according to DEC)
Date: 13 Nov 92 17:32:28 GMT
Organization: Department of Computer Science, U of Copenhagen

lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>DEC's architects also have a low opinion of HP's high semantic
>loading. That is, HP has instructions that also do some second thing -
>such as skip-on-condition. The Alpha team avoided that, and have
>handwaving arguments about how this will help in future "aggressive"
>implementations.

I recently looked at the PA-RISC architecture manual, and, well ...
it has a number of features that seem to make it easy and pleasant to
generate compact code for, but they probably make for some pain as
well when they have to be implemented in a deeply pipelined,
more-than-twice superscalar chip.

  0) The programmer model contains a processor status register, with
     rapidly changing contents; it is only visible on interrupts, and
     with a special instruction, but it still has to be synchronized.

  1) ``Skip-on-condition'' sets a nullification bit in this PSR;
     nullification depends on the ALU results of one instruction, and
     prevents all programmer-visible effects of the next --- including
     data cache move-in, as far as I can see.

  2) The instructions that support multiprecision and BCD arithmetic
     have carry bits in the status register as implicit arguments.

  3) Changes to the virtual memory mapping of the instruction stream
     are guaranteed to take effect within 8 instructions.

Nothing that cannot be fixed with, e.g., a file of ``post-instruction
states'' with attending scoreboarding and bypass tricks, but perhaps
the transistors could have been used to decrease cycle time instead.

On the other hand, right now PA-RISC seems to get numbers for SPEC/MHz
that are quite a bit better than Alpha. While some of the difference
may depend on pipeline and cache effects, and compilers, I suspect
that PA-RISC can get by with executing fewer instructions as well.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Xref: sparky comp.arch:10395 comp.lang.forth:3444
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: why no register + register addressing mode in R3000 (repost)
Date: 12 Nov 1992 21:12:24 GMT
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
Distribution: world
Reply-To: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
NNTP-Posting-Host: flayout

In article endecotp@cs.man.ac.uk writes:
>Although it's true that both register+offset and register+register modes
>require an addition, you haven't allowed for the fact that an extra
>register read has to take place.  Normally most microprocessors have two
>read ports and one write port on the register file, which is exactly what
>is required for three address arithmetic/logical operations.  When you
>execute a store instruction, one read port is used for the data value, and
>the other for the address register.

Actually most microprocessors these days have a register file with many ports.
All major companies (DEC, HP, Intel, Sun, Motorola, SGI, etc), are developing
superscalar processors which require many ports.
Adding one read port for allowing the loads to use the register+register
addressing mode becomes a smaller overhead as a percentage of the (bigger)
register file. If you look at the layout of some of these chips you will
see that the register file represents a small part of the die.
Considering that this addressing mode can lead to saving an instruction
(addition), it can be a real advantage.

Here is the percentage of loads and stores for SPECint92 benchmarks
running on SPARC which use the two register addressing mode [RX + RY]:

benchmark	loads	stores
---------	-----	------
espresso	37%	9.8%
li		2.5%	2.8%
eqntott		76.4%	5.4%
compress	27%	7.3%
sc		13.5%	7.9%
gcc		18.9%	37.5%

The numbers show that the compiler (based on SunPro SC2.0.1) makes
good use of this capability. There are ways around this addressing mode,
but a significant portion of the above percentage do save an addition.

If there is interest I can look into the numbers for floating-point code.

- Marc Tremblay.
Sun Microsystems.
From: kitchel@manta.dpsi.com (Sidney W. Kitchel)
Newsgroups: comp.arch
Subject: Re: More Alpha AXP Performance Numbers
Date: 13 Nov 92 19:55:43 GMT
Organization: Data Parallel Systems, Inc

bds@mbunix.mitre.org (Smith) writes:
>It has always been DEC's position that small systems like workstations
>should be limited in ways that the larger systems are not.  For
>example, if you need 10 or 12 Ethernet ports, you can't get them in a
>small system.  Thus the (current) VAXstation 4000/90 only allows 2
>Ethernet ports (using the Turbochannel port) while the VAX 7000/610,
>with the same 32VUP processor, allows 16 Ethernet ports.  Similarly,
>if you need sophisticated disk access, eg, DSSI, you can only get it
>on the larger machine while the smaller one uses SCSI.  Unfortunately,
>the choice of a machine in a large system is not as simple as looking
>at performance numbers/processor.

	This DEC position appears to be altering. The DS5000/240 now
has access to DEC's big disk technology, i.e. disk arrays and
intelligent controllers. It comes through a TurboChannel to Computer
Interconnect (CI) adapter. The amount of disk and performance available
this way is well beyond what you get through the SCSI port. This same
adapter is available on the "Big Max", DS5900, which can be upgraded
to an Alpha processor. 
	The smaller AXP's could also use the same approach to allowing
a small Alpha server to connect to an industrial strength disk farm.
The DEC folks might like to comment on whether CI will be available on
all of the AXP configurations.

							--Sid

--
Sidney W. Kitchel  	    kitchel@cs.indiana.edu, kitchel@dpsi.com
Data Parallel Systems, Inc.  ============||  DPSI  ||===============
4617 E. Morningside Drive	                      (812) 334-8100
Bloomington, Indiana,  47408  USA		FAX:  (812) 334-8121
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: Re: DEC Alpha AXP System Performance
Organization: Digital Equipment Corporation
Date: 11 NOV 92 10:38:55    


In article <1992Nov11.143555.20306@kpc.com>, paulk@kpc.com (Paul Kalapathy) writes...
>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. 
> 
>I suspect that the main reason for this is that HP has had considerably
>more time for their compilers to mature on the PA.  Remember that the
>Precision Architecture has been around since the mid-80's whereas the
>Alpha architecture is new.
> 
The answer is not that simple. HP has a slower clock, but shorter pipeline, and
they have a larger first level cache, but no secondary cache. It is very 
difficult to compare different machines without actually running benchmarks and
applications. What matters is the delivered performance and cost. Don't just 
look at aggregates like SPECmarks; individual benchmark performance varies.

/d
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch
Subject: Re: RISC goes CISC?
Date: 11 Nov 92 21:55:14 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <1992Nov11.011822.20226@labtam.labtam.oz.au> graeme@labtam.labtam.oz.au (Graeme Gill) writes:
>In article <15394@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
>> Do you, or does *anybody* else, have *any* solid evidence for the claim
>> that I've heard advanced on occasion that the 586^H^H^HPentium really
>> has a "native RISC mode" that can really execute "native RISC mode" code
>> directly?
>
>	And it would be disappointing (although not un-expected) to find
>Intel introducing yet another (different) RISC instruction set. They
>already have the 860 and the 960, why invent another one ?

The i860 is going down the pan, but the new chip to be used by Intel
SSD and which will be x86-ish will have a new instruction set.  This
SSD chip is due in 1996.  I wonder if it's really the Pentium?

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.
Newsgroups: comp.arch
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: Re: RTX and SC32
Organization: MIND LINK! - British Columbia, Canada
Date: Sat, 7 Nov 1992 09:25:55 GMT

lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes:

>+ These chips can also run several operations in parallel (without
>+ pipelining), accessing stacks, memory, and I/O simultaneously.
>
> It would be interesting to know exactly what instructions cause this
> (alleged?) speedup.  Could one or two instructions be added to a standard
> RISC processor (SPARC/MIPS/m88k/RIOS/HP-PA) to support the same operations
> and provide the same speedup?

I only have the instruction list for the Novix 4000: the predecessor of the
RTX series.  It has eight instructions that pack five operations in one
instruction.  An example is DUP nn I@ SWAP -, which does two stack
manipulations, a memory fetch, an internal register (I/O I think) fetch, and
an arithmetic operation.  That takes two clock cycles, due to the memory
access.

There  are also four, three, and two operation instructions, which are useful
more often.  Operations sequences such as SWAP DROP, DUP !, R> DROP, and OVER
SWAP - are commonly used in programs, but run inefficiently on "normal"
processors.  I'm unfamiliar with the internal register usage or literal fetch
instructions, so I can't say how frequently they'd be used in a program.
They sound like they could be useful for time-critical loops.

The multiple-operation instructions are based on the architecture of the
stack processors.  I don't see how you can add them to one of the processors
you mentioned, at least not without greatly increasing complexity and/or
restricting operations.

> I suspect that standard RISCs already provide what is needed to run Forth
> efficiently, they just are not handled in one cycle on load/store machines.
> If a particular operation takes 2 instructions on a load/store machine and
> one instruction on a "Forth machine", but the Forth machine requires two
> cycles to do it, what is the advantage of the Forth machine?
>
> So, the question remains:  are there any Forth operations which are not
> efficiently supported on the current crop of RISCs, and are on the named
> Forth machines?  If so, what operations are they, and why?  Could they be
> added to the current RISC architectures without major damage?

One very time-critical part of Forth programs is subroutine calls and
returns. There are a _lot_ of them in a typical program.  I don't have a
reference handy, but I think it's something like 10-20% of the instructions.
Forth processors are designed to make a call in one clock cycle, and a return
taking zero cycles (simultaneous with another instruction).  Standard
load/store machines do not offer that fast call/return feature.

Efficient access to two stacks plus memory is also not available--as far as I
know--in standard load/store machines.

So, to answer your question, the load/store machine does not offer the
critical instructions in 2 clock cycles.  The Forth machines offer them in
one or zero cycles.

--

Nick_Janow@mindlink.bc.ca
From: solman@athena.mit.edu (Jason W Solinsky)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 13 Nov 92 14:01:21 GMT
Organization: Massachusetts Institute of Technology

In article <1992Nov10.211153.5992@ryn.mro4.dec.com>, bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
|> 
|> In article <BxIJxr.GD5.1@cs.cmu.edu>, nickh@CS.CMU.EDU (Nick Haines) writes...
|> > 
|> >Two questions:
|> > 
|> >	- how much do these machines cost? What's the SPEC/$?
|> 
|> DEC 3000 Model 400 AXP starts at $15K
|> DEC 3000 Model 500 AXP starts at $39K
|> DEC 4000 AXP starts at about $70K
|> DEC 7000 AXP starts at about $150K
|> DEC 10000 AXP starts at about $300K

I can't believe that DEC still hasn't learned enough to put out a micro
immediatelly. How long is it going to be before they put together a minimal
Alpha system and sell it at a reasonable price?

Is anybody out there trying to use the Alpha in a small box and beat them
to the punch?

Jason W. Solinsky
Newsgroups: comp.arch,comp.lang.misc
From: jch@rdg.dec.com (John Haxby)
Subject: Re: CLU break and continue (Was: Re: A challenge to the anti-goto)
Organization: Digital Equipment Corporation
Date: Mon, 9 Nov 1992 17:57:37 GMT

In article <BRADLEY.92Nov9101822@marley.think.com>, bradley@marley.think.com (Bradley Kuszmaul) writes:
|> In article <1992Nov9.114323.22688@rdg.dec.com> jch@rdg.dec.com (John Haxby) writes:
|> 
|>    ...
|>    Apart from the local/procedure-call difference the two mechanisms are
|>    identical, although `signal' tends to be expensive and `exit' is simply
|>    an unconditional branch. ...
|> 
|> The signal is not as expensive as you might think.  This is because the

I should've said `relative to return or relative to exit'.

Once, long ago I implemented something that treated `signal' as
though it were a form of `return'.  It wasn't fast -- the program spent
most of its time in the signal dispatcher since (a) the offending procedure
was used for each input token and (b) the program didn't do very much
else.  Mind you, if I'd done the same thing in Ada it may well have been
running to this day.... (if it worked, the unhandled exception thing in Ada,
as you say, is rather silly).

-- 
John Haxby, Definitively Wrong.
Digital				<jch@rdg.dec.com>
Reading, England		<...!uknet!wessex!jch>

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.
Newsgroups: comp.arch,comp.lang.misc
From: solman@athena.mit.edu (Jason W Solinsky)
Newsgroups: comp.arch
Subject: Re: MINIMUM instruction set
Date: 13 Nov 92 14:11:22 GMT
Organization: Massachusetts Institute of Technology

In article <1992Nov10.235849.19192@fcom.cc.utah.edu>, val@news.ccutah.edu (Val Kartchner) writes:
|> I've heard that it is possible to implement all programming languages with
|> seven instructions.  (Possible does not mean practicle.)  Does anyone know
|> what these instructions are?  Is it possible to do all operations in less
|> than seven instructions?

I am quite sure that it can be done with 1 instruction. I think you need to give
us a definition of instruction.

Jason W. Solinsky