HDTenEightyP/NetNews huggingface dataset:
From: efeustel@IDA.ORG (Edward Feustel)
Subject: Re: Not using integers
Organization: IDA, Alexandria, VA
X-Newsreader: TIN [version 1.1 PL6]
Date: Fri, 2 Oct 92 11:38:03 GMT

No the B6500 and follow on used 3 tag bits. One of the eight
combinations indicated Number.  The number was confined to the 48 bit
field.

It is hard to preserve access security if you can mint addresses in a
tagged architecture. The other tag bits are used to express a variety
of addresses.

Ed

--
Edward A. Feustel, Research Staff Member
Institute for Defense Analyses           Phone: (703)-845-6657
1801 N. Beauregard Street                Fax:   (703)-845-6848
Alexandria, Va. 22311-1772               Email: efeustel@ida.org 
Newsgroups: comp.arch
From: lchoi@m.cs.uiuc.edu (Lynn Choi)
Subject: Performance metric for 386DX
Summary: Need to get the performance figures for 16Mhz 386DX
Keywords: Processor speed performance
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 6 Oct 1992 03:29:40 GMT

Hello, everybody..

    Can anyone give me performance figures like MIPS for 16Mhz 386DX?
I'd like to include the figure for paper writeup. I know MIPS or FLOPS
does not show the real performance...

The other information I'm looking for is the number of signal lines(i.e.
excluding power pins) for iWARP and MDP.

Please send the information by email.
Thanks.

-Lynn
lchoi@cs.uiuc.edu



Newsgroups: comp.arch
From: storm@cs.mcgill.ca (Marc WANDSCHNEIDER)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: McGill University, Montreal, Canada
Date: Sun, 27 Sep 1992 19:59:52 GMT

In article <Bv8tzG.Kv1.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>
>In article <14813@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:

>I count four:
>- Alpha  (which is about to be named VRX or some such??)
>- R4000
>- Ncube-2 node processor, I think
>- KSR-1 node processor (actually they only implemented 40 bits)
>
>plus in the works
>- SPARC
>- POWER
>
>and the players that definitely should have unrevealed plans are
>- x86

	As far as I'm aware, Intel's new P5 chip has 64bit addressing and the
like, and many other things to support 64bit stuff.  Not quite sure of the 
register size or other details though.


ToodlepiP!
Marc 'em.

-- 
  storm@cs.mcgill.ca           McGill University         C program run.  Run  
  Marc Wandschneider           Montreal, CANADA          Program run! PLEASE!
    Frank Sinatra is allowed to make rude comments about anyone he wishes.
        S. O'Connor is not. This is the law. Learn it.   - Net Poster
From: brb@falcon.is (Bjorn R. Bjornsson)
Newsgroups: comp.arch
Subject: Re: Multi uP P5 systems
Date: 26 Sep 92 04:21:51 GMT
Organization: Gagntaekni/Bijective Tech.

feustel@netcom.com (David Feustel) writes:
>Having spent more time using VAX VMS than I like to remember, I
>consider any resemblance of NT to that OS to be the single biggest
>strike against NT.

Much as I like Unix, I would kill to have a decent signaling system
(known as ASTs - Asynchronous System Traps in RSX-11 and VMS) instead
of the rotten kludges everyone has to put up with in the (various)
Unix systems.  I've been gnashing my teeth for ten years over the fact
that there was a chance to put this right when BSD was implemented.

I think it would be hard to measure how costly this deficiency
in Unix really is, not to mention the several subtly and not so
subtly incompatible implementations.  In case you don't know what
the costs are: Programming time and design constraints.

Bjorn R. Bjornsson
brb@falcon.is
Xref: sparky comp.arch:9770 comp.lang.misc:3197
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 1 Oct 92 13:01:40 GMT
Organization: Purdue University Statistics Department

In article <JAN.92Oct1110550@pallas.neuroinformatik.ruhr-uni-bochum.de> jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) writes:
>In article <BvF75z.GBA@mentor.cc.purdue.edu> 
>hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:

>                        On parallel machines, the cost of any test
>   is usually at least the cost of completely doing both branches.

>Come on Herman, why do you insist than a parallel machine must be SIMD?
>Any MIMD machine can, of course, emulate a SIMD machine, and do your
>tests efficiently. And newer SIMDs, like the MasPar, have some ability
>to perform conditional operations without deactivating/activating sets
>of processors, though I wouldn't know whether that applies to your examples.
>So your comment really only applies to the CM1/2...

From what I have seen, all of the massively parallel machines are SIMD.
I fail to see how a SIMD machine, by the very definition of SIMD, can
do what you say.  Of course, it the machines are modified so that a
moderate sized instruction cache is used, instead of just single instructions,
this will change.  But the problems I have cited with random number generation
are only somewhat alleviated by this.

One major problem with many parallel processors is the absence of sufficient
memory for each processor.  It would be difficult to do moderately efficient
random number generation without some thousands of words available for the
unique use of each processor.  It would be necessary to have a substantial
uniform buffer, and there are reasons to have two large exponential buffers
and a moderate third buffer.  
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: Multi uP P5 systems
Organization: Xenix Support, FICC
Date: Mon, 28 Sep 1992 15:25:37 GMT

In article <1248@falcon.is> brb@falcon.is (Bjorn R. Bjornsson) writes:
> Much as I like Unix, I would kill to have a decent signaling system
> (known as ASTs - Asynchronous System Traps in RSX-11 and VMS) instead
> of the rotten kludges everyone has to put up with in the (various)
> Unix systems.  I've been gnashing my teeth for ten years over the fact
> that there was a chance to put this right when BSD was implemented.

The designers of UNIX apparently made a deliberate decision to miminise
the visibility of asynchronous events to processes, and only implemented
a minimal set of such features. They retain this perspective: Plan 9
does not support asynchronous I/O within a process. The preferred method
of handling asyncronicity in UNIX is to spawn multiple processes and do
blocking waits.

Having worked on RSX-11 where you can't do much of *anything* without
messing around with ASTs, I can sympathise with this. In the other hand,
having worked with RSX-11 I sure miss them in UNIX. To me, this is the
single design-level problem with the UNIX family of operating systems.
Apart from this (and the kludges like poll and select that have been
invented to cover for it), UNIX remains a pretty clean design. There
really are no other areas that need enough of an overhaul to justify
creating a whole new API. The sort of extension needed to accomodate
real-time, networking, and transaction processing cleanly could be done
without abandoning the nice design in the rest of the system. You'd see
code like this:

	queue_read(fd, sizeof buffer, buffer);
	...
	nbytes = wait_for(fd);

	queue_read(fd, sizeof buffer, buffer);
	queue_read(fileno(stdin), 1, &c);
	fdset = FDBIT(fd) | FDBIT(fileno(stdin));
	avail = wait_many(fdset);
	if(avail & FDBIT(fd))
		nbytes = wait_for(fd);

This appears superficially like select, but all of the I/O operations would
have queue_ equivalents. For example:

	fdset = 0;
	for(i = 0; i < num_ttys; i++) {
		tty[i].fd = assign_fd();

		queue_open(tty[i].fd, tty[i].name, O_RD|O_WR);
		fdset |= FDBIT(fd);
	}

	avail = wait_many(fdset);

RSX hackers will recognise the relationship between LUNs and FDs... ASTs would
be similar.

I fear it's too late, though. The companies who can afford to do this are
playing idiot NIH games, and POSIX 1003.4 is looking more and more like it's
going to produce Sockets II : The Revenge.
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Newsgroups: comp.arch
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 1 Oct 92 15:10:45 GMT
Organization: Bergen Scientific Centre, Bergen, NORWAY

In article <BvAI3L.2CF@doppler.ncsc.org> gbyrd@ncsc.org (Gregory T. Byrd) writes:
>In article <Bv8tzG.Kv1.2@cs.cmu.edu>, lindsay+@cs.cmu.edu (Donald
>Lindsay) writes:
> >
> >I count four:
> >- Alpha  (which is about to be named VRX or some such??)
> >- R4000
> >- Ncube-2 node processor, I think
> >- KSR-1 node processor (actually they only implemented 40 bits)
>
>[rest deleted]
>
>Don't know why you made this caveat with the KSR1 processor and
>not the others.  Alpha only implements a 43-bit address, and
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the R4000 implements a 40-bit address, I believe.  I don't know
>about plans for the nCUBE-2 processor.

   The 21064 is what implements 43-bit addresses. The Alpha architecture
is a true 64-bit engine with the capability of supporting 64-bits worth of
address space.

-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	Izahi Engineering
izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-5)54-4653
Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Organization: Metaflow Technologies Inc.
Date: Wed, 30 Sep 1992 20:31:12 GMT

In article <1671@idacrd.UUCP>, desj@ccr-p.ida.org (David desJardins) writes:
|> John R. Mashey <mash@mash.wpd.sgi.com> writes:
|> > Since there may not be anything *after* microprocessors, maybe we'll
|> > have learned from our previous sins.
|> 
|> I can't tell if this is a joke.  You aren't seriously suggesting that
|> modern microprocessor design incorporates all of the design principles
|> that will be needed until the end of time??
|> 
|> I can just imagine those computer designers in the year 2100 or so
|> saying, "Yeah, single instruction streams with superscalar execution,
|> that's the ticket."  Not.
|> 
|> I would say that even suggesting that this is a possibility is just
|> about the most arrogant thing I have ever heard.
|> 
|>                                         David desJardins

Lighten up!  There's plenty of truly arrogant statements around, if you're
really looking for them.  This one isn't one of them:

  1) John is talking about *classifications* of processor *scale*.
     There was no implication that we have invented everything that
     we will ever need.  
  2) ...and even if you did believe that was his implication, there
     is always the equivocation (e.g., "Since there _may not be_")
     that is common to many personalities involved in science and
     engineering (including yours truly!).  

I suppose that when nanotechnology comes to fruition, we might have to
invoke that equivocation, to recapitulate all our previous errors on
the nanoprocessor, bioprocessor, and moleculoprocessor level!   8-)
-- 

...Russ Schnapp
BIX: rschnapp           Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: HELP: What does ARJ(or other) do besides Huffman Encoding ?
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Wed, 30 Sep 92 15:59:03 GMT

In article <AA7pVngKd6@sean.tomsk.su> root@sean.tomsk.su writes:
>
>        What does ARJ (or any other archive program) do in order to
>achive archivating the source volume into a half of it ? I.e. what does
>it do besides Huffman Encoding ? I've tried a pure Huffman Encoding
>and I've never got more than 1.5 compression ratio. Does anybody know : why ?

They tend to not use Huffman at all. They tend to use word or phrase-based
schemes such as LZW, and similar variants. I recommend you read a book
called "Text Compression". Unfortunately, I have lent it to someone,
so can't even give you the authors' name, publisher, etc. It is 
fairly slim, about 150-200 pages, has a blue cover, and costs an
arm and a leg (About $75 USD). However, it is an excellent work and
covers a large number of encoding schemes including Huffman, LZW
variants, arithmetic coding, etc.

Bob







Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: One Instruction Computers
Date: 3 Oct 92 13:05:35 MDT
Organization: Utah State University

In article <1992Oct2.192543.12309@dartvax.dartmouth.edu>, mac@coos.dartmouth.edu (Milton A. Colvin) writes:
> 
> The first NED processors were based on the Able minicomputer, notable
> for it single instruction - MOVE. MOVE encodes an 8-bit source and an
> 8-bit destination.
> 
> As far as I know, this was the only commercial one-instruction
> machine.  For its time it was quite fast. A number survive in
> Synclaviers and as network routers at Dartmouth.

DEUCE, a British machine ca. 1955, was also a MOVE-only machine. However,
it's instructions had three address: Source, Destination, and Next Instruction.

It was built by the English Electric Company, and I don't know who else
besides the Royal Aircraft Establishment bought one (the book that I got
the info from was written by someone from R.A.E.).

Roger Ivie
ivie@cc.usu.edu
Newsgroups: comp.arch,comp.arch.storage,alt.sys.sun
From: bertil@isy.liu.se (Bertil Reinhammar)
Subject: AUSPEX ? 
Summary: Request for info about AUSPEX systems
Organization: Dept of EE, University of Linkoping
Date:  1 Oct 92 08:18:07 GMT

!!!
Here in the outbound, we appear to lack representation
of AUSPEX. Thus I ask You:
1) Why should I (not) buy an AUSPEX system ?
   1a) NFS service any good ?
   1b) Compute service any good ?
   1c) OS any good ?

2) Where do I get in touch with a proper AUSPEX
   representative ( provided I wish after all answers :-)
   given that I live in Sweden.

------------------------------------------------------------------------------
Bertil Reinhammar, Dep. of EE. Linkoping University, S-58183 Linkoping, SWEDEN
Phone: +46 13 282647
email: bertil@isy.liu.se

Newsgroups: comp.arch
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Software Engineering Institute
Date: Thu, 1 Oct 1992 12:38:53 GMT

In article <BvF5pp.8ws@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Herman Rubin) writes:

>BTW, in the distant past, there has been at least one machine with 
>separate address and arithmetic units, with the addresses packed
>several to a word.

Indeed there has.  The English Electric KDF9 had this feature.  Arithmetic
was done on 48-bit integers, and there were no integer registers - the
machine had a hardware stack 16 cells deep.  The address length was 16
bits, and there were sixteen special registers (Q stores) that could
hold three 16-bit integers packed into 48 bits.  This was an interesting
design, since the three pieces were used differently:

	C (counter)
	I (increment)
	M (modifier)

The Modifier is the indirect address.  A special machine instruction 
would add the increment to the modifier, decrement the counter, and
jump if zero or non zero.  In other words, a FOR loop stepping over
an array.  To do any other kind of address arithmetic, you had to
copy from the M field onto the stack, munge at will, and copy back again.

For its time, a fascinating machine.  And very hard to write code for,
let me tell you!
Newsgroups: comp.arch
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Software Engineering Institute
Date: Thu, 1 Oct 1992 12:48:51 GMT

In article <lck5mmINNl11@spim.mti.sgi.com> cprice@mips.com (Charlie Price) writes:

>When looking at benchmarks analyses it was clear that not being able
>to directly transfer between the register sets in the SPARC architecture
>was losing them some performance.  This wasn't a case where someone
>wanted to use the registers as temporaries, but rather where
>a data object was operated on by both the ALU and FPU.

This agrees with my own brief analysis of the machine.  But I found that
the major loss of performance was due not to this feature alone, but to
its synergistic interaction with another "feature" - a calling convention
that passes all parameters in integer registers, even floating ones.

A typical function call - sqrt(x), say - then involves this:

	store actual x from fp reg into memory
	load from memory into int (o) reg
	call
	store passed parameter from int (i) reg into memory
	load from memory into fp reg
	munge
	store result into memory
	load result into int reg
	return
	store returned value into memory
	load returned value from memory

Well, I've seen a lot of machines in my time, but cannot recall a more
blatant mismatch between what the hardware actually does and how you
are supposed to use it.  Nuff said.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Date: 27 Sep 92 22:55:19 GMT
Organization: Auspex Systems, Santa Clara

>	As far as I'm aware, Intel's new P5 chip has 64bit addressing and the
>like, and many other things to support 64bit stuff.

As far as I'm aware, Intel's upcoming P5 chip won't have anything of the
sort; where had you heard that P5 was going to be an implementation of a
64-bit version of the *86 architecture?
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Average number of instructions between context switches
Organization: Intel Corp., Hillsboro, Oregon
	<1992Oct1.150546.19768@ryn.mro4.dec.com>
Date: Wed, 7 Oct 1992 04:51:20 GMT

You can get a first approximation to this number by running vmstat on
any reasonably BSD UNIX system. It'll give you context switches per
second, and total user/system time. This can be used to give yourself
upper bounds on time between context switches. Then, take your
favorite mechanism for projecting instructions between context
switches.


--

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)
From: jtien@venice.eng.uci.edu (Joe Tien)
Subject: need ftp site for Specmark program
Newsgroups: comp.arch
Reply-To: jtien@venice.eng.uci.edu (Joe Tien)
Organization: University of California, Irvine
Date: 30 Sep 92 00:48:18 GMT


Could someone tell me the ftp site for the Specmark benchmark program (in C).
Also, I was told there is this set of benchmark programs from Stanford. I don't
know the exact name, but I'm working on cache, so any good benchmark program
would be fine.

Thanks much,

Joe Tien
jtien@balboa.eng.uci.edu
Newsgroups: comp.arch
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Subject: Re: DRAMs, etc.
Organization: Netcom Online Communications Service
Date: Thu, 1 Oct 1992 15:29:16 GMT

In article <BvEzuv.2x2@mentor.cc.purdue.edu> dschleef@sage.cc.purdue.edu (John Paul George Ringo, III) writes:
   > Is it possible to pipeline a "70 ns DRAM", say, sending
   > it an  address every 30 ns and picking up the corresponding
   > data 70 ns after the address was sent?

There are two answers to your question.  Both depend upon the
fact that physically, on silicon, DRAMs are organized as
rectangular arrays of rows and columns.

Because of the destructive read mechanism (which is part of
what gives DRAMs their high bit density per square micron),
you read a DRAM by activating the Row, then activating the
Sense Amplifier, then activating the Column, then transporting
the desired bit(s) out to the I/O circuits, then driving
them off-chip to the user.

Since the 4K DRAM (1974) people have realized that IF YOU
ARE WILLING TO CONSIDER A SUBSET OF THE ADDRESS BITS, then
accesses can be much faster.  Namely, if you only change
the address bits associated with the columns, leaving the
row address the same, more than half of the delay of a
general-purpose random access can be eliminated.
In the 4K, 16K, 64K, and 256K DRAMs this was implemented
and called "Page Mode".

Then Inmos came along and invented "Nibble Mode", and TI
and NEC invented Video DRAMs and DEC invented Static Column
and all hell broke loose.  Inside the guts of the DRAM,
these are just bells and whistles bolted onto Page Mode.
Each one has certain advantages for certain types of external
system application and use.

So the first answer to your question is Yes, DRAMs can
be pipelined; and for column addresses, they have been
pipelined for the last 18 years.

The second answer to your question is also Yes.
DRAMs _can_ be pipelined in general.  It is possible
to present to the user, the fiction that all address
bits are equivalent, and let the user apply addresses
every X nanoseconds even though the access time is
really (n*X) nanoseconds for some integer n>1.

However, nobody is rushing out to do this.  Why?
Because (A) it's difficult; (B) it will take a lot of
extra circuitry to do it, and this extra circuitry takes
up chip area, area that isn't bits-o-memory, so the cost
per bit of memory will go up (and DRAM mfr's still STRONGLY
believe that big high volume customers buy predominantly
on price); (C) the IBM's and DEC's and HP's and Sun's
and Compaq's and Philips' and Sony's of the world,
the customers that can demand something of a vendor
and get it, aren't demanding it.

Have a look at the paper by N. Kushiyama et al,
"A 4-Mb DRAM with Pipeline Operation", IEEE Journal
of Solid-State Circuits, Vol 26, No 4 (April 1991),
pp. 479-483.

Finally, there's a new move afoot to improve Page Mode
to give incredibly high bandwidth into and out of the
DRAMs.  Three approaches are being tried: Synchronous
DRAM (delivering 100 Mbits/sec per pin), Rambus
(delivering 500Mbits/sec per pin), and CDRAM (whose
bandwidth I don't know but I suspect it is also
100Mbits/sec per pin).

  -- M. Johnson
Newsgroups: comp.arch