HDTenEightyP/NetNews huggingface dataset:
From: sthe@td2cad.intel.com (Siang-Chun The)
Subject: Re: Neural networks chips?
Reply-To: sthe@td2cad.intel.com
Organization: Intel Corporation, Santa Clara
Date: Thu, 8 Oct 1992 16:21:09 GMT

Intel has released a neural network chip (called the 80170NX) as well as
various support products for it.  For more information, please contact:

	Phone:	(408)765-9235
	FAX:	(408)765-9797

or mail:

	Mailstop RN3-17
	Intel Corporation
	P. O. Box 58119
	Santa Clara, CA 95052-8119.

Glossy brochures as well as data sheets are available.

				Siang-Chun The
				sthe@td2cad.intel.com
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: Other VMS features...
In-reply-to: zrepachol@cc.curtin.edu.au's message of Thu, 8 Oct 1992 18:29:18 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<1992Oct6.133255.2382@crd.ge.com> <1992Oct9.032918.1@cc.curtin.edu.au>
Date: 9 Oct 92 09:31:41

In article <1992Oct9.032918.1@cc.curtin.edu.au> 
zrepachol@cc.curtin.edu.au (Paul Repacholi) writes:
   Another HBD was turning the record size word ( 16 bits ) into a SIGNED int.
   ask anyone who has tryed to copy a backup saveset of >32K blocksize. :={

Yah, that's an example of the fixes backwards compatibility gets you into.
IMHO, it was the wrong decision even at the time the VMS version of RMS was
designed: PDP compatibility mode did I/O in native mode anyway and could
have hidden the difference from compatibility mode programs easily, and
you wouldn't have expected to share disks between your RSX and VMS system.
All it got us was the (inefficient) kludge the FORTRAN RTL has to use for
unformatted I/O.

To get back to (computer) architecture: Any suggestions on how to implement
functionality like variablelength records in RMS in such a way that changes
in word size don't bite you badly in the future? Or do we just modify RMS64
for OpenVMS to use 64 bits for the record size and hope nobody will remember
about the system by the time the next expansion comes along?



Lines: 9
Date: Thu, 15 Oct 92 08:31:21 MDT
From: kelly@baloo.ee.byu.edu (J. Kelly Flanagan)
Newsgroups: comp.arch
Subject: DRAM Controllers


	Sorry if this is the wrong group, but does anyone have any
	idea where I can get or who makes modern DRAM controllers?

	I know LSI logic makes one for the SPARC chipset, but there
	must be others?

Kelly
kelly@ee.byu.edu
Newsgroups: comp.arch
From: grunwald@foobar.cs.colorado.edu (Dirk Grunwald)
Subject: Re: Memory reference sequences
Reply-To: grunwald@foobar.cs.colorado.edu
Organization: University of Colorado at Boulder
Date: Sat, 10 Oct 1992 17:29:35 GMT

>>>>> On Thu, 8 Oct 1992 14:59:29 GMT, preston@helena.cs.rice.edu (Preston Briggs) said:
PB> stripes@pix.com (Josh Osborne) writes:
>I have written a (somewhat substandard) cache simulator.  I quickly
>realised that it can't tell me much without real (or something
>approxamating real) reference sequences.  Does anyone know where I
>could find either a large file with a reference sequence, or a way to
>gennerate reasonable approxamations (code, or algos would be great)?

PB> The problem with traces is that they get very large.  One
PB> approach, apparently independently discovered several times, is to
PB> avoid collecting traces; instead simulate the cache "in real
PB> time".
--

Actually, you can do this using 'pixie' w/o the instrumentation.  I
write a wrapper called ``tychout'' that opens a socket (29, by
default), waits for a connection on unix domain socket and then starts
a pixified application.

Then, I have a version of tycho (ptycho) that reads the binary data
directly from the application. Using this, you can run very big cache
simulations (which we've been doing, for comparisons of memory
locality in memory allocators). Also, side-stepping the normal 'tycho'
structure means you can speed up tycho about four-fold (skip
text->binary conversion, inline somethings using gcc, etc).

We also have a system based on the somewhat more awkward 'AE' (called
'SPAE') system for simulating parallel programs ``on the fly''.  Here,
you have to have the simulator direct the program execution to
faithfully model e.g., internetwork delays and or cache contention in
a parallel system. But it's more difficult to use.

Dirk Grunwald                          Asst. Prof, Univ. of Colorado at Boulder
Newsgroups: comp.arch
From: alpha@waggen.twuug.com (Joe Wright)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: ALPHA, Box 68621, Va. Beach, VA 23455
X-Newsreader: TIN [version 1.1 PL6]
Date: Sat, 10 Oct 1992 21:30:00 GMT

