HDTenEightyP/NetNews huggingface dataset:
From: moss@cs.cmu.edu (Eliot Moss)
Subject: Re: DEC Alpha architecture issues
Followup-To: comp.arch
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
	<lgnfc3INNqnt@spim.mti.sgi.com>
Date: Fri, 20 Nov 1992 15:11:51 GMT

>>>>> On 19 Nov 1992 16:14:59 GMT, woodacre@mips.com (Michael Woodacre) said:

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

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

It's not really all that different. My understanding of the point of PAL code
is that a collection of architecture implementation specific routines are
provided in ROM, reducing implementation specificities of the kernel. It may
also be the case that entering/exiting PAL code is a little faster than a
usual syscall (but gives a more restricted execution environment).
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
From: weaver@jetsun.weitek.COM (Michael Gordon Weaver)
Newsgroups: comp.arch
Subject: Re: Question about SPARC FP traps
Keywords: SPARC FP
Date: 20 Nov 92 00:32:21 GMT
Organization: WEITEK Corporation, Sunnyvale CA

In article <1992Nov18.181014.1667@Princeton.EDU> awolfe@moo.Princeton.EDU (Andrew Wolfe) writes:
...
>
>My students and I are confused about the way that traps are handled in
>SPARC implementations with multi-cycle, unpipelined FP operations.  I
>can't find anything in the SPARC arch. ref. that says anything
>different.  Here is our problem.  If you only save the instructions and
>PCs of uncompleted operations, then how do you get the input operands
>to re-execute them.  For example if instruction-2 requires r7, but
>instruction-n (that has completed) overwrites r7 then how can I restart
>instruction 2?
>
>It would seem that a history buffer of some type containing register
>values is still required.
>
On the SS1 and the IPX, there is no history buffer. I believe the way
this is handled is that instructions which have dependencies like your
example are interlocked. In your example, instruction-n would not 
start execution until instruction-2 finishes. When an instruction
has a fault, results are not written back to the register file. 
So the only thing that is imprecise is that some instructions 
may have completed out of order. No source registers for uncompleted
instructions will have been modified.

On the SS1 and the IPX, you can only really have two floating point
operations (of different types) executing at a time, and of course the
FPU and IU have separate register files, so this is not a big
performance hit.

I belive that the SS2 trap handling is very similar to SS1. I 
have not yet heard about trap handling on the SuperSPARC. There
is more that can be going on in a single cycle on that one, so
I would expect something more complicated would be necessary 
to avoid an excessive number of stalls.

Michael Weaver.
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: DEC Alpha performance; whose compiler?
Summary: Alpha compilers from DEC
Keywords: compilers, Alpha
Date: 17 Nov 92 00:53:12 GMT
Organization: Digital Equipment Corporation


In article <1992Nov16.204559.3481@nas.nasa.gov>, dresselh@rft30.nas.nasa.gov (Eliot Dresselhaus) writes...
>Who did the Alpha compiler correponding to the released SPECS?

These were DEC's compilers, for C and FORTRAN.  The compilers are based
on a common front-end back-end system, developed at DEC and first released
more than a year ago (with a Mips back end) as DEC FORTRAN V3 and DEC Ada V1.

>Someone (DEC folks?) care to measure GCC-2.3's Alpha versus HP-PA SPECs?

As the implementers of Zork used to say, feel free...

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: tch@kepler.unh.edu (Travis C. Hayes)
Newsgroups: comp.arch
Subject: Mach. Simulators for OS Design
Date: 19 Nov 1992 16:53:39 GMT
Organization: University of New Hampshire  -  Durham, NH
NNTP-Posting-Host: kepler.unh.edu

This may not really belong in comp.arch but...

Does anyone know of any publicly available (by ftp) machine simulators
that would run under UNIX and include a compiler.

The reason:

I am doing some operating system design and I would like to do the
design work in a UNIX environment. Of course I don't always get what I
want, but this is what I would like:

A C compiler (gcc would be great) that runs under UNIX and produces
object code for the simulated machine. This, I assume, is no big
problem if a decent simulated machine exists.

A way of copying a kernel produced by the compiler (with some assembly
code) into the memory space of the simulated machine (which would be
in virtual memory on the UNIX machine) and then a way to start execution
at a certain address.

It would be nice if the simulated machine was relatively complex,
32-bit arch., MMU, some simulated hardware devices like disk I/O
(stores filesystem in one UNIX file maybe) and simple character
output (for debugging and seeing what is actually going on).

