HDTenEightyP/NetNews huggingface dataset:
From: casey@gauss.llnl.gov (Casey Leedom)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: gotos in hardware
Date: 15 Nov 92 18:47:19 GMT
Followup-To: comp.arch
Organization: Lawrence Livermore National Laboratory

| From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
| 
| A goto, with no intervening possible exits, should be handled in such a
| way that that the hardware starts getting the code at the new location
| early, so that there are no unnecessary delays.  It could even issue
| instructions from that "new" code in the same way it does from current
| code.  The "structured" approach, where unconditional transfers are not
| the rule, prevents this type of optimization.

  Just because you don't see many explicit "goto"'s in ``structured
programs'' doesn't mean they aren't there.  They're usually hidden as
``structured goto's'': e.g. "break" and "continue" in C.

Casey
Newsgroups: comp.arch
From: dannyj@oakhill.sps.mot.com (Danny K. Jain)
Subject: Re: Performance of Alpha on SPECfp92 (alvinn and ear)
Organization: Motorola Inc., Austin, Texas
Date: Tue, 17 Nov 1992 01:25:50 GMT

tremblay@flayout.Eng.Sun.COM (Marc Tremblay) writes:

>Considering that this hypothetical HP machine has 2 cycle latency
>floating-point operations, much closer caches, muladd capabilities,
>smaller mispredicted branch penalty, etc., these numbers are quite
>surprising. They represent a swing of maybe 30% in the opposite 
>direction. DEC must be doing something pretty fancy with their
>compilers. Could someone from DEC comment on what kind of
>optimizations were used on alvinn and ear?

I think that the reason that Alpha has more Specmarks that HP, even if both
were at the same clock frequency, is because Alpha is a 2-issue machine while
the HP is a single issue machine.

-Danny Jain
-Motorola
Newsgroups: comp.arch
From: samf@yosemite.dell.com (Sam Fuller)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Keywords: Alpha, AXP, SPEC, DEC, INTEGER
Organization: Dell Computer Corporation
Date: Fri, 20 Nov 1992 22:06:15 GMT

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.
|> 
|> DEC chose pretty much the latter approach.

After reviewing the Alpha performance claims, I had the feeling that the integer unit
did not really run at 133Mhz.  It looked to me that the floating point pipeline was
superpipelined at 133Mhz, but that the integer side ran at a more reasonable 66Mhz.  The
pipes can operate independently and I imagine be dispatched in parallel, hence the 
superscalar appelation. In my opinion, either DEC did a terrible job of code scheduling 
for their integer pipeline or its not really running at 133Mhz or 200Mhz as the case may
be.



Anyone who knows care to comment on this analysis?


-- 
=================================================================
Sam Fuller                                  sam@yosemite.dell.com
Software and Technical Strategy 	           (512) 338-8436
Dell Computer Corporation   1807 West Braker Ln, Austin, TX 78758
=================================================================
Newsgroups: comp.arch,comp.lang.misc
From: dhd@exnet.co.uk (Damon)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sun, 15 Nov 1992 23:18:54 GMT

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?	

In Pascal, or some similar language where everything is built into the
language, like the exact read and write syntax and semantics, you would
have to add all these special cases for special machines and bloat the
language.  Therefore, to avoid inventing PL/1 all over again, they
shouldn't be put in at all.  (To avoid penalising evry implementation,
just like CISC.)

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.

Of course, ML's pattern matching is nice...

let val (x:int, y:string) = (mystery_function(args)):t1 ... t3 -> (int*string)

...which is maybe what you are after.

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,comp.lang.misc
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Purdue University Statistics Department
Date: Wed, 18 Nov 1992 20:07:31 GMT

In article <722061195@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>: From: hrubin@pop.stat.purdue.edu (Herman Rubin)
>: Message-ID: <Bxv2t2.4FH@mentor.cc.purdue.edu>
>: I have given examples.  Some have even introduced conflicts with previous
>: notation in the computer field.  A brief repetition of some of them is in
>: order.
>:         The use of | for or. [...]
>:         The use of ^ for exclusive or. [...]
>:         using * for indirection, [...]
>:         using & for  "address of", 
>:         Even the use of ; as a statement end conflicts with mathematical
>: 	notation almost two centuries old. 
>: SOME of this may have been inadvertent, and due to the ignorance of those
>: introducing the notation.  

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