Us 'old' guys should also remember that 7-track tape is six bits
plus parity, 9-track is eight bits plus parity.  That's mag tape.
The ascii set was done at AT&T for teletype machines with 8-channel
paper tape (seven bits plus parity).  
-- 
Joe Wright  alpha@waggen.twuug.com  
Xref: sparky comp.arch:9926 alt.folklore.computers:15016
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch,alt.folklore.computers
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 12 Oct 92 00:12:23 GMT
Followup-To: alt.folklore.computers
Organization: Auspex Systems, Santa Clara

(Followups to "alt.folklore.computers".)

>Besides, what was the advantage at that time of a word length which
>was a multiple of 8? There was no agreed upon character coding scheme
>of that length (IBM's EBCDIC was 12 bits, CDC used 6 bits, ...)

No, EBCDIC was 8 bits, but I don't think it emerged until the 8-bit-byte
360 did.  I think IBM's BCD used 6 bits; IBM *punched cards* used 12
bits, but which IBM machines, if any, stored character strings in
punched-card code (which doesn't include reading raw punched card code
into memory and then converting it to BCD for processing)?
From: sarr@sinshan.citi.umich.edu (Sarr J. Blumson)
Newsgroups: comp.arch
Subject: Re: Whatever became of the DEC 10/20 systems...
Date: 14 Oct 1992 13:36:08 GMT
Organization: University of Michigan, CITI
Distribution: world
NNTP-Posting-Host: sinshan.citi.umich.edu

In article <Bw2n8u.172@xrtll.uucp> rsnider@xrtll.uucp (Richard Snider) writes:
>I am curious as to what happened with DEC's Jupiter project to
>replace the Decsystem-10 or 20's with something faster...  I belive
>it was called the Jupiter Project and I heard that it died..  
>
>Does anyone know why ??
>
>Various sources here comment on the fact that the KL CPU took too
>much power for what it did, to word-size, etc...
>
From the viewpoint of a large 10 customer, where I worked at the time,
DEC apparently believed in a single instruction set product line.  You
will receive many flames discussing whether this was incredibly stupid
and they killed the greatest architecture in history or they were very
smart and the 10/20 was competing only with the VAX anyway.

It appeared to be a pure marketing decision, at any rate.


(Sarr Blumson)
Newsgroups: comp.arch
From: alvin@eyepoint.com (Alvin Starr)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: eyepoint
Date: Wed, 7 Oct 1992 12:24:08 GMT

eb@felix.Sublink.Org (Enrico Badella) writes:

>Recently I came hold of and old paper that described the TENEX Operating
>System for old DEC Systems 10 and 20; I never used or saw such beasts but
>I was wondering what was the advantage of having 36 bits instead of 32
>or other 8*n (n>4) architecture.

 These machines where based on 6 bit byte. Where a byte is the size of memory
 needed to hold a character. Consider that these machines were itended for the
 data processing industry where data was being collected on paper tape/punch
 cards and being stored in memory that was extreemly expensive. So the
 designers of the time built systems that had byte sizes optimal to the
 job at hand.
 just think A-Z,0-9 would only reqire 6 bits and you would still have room
 left over fore some punctuation. This restriction of a character set is
 unthinkable today. But at the time it made good sense.
-- 
Alvin Starr                   ||   voice: (416)513-6717
Eyepoint Inc.                 ||   fax:   (416)513-6718
alvin@eyepoint.com            ||
Xref: sparky comp.arch:9982 comp.lang.misc:3266
From: odkahn@eos.ncsu.edu (OPHER DANIEL KAHN)
Subject: Re: One Instruction Computers
Organization: North Carolina State University
Date: Wed, 7 Oct 1992 18:31:58 GMT

In article <1992Oct7.011331.26842@ntuix.ntu.ac.sg>, eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:
|> : 
|> : Let's update this exercise for TODAY'S students.  My question is, for 
|> : all you Hennessy and Patterson readers out there: suppose we actually 
|> : BUILT such a beast.  Update the technology to be the fastest available 
|> : (say, GaAs) and use 1990s address and data widths (let's say 64-bit 
|> : twos-complement data path and 32-bit addresses).  Recognizing that it's
|> : going to take several cycles to do simple things like stepping through 
|> : an array, calling a subroutine, manipulating stacks, etc., and that 
|> 
|> If we have the latest technology, then there should be little problem in
|> doing a lot of instructions in one cycle. 

Like how exactly?
|> 
|> ii)calling subroutine.
|> Why should we call a subroutine, when optimising compilers routinely can 
|> collapse it for us. There is no more need to do that. gotos is the most
|> efficent for a machine but may be difficult for a human to debug, but the
|> optimising compiler can do the work for us.

Compilers can sometimes inline a routine, but how about recursive calls?
How would you inline those? And what memory would you use to store the huge
code that would result?

|> : niceties like multiplies, floating point arithmetic, string collating 
|> : sequence compares, etc. take HUNDREDS or THOUSANDS of cycles, what does
|> 
|> If you have the technology, you do not need thousands of cycles.

Again - how exactly?

|> 
|> : the cycle time of such a machine have to be to be as fast as an IBM 
|> : PC/AT with co-processor on Lotus 1-2-3?
|> 
|> My rought estimate is 0.5 milisecond. 500 cycles of 1 micro second, average.
|> Because of the "string collating sequence compares" or "convolution".

???????? How did you get that cycle time?


-- 
 Opher D. Kahn
From: jgd@csd4.csd.uwm.edu (John G Dobnick)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 10 Oct 1992 00:17:15 GMT
Organization: University of Wisconsin - Milwaukee
Reply-To: jgd@csd4.csd.uwm.edu
NNTP-Posting-Host: 129.89.7.4
Originator: jgd@csd4.csd.uwm.edu

From article <1992Oct9.230020.3388@nas.nasa.gov>, by eugene@wilbur.nas.nasa.gov (Eugene N. Miya):
> For those claiming the existence of a 6-bit byte, sorry I have never
> heard of such a thing on the three 36-bit machines I am familiar with.

Far be it for me to dispute what Mr. Miya says, but...  [ :-) ]

From the Univac 1110 on (that's about 1971-ish, I think), the 1100 series
machines supported "bytes".  The 1110 introduced a set of "byte" instructions
(BM - byte move, BC - byte compare, EDIT - guess :-), decimal arithmetic,
etc.).   These operated on units called "bytes".  The size of these
entities could be programmer specified, as 6, 9, 12, or 18 bits.  In most
cases, the source and destination sizes were independently specifiable,
thus allowing, for example, the BMT instruction (Byte Move with Translate)
to convert FIELDATA (6-bit) to ASCII (9 bit) in one swell foop, as it were.

-- 
John G Dobnick (Ex 1100 jockey)         ATTnet: (414) 229-5727
Computing Services Division             INTERNET: jgd@uwm.edu
University of Wisconsin - Milwaukee     UUCP: uunet!uwm!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire
Newsgroups: comp.arch
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: Multi uP P5 systems
In-reply-to: davidsen@ariel.crd.GE.COM's message of 6 Oct 92 13:32:55 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<1992Oct6.133255.2382@crd.ge.com>
Date: 7 Oct 92 10:33:24

In article <1992Oct6.133255.2382@crd.ge.com> 
davidsen@ariel.crd.GE.COM (william E Davidsen) writes:

[good comments on asynchronous I/O removed]

     I sure hope so. Any o/s which puts file types in the o/s instead of
   the program is really creating problems for the user, and I find that
   more of a problem than the user interface. If programs really want a "$
   delimited left handed nybble swapped hexadecimal" file type, let it be
   done in the program or shared library, and not at a level when all
   userwritten file transfer and backup programs have to deal with it. As
   my youngest says "yuckypoo!"

But Bill, that's exactly how it is in VMS  the file system _only_
handles files as a set of bytes (well, blocks, but anyway). It's a shared
library called RMS that does all that "$ delimited..."type stuff. 
And RMS is decidedly not a part of the o/s. There's no problem doing
all your file i/o at the raw byte level as other (:) systems force you
to do! I, for one, am glad to have an optimized version of an ISAMfile
handling library delivered with my computer...and all the tools to go
with it (EDIT/FDL, for instance).
From: eliot@dcs.qmw.ac.uk (Eliot Miranda;W211)
Newsgroups: comp.arch
Subject: compiled bitblt on 68040s
Summary: need to know about 68040 caches
Keywords: dynamic compilation, cache flushing, 68040, bitblt
Date: 7 Oct 92 11:10:36 GMT
Organization: Computer Science Dept, QMW, University of London

I have a dynamically compiled bitblt routine that does bitblt in my Smalltalk
virtual machine on mac IIs.  We've just got some Mac quadras with 68040s and
the routine no longer works unless its run under adb and stepped through slowly.

The problem appears to be the twin I & D caches on the 68040.


The bitblt routine works by concatenating a set of machine code fragments
by writing them into a buffer, and then calling the resultant code sequence.

As I understand it the 68040 is a harvard architecture so I have to ensure
both that the data written is flushed from the dcache, and that the icache is
flushed so that the written data can be executed.

We have no 68040 manual.  Can those that know email me either
	a) a description of the 68040 I&D caches
	b) a description of their solution to this very problem :-)

Send email and I'll summarise for the net.

I need this information quickly!  I have to give the term's first MSc Object-
Oriented programming lab to 40 students on Monday.  the lab has only 26 machines
of which 4 are Quadras.


HELP!

AdvThanks!ance
--
Eliot Miranda,  Lecturer	email:	eliot@dcs.qmw.ac.uk
Department of Computer Science	ARPA:	eliot%dcs.qmw.ac.uk@nsf.ac.uk
Queen Mary Westfield College	UUCP:	eliot@qmw-dcs.uucp
Mile End Road, LONDON E1 4NS	Tel:	071 975 5229 (+44 71 975 5229)
				Fax:	081 980 6533 (+44 81 980 6533)
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 12 Oct 92 20:21:34 GMT
Organization: IDA Center for Communications Research, Princeton

Will Walker <wlw@hpfcso.FC.HP.COM> writes:
> For example without a transfer instruction you might do a store and a
> load from cache to do the transfer.  Suppose this takes 3 cycles.  If
> you add new register ports and a new bus you can almost certainly do
> the new transfer instruction in one cycle.  So your trade-off is 2
> cycles times "how common are register transfers" versus a rather
> significant hardware cost (as John pointed out, register read/write
> ports are precious).

Of course, if this were the real tradeoff, no one would ever propose
implementing transfers.  The problem is that a store and a load rates to
take much more than 3 cycles.  As I have said before, on a machine with
a write-through cache, every write forces an eventual memory cycle, and
if your code is memory-bound than this directly increases the run time
of your program.  As someone else pointed out, this can easily be up to
30 cycles, although I suspect that worst case won't be too often
achieved.  Still, it is far more than 3.

Someone else suggested that one could use the write buffers of the Alpha
chip as a mini-write-back cache which avoids this excess memory traffic.
I think that is very unrealistic.  If your code has any substantial
amount of memory traffic, there are going to be a whole train of writes
coming along after the one in question.  Once a few additional writes
have been done, the one for the register transfer reaches the head of
the queue and has to be flushed.  At that point you pay whatever memory
penalty applies.

Unless you manage to write to the same cache line twice in a very short
period of time, every write has to cost you a separate memory cycle.

                                        David desJardins
From: tahar@i80s25.ira.uka.de (tahar)
Newsgroups: comp.arch
Subject: DLX-VHDL Description
Date: 8 Oct 1992 16:06:32 GMT
Organization: University of Karlsruhe, FRG
Distribution: world
NNTP-Posting-Host: i80s25.ira.uka.de
Keywords: DLX, VHDL, RISC

Hi there,

I am looking for the VHDL description of the DLX RISC. 
I just know, that this work has been done by  "Avaneendra Gupta" and 
"Paul R. Stephan" as a project titeld: "Design and Analysis of DLX".

Could somebody provide me the ftp-address of the site, where to get access
to this VHDL description or may someboy know one of the above mentioned people.

Please reply direct to me: (email) tahar@ira.uka.de

  Thanks in advance,

    Sofiene Tahar
-- 

*******************************************************************************
Sofiene Tahar                                     | email: tahar@ira.uka.de 
Institut fuer Rechnerentwurf und Fehlertoleranz,  | Tel.: +49 (721) 608 4220
Fakultaet fuer Informatik, Universitaet Karlsruhe,| Fax: +49 (721) 370455
P.O. Box 6980, W-7500 Karlsruhe 1,                |
Germany                                           |

Newsgroups: comp.arch
From: dan@cae.prds.cdx.mot.com (Dan Breslau)
Subject: Re: What was the intended advantage of using 36bits CPU?
Organization: none
Date: Fri, 9 Oct 1992 13:51:12 GMT

jgd@csd4.csd.uwm.edu (John G Dobnick) writes:

>     If you do a _backward_ read on such a tape record, you're in deep
>     doo-doo (:-)) -- characters won't line up properly on word boundaries.

And you hear the voice of Robert Palmer whispering, "I buried Ken..."

Dan Breslau
dan@codex.com
From: krn@waikato.ac.nz
Newsgroups: comp.arch
Subject: CM-1 and CM-2 flag bit diferences
Date: 9 Oct 92 16:27:19 +1300
Organization: University of Waikato, Hamilton, New Zealand

I've read in the literature that the CM-1 processor has 8 flag bits and 
the CM-2 processor has only 4 flag bits. Now I know what each bit is and
what it does in the CM-1 but can't find any information about the 4 CM-2
flag bits. Are they just 4 of the ones from the CM-1? Could someone
please tell me what each flag bit is and if any of them are different from
the CM-1 flag bits, give an explaination of what they do as well. Thanks.
					Kevin Niederberger.

Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Memory reference sequences
Organization: Pix Technologies -- The company with no adult supervision
Date: Wed, 7 Oct 1992 17:15:19 GMT

I have written a (somewhat substandard) cache simulator.  I quickly
realised that it can't tell me much without real (or something approxamating
real) reference sequences.  Does anyone know where I could find either
a large file with a reference sequence, or a way to gennerate reasonable
approxamations (code, or algos would be great)?
-- 
           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.parallel
From: Lubomir Bic <bic@binky.ICS.UCI.EDU>
Subject: Call for Workshop Proposals
Organization: Clemson University
Date: 9 Oct 92 23:40:15 GMT

COMPUTER ARCHITECTURE WORKSHOPS: CALL FOR PROPOSALS (please post)

As in previous years, a number of workshops dealing with important
issues in the field of Computer Architecture will be organized in
conjunction with the 20th Annual International Symposium on Computer
Architecture (ISCA '93), to be held in San Diego, California, USA.

The workshops will be held at the same location as the conference,
(for one or two days - May 14-15, 1993) prior to the main Architecture
Symposium (May 16-19). Several other conferences will also take place
during the same week (May 16-22) as part of the Federated Computer
Research Conferecne (FCRC).

Support for each workshop will consist of providing a meeting space,
overhead projectors, coffee breaks, publishing the record, publicity
arrangements, and some social events.  Participants will be charged a
small registration fee to cover these expenses.

Each workshop will be requested to produce a record of the workshop
events, discussions, and presentations.  These may later be published
in the ACM SIGARCH Computer Architecture Newsletter (CAN).

Only a limited number of workshops can be accommodated.  To assist in
the organization of these workshops, SIGARCH and the ISCA Organizing
Committee are soliciting proposals for workshops.  Proposals should
include the title of the workshop, a brief description of the focus,
the organization and format of the workshop, the duration (1 or 2
days), and a proposed list of invitees.

Proposals should be submitted as soon as possible, and in no case
later than November 1, 1992, to:

Alex Nicolau, Workshops Chair
Department of Information & Computer Science
University of California, Irvine
Irvine, CA 92717
nicolau@ics.uci.edu
(714) 856--4079

A selection committee will evaluate all proposals.  Notifications of
acceptance will occur in a timely manner.


Newsgroups: comp.arch
From: mash@mash.wpd.sgi.com (John R. Mashey)
Subject: SunWorld, October 1992, p103
Keywords: 64-bit
Organization: Silicon Graphics, Inc.
Date: Mon, 12 Oct 1992 21:47:26 GMT

At least 3 people already called the following to my attention, and asked if
it were true; hence I suspect many people may actually believe it's
true, hence the response:

In the latest SunWorld, an article on SPARC V9 says that:

	"According to David Ditzel, chair of SPARC International's (SI)
	SPARC Architecture Committtee, SPARC Version 9 (SPARC-64) and
	DEC's Alpha are the only "true" 64-bit RISC architectures that
	are licensable today.  (The average time betwen when a RISC chip
	becomes "licensable" and "available in production quantities" is
	usually three to four years.)

	     Ditzel uses the term "true" to define the fact that
	SPARC-64's and Alpha's 64-bit address spaces are linearly
	accessible.  Both the HP Precision Architecture RISC (PA-RISC)
	and the Mips R4000 architecture address 64 bits of virtual
	address space, but that address space is divided into 32-bit
	segments.  So, with the latter architectures, a signle process
	can address only 32 bits of memory, and therefore can't tackle
	the thorny technical problems that occur with large arrays of
	floating-point numbers."

Well:
	1) R4000 information has been public for quite a while that
	emphasizes the importance of linear (as opposed) to segmented
	address spaces, and says that the R4000 does this.   R4000s
	are limited to 32-bit addressing in 32-bit mode; are not so limited
	in 64-bit mode; the chips have been shipping;
	the software is being worked on.
	If the argument is that they're only 32-bit because 64-bit
	software isn't done, 64-bit SPARC software isn't shipping yet
	either....
	
	2) Ditzel was on the same 64-bit panel as I was one year ago at
	Microprocessor Forum,  in which this was dicussed,
	so he can hardly have missed this, although
	he pooh-poohed the importance of 64-bit at the time ...

	3) Hence, the published comments should be ignored: they are
	explicit mis-representations of the facts...

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94043
Newsgroups: comp.arch