HDTenEightyP/NetNews huggingface dataset:
From: zstern@adobe.com (Zalman Stern)
Subject: Re: PALcode
Organization: Adobe Systems Incorporated
Date: Mon, 23 Nov 1992 20:48:26 GMT

In article <By2qA1.5z3.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay)  
writes:
[Discussing Alpha PALcode.]
> 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.
> 
1) The 386 has all the features necessary to implement software abstraction  
to handle this situation. If these vendors agreed on the interface and cast  
it into ROM, life would be good.
2) If there were five highly competitive companies implementing low-power  
Alpha chips and they all defined different PALcode interfaces you'd have  
exactly the same problem.

So, where's the beef?
--
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
From: deepak@konark.njit.edu (Albatross)
Newsgroups: comp.arch
Subject: SPARC 10 (Information needed)
Date: 19 Nov 92 20:53:37 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

I need specifications of sun's SPARC 10. If anybody out there has them

could you please mail them to me. 

Thanks in advance....

Deepak
--
VLSI:=> "Getting High On Low Voltage"       ** 
E15WNJTPXE15x280WXR1TL21NXL4TL17NXR10TL->    **    Those who can, DO
You can tune a guitar, but you cant tuna fish.**    Those who cant, TEACH.
*******************************************************************************
Newsgroups: comp.arch,comp.lang.misc
From: designer@siemens.com (Designer job ad)
Newsgroups: comp.arch
Subject: test
Date: 20 Nov 92 18:37:26 GMT
Distribution: usa
Organization: Siemens Corp. Res., Inc.

This is just a test.
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: 19 Nov 92 19:57:49 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <1992Nov16.231949.1214@ryn.mro4.dec.com>, blair@snogum.enet.dec.com (Blair Phillips - Digital) writes:
> 
> I'm tempted to say: 
> "Go read Hennessy & Patterson, then you will see that John DiMarco *does*
> answer your question"
> 
   My copy of the above doesn't even mention the ALPHA; does yours ?  

   greg pavlov
   pavlov@fstrf.org


   (5 DEC people responded to my question.  All were defensive and/or antagon-
    istic.  The most useful answer, from an architectural/technical point of
    view, with references to DEC publications, came from someone at SUN....)


   
   
Newsgroups: comp.arch,comp.lang.misc
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 21 Nov 1992 03:56:16 GMT

alan@sal.wisc.edu (Alan Watson) writes:

>If you are using a compiler which cannot recognize the fact that mixed
>64/32-bit instructions can be used in both of the cases I cited then
>BUY a better compiler.  

... or get one for FREE.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
Newsgroups: comp.arch
From: richard@meiko.com (Richard Cownie)
Subject: Re: DEC Alpha architecture issues
Organization: Meiko Scientific Corp.
Date: Wed, 18 Nov 1992 19:17:30 GMT

1. Conditional move instruction is certainly useful.  I was involved
   in writing a compiler for the Acorn RISC Machine (ARM), which has
   the unusual feature that all instructions are conditionally
   executed, with a 4-bit field to specify the condition (the most
   common condition being "always").  Any conditional branch over
   a short sequence of instructions was optimised into a short
   sequence of conditionally-executed instructions, which reduced
   the code size and saved flushing the pipeline (there was no smart
   branch prediction or delayed branches).

   You can't play quite the same game with just conditional move,
   but things like "if (a < b) a = b;" will work nicely.
   Note that the SPARC Version 9 architecture also includes
   conditional move (together with 64-bit extensions & much else).

3. I believe 1000 tera-FLOPS = 1 peta-FLOPS ?  However, anyone using
   this word before 1997 should be regarded as a hype-merchant.
   Hennessy & Patterson refer to performance on the Perfect benchmarks
   which averages about 1% of peak MFLOPS rates - the real challenge
   for the millenium is to regularly attain > 1GFLOPS performance
   on these dusty decks.

   I'm not sure what Cray are up to, but with current technology it's
   more likely to be 300GFLOPS than 300TFLOPS - this would be roughly
   in line with Fujitsu VPP500, TMC CM-5, Meiko CS-2, and could be
   achieved with around 1000 or 2000 Alpha processors, which is a
   manageable number.
  
-- 
Richard Cownie (a.k.a. Tich), Meiko Scientific Corp 
email: richard@meiko.com
phone: 617-890-7676
fax:   617-890-5042       
Newsgroups: comp.arch
From: upton@quip.eecs.umich.edu (Michael Upton)
Subject: Re: DEC Alpha AXP System INTEGER Performance
Organization: University of Michigan EECS Dept., Ann Arbor
Date: Fri, 20 Nov 1992 16:04:17 GMT