It's a tall order, but why not? I don't expect it to be fast of course.
I believe such a thing would be useful for many applications.
I find myself wishing for simulated machines all the time; maybe
someone else does too. Boy do I sound like a nerd  8-D

If no one has such a thing, I just might be convinced to work on one
myself... Sounds like fun.


It kind of obscures my goal of OS design though.
-- 
+-------------------------------------------------------------------------+
| Travis C. Hayes                                         Travis C. Hayes |
| University of New Hampshire               UNH Research Computing Center |
| Computer Science Major                     Computer Operator/Programmer |
+-------------+-----------------------------------------------------------+
| tch@unh.edu | You too can get your CS degree in only 6 years!           |
+-------------+-----------------------------------------------------------+
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System INTEGER Performance
Keywords: Alpha, AXP, SPEC, DEC, INTEGER
Date: 16 Nov 92 18:53:27 GMT
Organization: Canisius College, Buffalo NY. 14208

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


  pavlov@fstrf.org
From: 2hutempire@kuhub.cc.ukans.edu
Newsgroups: comp.arch
Subject: Info needed on i860XP
Date: 20 Nov 92 14:44:33 CST
Organization: University of Kansas Academic Computing Services

Information needed on the i860XP.

Could someone post the SPECmarks on the i860XP?  Is there
an ftp site with this information?

Thanks
Eric
 
Newsgroups: comp.arch
From: cliffc@rice.edu (Cliff Click)
Subject: Re: integer distance or sqrt
Organization: Center for Research on Parallel Computations
Date: Mon, 16 Nov 1992 00:43:40 GMT

bbs.dennis@tsoft.sf-bay.org (Dennis Yelle) writes:
> because of the interest in Herman Rubin's optimization problems
> some people here might be interested in this.
> It is a real problem.  That is, I have a program that spends quite a 
> lot of time here, and I would like to change this if I could.  

> I first considered asking for a integer sqrt, but maybe if the context is 
> known a better answer can be given.  This program is normally run on a 
> machine with no floating point hardware so I would like to get rid of 
> floats entirely.

I sent him an integer square root code using Newton's Method.  I've done 
this problem before and I'm sure there are better methods out there.  Does 
somebody want to post/email something better than Newton's?

Thanx,
Cliff

--
Through a gentle rain / the moon throws silver shadows /
and tears fall like pearls.                    Cliff Click (cliffc@cs.rice.edu)
Newsgroups: comp.arch
From: dipirro@star.dec.com (Steve DiPirro)
Subject: Re: DEC Alpha architecture issues
Organization: Digital Equipment Corporation
Date: Thu, 19 Nov 1992 20:30:12 GMT


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.

------------
Steve DiPirro        dipirro@star.dec.com
                     --or-- dipirro@star.enet.dec.com
                     --or-- ...!decwrl!star.dec.com!dipirro
                     --or-- dipirro%star.dec@decwrl.dec.com
------------
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: Wed, 18 Nov 1992 20:14:00 GMT

In article <TMB.92Nov17181419@arolla.idiap.ch> tmb@idiap.ch writes:
> The only problem with this approach was
> that the early C compilers for 32bit machines messed up and didn't
> make "long" 64bits.

Yep, that's one of the horrible historical dregs we'll have to live
with. You can bet that 64-bit computers will have int=32, long=64, and
long-long=128.
-- 
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?
Xref: sparky comp.arch:10825 comp.lang.misc:3734
From: moss@cs.cmu.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: Re: integer distance or sqrt
Date: 16 Nov 92 14:47:10 GMT
Article-I.D.: CRAFTY.MOSS.92Nov16094710
	<CLIFFC.92Nov15184340@miranda.rice.edu>
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

I don't recall the details, but there are more clever ways to calculate
distance (sqrt(x^2 + y^2)), which avoid the overflow problems of the squaring
and summing. I suspect the principle is something like this (assuming x > y >=
0): dist = x * sqrt (1 + (y/x)^2). One then applies an appropriate
approximation method to this instance of sqrt (note that 0 <= y/x < 1). Of
course, if you're sure you won't overflow, and an integer result is accurate
enough for you, I'd suggest the direct method, unrolling the Newton's Method
iteration an appropriate fixed number of times by hand. (The algorithm
converges very rapidly, about doubling the number of bits on each iteration;
it is about the only approximation method with such rapid convergence.)
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
Xref: sparky comp.arch:10917 comp.lang.misc:3790
From: moss@cs.cmu.edu (Eliot Moss)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: adding new operators on the fly
Date: 19 Nov 92 14:44:11 GMT
Article-I.D.: CRAFTY.MOSS.92Nov19094411
	<1992Nov18.212323.15324@newshost.lanl.gov>