>In the second place, Herman's claim that the above "notation conflicts"
>or "obfuscations" are *intended* to conflict or obscure is just silly. 
>It is fairly clear that the oritinators simply didn't *care* about the
>conflict with notations used to express completely different concepts,
>and were simply consuming characters from their palatte of available
>characters without much *attention* to conflict or obfuscation, let
>alone intent.  

It has been pointed out that there were other possibilities from the
palette of available characters.  And if they didn't *care*, as you 
put it, which I am almost sure most of them will deny, that is an
explicit statement to the mathematical and scientific community that
they will have to establish their own CS programs to develop it, and
consider what the CS language guys are doing as no more relevant than
natural language research into Nostratic.  Now I did not say that they
did not care, you did.
-- 
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: zstern@adobe.com (Zalman Stern)
Subject: Re: DEC Alpha architecture issues
Organization: Adobe Systems Incorporated
Date: Fri, 20 Nov 1992 09:26:35 GMT

In article <1992Nov19.204209.6619@nntpd.lkg.dec.com> dipirro@star.dec.com  
(Steve DiPirro) writes:
> 
> In article <lgnfc3INNqnt@spim.mti.sgi.com>, woodacre@mips.com (Michael  
Woodacre) writes...
> >In article <1992Nov18.210416.27212@nntpd.lkg.dec.com>,
> .. . .
> >Can you explain how this is different from kernel code with interrupts
> >disabled on any other risc processor? For instance, an R4000 can
> >implement uniprocessor-atomic "instructions" which are sequences of
> >MIPS instructions to implement complex functions by running code
> >in kernel level with interrupts switched off.
> 
> There are certainly similarities. PALcode "instructions" actually appear
> as single instructions in the Istream which is handy for debuggers, etc.
> PALcode runs with interrupts disabled, Istream memory management traps
> disabled, and complete control over machine state. The environment allows
> more flexibility and more possibilities than merely running in the  
"standard"
> environment with interrupts disabled.

This is true of trap/syscall instructions on the R3000, R4000, and R6000 as  
well. You will need properly written exception handlers to get all the  
benefits, but PALcode has to obey many constraints as well. I'm going to  
have to look at the details, but MIPS syscall may in fact conform to the  
PALcode architecture. I can't find where the Alpha arch. defines any  
functions which must be available only in PALmode.

If you really want an extra "privillege" level for "more flexibility and  
possibilities" (whatever those may be), you can add one without touching a  
single byte of user code. (the Alpha PALcall instruction looks almost  
exactly like the MIPS syscall instruction to an application.) If I  
understood Joel Boney's SPARC version 9 talk, they have something simillar  
to PAL mode in their privelleged architecture. Supposedly for reliability  
purposes more than anything else.

Like I said before, PALmode is more about usage than mechanism. (And it has  
to be on Alpha given that most of the mechanism is implementation specific.) 

(I use the MIPS architecture above because it is the one I am most familliar  
with. You may be able to substitute your favorite arch. without loss of  
generality :-))
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
  "Yeah. Ask 'em if they'll upgrade my shifters too." Bill Watterson
Xref: sparky comp.arch:10758 comp.lang.misc:3697
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 15 Nov 92 23:43:18 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <mwm.2n6z@contessa.palo-alto.ca.us> mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
>In <Bxq7y0.IJ@mentor.cc.purdue.edu>, hrubin@mentor.cc.purdue.edu (Herman Rubin) wrote:
>> With instruction scheduling, one place for an optimizer would be in the
>> ASSEMBLER, and even interaction between the programmer and the compiler/
>> assembler.  I do not know of any such.
>
>Herman, I've *never* seen you suggest something that hasn't been tried
>already, in some form or another. This is no exception. It's been
>tried. It didn't work very well.