Re: Why no byte write on Alpha?

Our group is working on GaAs microprocessor designs, and we have made
many of the same decisions that DEC made on Alpha.
There are two main reasons to avoid byte read and write.

1) Adds a mux on reads, 
	As Mark F. from HP has said, this is no big deal in CMOS.
	but what about other technologies? We are constantly finding
	archetectural decisions that have been made based on  1.2 micron
	CMOS technology that make things very difficult for us in GaAs.
	DEC has said that the architecture is to last for XX (25?) years.
	Decisions made based on current technology often look out of place
	decades later, look at the VAX. Granted, this one instruction will not
	make or break an implementation, but DEC has done a very good job of
	designing a technology neutral architecture.

2)a read-modify-write is required on writes.
	To allow ECC protected writeback primary cache, a RMW is 
	needed to update the ECC bits.

Mike Upton
Gallium Arsenide Processor Project
University of Michigan
From: wca@ut-emx.uucp (William C. Anderson)
Newsgroups: comp.arch
Subject: need "find first one" algorithm recently discussed here
Keywords: "find first one" / "find first set bit" algorithm
Date: 24 Nov 92 05:29:54 GMT
Organization: The University of Texas at Austin, Austin, Texas

comp.arch mavens:

I have unfortunately misplaced the most recent discussion regarding the
fast log(N) algorithm for finding the first bit set in a word from a given
end.

I would most appreciate it if some kind soul could send me email with a
summary of that discussion, including an outline of algorithm.  A pointer
to an ftp site would suffice.

Thanks,

Willie Anderson

wca@emx.utexas.edu
wca%m.ibmoto.com@oakhill.sps.mot.com
From: adrianc@sunfen.uk.sun.com (Adrian Cockcroft - Sun UK - Cambridge SE - SPARC Specialist)
Newsgroups: comp.arch
Subject: Re: Parallelised SPECfp92 on the SPARCcenter 2000
Date: 16 Nov 1992 16:18:41 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: adrianc@sunfen.uk.sun.com
NNTP-Posting-Host: sunfen.uk.sun.com

Correction to my previous posting:

The SunPro SC3.0 compiler has a back-end paralleliser that has nothing to
do with KAP and sits on the Solaris 2.X thread libraries. KAP was used on
"ora" but it works on the front end and generates multiple Unix processes
to partition a loop.

Regards Adrian

---
Adrian Cockcroft -  adrian.cockcroft@uk.sun.com or adrian.cockcroft@sun.co.uk
Sun Microsystems, 306 Science Park, Milton Road, Cambridge CB4 4WG, UK
Phone +44 223 420421 - Fax +44 223 420257	Sun Mailstop: ECBG01

Newsgroups: comp.arch,comp.benchmarks
From: stripes@pix.com (Josh Osborne)
Subject: Re: Lisp performance (on Sparc SS2, SS10-30, HP720)
Organization: Pix Technologies -- The company with no adult supervision
Date: Mon, 16 Nov 1992 13:24:37 GMT

In article <1e824rINNlpu@iraul1.ira.uka.de> wolpers@i11s10.ira.uka.de (Andreas Wolpers) writes:
>Hello everybody,
>
>I'm having a minor problem on which I would welcome any comments:
>Since I'll have some money to spend real soon now, I've been pondering
>whether we should switch from Sun to HP. The usual benchmark results
>suggest that a change might result in faster execution of our pet
>program, a large "theorem prover" written in Lisp.

You should get Sun and HP to send you computers to test, then send back
the slowest.  From your comments below, I assume that you at least got
Sun to send you a machine...

>From the SpecInt92 results, one should expect a performance increase
>of about a factor of 2 when switching from a SS2 to either s SS10-30
>or HP720. Unfortunately, on both machines turned out to but just
>30% faster than a SS2 when running our system (for which ps NEVER
>shows a resident set under 3-4 MB, not even on an 8MB machine).

(a) I am sure the SPECInt's ops were all normal add's and sub's, and
I am guessing that Lisp's are all taged add's and sub's.  Can you
execute >1 tagged op per cycle?  Also did you re-compile the lisp
interpreter on the SS10 with a compiler that can schedule code for
the new CPU?

(b) If you only have 8M, you may be out of RAM even when ps says your
code is only using 3-4M.  First, ps doesn't (by default) report pages
used by shared libs, which can be quite a few pages (besudes if it did
report them, who should it assign them to?).  Second, if you are using
the generic kernel, it is over 1M.  Third, your buffer cache may be
using some RAM.  Forth, what else is running, just ps?

