HDTenEightyP/NetNews huggingface dataset:
From: burley@geech.gnu.ai.mit.edu (Craig Burley)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 13:27:08 GMT
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
In-reply-to: eb@felix.Sublink.Org's message of 3 Oct 92 16:11:56 GMT

In article <869@felix.Sublink.Org> 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.

Because unlike a 32-bit architecture, a 36-bit could be said to be an even
integral multiple of (and hence somewhat compatible with) other important
DEC machines, particularly the PDP-1 (18 bits) and the PDP-8 (12 bits).

   On the DEC Systems 10 and 20 subject, why did they fade away in those
   days when nobody news what Open Systems were?

They didn't fade away -- they're still running Compu$serve!

Seriously, DEC tried hard to kill the 36-bit line (and the 16-bit line and
the 12-bit line and ...) and largely failed.  Their new VAX line was to
offer a wider range of processing power and price with full compatibility,
and furthermore help DEC be able to organize the company more efficiently
(since VAX/VMS expertise could be leveraged across a range of small, medium,
and huge systems) and reduce DEC's hydra-headed tendency to compete with
itself with different sales units for different machines showing up at
the same prospects' offices trying to outsell each other.

And I suppose that the lack of a workstation-model '10 was part of the
problem, since at least with VAXen, your crusty old VP in DP could easily
agree to buy the "mainframe", and later as it became clear you needs were
migrating to having a more local/personal workstation or server, you could
pony up the money for a smaller VAX and not have to worry about compatibility
problems.  '10s simply couldn't offer that, what with DEC trying to kill them.

Not that '10s _couldn't_ have offered incredibly workstation value.  Heck,
ITS (MIT's Incompatible Timesharing System) was probably the first
half-decent OS for a workstation, and to this day runs only on '10s (if
it runs at all).  :-)

But remember DEC's motto when it comes to retiring older architectures:

    "If we can't kill it, it's immortal!"

--

James Craig Burley, Software Craftsperson    burley@gnu.ai.mit.edu
Member of the League for Programming Freedom (LPF)
From: morioka@hrlgw92.hrl.hitachi.co.jp (Michio Morioka)
Newsgroups: comp.arch
Subject: SPLASH
Date: 30 Sep 92 04:08:59 GMT
Organization: Hitachi Research Lab., Hitachi, Ltd., Japan


Does anyone know where the Stanford SPLASH benchmark programs are?
Let me know the IP address (real address like a 133.11.11.11) 
of the ftp-site.

Thank you in advance for you reply.

------------------------------------------------------------------------------
Michio Morioka                   Hitachi Research Lab.         
                                 Hitachi, Ltd.
------------------------------------------------------------------------------
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 26 Sep 92 16:34:46 GMT
Organization: IDA Center for Communications Research, Princeton

Adams <adams@pdv3.fmr.maschinenbau.th-darmstadt.de> writes:
>>   This is not nessecarily so.  Not all stores to cache are 1 cycle,
>>	or even 2.

> Should not they be one-cycle?

All stores on the DEC Alpha (the processor which I mentioned at the
beginning of this thread) cost many cycles, because current
implementations have write-through cache.  So you actually have to
perform a memory cycle for every one of these.  Assuming your
computation is memory-bound, as most are, that's a very substantial
cost.

Additionally, read hits on the contents of the write buffer can have
unpleasant effects.  I think all of the write buffers have to be
flushed.  Thus reading in your spilled registers too quickly can be
expensive.

I think that int-to-fp transfers on the current generation of Alpha
would be quite a substantial win.  But I'm not a chip designer, and I
know that everything has its price.

                                        David desJardins
Newsgroups: comp.arch
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 12:15:39 GMT

The B6500 and subsequent machines had 3 tag bits separated from
other data fields.  The size of a number is 48 bits.

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
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 15:52:49 GMT
Article-I.D.: iecc.9210051152.AA27759
Organization: I.E.C.C.

In article <869@felix.Sublink.Org> you write:
>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.

All of IBM's scientific mainframes before the 360 series were 36 bits (the
701, 704, 709, 7040, 7044, 7090, and 7094.)  The Univac 1100 series was 36
bits as well (still alive as the Unisys 2200, no?)

As has already been mentioned, then-common six-bit codes fit into 36 bits,
and there was enough room for a 15 or 18 bit address along with the opcode
and a register specifier.

>On the DEC Systems 10 and 20 subject, why did they fade away in those
>days when nobody news what Open Systems were?

Two reasons: one was that the DEC Jupiter project which was to build the
10/20 CPU to follow the KL failed and never produced a working system.
Even had they succeeded, by now the 10's archicture would be looking
rather tired.  It only had 18 bit word addressing, with a moderately
satisfactory kludge on the KL to allow larger addresses in registers and
indirect words, meaning you'd have 8086-style ``near'' and ``far''
addresses.

I'd also think that it'd be very hard to build a modern fast PDP-10
because the instruction set was very memory-intensive, indirect addressing
could be arbitrarily deep with the depth determined by the contents of the
address words, the registers looked like part of memory (e.g., there was
no add register, you just used a register as the second address in a
regular add from memory), and frequent skips, jumps, and executes would
cause severe pipeline breaks.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl
Newsgroups: comp.arch
From: grout@sp90.csrd.uiuc.edu (John R. Grout)
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Reply-To: j-grout@uiuc.edu
Organization: UIUC Center for Supercomputing Research and Development
Date: Mon, 28 Sep 92 20:10:33 GMT

davew@willow03.cray.com (Dave Wagner) writes:

>Check address spaces in Alpha though.  Alpha (21064) has only a 43-bit virtual
>space, and a 34-bit physical space.  I think a 'real' 64 bit processor should
>provide more (64bits) of both.

It depends on how you define 'real'... the Alpha ISA requires the use of
64-bit virtual and physical addresses, which means that any unimplemented
high-order bits on a given processor are reserved for future expansion and
must be zero (and this is _enforced_).  Given this, an ISA subset on a
specific Alpha processor chip (e.g., the 21064) can be a win (a valid
cost-benefit tradeoff) without being a first-implementation artifact which
loses the ability to compatibly implement full 64-bit physical or virtual
addresses later.

IBM found out the hard way that if you don't _enforce_ "reserved and must be
zero", you lose the ability to grow later... because the 360 architecture
allowed the high-order byte of address fullwords in memory and GP registers to
be a flag byte (to save expensive memory) as a first-implementation artifact,
the 390 architecture is stuck almost thirty years later with a mode bit to
distinguish between 24-bit and 31-bit addresses... the Alpha architecture
won't be caught in _that_ trap.

--
John R. Grout						j-grout@uiuc.edu
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development
Newsgroups: comp.arch,comp.arch.storage,alt.sys.sun
From: vanepp@fraser.sfu.ca (Peter Van Epp)
Subject: Re: AUSPEX ? 
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Fri, 2 Oct 1992 00:42:03 GMT

bertil@isy.liu.se (Bertil Reinhammar) writes:

>!!!
>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 ?

Yep, thats what its for, we have one and like it.


>   1b) Compute service any good ?

Nope, as we see under 1a, they have chosen to do one thing well, NFS. There
is a Sparc Host processor, but it isn't a good CPU server, nor is it intended
to be. We have 6 server machines that mount home directories and common files
from the Auspex (across 6 Ethernet ports for performance) for some 11,000
active accounts (there are some 29,000 home directories present on the
server at the moment). The server machines were picked for CPU performance
and the Auspex for I/O performance.

>   1c) OS any good ?

A modified version of SunOS 4.1 runs on the host processor (NFS is done by
dedicated 68xxx micros in the various special processing units.)

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

mstevens@auspex.com would probably be happy to direct you to the appropriate
person.   

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

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 1 Oct 92 01:34:36 GMT
Organization: Purdue University Statistics Department

In article <lck5mmINNl11@spim.mti.sgi.com> cprice@mips.com (Charlie Price) writes:
>In comp.arch, desj@ccr-p.ida.org (David desJardins) 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 is common enough:
>  you do an FP calculation,
>  you convert the result to an integer to use it as an index...

There are many places where this, and other reasons to operate on
the same "words", occurs.  This essentially holds for every trigonometric,
exponential, and logarithmic implementation.

Even many of the RISC machines which have decent integer multiplication
do it in the floating registers.  This is not all that surprising, because
the floating unit, between juggling exponents and shifting, is doing 
fixed point arithmetic.

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.  And Seymour Cray seems to like separate
address and arithmetic units, with common integer and floating
registers.
-- 
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)
Newsgroups: comp.arch
From: mccrohan@salthl.enet.dec.com ()
Subject: Re: Roger Ross quote about Alpha being the only 64-bit micro?
Reply-To: mccrohan@salthl.enet.dec.com ()
Organization: Digital Equipment Corporation
Date: Thu, 1 Oct 1992 08:19:13 GMT


>> 	[deleted]
>>From: koontz@lysithea.jupiter.com (David G. Koontz)
>> 	[deleted]
>>Speaking of vaporware, is it possible to buy an Alpha machine?  
>> 	[deleted]

I believe that there are already a considerable number of them in the hands
of third party developers, and I KNOW that there are lots in house, having
seen a number of them myself. I am confident in Digitals ability in delivering
solid, substantially HW/SW on shipment day. Unless you would prefer 
your computing to be enhanced with "gotchas".  :-)

..just my opinion - not DEC's
Mike
Newsgroups: comp.arch
From: rg9538@ehsn5.cen.uiuc.edu (Ronald E Garnett)
Subject: Thesis projects
Organization: University of Illinois at Urbana
Date: Tue, 29 Sep 1992 02:40:06 GMT
Keywords: thesis

Hello architecture types!

I am a brand new graduate student in computer 
architecture (Electrical Engineering) at the
University of Champaign-Urbana.  I plan on
doing a "hands-on" type thesis, and am looking
for good project ideas.  I have experience
with the Motorola 68HC11 & 6809 as well as 
Intel 80X86 line.

I want to gain experience with either or both
of the AMD29K series and the INTEL '960 series
of RISC processors.  I wouldn't mind getting
a little Motorola 68K work thrown in, as I Ibut
have done a *little* work already with the
68000. I am not plnning on continuing for
my PhD at this time, and what I really want
is some good exposure to advanced digital
design to include such basics as ROM burning,
PLA burning, etc.  

I am not overly interested in parallel 
processing, or rather I don't want to do my
thesis on it!  I find it intriguing, but 
feel I have enough to learn about uniprocessors
for now.  I am in an advanced architecture 
course which inludes pipelining, vector 
processors, cache coherency, parallel systems,
etc.

What I need is a good idea for a thesis-level
project.  I've had several ideas, but none
have really worked out.  I call upon you,
oh great gurus of architecture, give me some
ideas that may at least inspire me to come up
with a topic!!!!!  I'm drawing a blank!

Ron Garnett
!
Newsgroups: comp.arch
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: No special branch/jump formats?
Date: 2 Oct 92 09:16:04 GMT
Organization: Department of Computer Science, U of Copenhagen

michalj@fuw.edu.pl (Michal Jankowski) writes:
>>>>>> On 30 Sep 92 10:39:44 GMT, thorinn@diku.dk (Lars Henrik Mathiesen) said:
>Lars> 	MOV @(R3),PC	becomes	JMP @0(R3)	--- one location more
>This is wrong.

Right. I didn't recognize @(R3) as the assembler shorthand for @0(R3),
so I mistook it for simple register deferred. If you make that line

	MOV (R3),PC	becomes	JMP @0(R3)	--- one location more

we are in total agreement. (I didn't list the non-deferred MOVs that
correspond to deferred JMPs, of course those are equivalent, pace CC.)

>I'll post a table with all the addressing modes tomorrow.

I don't think you need to post the whole table, the last dregs of
relevance have already drained from this thread.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: No special branch/jump formats?
Organization: Xenix Support, FICC
Date: Wed, 30 Sep 1992 15:54:16 GMT

In article <6267@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes:
> It had a 16 bit address bus, but only an 8 bit data bus.  It therefore had
> 8-bit immediate mode, and 16-bit indirect-register mode (from its 16bit gprs).
> It needed either: (a) absolute mode 16-bit addressing; (b) 8-bit indexed
> addressing (displacement mode, for VAX enthusiasts); (c) 8-bit paged mode
> addressing; (d) 8-bit segment addressing; OR (e) absolutely anything else
> of equivalent utility.

I think they ran out of 4-bit opcodes, which they'd have to use for the general
case. If they hadn't they'd have surely implemented "STD" to complement "LDA"
so you didn't have to keep having "SEX" and "STXD". I guess you could make
these stack-relative:

	SEX	Rn
	LDXR	#offset

I'd say the 1802 code had more "SEX" than any other opcode, except maybe
Get HI. A very '60s CPU, indeed. :->
-- 
Peter da Silva                                               `-_-'
Ferranti Intl. Ctls. Corp.                                    'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                                   Har du kramat din varg idag?
Newsgroups: comp.arch
From: breese@monet.imada.ou.dk (Bjoern Reese)
Subject: Neural networks chips?
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Date: Thu, 1 Oct 1992 12:20:18 GMT

Are there any chips supporting the concept of neural networks?

--

Bjoern Reese                   |     Email: breese@imada.ou.dk
Odense University, Denmark     |     Voice: +45 65 932 182 (private)
From: wlw@hpfcso.FC.HP.COM (Will Walker)
Date: Tue, 29 Sep 1992 17:12:44 GMT
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Hewlett-Packard, Fort Collins, CO, USA
From: fpj@ingrina.inesc.pt (Fernando Pereira Jesus)
Subject: Re: implementing random replacement
Organization: INESC (Inst. Eng. Sistemas e Computadores) Lisboa, Portugal
	<1992Sep23.084329.20121@inmos.co.uk>
Date: Mon, 28 Sep 1992 17:11:44 GMT

In article <1992Sep23.084329.20121@inmos.co.uk> roger@gimli.inmos.co.uk (Roger Shepherd) writes:

>   |> Well, a counter can be fairly random as far as replacement is concerned,
>   |> especially if one is just sampling low order bits. Another cheap and easy
>   |> possibility is a feedback shift register that generates a pseudorandom
>   |> sequence. 
>
>   You need to be careful - a feedback shift register generates a pseudo-random
>   sequence of bits. If you just shift a single place in order to generate
>   the a new random number, there will be some very peculiar behaviours possible.
>   For example, line 0..0010 can never be replaced immediately as the only possible
>   next 2 ``random'' numbers are 0..0100 or 0..0101, where as line 0..0000 can
>   be replaced immediately.  Now, whether this matters is another matter, ..... 
>

We have an experimental design in which we use a special feedback
shift register. The shift register runs assyncronously at the speed of
the VLSI logic. That is, as soon as the output of one stage is "1", it
resets the previous stage and sets the next one. The time needed to
step one stage is about 10ns. This time is not constant and is not
deterministic, it may change with temperature (for example), and as
the stages are not exactly equal, it may be different from stage to
stage. With this design, two caches with the exact same initial
conditions will have different replacement sequences.

Aditionaly, the shift register stops at empty (flushed) lines, thus
ensuring that empty lines are used before lines allready in use.

PS: My english is bad, but if I wrote it in Portuguese you probably
    wouldn't understand a word :-) !!
--
   _____                  _ __   ___            
    /  '             /   ' )  ) '  /            Fernando Pereira Jesus
 ,-/-_ _ _  _  _  __/__   /--'  __/-_ _     _   Telef : +351.1.3100282
(_/ (~/ / )(_|/ )(_/(_)  /     / / (~/_)(_// )  e-mail: fpj@inesc.pt
     ___________________/_____(_/___________/   
Newsgroups: comp.arch,comp.lang.misc
From: aranake@cse.uta.edu (Sandeep Suresh Aranake)
Newsgroups: comp.arch
Subject: Where can I get DLX simulator
Keywords: ????
Date: 6 Oct 92 14:00:38 GMT
Article-I.D.: utagraph.1992Oct6.140038.15307
Distribution: usa
Organization: Computer Science Engineering at the University of Texas at Arlington

Could you please tell me the ftp site
where DLX simulator is available ? A friend of
mine who does not have access to news needs
it for his project.

Please send your reply on my e-mail address.

Thanks in anticipation.

Sandeep

aranake@cse.uta.edu
Newsgroups: comp.arch
From: roger@gimli.inmos.co.uk (Roger Shepherd)
Subject: T9000 crossbar/C104 packet router (was  Re: Fujitsu VPP500)
Organization: INMOS Limited, Bristol, UK
Date: Tue, 29 Sep 1992 09:27:04 GMT

>| In article <43035@ogicse.ogi.edu> 
>|  borasky@ogicse.ogi.edu (M. Edward Borasky) writes:
>|     1. First of all, Fujitsu had the courage to implement a full crossbar
>|        for the communication network.  We teach our students that a full
>|        crossbar is too costly to put in a real machine, yet there it is 
>|        a 224x224 full crossbar!  
  
>|  Interesting. A few days ago, I saw the layout of the T9000 transputer.
>|  It contains a 9x4 port crossbar to connect up all the functional units
>|  of the chip to the cache. 

True. Each path supports 32 data bits and 32 address bits. It occupies
less than 10 percent of the die area (depends on what you count as 
"the crossbar"). It will cycle once every 20 nS, giving a data rate
of 800 Mbyte/s (and there's another 800 Mbyte/s second of address
crossing the crossbar as well).

Jan Vorbrueggen now appears to get the T9000 transputer and the C104 
packet router muddled up:

                                 Its datapath thus is 32 bits times 4 wide.
>|  Nonetheless, it seems to take up 68% of chip area. David May remarked
>|  that "nobody should tell you anymore that crossbars are too costly or
>|  can't be implemented".

This is a description of the implementation of the C104 packet router. This
is a 32 way cross bar which worm-hole routes packets for T9000 communication
links. The T9000 link uses 4 wires; this does not mean that the internals
of the C104 is implemented in the same way. It is possible to use C104 packet
routers to build very large networks quite cheaply.


-- 
Roger Shepherd, INMOS Ltd   JANET:    roger@uk.co.inmos 
1000 Aztec West             UUCP:     ukc!inmos!roger or uunet!inmos-c!roger
Almondsbury                 INTERNET: roger@inmos.com
+44 454 616616              ROW:      roger@inmos.com OR roger@inmos.co.uk
From: ivie@cc.usu.edu (CP/M lives!)
Newsgroups: comp.arch
Subject: Re: What was the intended advantage of using 36bits CPU?
Date: 5 Oct 92 09:40:53 MDT
Organization: Utah State University

In article <ld0gv1INNfh9@news.bbn.com>, fwebb@star-trek.bbn.com (Fred Webb) writes:
> 
> The DecSystem 20 had 36 bits becuase the DecSystem 10 had 36 bits.  The
> DecSystem 10 (originally the PDP-10) had 36 bits becuase the PDP-6 did. The
> PDP-6 probably had 36 bits because the PDP-1 had 18 bits (36 = 2*18).
> 
I think the PDP-6 had 36 bits because the PDP-3 had 36 bits. The PDP-3 was
a 36-bit version of the 18-bit PDP-1 (actually, the reference that I have
lists the PDP-1 as being an 18-bit version of the 36-bit PDP-3...).

Roger Ivie
ivie@cc.usu.edu
From: ldr@merrymeeting.mv.com (Lee D. Rothstein)
Newsgroups: comp.arch
Subject: Which is the Best RISC Arcitecture ?
Distribution: world
Date: Tue, 29 Sep 92 09:44:42 GMT
Organization: VeriTech; IEEE Computer Society, NH
Reply-To: ldr@merrymeeting.mv.com

Sequoia is building a fault tolerant system with PA-RISC architecture
processors--or at least they said they were.

HP is working with Novell to port native NetWare (server OS) to PA RISC.

  /-----------------------------------------------------------\
 /Lee D. Rothstein                                 603-424-2900\
/ VeriTech: IT Verification & Leadership      Fax: 603-424-8549 \
\ 7 Merrymeeting Drive           Email: ldr@merrymeeting.mv.com /
 \Merrimack, NH 03054-2934            IEEE Computer Society, NH/
  \-----------------------------------------------------------/
Xref: sparky comp.arch:9860 comp.lang.misc:3223