On at least the Sun-3 cc/as there is a flag which implies that the
assember is doing something tricky with the code the compiler spits
out, eg some sort of peephole optimisation based on what the compiler
wanted to say rather than on what it actually said...

Ah, and on the Sun-4 as well, I see.  Though this isn't exactly what
Dr Rubin was talking about, I think, it's still relevant...


AS(1)                    USER COMMANDS                      AS(1)
 
NAME
     as - Sun-1, Sun-2 and Sun-3, Sun-4 and Sun386i assemblers

...

  Sun-4 Options
     -O[n]
          Enable peephole optimization corresponding to optimiza-
          tion  level  n  (1 if n not specified) of the Sun high-
          level language compilers.   This  option  can  be  used
          safely only when assembling code produced by a Sun com-
          piler.

-- 
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,comp.lang.misc
From: dhd@exnet.co.uk (Damon)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: ExNet Systems Ltd Public Access News, London, UK
Date: Sat, 21 Nov 1992 02:31:19 GMT

In article <BxxGKp.81A@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>             For numerical programming, C, if it had multidimensional
>arrays...

What do you mean, ``if''?

And to answer some of the rest of your points about language flexibility:

* You've been offered macros, albeit with syntax not perfect but
  semantics OK.

* You've been offered escapes to asm.  I use a standard method of
  portable coding which allows me to have basic C implementations of
  non-portable things, with fast (asm if necessary) versions for
  machines with the required (h/w and/or OS) features.

* It has been pointed out that mucking with the language syntax is
  *not* generally a good idea as it often has unforseen consequences,
  but arbitrary syntax preprocessors are available if you want them.

* You complain about operator overloading or bad symbol choice.  What
  are we meant to use, raw TeX?  The symbols chosen for C, for example,
  were chosen to be in the limited chracter sets, and to be *short*.
  (Have you noticed how much less typing a C equivalent to a PASCAL
  program can involve?)  Less bloated script gives fewer typos and
  better productivity.  (I resent typing BEGIN and END in Pascal when
  we all know that { and } works in C!)  Consider then hamming-coded
  for typical CS apps of the time---your ops will be long and ugly
  sometimes.

I won't even complain about lamentable style in your examples.  B^>

I'm sure you are a well-respected worker in your field.  (You are
probably even twice my age B^>.)  You are right that the world should
not revolve around CS, but why the h*** should it revolve around *your
branch of maths* instead when most of the workers in the field are not
in *your branch of maths* (maybe not even in maths).  Why should the
syntax not all be lamba-calculus if it should be something else?

It *would seem* from your postings that you demand the
computing-language world should rotate about the same centre as your
not-insubstantial one, whatever you protest to the contrary.  That is a
narrow view if true.

HOWEVER, your views are interesting to me at least, so this is most
definitely a ``put up or shut up message'' even had I the right and
temerity to spout one.  B^>

[An answer to your email will follow, I only just got back from
 Minneapolis.]

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.
From: lindsay+@cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: PALcode
Date: 21 Nov 92 16:10:49 GMT
Article-I.D.: cs.By2qA1.5z3.2
Organization: School of Computer Science, Carnegie Mellon

zstern@adobe.com (Zalman Stern) writes:
	[ talking about PALcode as abstraction, performance aside ]
>Also, it has a certain amount of  
>intellectual and logistical complexity. There's a layer between the OS  
>writer and the hardware. You must understand the layer, and somebody must  
>provide the code for the layer. If that interface is not a good match to  
>your needs there's going to be a problem.

DEC has published a detailed data sheet for the 21064, from which I
could hope to design my own PALcode. As for actually writing it,
that's just Alpha instructions: the user-mode tools and expertise
more-or-less carry over. So far, this is nicely analogous to writing
the lowest-level OS code on an Rx000.

The big difference is that DEC intends to have multiple Alpha
implementations (and fairly soon) and it is not guaranteed that
PALcode for the 21064 will be appropriate for any/all of the others.
This is the *only* reason why an OS group might decide not to be
in the PALcode business. And then, yes, they might dislike what
they get given, but that's life.

The upside here is that the Alpha could (for example) avoid the
strange situation of the 386 power management modes. What's happening
is that vendors are adding (incompatible!) features which have to be
controlled by some sort of code, and yet the features are supposed to
be completely invisible to the OS. Say what? 

A portable with an Alpha would do power management from PALcode, and
there would be some effort to keep each PALcode/OS interface
unchanged.




-- 
Don		D.C.Lindsay	Carnegie Mellon Computer Science
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: More Alpha AXP Performance Numbers
Summary: MP configurations available, including performance data
Keywords: MP, system attributes
Date: 15 Nov 92 18:29:22 GMT
Organization: Digital Equipment Corporation


In article <1992Nov13.140907.2304@athena.mit.edu>, solman@athena.mit.edu (Jason W Solinsky) writes...
> [text deleted]
>Based on this data, it is extraordinarily unclear why somebody would be willing
>to go for the 10000 box when the 3000 delivers better than half the performance
>at a TINY fraction of the price. Also, why aren't there any multi-processing
>configurations available?

Multiprocessor configurations are available.  The 4000-600 AXP takes up to
two processors; the 7000/1000-600 AXP take up to six processors.  Both
SPECthruput and SPECrate performance data has been published; contact your
local DEC sales office for a more detailed performance brief, if required.

As has been mentioned before, there are other differences than performance,
such as maximum memory, available I/O bandwidth, expandability, and so on.
Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation
From: woodacre@mips.com (Michael Woodacre)
Newsgroups: comp.arch
Subject: Re: DEC Alpha architecture issues
Followup-To: comp.arch
Date: 19 Nov 1992 16:14:59 GMT
Organization: Mips Technologies, Inc.
Distribution: world
Reply-To: woodacre@mips.com (Michael Woodacre)
NNTP-Posting-Host: krell.mti.sgi.com

In article <1992Nov18.210416.27212@nntpd.lkg.dec.com>,
dipirro@star.dec.com (Steve DiPirro) writes:
> 
> 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.

Can you explain how this is different from kernel code with interrupts
disabled on any other risc processor? For instance, an R4000 can
implement uniprocessor-atomic "instructions" which are sequences of
MIPS instructions to implement complex functions by running code
in kernel level with interrupts switched off.

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

   Michael S. Woodacre | Phone: (415) 390 4175
UUCP: {ames,pyramid,decwrl}!mips!woodacre OR woodacre@sgi.com
USPS: MIPS Technologies Inc, M/S 10U-178,
      2011 N. Shoreline Blvd, Mountain View, CA 94039



Newsgroups: comp.arch
From: jg@crl.dec.com (Jim Gettys)
Subject: Re: DEC Alpha architecture issues
Organization: DEC Cambridge Research Lab
Date: Thu, 19 Nov 1992 01:15:25 GMT

In article <1992Nov19.002740.7914@adobe.com>, zstern@adobe.com (Zalman Stern) writes:
> In article <1992Nov18.112407.2518@doug.cae.wisc.edu> keiths@cae.wisc.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?
> 
> I don't have a good answer to your question, but conditional moves do seem  
> to be a win. SPARC version 9 includes them. The HP precision architecture  
> already has features that do much the same thing. And rumour has it some  
> MIPS architecture types like them too...
> 

If you want some more direct measurements, you might take GCC on a machine
with conditional moves and remove the use of conditional move instructions;
I think you'll find a significant performance difference.  The bottom line is that
you want to keep the pipe running flat out, and branches kill your pipe performance.

It certainly caused a noticable improvement when Richard Kenner taught
GCC to use them on Alpha a while back, though GCC is not as good as it 
might be about recognising when the can be used (last I remember on the topic
was that it recognised some common idioms, but was nowhere as clever as it
might be, and probably will be with time).  We are, of course, still
improving our own compilers to use them more of the time as the compiler guru's
continue doing their things.
			- Jim Gettys

Newsgroups: comp.arch