Try using vmstat to see how many pageins and pageouts are being done.
Get more RAM and see if it helps.

>Any explanations at hand? Did we encounter a bottleneck between
>CPU and memory, or what? What performace should I expect from
>a SS10-41 or SS10-52 (which have a larger cache, but still not 
>large enough to hold the Lisp's resident set. And if I'm not
>mistaken, the large cache results in a longer time spent for
>non-cache memory accesses (6 cycles instead of 3)). What 
>performace should I expect from a HP735?

Get Sun and HP to send you a machine, don't wriite a $50k check
on a guess.  Even a good one.

>I can buy enough memory so that disk speed is no criterion.
>Should I wait for machines with 8MB of cache? Should I shoot myself?

How long can you wait?  Wait long enough and lisp machines will come
back into style (half :-) ).

>Should I give YOU the money? :-)

Yes, in small unmarked bills.
-- 
           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
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 18:48:43 GMT

In article <id.6S0V.FKH@ferranti.com>, peter@ferranti.com (peter da silva) writes:
|> In article <Bxpoy9.GD6@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:
|> > There is jargon and there is jargon.  I know of no case in which anybody
|> > in mathematics or statistics deliberately introduced jargon for the purpose
|> > of obfuscation, or deliberately introduced notation which conflicted with
|> > notation in another field.
|> 
|> So you're making the claim that computer language syntax was deliberately
|> introduced to obfuscate or conflict with another field? Is that really
|> what you mean here, or am I putting words in your mouth?

Well, I can't speak for Dr. Rubin nor for the designers of any language.
However, deliberate obfuscation is a *plausible* explanation for some of
the features of a certain popular language.  ;>)

-- 
J. Giles
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Newsgroups: comp.arch
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 15 Nov 92 23:20:37 PST
Organization: Missionaria Phonibalonica

In <7903@charon.cwi.nl>, dik@cwi.nl (Dik T. Winter) wrote:
> 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.
>  > 
> Wrong.  The MIPS assembler performs some optimizations (like delay slot
> filling and instruction scheduling).  It works quite well.

My fault - I was referring to the "interaction between the programmer
and the compiler/assembler" when I said "didn't work very well".  I
should have made things clearer.

I do know that "optimizing" assemblers of various kinds have been
around for a long time, and do work quite well. Given what I've seen
of MIPS compiler technology (or should I call it SGI compiler
technology now? :-), I'm sure they did wonderful things.

	<mike

Newsgroups: comp.arch,comp.lang.misc
From: sef@kithrup.COM (Sean Eric Fagan)
Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
Organization: Kithrup Enterprises, Ltd.
Date: Thu, 19 Nov 1992 11:12:33 GMT

In article <id.RT2V.U4F@ferranti.com> peter@ferranti.com (peter da silva) writes:
>You can bet that 64-bit computers will have int=32, long=64, and
>long-long=128.

64-bit computers have:

a) int=32, long=32, long long=64 (ELXSI)
b) int=64, long=64, long long=syntax error (Cray)
c) int=32, long=64, long long=syntax error (alpha, I think)

(Note that, for the current and upcoming 64-bit microprocessor-based
computers from the major companies [DEC and MIPS at least, presumably Sun]
will probably end up having various options for type length, either on the
command line, or via a header file.)

And throw in combinations of pointers being 32 and 64 bits (or 24 or 32
bits, on the Cray)...

-- 
Sean Eric Fagan  | "Time and space is a bitch!"
sef@kithrup.COM  |    -- Gooshie (Dennis Wolfberg),
-----------------+       "Quantum Leap:  Killin' Time"
Any opinions expressed are my own, and generally unpopular with others.
Xref: sparky comp.arch:10955 comp.lang.misc:3809
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 20 Nov 92 21:18:54 GMT
	<722061195@sheol.UUCP> <BxxH8K.C4t@mentor.cc.purdue.edu>
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: hrubin@pop.stat.purdue.edu's message of 18 Nov 92 20:07:31 GMT

In article <BxxH8K.C4t@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   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.

You are finally getting the point: evidently, your needs are not
served by the large amount of current research on programming
languages, even scientific ones. I don't consider that an indictment
of current research programs. If you want something different, you
have to invest your time, effort, and money.

					Thomas.
Newsgroups: comp.arch
From: gbyrd@ncsc.org (Gregory T. Byrd)
Subject: Re: DEC Alpha architecture issues
Followup-To: comp.arch
Keywords: alpha architecture
Reply-To: gbyrd@ncsc.org (Gregory T. Byrd)
Organization: North Carolina Supercomputing Center
Date: Wed, 18 Nov 1992 20:35:52 GMT