Reply-To: moss@cs.cmu.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

I contend that when adding new operators it is much too confusing to allow the
user to choose/define precedence (at least), thoough associativity and
commutativity are less of a problem. The point is that it gets too complicated
for someone trying the READ the program and understand it. Rather, it is
likely better to take the approach of APL and Smalltalk: define one simple
evaluation order and otherwise require parenthesization. In APL I believe
evaluation is right to left; in Smalltalk it is only slightly more
complicated. There are three kinds of operators: unary postfix, binary infix,
and keyword "mixfix". The unary ones are simple identifiers, for example:

	17 negate

The binary ones are formed from a set of "special" characters, and consist of
one or two (maybe even three; I'm doing this from memory) characters from that
set. Examples are:

	x + y
	y << 3

Finally, keyword operators consist of a sequence of one or more identifiers,
each followed by a colon; if there are K identifiers, then there must be K+1
subexpressions, with the pieces of the operators inserted between the
expressions. For example:

	x at: 17
	x at: 17 put: y

The evaluation rule is unary, then binary, then keyword (unless parentheses
further delimit the expression). One DOES get used to this fairly quickly.

Finally, I suggest further discussion of this topic be moved out of comp.arch,
since it is a language/compiler issue, not fundamentally one of computer
architecture.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
From: srini@cs.wvu.wvnet.edu (Srinivas Kankanahalli)
Newsgroups: comp.arch
Subject: Cache Simulators
Date: 16 Nov 92 05:17:32 GMT
Organization: WVU Statistics and Computer Science

Hi Netters:
         I would be grateful if any of you can point me to any public domain
Cache Simulators.

Thanks In Advance

-Srinivas

---------------------------------------------------------------------
Srinivas Kankanahalli
Asst Professor of Computer Science
West Virginia University
Morgantown, WV 26505
Email: srini@cs.wvu.wvnet.edu

--------------------------------------------------------------------
Newsgroups: comp.arch,comp.lang.misc
From: prener@watson.ibm.com (Dan Prener)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: Fri, 20 Nov 1992 06:46:21 GMT
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
	<id.HJ1V.BTG@ferranti.com> <1992Nov19.034325.3864@technix.mn.org>
Organization: IBM T.J. Watson Research Center, Hawthorne, New York

In article <1992Nov19.034325.3864@technix.mn.org> bret@technix.mn.org (Bret Indrelee) writes:

>    In article <id.HJ1V.BTG@ferranti.com> peter@ferranti.com (peter da silva) writes:
>    >In article <BxtA6v.CE8@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>    >> But it is.  The operations often use register arguments and the results
>    >> are wanted in registers.
>    >
>    >What's a register? Most modern compilers ignore "register", or use it as a
>    >hint "this is a frequently used value".
>    >
>    >And how is an inline library part of the language more than a subroutine
>    >or an include file?
> 
>    Which brings up a question I've wondered about.  Do any compilers use
>    'register' to indicate that a pointer reference DOESN'T access the
>    value?
> 
>    If so, it once again becomes usefull to use the register keyword,
>    as a no-alias.  Compiler could optimize knowing that the value isn't
>    changed by that weird intervening pointer reference.

There are two separate issues here.  One is a minor point for language
lawyers.  There is some semantic content to C's "register" declaration,
namely that it is illegal to take the address of a "register" variable.

Which leads to the optimization issue.  Compilers don't have to be
completely pessimistic about what might be changed by pointer references.
With a suitable definition of what it means for a variable to have its
address taken, pointer references can only change those variables that
have had their addresses taken.

So, while it is true that register variables may lead to better optimization,
that is because they never have their addresses taken.  So, with a compiler
that keeps track of which variables have their addresses taken, the
performance improvements resulting from the use of register variables remain,
even after you delete the "register" declaration.
--
                                   Dan Prener (prener@watson.ibm.com)
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Summary: Were at announcement
Keywords: Small Alpha's
Date: 15 Nov 92 18:22:51 GMT
Organization: Digital Equipment Corporation

> [text deleted]
>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?

The announcement included advance information on a pair of sub $10k desktop
machines, one an Alpha personal workstation for VMS and OSF/1, the other an
Alpha PC for Windows NT.  Performance and pricing will be provided when
the units are available for immediate volume shipment, first half next year.

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
Xref: sparky comp.arch:10998 comp.lang.misc:3830
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Date: 22 Nov 92 00:18:15 GMT
Followup-To: comp.arch
Organization: CWI, Amsterdam

In article <TMB.92Nov20140542@arolla.idiap.ch> tmb@idiap.ch writes:
 > I think it might well be worth trying to standardize an interface to
 > arithmetic that provides you with access to the low-level arithmetic
 > primitives that you need. However, in order to make your code truly
 > portable, you will need to come up with an interface that takes into
 > account that there are machines with odd word sizes. Such a facility
 > needs to have a much more abstract and much more task-specific than a
 > general facility for accessing "low-level features". That is precisely
 > why I think that Rubin and Silverman are barking up the wrong tree.
 > 
Perhaps this is indeed true, although I do not know what the real solution
is for this problem.  The first step when installing my package (which
contains Assembler, Fortran and C) is to first fix-up all machine
dependencies.  I.e. machine dependent header files and source files are
picked up.  (And indeed it is also possible to create a machine independent
version, although not as efficient as the others.)  One of the things defined
in the machine dependent header files is the number of bits to use.  For
some reason I use 30 bits on most 32 bit machines (and in general two bits
less than the word size), but there are exceptions:
	Cray: only 23 bits used of the 64 available.
	MIPS, i860: only 26 bits used of the 32 available.
and possibly some more between those ~40 machines to which I ported the
stuff.  All this is for efficiency.  On the i860 there is no integer
multiply, only fp multiply, so the double multiply is used (actually
some strange derivative of that operation).  Similar observations hold
for Cray.  MIPS does have integer multiply, but I found that the code
using fp multilpy was faster (this is true on the R3000 and earlier,
one of these days I should check the R4000).  This is true even though
we need more operations.  (One of these days I should try the same on SPARC.)

As I said, I do not know what the real solution is, it is certainly not
as clear-cut as Herman thinks.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
Xref: sparky comp.arch:10787 comp.benchmarks:1702
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: Performance of Alpha on SPECfp92 (alvinn and ear)
Date: 17 Nov 1992 17:48:39 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout

In article <1992Nov17.012550.7243@oakhill.sps.mot.com> dannyj@oakhill.sps.mot.com (Danny K. Jain) writes:
>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.

Not! HP is a 2-issue machine tuned for floating-point computations.
It can do among other combinations:

	a) ld/st fp   and   fadd, fsub, fmpyadd, etc.
	b) ALU	      and   fadd, fsum, fmpyadd, etc.

What it does *not* do is:

	a) ALU	      and   load/store integer
	b) ALU	      and   ALU

That's the main reason why integer performance in relation
to the clock frequency is low, i.e. 80 SPECint92 at 99 MHz.
A full dual-issue machine allowing ALU+ALU and ALU+ld/st
with the same characteristics as the HP machine (especially
the cache latency and sizes) would show something around
a one-to-one ratio between SPECint92 and MHz
(e.g. 100 SPECint92 at 100 MHz).

- Marc Tremblay.
Sun Microsystems
Newsgroups: comp.arch,comp.lang.misc
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Los Alamos National Laboratory
Date: Tue, 17 Nov 1992 19:19:38 GMT

In article <Bxv2t2.4FH@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
|> [... examples of obfuscating syntax including `|' for boolean OR,
|>      '*' for dereferencing, end `;' for statement termination ...]

I'm disappointed with Dr. Rubin.  He left out such obvious ones as:
making a leading zero digit mean octal!  Or, the fact that `/*' is
actually *ambiguous* in C because it's either a comment or a divide
followed by a dereference (C resolves this by simply filtering out
comments in the preprocessor phase without warning that something
unintended may have happened).  He left out that unsigned integers
are considered to be a *promotion* over signed integers the same size:
they aren't, but C treats them as such.  He left out that the keyword 
"static" means "private" one place and "static allocation" elsewhere.
He left out that there are 50+ operators and 15 levels of precedence.
Or, that the precedences of the operators were selected based on their
algebraic form not their semantic content (for example, it would be more
natural to have unary minus with the same precedence as subtraction).
He didn't mention that the distinction between bit-wise and logical
operators would not have been necessary if C had a LOGICAL data type.

Etc....

-- 
J. Giles