HDTenEightyP/NetNews huggingface dataset:
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: News Release - Pentium - "INTEL UNVEILS NAME FOR ITS FIFTH GENERATION COMPATIBLE MICROPROCESSOR"
Organization: Intel Corp., Hillsboro, Oregon
	<1992Nov7.172705.14365@black.ox.ac.uk>
Date: Tue, 10 Nov 1992 07:06:55 GMT

    All this arguing about the name is fine, but when are we going to see
    it, whatever it is called?  I vaguely remember the original article,
    and the Intel dude iced over this question if I remember rightly...

Well, I posted the original news release ("dude" is a lot better than
"s.o.b." I suppose).

I don't think I "iced over" the release date question - for the very
good reason that I don't know. I didn't work on that chip. The release
date is up to marketing.
--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Xref: sparky comp.arch:10719 comp.lang.misc:3651
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Summary: what were we saying?
Date: 13 Nov 92 01:08:41 GMT

: From: bs@gauss.mitre.org (Robert D. Silverman)
: Message-ID: <1992Nov12.131856.12605@linus.mitre.org>
: What we are discussing is
: the notion that some people seem to have that "correct style" is more
: important than speed.

I thought we were discussing the notion that some people seem to have 
that once correctness and speed have been acheived, style is of 
little value.

I claim that *both* of these "notions" are incorrect.
--
Wayne Throop  ...!mcnc!dg-rtp!sheol!throopw
Newsgroups: comp.arch,comp.lang.misc
From: jch@rdg.dec.com (John Haxby)
Subject: Re: CLU break and continue (Was: Re: A challenge to the anti-goto)
Organization: Digital Equipment Corporation
Date: Mon, 9 Nov 1992 11:43:23 GMT

In article <721054332.26680@minster.york.ac.uk>, mjl-b@minster.york.ac.uk writes:
|> >You're probably thinking of the `exit'/`except' mechanism, which allows
|> >you to escape from multiple loops (or from within a `proc', with the
|> >`signal' statement) by raising a condition which transfers control to
|> >the nearest enclosing handler for that condition.
|> 
|> This sounds a lot like the Ada exception mechanism. Briefly, when an
|> exception is raised, the run-time starts looking for a handler for that
|> particular exception. If there isn't one for that exception in the current
|> block, the call stack is wound back until one is found, or the top-level
|> subprogram is reached (when the program stops).

It's not surprising that the Ada exception mechanism is similar to CLU's
since CLU is one of Ada's ancestors.

CLU has two exception mechanisms for slightly different purposes.  One
mechanism is for returning an exception from a procedure call: a procedure
can signal an exception to be caught by its caller (the exception is not propagated
up the procedure call stack) or by a generic handler for unhandled exceptions.  The
other mechanism is a local form that allows a block (eg in a loop or if-statement) to
exit to an enclosing block.  Apart from the local/procedure-call difference the two
mechanisms are identical, although `signal' tends to be expensive and `exit' is simply
an unconditional branch.  For example:

	...
		x := sum (n)
		    except when negative: x := 0 end
	....

	sumOfInts = proc (n: int) signals (negative)
	    if n < 0 then
	        signal negative
	        end
	    sum: int := 0
	    while true do
	        sum := sum + n
	        n := n - 1
	        if n <= 0 then
	            exit done end
	        end except when done: return (sum) end
	    end sumOfInts

The example is a little contrived I'm afraid.  Both sorts of exception can be
parameterized.  For example, procedures that map on to system calls often signal
not_possible(string) -- the string is the string representation of the error code
from the routine when it fails.

Liskov and Guttag's "Abstraction and Specification in Program Design",
already cited, is much better at explaining this than I am on a Monday
morning.

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

----------------------------------------------------------------
The opinions expressed herein are my own, not my employers.
Newsgroups: comp.arch
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Subject: Re: RISC goes CISC?
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development
Date: Mon, 9 Nov 92 19:36:15 GMT

storm@cs.mcgill.ca (Marc WANDSCHNEIDER) writes:

>	Given current technologies, it could end up being EXTREMELY difficult
>to make instructions  execute in one clock cycle, if the clock cycles starting
>dropping below a certain time.  There is just so much that goes on, and gates
>can only go so fast.  Thus, the compromize is to try and overlap execution.