In article <1992Nov18.112407.2518@doug.cae.wisc.edu>,
keiths@cae.wisc.edu (Keith Scidmore) writes:

 >3. Cray has annouced intention to build a 300 Teraflop machine based on the
 >   alpha.  What is the word for 1000 teraflops?
 >

First, I assume your mean Cray Research, Inc.

Second, CRI has announced a three-phase strategy for a scalable parallel
system.  The third phase, as I understand it, would result in a machine
with a peak of 3 teraflops, not 300.

Third, CRI is using Alpha for the first phase, but it is not committed
to using Alpha for either the second or third.

(I know this didn't answer your 1000 teraflops question...)

...Greg Byrd             North Carolina Supercomputing Center
   gbyrd@ncsc.org        P.O. Box 12889
   (919)248-1439         Research Triangle Park, NC  27709-2889
Newsgroups: comp.arch,comp.lang.forth
From: rminnich@super.org (Ronald G Minnich)
Subject: Re: What's RIGHT with stack machines (Was Re: What's wrong...)
Keywords: stack computers, embedded control
Organization: Supercomputing Research Center (Bowie, MD)
Date: Mon, 16 Nov 1992 12:50:09 GMT

In article <id.9FYU.UBJ@ferranti.com> peter@ferranti.com (peter da silva) writes:
>In article <1992Nov11.134556.20150@super.org> rminnich@super.org (Ronald G Minnich) writes:
>> Only if you don't care about protection, right?
>From an interrupt routine???

What can I tell you. The people who write the OS for these machines, 
at least a few years ago, told me they switch stacks on interrupt. One reason 
given is protection.  Ask them. Any of you MCP hackers reading this?

If memory serves so did the HP3000. Any HP people care to comment?

>In any case, the Burroughs A-series did security entirely in software. The
>hardware memory protection was to enforce type correctness, not security
>policy.

Not really. First off, don't extrapolate what you may have read in Bell&Newell
about the 6700/7800/7900 to the A-series. They are not the same. 
Secondly, past some very early machines there was always bounds checking to 
make sure you stayed in your stack. So not "entirely". 
Thirdly, with the advent of E-mode in 
ca. 1985 or so you find a set of memory mapping registers which look much like
what you find on PDP-11s that ran out of address bits. And for the same reason:
ca. 1982 or so Burroughs began to realize that 20 bits of (48-bit word) 
address was not going to be enough for much longer. 
My E-mode spec. is ca. 1983 and an internal document anyway, 
so is hopelessly out of date, 
so possibly someone more current can comment here on what E-mode provides
in the way of mapping/protection. 

Finally, the correct tense (for now :-) ) is "the A-series DOES". :-)
ron
-- 
you want windows? I got windows. 4608 by 3600,    | rminnich@super.org
16 channels of sound, 4' by 6'. Fun.              | (301)-805-7451 or 7312
Most abused words: open, scaleable, [more later]  |
Newsgroups: comp.arch
From: payne@crl.dec.com (Andrew Payne)
Subject: Re: DEC Alpha architecture issues
Organization: DEC Cambridge Research Lab
Date: Sun, 22 Nov 1992 00:28:03 GMT

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

[ text about Alpha's PAL mode deleted ]

>>3. Interrupts are disabled (so you can do atomic operations)
>
>Hold it!  Disabling interrupts is not usually enough to guarentee that
>an operation is atomic!

Of course!  In context, the statement meant "without disabling interrupts you
can't do atomic operations."

>Either I am missing something, or PALcode has to do more in order to make
>sure that the operation is atomic.

For implementing atomic memory operations, Alpha provides a load_locked/
store_conditional mechanism.

-- 
Andrew C. Payne
DEC Cambridge Research Lab
Xref: sparky comp.arch:10874 comp.lang.misc:3764
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 18 Nov 92 01:44:16 GMT

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

Absolute rubbish.  In the first place, Herman's implied claim that only
programming notations overload symbols is blatantly false.  He waves
away some examples in making this claim (math vs physics in particular),
but there are dozens more, one particularly pervasive example of overloading
being the interpretation of juxtaposition, which has dozens of uses
in mathematics, biology, chemistry, and so on and on.  The claim that
programming notations are exceptional in their rate of notation overloading
is totally unjustified by the facts.  Notation conflicts in *all* fields,
even conflicts with formerly established usage in the *same* field,
are as common as dirt.

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.  
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch