HDTenEightyP/NetNews huggingface dataset:
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Date: 20 Nov 92 18:33:38 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout

In article <1992Nov19.204729.24714@crl.dec.com> payne@crl.dec.com (Andrew Payne) writes:
>>The last sentence is key here. If branches can be predicted with decent
>>accuracy then it is hard to obtain benefits from conditional moves
>>over using conditional branches. 
>
>Do you have any data to back up this claim?

Sure do. If branches can be predicted with 100% accuracy then the
version with conditional branches may run up to twice as fast. :-)
Seriously, the silly example above should nonetheless show that if
there are many instructions to guard, then potentially only half of the 
functional units will accomplish useful work while running the code
surrounded with conditional moves. 

As a previous poster mentioned, it would be nice to get some
numbers on the impact of conditional moves on a superscalar processor
with good branch prediction. Not on a 10 line function but on a large
integer program (some of the SPECint92 programs).

>Don't forget that conditional move sequences can be shorter than the 
>corresponding branch sequence.  In other words, the two instruction
>sequence branch/op can sometimes be replaced with a single conditional move 
>instruction.

True. I have seen some great little examples where conditional moves
perform very well [e.g. if (a>b) then c=3 else c=5] or finding max (a,b).
Notice that in most examples, either the guarded code is very small
and/or the branches could not be predicted well.
 
>Second, I believe the second order effect of providing larger basic blocks
>is the conditional move's greatest benefit.  Larger basic blocks offer
>more scheduling opportunities.  I don't have any data (yet), but I've 
>certainly seen it happen.

Since conditional moves won't replace all of the conditional branches,
a good compiler will have to handle moving instructions across
conditional branches anyway, otherwise performance will be low.
Large basic blocks can be created through several methods
(e.g.superblocks from Illinois) that basically group basic blocks together.
Conditional moves will help wherever branches were hard to predict
or where the trace did not show any definite direction for the branch
(once again, hard to predict branches).

Finally, as you may know, SPARC V9 (64-bit) does include conditional moves
and we do think that we can get some benefits out of them.

- Marc Tremblay.
Sun Microsystems.
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: 23 Nov 92 10:05:25
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<martin.722176263@bert>
	<1992Nov20.135747.4642@sun0.urz.uni-heidelberg.de>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: dentzer@clio.iwr.uni-heidelberg.de's message of Fri, 20 Nov 92 13:57:47 GMT

In article <1992Nov20.135747.4642@sun0.urz.uni-heidelberg.de> dentzer@clio.iwr.uni-heidelberg.de (Ralf Dentzer) writes:

   As some sort of compromise between portability and efficiency I would make
   the following proposal for a set of basic functions to deal with multiple
   digit integers. The main restriction for them is the imposition to have a 
   C-function interface, but only thus portability can be guaranteed.

Good; that's the right way to go.

   First there should be a data type "Digit_t" e.g., usually unsigned long
   or what else fits into one register, and a constant BitsPerDigit.
   Then come six functions for calculating with Digits, these provide
   access to carrys, the higher digit of a product and a division
   with two digit dividend:

   Digit_t DigitAdd(Digit_t *sum, Digit_t a, Digit_t b, Digit_t carry);
	   /* *sum=LOW-DIGIT(a+b+carry);
	      return HIGH-DIGIT(a+b+carry); 
	   */
   [...]

   These functions are sufficient to build a multiple digit arithmetic,
   but due to function call overhead they are too slow.
   (More or less, depending on the processor; on a Sparc their
   performance is not that bad.)

You could standardize these as macros, not functions.  The main
user-visible difference would be in not being able to take the
address. Even if you do define these as functions, your compiler
could (and should) inline them.

Also, a slightly better interface might be to turn this into a
conditional construct, conditional on the carry bit:

	CPU_WORD result,a,b;
	...
	ADD_WITH_CARRY(result,a,b) { /* carry==1 */ }
	else { /* carry==0 */ }


					Thomas.
Newsgroups: comp.arch
From: uesu03@giac1.oscs.montana.edu (Lou Glassy)
Newsgroups: comp.arch
Subject: What happened to the UCSD p-System?
Date: 17 Nov 92 16:24:28 GMT
Organization: Montana State University, Bozeman  MT

Is the idea of running code on virtual machines dead?
Found a couple of old books yesterday on the p-System and 
MINT.  

The possibility of taking my binary from machine to machine,
(with possibly different physical architectures), and having
it run without dinking, is an intriguing one.

Is any work going on in this area?  Or does performance pay
more than portability?

Thanks in advance,

Lou.

-- 
Lou Glassy (uesu03@giac1.oscs.montana.edu)   Watch the field behind the plow
Earth Sciences Department                    Turn to straight, dark rows
Montana State University                     Put another season's promise
Bozeman, Montana 59715 USA                   In the ground...  --Stan Rogers
Newsgroups: comp.arch
From: bt@irfu.se (Bo Thide')
Subject: Re: DEC Alpha AXP System Performance
Date: Mon, 16 Nov 1992 13:11:26 GMT
Organization: Swedish Institute of Space Physics, Uppsala, Sweden

In article <1992Nov10.212454.6317@ryn.mro4.dec.com> bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) 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. 
>> 
>>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


Don't forget that the 735 is both faster and less expensive than the
DEC 3000/500 AXP:

9000/735: 80   SPECint92,   150.6 SPECfp92  at $35k
500AXP:   74.3 SPECint92,   126.0 SPECfp92  at $39k

Bo
-- 
   ^   Bo Thide'--------------------------------------------------------------
  |I|        Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden
  |R|      Phone: (+46) 18-303671.  Fax: (+46) 18-403100.  IP: 130.238.30.23
 /|F|\          INTERNET: bt@irfu.se      UUCP: ...!mcvax!sunic!irfu!bt  
 ~~U~~ ----------------------------------------------------------------sm5dfw-
From: maf@hpfcso.FC.HP.COM (Mark Forsyth)
Date: Thu, 19 Nov 1992 17:28:29 GMT
Subject: Re: DEC Alpha AXP System INTEGER Performance
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.arch


In comp.arch, blair@snogum.enet.dec.com (Blair Phillips - Digital) writes:
> 
> 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.

I've been hearing about this claimed architectural advantage for months now
but still don't get it.  For example:

1) why is the cache to register file path so critical in the alpha chip ?  
this is not the case with all microprocessors.  especially the store path - 
I thought that address generation was usually tougher.  is this another
"superpipelining" dividend ?

2) multiplexers can be made VERY fast -  they only add a transfer gate and
wire delay in the data path (or you can just use the transfer gate already
needed for the register input). why not just speed up this circuit, or take 
a slight amount of time from the cache access (should be easy with on-chip 
primary cache) or register setup time ? or add another transparent data 
latch in front of the multiplexer so it can be done in a different clock 
cycle ?  perform the multiplexing in existing cache circuits ?  (your idea
here) ? 

3) is it really forward looking to modify the instruction set because one
circuit design had trouble meeting its speed budget ?  isn't it conceivable
that other implementations won't have the same critical speed path ?

Do other processor designers see any fundamental speed advantage for alpha 
due to this decision ?  Alpha certainly is fast, but I would guess that this
is due more to the long pipeline, the special VLSI technology DEC developed, 
a willingness to sort out the very fastest parts in the speed distribution 
for the mainframe version (even DEC says 200MHz is not available "in volume") 
and good circuit designers rather than instruction-set wizardry.  It is 
unfortunate that marketeers can't be satisfied with just good engineering.

- Mark Forsyth   (my opinions, not HP's) 
  maf@fc.hp.com
From: mitch@ross.com (Mitch Alsup)
Newsgroups: comp.arch
Subject: short forward branch
Summary: conditional move not necessary
Date: 23 Nov 92 18:48:56 GMT
Distribution: usa
Organization: ROSS Technology, Inc. Austin, Tx.
Originator: mitch@sparhawk

willmore@iastate.edu (David Willmore) writes:
keiths@cae.wis> c.edu (Keith Scidmore) writes:
> 
> >1. The DEC Alpha includes a conditional move instruction that they claim
> >   can be used to avoid using branches and the associated branch penalties.
> >   I'm trying to evaluate the usefulness of this feature.  Can someone tell
> >   me where I might find articles that discuss this or raw data that can be
> >   used to calculate the advantages of such an instruction.  I'm not into
> >   compilers, and I need to know what kinds of situations an optimizing
> >   compiler could make use of this instruction.  Is it even practical?  Are
> >   there any compiler writers out there with opinions on this?
> 
> You might try asking the HP people.  They were discussing the benefit of
> their conditional execution 'branches'.  Other people to ask, if you're
> brave enough, are the ARM people.  In their assembler, almost every inst.
> is conditional.

If one checks Guri Sohi's litterature, they will find that many architects
are rushing to find mechanisms to deal with these situations.  In particular,
almost all of these situations manifest themselves in where a small number
of instructions are skipped by a short forward branch.  Depending on the scale
of the fetch machine, the target of the branch instruction may already be inbound
from the instruction cache.  In these cases, there is no faster way to arrive
at the target of the branch than simply to wait for these instruciton to 
arrive.  THERE IS NO REASON TO DISRUPT THE FETCH MACHINE!  In onder to 
effect the taking or not taking of the branch, one must be able to identify
those instructions in the shadow of the branch.  When one determines the 
outcome of the branch, then one can execute these instructions or discard
them.  THERE IS NOT REASON TO BACK UP THE MACHINE DUT TO THE SHORT FORWARD
BRANCH MISPREDICTION!

This means that branches are predicted accordint to three patterns; short forward
branches are predicted to be not taken and execution canceled follwing branch
determination, other branches are predicted and the machine is backed up on a
misprediction.  The key payoff is that the short forward branches are manipulated
ins such a way as to avoid disrupting the fetch machine.  The number of instructions
under the short forward branch is implementation dependent as it should be!

The addition of conditional move/... instrucitons is a cluttering of instruciton
sets and their decoders.

-------------------------------------------------------------------------------------
Mitch Alsup        mitch@ross.com
(512)-892-7802x231 ROSS Technology
(512)-263-5086     Evenings
Disclaimer:        I speak for myself.
-------------------------------------------------------------------------------------
Newsgroups: comp.arch
From: deraadt@newt.cuc.ab.ca (Theo de Raadt)
Subject: Re: Registerless processor
Organization: little lizard city
Date: Fri, 20 Nov 1992 06:11:03 GMT

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. There are two
banks of 8 registers, though which can be accessed depends on a bits in
the status register.

I wonder how this was implimented? I guess that in the early PDP11's the
registers did not exist at all. But certainly they must have fixed that
in later versions. Was it possible to run programs out of the registers
on a newer PDP11?
 <tdr.
--

This space not left unintentionally unblank.		deraadt@newt.cuc.ab.ca
From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: MIPS and MHz
Keywords: RISC, MIPS, cps
Date: 16 Nov 92 00:51:22 GMT
Organization: Silicon Graphics, Inc.

In article <BxMn1J.GB3.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
|> 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

|> 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.
YES.
It is interesting to note that the SUNFLASH introducing the low-end machines
emphasizes MIPS-ratings (and doesn't even say Dhrystone-mips....) and says:

"....
These new Sun(TM) workstations deliver 59.1 MIPS, with the SPARCclassic
offering industry-leading value at $63 per MIPS.
....
These new systems deliver more performance than `486 PCs, with 59.1
MIPS, 26.4 SPECint92 and 21.0 SPECfp92."

It is interesting to note the historical trend:

System	SPECint92	MIPS-rating	MIPS/SPECint92
SS IPC	13.8		16		1.2
SS2	21.8		28.5		1.3
-------------
SS LX	26.4		59.1		2.2
SS10/30	45.2		101.6		2.2
SS10/41	53.2		109.6		2.1

Yep:
1) Higher performance than `486 PCs: is certainly true, you can find 486 PCs
that are slower ... of course, you can find some that are faster,especially
with positioning in commercial market, and where 486DX2-66 certainly has a higher SPECint92.  The Sun's SPECfp92 is higher, I think.
2) There were no cost/SPECint or SPECfp numbers, just cost/(unspecified) MIPS;
obviously the former can be computed....
3) What's really fascinating is the combinations of compilers used to get
the various numbers (from other announcements):

CINT92: Sun C 3.0 Alpha
CFP92: Apogee C & FORTRAN 0.82 Alpha with integrated Kuck (for Classic & LX)
	Sun C & FORTRAN 3.0 Alpha + Kuck (for SS10s) 
MIPS: Dhrystone 1.1: Apogee C 0.82 Alpha
LINPACK: Apogee FORTRAN 0.82 Alpha

Apogee is listed as being available 1/93; the Sun compilers in 5/93.
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)
It will be fascinating to see which combinations real people will choose:
maybe somebody from SMCC would care to post something about advice to users about which compilers to actually buy?

 
-- 
-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94039-7311
Newsgroups: comp.arch,comp.lang.misc
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 21:56:36 GMT

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 have also been concerned
that no high level language other than Forth provides this sort of facility.
I have become MORE concerned that the ANSI C standard requires that the
straightforward expression of this NOT work, although it's possible to
write code that your compiler vendor may convert to this operation if
he was smart enough not to prohibit it...
-- 
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?
Newsgroups: comp.arch
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: DEC Alpha AXP System Performance
Reply-To: vhs@rhein-main.de
Date: Mon, 16 Nov 92 12:09:55 GMT

In article <1992Nov12.143743.2517@sal.wisc.edu> alan@sal.wisc.edu (Alan Watson)  
writes:
> 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. 

But at 220 Volts vs. 110 in the US, we can execute two instructions
simultaneously ;-)

--
Volker Herminghaus-Shirai (vhs@rhein-main.de)

Computer industry: Industry in which the number of units sold of any
given product is inversely proportional to its technical excellence.
See also: MS-DOS, Windows, IBM-PC, X, QWERTY,
          80x86, TrueType, Survival of the shittest.
Newsgroups: comp.arch
From: pettengill@cvg.enet.dec.com ()
Subject: Re: More Alpha AXP Performance Numbers
Reply-To: pettengill@cvg.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Wed, 18 Nov 1992 05:38:34 GMT


In article <1992Nov16.173306.9663@qb.rhein-main.de>, vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
|>> >memory, big caches
|>> 
|>> Just to rub the point in: the DEC 10000 AXP has:
|>> 
|>> - 6 processors
|>> - 2 to 14 GB of ECC RAM
|>> - up to 4 Futurebus+ IO busses
|>> - up to 8 FDDI (100 Mb/s network) links
etc
|>
|>yes, but...
|>
|>
|>
|>
|>...can it run MS-DOS?
|>
|>;-)
|>

Yep, it even runs MS-DOS, in fact it can run hundreds of copies of MS-DOS
thanks to SoftPC...

mulp
DEC, CVG cluster buster
any statements i make are worth less than the paper they're written on...
Newsgroups: comp.arch
From: grout@s11.csrd.uiuc.edu (John R. Grout)
Subject: Re: Registerless processor
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development
Date: Thu, 19 Nov 92 20:30:57 GMT

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
>"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......

"Fast memory" (accumulators as logic) was optional on the PDP-6 (a PDP-10
predecessor) and perhaps the KA10 also (I'm sure most KA10's did have it).
Moving code into fast memory was useful on the -10 (and -6) processors without
cache; MACRO-10 supported the practice by allowing sections of code to be
relocated (by the linker) for residence in fast memory (but the user had to
BLock Transfer (BLT) the code into fast memory and jump to it).  On PDP-10
processors with cache (the KL10 and KS10), it was better to keep tight loops
out of fast memory.

Sadly, the dual use of locations 0-17 as accumulators and memory helped doom
the -10 ISA... it created a potential data hazard between instructions using
an accumulator and any instruction which might be referencing that accumulator
as memory...  this made it very difficult to pipeline or micropipeline (even
worse than the VAX).

--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
From: stripes@pix.com (Josh Osborne)
Newsgroups: comp.arch
Subject: Re: IBM Clock-tripled 486
Date: 18 Nov 92 17:39:46 GMT
Article-I.D.: pix.BxxAEC.GGB
Organization: Pix Technologies -- The company with no adult supervision

In article <Bxx6MK.B47@inews.Intel.COM> rskinner@mipos2.intel.com (Rod Skinner) writes:
[...]
>IBM has a license from Intel to produce derivatives from the 80386 not 
>the 80486.  The IBM 486 SLC2 was introducted in June.  It is a clock 

Ahhh, the "486" is for marketing not to tell us the #cycles each instruction
takes, or what op codes are supported.  *sigh*

>doubled version of the IBM 386 SLC part.  It has a 16k on-chip cache
>and no on-chip math coprocessor but supports the standard Intel387 math
>coprocessor chip.  IBM introduced the "tripler" part at Comdex and will
>operate at 33 MHz externally and 100 MHz internally.

However the 386 takes more cycles to eexecute most instructions, so it
is less memory bandwith limited then 486es.  That means a *3 internal clock
is worth more for the integer ops on a 386 then a 486 (but can't help FP
because it is done off chip)..
[...]
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Xref: sparky comp.arch:10756 comp.lang.misc:3696