Note that this can be done either through superscalar (multiple
execution units/pipelines) or superpipelining (very short cycle time
with multiple pipeline stages for things like decode and execute)
techniques or both (e.g., the DEC 21064 has a very fast cycle time and
two parallel execution pipelines for integer and floating-point
operations).
--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
Xref: sparky comp.arch:10480 comp.lang.misc:3534
From: ferris@turtle.fisher.com
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: A Challenge to GOTO-LESS
Date: 6 Nov 92 11:19:38 CDT
Organization: Fisher Controls International, Austin, TX

For some reason this posted without a comment line. This is a response 
to the "A CHALLENGE FOR GOTO-LESS..."

> Since this discussion is posted in comp.architecture shouldn't we be
> discussing the possibility of a goto-less object code?
> 
> I believe that it is possible at the micro-code level but not at the
> machine level. However, I can envision something like:
> 
> SET FLAG TO VALUE
> INTerrupt
> ...
> ...
> :INTerrupt address
> DO CASE
>    CASE FLAG 1
>         PROCESS
>    CASE FLAG 2
>         PROCESS
>    CASE FLAG N
> ...
> 
> The INTerrupt command could be used to cause case-type processing
> based on a flag setting.
> 
> Now, can anyone suggest a reason for implementing a goto-less processor?
> Isn't the reason for goto-less code to eliminate the programmer's
> tendency to create indecipherable code? Why would anyone in their
> right mind implement a goto-less CPU?
> 
> Jeff
> 
> 
> 
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: Thu, 12 Nov 1992 13:27:33 GMT

In article <721539025@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
>: From: rh@smds.com (Richard Harter)
>: Message-ID: <1992Nov11.100555.4706@smds.com>
>: What Bob is telling you is that there are problems
>: which are so computationally demanding that computational efficiency is
>: far more important than standard programming style guides. 

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

>: There is a price for programming for clean code;
>: in most cases the benefits far outweigh the price; sometimes they don't.

There is a price for programming in what the languagists think is clean code.
Nobody except a computer programmer can read it at all!  Now I received some
email from someone about the algorithm I posted in which he asked for another
copy of the code where the control-path was "clear" and not defined by breaks
or gotos.  Now I do not know how to do that, but analyzing breaks is not that
simple for a human, either.  

>True, but I'm more sympathetic with the Jon Bentley school of
>optimization, where you transform clean, correct code into arcane,
>incomprehensible code by known-safe transforms, and RECORD THE
>TRANSFORMS.  For example, the chapter on code tuning in Programming
>Perls, especially the case study of the binary search.  Or, if I'm
>remembering rightly, Bentley's book Writing Efficient Programs.  Of
>course, the shortcoming in this context is that the central focus isn't
>really numerical problems, but I regard that as relatively minor. 

We still have the problem of what is comprehensible to whom.  And what 
is one supposed to do if the hardware operations wanted are not even
expressible in the language?  Sure, one can simulate them, but nobody
will be able to read THAT code.
-- 
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)
From: bs@gauss.mitre.org (Robert D. Silverman)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 12 Nov 92 13:31:26 GMT
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA

In article <1992Nov10.211153.5992@ryn.mro4.dec.com> bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
:
:In article <BxIJxr.GD5.1@cs.cmu.edu>, nickh@CS.CMU.EDU (Nick Haines) writes...
:> 
:>Two questions:
:> 
:>	- how much do these machines cost? What's the SPEC/$?
:
:DEC 3000 Model 400 AXP starts at $15K
:DEC 3000 Model 500 AXP starts at $39K
:DEC 4000 AXP starts at about $70K
:DEC 7000 AXP starts at about $150K
:DEC 10000 AXP starts at about $300K
:
 
These prices are ridiculous. There are nowhere close to being competitive
with what is being offerred by Sun or HP.
 
108 Specs for $15K??  Why would anyone want one?

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.arch
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
Date: 13 Nov 92 10:46:02 GMT
Organization: Department of Computer Science, U of Copenhagen

caperkin@ursa11.law.utah.edu (Charles Perkins) writes:

>This caught my attention because of an idea I have been toying with, which
>I have decided to call the Fractal Logic Asynchronous Scalable Circuit.
>(Basically a 'memory' where every cell is a finite state autonoma 'conversing'
>with the cells next to it.)  I figure eight thousand of the little guys on a 
>chip, simple though they might be individually, could get some serious
>computation done.

Have you considered how to program such a beast? And on the hardware
side, how do you load a program?

	Torben Mogensen (torbenm@diku.dk)
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.arch
Subject: Re: Integers implementation
Date: 6 Nov 1992 21:47:29 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


I'd say that 2's complement makes signed addition and subtraction very
easy and obvious.  Sign-magnitude makes multiplication easy and obvious.
Division is sort of a drag in any representation.
1's complement and sign-magnitude make changing the sign easy - no carry
propagation to worry about.  2's complement has the nagging problem of
a bigger most-negative magnitude than the biggest most-positive
magnitude.  The others have the nagging problem of two different
representations for zero.  Even if you force computations to yield a
consistent representation for zero there is the possibility that some
joker will manufacture the other one and store it in memory and then
you later try to use it in a computation.

One creative possibility is to say that the "funny number" (1 followed
by 0s in 2s complement, or negative zero in the others) is not a legitimate
number and use it to represented uninitialized memory contents and trap
on any attempt to use it in a computation.  But that introduces some
problems of time delay for checking, and of being able to do multiple
precision arithmetic easily.  Multiple precision introduces some other
funnies with sign-magnitude and 1s complement; what if the sign bits
of different parts of the operands are different?
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Ya can argue all ya wanna, but it's dif'rent than it was!"
"No it aint!  But ya gotta know the territory!"
        Meredith Willson: "The Music Man"
From: solman@athena.mit.edu (Jason W Solinsky)
Newsgroups: comp.arch
Subject: Re: More Alpha AXP Performance Numbers
Date: 13 Nov 92 14:09:07 GMT
Organization: Massachusetts Institute of Technology

In article <1992Nov10.204139.5148@ryn.mro4.dec.com>, bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar) writes:
|> This is in response to e-mail requests for more benchmark data.
|> 
|>     Alpha AXP OpenVMS (version 1.0) SYSTEMS PERFORMANCE DATA 
|> 
|>  |---------------------------------------------------------------------------|
|>  |METRIC              | 3000/400  | 3000/500 |   4000   | 7000      | 10000  |
|>  |====================|===========|==========|==========|===========|========|
|>  |SPECint89           |   65.8    |   73.5   |   83.7   |   95.1    | 104.5  |
|>  |SPECfp89            |  150.6    |  169.9   |  188.4   |  244.2    | 268.6  |
|>  |SPECmark89          |  108.1    |  121.5   |  136.2   |  167.4    | 184.1  |
|>  |--------------------|------------------------------------------------------|
|>  |SPECint92           |   65.3    |   74.3   |   83.5   |   96.6    | 106.5  |
|>  |SPECfp92            |  112.2    |  126.0   |  143.1   |  182.1    | 200.4  |
|>  |--------------------|------------------------------------------------------|
|>  |Dhrystone(DMIPS)V1.1|  129.9    |  146.7   |  158.8   |  177.3    | 194.5  |
|>  |--------------------|------------------------------------------------------|
|>  |Linpack 100x100     |   26.4    |   30.2   |   36.3   |   38.6    |  42.5  |
|>  |       1000x1000    |   70.8    |   79.9   |   86.4   |  102.1    | 111.6  |
|>  |--------------------|------------------------------------------------------|
|>  |Perfect BM Suite    |   18.1    |   20.4   |   22.9   |   26.0    |  28.6  |
|>  | Mflops(Geom. Mean) |           |          |          |           |        |
|>  |--------------------|------------------------------------------------------|
|>  |DN&R Labs           |           |          |          |           |        |
|>  |CPU2    (MVUPS)     |  159.1    |  179.7   |  193.2   |  217.9    | 239.3  |
|>  |--------------------|------------------------------------------------------|
|>  |Livermore Loop Mflop|   18.7    |   21.3   |   22.9   |   25.6    |  28.1  |
|>  |--------------------|------------------------------------------------------|

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?

Jason W. Solinsky
From: 8904596@ul.ie
Newsgroups: comp.arch
Subject: ISPS Simulator / 8086 Spec. Wanted.
Date: 3 Nov 92 18:07:48 GMT
Organization: University of Limerick, Ireland


My wish list...

Are there ftp sites with ISPS simulators available ?

Does anyone have a ISPS description of the Intel 8086/8088 architecture ?

Any information on the above would be most helpful.
	
			Thanking you in advance,

				Warren Buckley,

				Email : 8904596@ul.ie
Newsgroups: comp.arch
From: jg@crl.dec.com (Jim Gettys)
Subject: Re: DEC Alpha AXP System Performance
Keywords: Alpha, AXP, SPEC, DEC
Organization: DEC Cambridge Research Lab
Date: Thu, 12 Nov 1992 10:15:20 GMT

In article <martin.721554717@bert>, martin@math.rwth-aachen.de (  Martin Schoenert) writes:
>     DEC 3000 Model 500 AXP, @150 MHz
> 	SPECint92	 74.30
> 	SPECfp92	126.0
> 
>     DEC 3000 Model 400 AXP, @133 MHz
> 	SPECint92	 65.32
> 	SPECfp92	112.2
> 
> 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
> 
>     DEC 3000 AXP Model 500
>         SPECint92        66
>         SPECfp92        118
> 
>     DEC 3000 AXP Model 400
>         SPECint92        59
>         SPECfp92        103,5
> 
> 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.

In any case, Dileep's numbers are the first set
of "official" correct ones and were submitted to SPEC.
			- Jim

-- 
Digital Equipment Corporation
Cambridge Research Laboratory
Newsgroups: comp.arch
From: nickh@CS.CMU.EDU (Nick Haines)
Subject: Re: IEEE used for Dollars and Cents
Originator: nickh@VOILA.VENARI.CS.CMU.EDU
Organization: School of Computer Science, Carnegie Mellon University
	<1992Oct31.193109.611@microsoft.com>
	<1992Nov4.204328.18590@draco.macsch.com>
Date: Thu, 5 Nov 1992 17:01:50 GMT

In article <1992Nov4.204328.18590@draco.macsch.com> dnl@convex.is.macsch.com (David Lombard) writes:

   >In article <BwyBs0.M88.1@cs.cmu.edu> nickh@CS.CMU.EDU (Nick Haines) writes:
   >>All business software everywhere uses integer arithmetic.

   [...]

and criticizes this statement. We've discussed it over email (he
kindly apologized for his harsh language) and I think I should write
it more clearly:

"All business software everywhere uses arithmetic which preserves full
accuracy".

i.e. FP is out of the question (unless you represent everything as
integers and do tests for some MAXINT which is equal to the size of
the mantissa). I didn't mean that business software uses 32-bit two's
complement integer representations (god forbid).

I still wait for counter-examples.

Nick Haines
Newsgroups: comp.arch
From: symin@cosmos.kaist.ac.kr (Min Sanglyeol)
Subject: SPA: pixie for Sparc architecture
Organization: KAIST
Date: Thu, 5 Nov 92 08:49:54 GMT

Could someone in the netland please indicate whether the trace generation
program called SPA is public domain software and if so where I can get that
through anonymous ftp ? Someone previously mentioned that the above program
is available from solbourne.solbourne.com in /pub/uploads/from.larry but
I could find that in the above mentioned directory. For your information,
SPA is a program similar to pixie on R-x000-based systems.
Thanks in advance.
----------
Sang Lyul Min
Dept. of Computer Engineering
Seoul National University

symin@dandelion.snu.ac.kr
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: MIPS and MHz
Keywords: RISC, MIPS, cps
Date: 13 Nov 92 01:13:18 GMT
Organization: Auspex Systems, Santa Clara

>How can a non-superscalar implementation at 50MHz run 59.1 MIPS?

Remember, MIPS, when used to describe how fast a processor runs, stands
for Meaningless Indicator of Processor Speed.  It does *not* necessarily
mean Millions of Instructions Per Second.

"59.1 MIPS" could mean that the machine in question ran some particular
benchmark 59.1 times faster than some VAX-11/780 did, at some point in
the distant past.

I.e., don't worry about it, just ignore all performance numbers given as
"n MIPS".
From: pl@hakki.cs.tut.fi (Lehtinen Pertti,,,OHJ,J8344)
Newsgroups: comp.arch
Subject: Re: MINIMUM instruction set
Date: 11 Nov 1992 15:04:12 GMT
Organization: Technical University of Tampere, Dep. of Computer Science ,Finland 
Distribution: world
Reply-To: pl@hakki.cs.tut.fi
NNTP-Posting-Host: hakki.cs.tut.fi
Originator: pl@hakki.cs.tut.fi

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

	Some time ago there was rumour about one instruction RISC,
	so called ultrarisc, which is capable to do everything.
	This was not practical. (But disassemler is easy to write :-)

	(Instruction is reverse substract and skip if borrow with
	some additional architectural requirements)

=====

	
-- 
pl@cs.tut.fi				! All opinions expressed above are
Pertti Lehtinen				! purely offending and in subject
Tampere University of Technology	! to change without any further
Software Systems Laboratory		! notice
Xref: sparky comp.arch:10562 comp.graphics:11647
From: hepler@cbmvax.cbm.com (Ed Hepler)
Newsgroups: comp.arch,comp.graphics
Subject: Early use of XOR to show motion
Date: 9 Nov 92 22:02:36 GMT
Reply-To: hepler@cbmvax.cbm.com (Ed Hepler)
Distribution: world
Organization: Commodore, West Chester, PA
Keywords: XOR Raster

Does anyone have any early (pre 1974) references to the
use of XOR (Exclusive-OR) to display "alternate images"
(i.e. make it look like one image is moving over another)?

Thanks,

Ed Hepler
hepler@cbmvax.cbm.com



Newsgroups: comp.arch
From: mo@gizmo.bellcore.com (Michael O'Dell)
Subject: Re: RTX and SC32
Keywords: 
 
Reply-To: mo@bellcore.com
Organization: Center for Chaotic Repeatabilty
Date: Thu, 5 Nov 92 16:32:50 GMT

if what was said about the RTX and it's forth performance is true,
why not just compile C into forth?

i did read that a c compiler was being done for the SC32 when it
was abandonded.

	-mo

Bellcore?? Bellcore isn't allowed opinions; these be mine.
From: pavlov@niktow.canisius.edu (Greg Pavlov)
Newsgroups: comp.arch
Subject: DEC Alpha AXP System INTEGER Performance
Keywords: Alpha, AXP, SPEC, DEC, INTEGER
Date: 13 Nov 92 14:33:12 GMT
Organization: Canisius College, Buffalo NY. 14208

In article <1992Nov12.101520.2828@crl.dec.com>, jg@crl.dec.com (Jim Gettys) writes:
> [re ALPHA SPEC results]  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.
> 
  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.

  greg pavlov
  pavlov@fstrf.org
Newsgroups: comp.arch,comp.benchmarks
From: ifenton@crc.ac.uk (I. Fenton)
Subject: Re: DEC ALPHA Performance Claims
Organization: MRC Human Genome Resource Centre
Date: Fri, 13 Nov 1992 16:53:19 GMT

i didn't write the numbers down, but i think that the low-end ALPHA
box is a 133MHz job which gives a specint92 of about 70-ish (?).  from what
i remember the 486-50MHz has a specint92 of around 30.  so, MHz for MHz,
alpha seems no better than a 486... or i am a twit ?!

=============================================================================
IAIN FENTON                             | All errors of spelling, grammar &
Institute of Medical Genetics           | fact are due to a missing <Del> key
University of Wales College of Medicine |====================================
Heath Park                              | "No man should marry until he has
Cardiff  CF4 4XN                        |  studied anatomy and dissected at
U.K.                                    |  least one woman" - de Balzac
=============================================================================
Voice = +44 - 222 - 744049   | In 1912, Jack Johnson, the first black world
Fax   = +44 - 222 - 747603   | heavyweight boxing champion, was refused
Email = fenton@uk.ac.cardiff | permission to board the Titanic because of
   (or) wmgif@uk.ac.cardiff  | his colour.
   (or) ifenton@uk.ac.crc    |
=============================================================================

Newsgroups: comp.arch