HDTenEightyP/NetNews huggingface dataset:
From: bds@mbunix.mitre.org (Smith)
Subject: Re: More Alpha AXP Performance Numbers
Organization: The MITRE Corporation, Bedford, MA
Date: Fri, 13 Nov 1992 17:30:19 GMT

In article <1992Nov13.140907.2304@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>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 


[data deleted]

>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


It has always been DEC's position that small systems like workstations
should be limited in ways that the larger systems are not.  For
example, if you need 10 or 12 Ethernet ports, you can't get them in a
small system.  Thus the (current) VAXstation 4000/90 only allows 2
Ethernet ports (using the Turbochannel port) while the VAX 7000/610,
with the same 32VUP processor, allows 16 Ethernet ports.  Similarly,
if you need sophisticated disk access, eg, DSSI, you can only get it
on the larger machine while the smaller one uses SCSI.  Unfortunately,
the choice of a machine in a large system is not as simple as looking
at performance numbers/processor.

Barry Smith

Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: What's wrong with stack machines?
Organization: Pix Technologies -- The company with no adult supervision
Date: Fri, 6 Nov 1992 18:36:45 GMT

In article <1992Nov5.144403.6359@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) writes:
>In article <17035@mindlink.bc.ca> Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
>>You have to consider stack machines according to their own strengths, not how
>>well or not well they handle non-stack language programming techniques.
>
>Maybe I'm misinterpreting, but what this sounds like to me is "Don't
>evaluate stack machines by how well they perform running real code in
>existing languages.  Look at how well they execute unreal code in
>nonexistent languages."

Well, since there are stack languages, and code written in them, this isn't
a very good argument.  (example language: FORTH)

>After all, if a stack machine performs badly on almost all existing code,
>and almost all future code written in existing languages, isn't that a
>very strong argument against building one?  If you disagree, then I have

Not if it runs code written for it well enough that for a substantal number
of applications (mesured in CPUs used, not number of problems) they are
as good as, or better then non-stack computers.  (example application:
I don't know, mabie fuel injection systems, but I think motorola
has the market there...)

>this automobile to sell you.  It's got half the fuel consumption of a
>conventional automobile, provided you only drive it on specially built
>roads.

Which I might buy, if the roads when places I wanted to go.
-- 
           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
From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: Mixing Greek/Latin in product naming (was: Re:<None>)
Reply-To: vhs@rhein-main.de
Date: Tue, 10 Nov 92 20:56:02 GMT

In article <1992Nov9.184247.2626@lsl.co.uk> snail@lsl.co.uk writes:
> In article <1cok6sINN25m@iraul1.ira.uka.de>, S_JUFFA@iravcl.ira.uka.de (|S|  
Norbert Juffa) writes:
> > or automobile (auto being Greek, mobil- being Latin, in pure Latin it would  
be
> > a ipsemobile or some such)? I am sure there are more good exaxples, but I  
know 
> > too little Greek/Latin to come up with them right away.
> 
> In England, I think we'd call it a motor car. Which two languages is that
> descended from? :-)

It's both latin (no :-). Motor is derived from "movere" (to move), car
stems from latin "carrus", which is originally Celtic meaning "vehicle".

But where does "computer architecture" come from ;-)

--
Volker Herminghaus-Shirai (vhs@rhein-main.de)

Computer industry: Industry in which the number of units sold of any
given product is inversely proportional to its technical excellence.
See also: MS-DOS, Windows, IBM-PC, X, QWERTY,
          80x86, TrueType, Survival of the shittest.
Newsgroups: comp.arch,comp.lang.misc
From: mad@math.keio.ac.jp (MAEDA Atusi)
Subject: Re: IDE faster than Mips SCSI disk
Reply-To: mad@math.keio.ac.jp
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
Date: Sat, 7 Nov 1992 13:08:26 GMT

In article <1992Nov6.033942.21194@ntuix.ntu.ac.sg> eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) writes:

 >	  IDE is just a simple interface definition, just like SCSI-2, but IDE,
 >is optimised for HARD DISKS, SCSI is not. SCSI is more general purpose.

You may be right.  But unfortunately, bare speed of hard disk drives
around is not so fast (typically < 2MB/sec) that can fill up the
bandwidth.  And, as Dan Hildebrand mentioned (in article
<7j+q=2d@quantum.on.ca>), SCSI can do multiple transfer at the same
time, as well as let CPU free from data transfer job and keep
computing.  You can't even perform seek on another IDE drive during
IDE data transfer.  It can make a difference under multi-tasking OS.

 >This PC machine runs on 386bsd. Using 1 megabyte test file it is faster than
 >a similar 486/50Mhz EISA SCSI-2 hard-disk.
 >
 >486/33 Maxtor 7120 200Mbyte
[deleted]
 >IOZONE performance measurements:
 >	  367586 bytes/second for writing the file
 >	  499942 bytes/second for reading the file

The PC result looks reasonable.  But mips result seem to be too slow
for SCSI-2 disks.  Maybe because (as Phillip Fayers written in
<13481.9211061131@thor.cf.ac.uk>) poor I/O performance of Ultrix.  But
I think larger buffer size (e.g. 8192 bytes) would be better for
testing disk drive/interface performance, while smaller buffer size
test can measure total I/O performance including OS/library overhead.

On SparcStation1+ with SCSI drive, running SunOS 4.1.1, I get:

32M file, 512bytes buffer:
IOZONE performance measurements:
	204348 bytes/second for writing the file
	556120 bytes/second for reading the file

32M file, 8192bytes buffer:
IOZONE performance measurements:
	653760 bytes/second for writing the file
	1207012 bytes/second for reading the file

Hmm... SunOs, too, seems to have significant overhead with small buffers.
Is this figure mean ISA machine running 386bsd beats SparcStation1+ in I/O?
PCs are widely believed to be "comparable to WS in CPU speed, but far
more slower in I/O".

I'm very interested in the result of EISA SCSI-2 with large file size
& large buffer size, if it's available.

;;;  Keio University
;;;    Faculty of Science and Technology
;;;      Department of Math
;;;		MAEDA Atusi (In Japan we write our family names first.)
;;;		mad@math.keio.ac.jp
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Subject: Re: Registerless processor
Organization: Purdue University Statistics Department
Date: Fri, 13 Nov 1992 19:48:57 GMT

In article <1992Nov13.181654.11692@fcom.cc.utah.edu> drdavis@u.cc.utah.edu (Darren R. Davis) writes:
>I have been pondering an idea for a machine architecture.  A processor
>that has no registers. 

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


>The one processor I know of is the TI9900 I believe, but it does not
>have all the cache stuff.

That machine had three registers in the original sense of register, not
fast memory, the program counter, the condition code register, and the
register pointer.  The register pointer held the address of the 16 word
block which served as registers currently.

The early von Neumann machines had 3 registers, and some others had only
the essential one, the program counter.  The others in the von Neumann
machines were the accumulator, where addition/subtraction was actually
done, and the MQ register, where multipliers were put and quotients 
formed.  These were one-address machines; on three-address machines
of the time, these were generally not present, and those would correspond
to what you are seeking.  There were a fair number of such machines; I
seem to recall an NCR machine in the 1950's.  
-- 
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)
Xref: sparky comp.arch:10665 comp.lang.forth:3484
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.arch,comp.lang.forth
Subject: Re: What's RIGHT with stack machines
Date: 12 Nov 1992 19:33:38 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: rbbb

In article <id.Z9WU.QA1@ferranti.com> peter@ferranti.com (peter da silva) writes:
>Of course, superscalar RISC machines with lots of pipelines are really terrible
>at handling byte-code interpreters (lots of non-predictable branches) and run-
>time code generation (OK, now we blow away the pipeline...). Oh, and the
>infamous autoincrement deferred addressing mode becomes a major win...

It ain't necessarily so.  You can use speculative or non-faulting
loads and multiple condition codes to pipeline the interpreter itself.
This is not a panacea, but it's not a catastrophe.  Not all RISCs have
these (yet).

It's also not clear to me that the stack machine will come with a
simpler pipeline.  Branches will probably be just as bad there, and
your autoincrement deferred addressing mode looks like a big consumer
of register file ports.  Superscalar group or messy addressing modes,
it's all the same in terms of hardware resources.

David Chase
Sun
From: jcooley@miracle.com (John Cooley)
Newsgroups: comp.arch
Subject: Re: ************* Architecture Project HELP ************
Date: 10 Nov 92 21:05:16 GMT
Organization: Miracle Computer Consultants

cholette@JSP.UMontreal.CA (Cholette Martin) writes:

> I have a class in computer architecture, and I have to make an oral
> and written presentation for my class project. I can choose whatever
> subject I want ( subject to approval of course ) that is related to
> comp. architecture. My oral presentation must be between 30 - 50 minutes,
> and the written report must be 10-20 pages. I am a 3rd year comp. sci.
> student. 
>
> Does anyone have any suggestions as to which topic I should choose?
> I am looking for something recent and hopefully " cool and interesting "
> I would prefer to do it on a topic that is relatively unknown, hence
> my difficulty in finding a subject. I would appreciate any insight!

 Martin,

    If you want to present something to the class that's somewhat
 unusual for your average college course on computer architecture
 plus get an idea of where the industry is going today, you may
 want to do a report on "How the Present Level of Synthisis Software
 Impacts Modern Computer Design".

    Not only will this be an eye opener for most of your classmates,
 you'll also get a leg up on them by delving into real world issues
 that knowlege of becomes useful come interview time.

                                                 - John Cooley
                                                   ESNUG Moderator



 ===========================================================================
 Trapped trying to figure out a Synopsys bug?  Want to hear how others dealt
 with it ?  Join the E-Mail Synopsys Users Group!  To join, E-mail me today! 
 ===========================================================================
      !!!     "It's not a BUG,    | Preferred Address: jcooley@world.std.com
     /o o\  /  it's a FEATURE!"   |    Backup Address: jcooley@miracle.com
    (  >  )                       |              (508) 429-4357
     \ - /       | Snail Mail: P.O.Box 6222, Holliston, MA, 01746-6222, USA
     _] [_       |        "This here ain't no one's opinion 'cept my own."
Newsgroups: comp.arch
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: Re: What's RIGHT with stack machines
Organization: MIND LINK! - British Columbia, Canada
Date: Fri, 13 Nov 1992 08:08:09 GMT

chased@rbbb.Eng.Sun.COM (David Chase) writes:

> It's also not clear to me that the stack machine will come with a simpler
> pipeline.  Branches will probably be just as bad there, ...

There's some research being done into stack processors with no conditional
branch instructions.  Instead, there will be conditional calls (and maybe
conditional returns?).  These operations can be fast (one or zero clock
cycles?) on a stack machine.

I'm not sure if replacing branches with calls would reduce the problem of
conditional anything, as far as pipelining is concerned, but I suppose it has
possibilities.

--

Nick_Janow@mindlink.bc.ca
From: tomw@orac.asd.sgi.com (Tom Weinstein)
Newsgroups: comp.arch
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
Date: 13 Nov 92 02:50:25
Organization: Silicon Graphics Inc.
	<1992Nov11.144304.10494@news.uiowa.edu>
	<1992Nov12.164510.28248@dartvax.dartmouth.edu>
	<1992Nov12.220301.23915@fcom.cc.utah.edu>
Reply-To: tomw@asd.sgi.com
NNTP-Posting-Host: orac.asd.sgi.com
In-reply-to: caperkin@ursa11.law.utah.edu's message of Thu, 12 Nov 92 22:03:01 GMT

In article <1992Nov12.220301.23915@fcom.cc.utah.edu>, caperkin@ursa11.law.utah.edu (Charles Perkins) writes:

> Assuming good density, how many of the above could we put on a chip
> using today's processes (We can make 16 Megabit dram chips... but dram is
> very regular.)

> How many transistors would it take to make a minimally sized 32-bit chip?
> Optimized for transistor count, not cycle speed, op-code simplicity, or
> speed of design.

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

Why bother?  Why not just make a programmable systolic array processor?
There's been very little cool stuff done with them in recent years, and
it seems to me that with the right kind of control logic, you could get
some rather serious performance.

--
Love is a conveyor belt of   |   Tom Weinstein  tomw@orac.esd.sgi.com
warmth  -- Jackie Chan       |                  tomw@bears.ucsb.edu
Newsgroups: comp.arch
From: cliffc@rice.edu (Cliff Click)
Subject: Re: RTX and SC32
Organization: Center for Research on Parallel Computations
	<CLIFFC.92Nov5101357@miranda.rice.edu>
	<KHB.92Nov5194320@chiba.Eng.Sun.COM>
Date: Fri, 6 Nov 1992 15:42:32 GMT

khb@chiba.Eng.Sun.COM (Keith Bierman fpgoup) writes:
> cliffc@rice.edu (Cliff Click) writes:
> > And now a soapbox:
> > Compiler technolgy is driven by computer archetectures.
> > If a big-name company produced a blazing stack machine and handed a few
> > out to CS departments doing compiler research, compiler researchers 
> > (like myself, hint, hint) would find the moral equivalent of the
> > "graph coloring register allocator" for stack machines.

> The A series machines from UNISYS date back to the early sixties. They
> are stack machines.  Do they have to throw more than 30 years of machines 
> out to attract CS researchers? 

How come I've never programed on one, despite 8 years of college-level
schooling?  Obviously I picked the wrong schools ;-).

> It is possible that some optimizer writers have looked at stack
> machines more than once ;>

Guilty: I looked once and it looked solvable (stack allocation for DAGs
with fast "pick n" and "put n" ops), but not necessarily PhD thesis material.

Cliff

--
Through a gentle rain / the moon throws silver shadows /
and tears fall like pearls.                    Cliff Click (cliffc@cs.rice.edu)
From: endecotp@cs.man.ac.uk (PB Endecott (PhD SFurber))
Newsgroups: comp.arch
Subject: Re: why no register + register addressing mode in R3000
Date: 9 Nov 92 17:23:22 GMT

kong@ece.ucdavis.edu (Timothy Kong) writes:

>The Mips R2/3/4000 has the register + offset addressing mode, i.e.
>"load Rx,offset(Ra)," where offset is a 16-bit constant.  Why doesn't it
>have the more flexible "load Rx,Ra,Rb," where effective address = Ra + Rb?
>Since either way effective address calculation needs an addition, the
>reg.+reg. mode shouldn't require any more hardware.  Am I missing something?
>The Sparc has the reg.+reg. mode.

>I have seen code where a "load Rx,Ra,Rb" would reduce instruction
>count, and so the argument that such an instruction is rarely used
>wouldn't make sense.

>Timothy Kong
>kong@eecs.ucdavis.edu


Although it's true that both register+offset and register+register modes
require an addition, you haven't allowed for the fact that an extra
register read has to take place.  Normally most microprocessors have two
read ports and one write port on the register file, which is exactly what
is required for three address arithmetic/logical operations.  When you
execute a store instruction, one read port is used for the data value, and
the other for the address register.

If you want to implement register+register addressing, you have two main
choices :

- Add a third read port.  This increases the size of your register file by
about 25%-ish, plus another set of decoders.  The question you must ask is,
would that extra silicon be better used for increasing the cache size, or
just keeping the die cost down ?

- Insert an extra cycle and read the registers in two goes.  Ignoring the
effect of cache misses etc. this takes the same number of cycles as doing
an explicit add in a separate instruction - provided you have enough
registers.

Of course for a load, you do have two read ports available.  Would anyone
consider an architecture with non-symetrical addressing modes, where loads
can do register+constant or register+register, but stores can do
register+constant only?

Another feature that some processors have and others don't is
auto-indexing.  During loads, this requires an extra write port (or an
extra cycle) to put the modified value back in the register; but during
stores the write port is not used for data.  So how about an architecture
with autoindexing for stores but not for loads ?

-- Phil.
From: desj@ccr-p.ida.org (David desJardins)
Newsgroups: comp.arch
Subject: Re: Hardware Support for Numeric Algorithms
Date: 7 Nov 92 06:59:09 GMT
Followup-To: comp.programming
Organization: IDA Center for Communications Research, Princeton

J. Giles <jlg@cochiti.lanl.gov> writes:
>>> 	for(i=0;i<N;i+=4)
>>> 	{	b0=b[i]; b1=b[i+1]; b2=b[i+2]; b3=b[i+3];
>>> 		c0=c[i]; c1=c[i+1]; c2=c[i+2]; c3=c[i+3];
>>> 		a0=a[i]; a1=a[i+1]; a2=a[i+2]; a3=a[i+3];
>>> 		a[i]=a0+b0*c0; ...

> And the code still does not parallelize.  Why?  An ANSI C
> implementation must *infer* which things can be parallel and which
> can't because the C language doesn't have explicit vector constructs.
> There is *NO* *HAND* optimization of the above code which will remendy
> this - without using some non-standard extension for explicitly
> declaring whether the variables are aliased or not.

You should read before you reply.  The point of the above transformation
is that there is no aliasing problem, and the compiler can know without
any extensions that parallel execution is valid.  Executing the four
multiply-adds in parallel is valid regardless of any overlap between a,
b, and c.

Followups to someplace that isn't comp.arch.

                                        David desJardins
Newsgroups: comp.arch
From: berc@src.dec.com (Lance Berc)
Subject: re: Symbolics & LISP Machines
Organization: DEC Systems Research Center
Date: Fri, 6 Nov 92 00:50:00 GMT

A starting place is

	3600 Technical Summary
	Symbolics Inc.
	February 1983

You're probably interested in the processor architecture section from
pages 77 to 104.  I don't know what rock you might look under to find
a copy...

Newsgroups: comp.arch
From: rec@aim.com (Bob Cousins)
Subject: Re: Integers implementation
Organization: /usr/lib/news/organization
Date: Mon, 9 Nov 1992 17:45:28 GMT

In article <MEISSNER.92Nov6161926@tiktok.osf.org> meissner@osf.org (Michael Meissner) writes:
>In article <1992Nov6.144502.17520@osf.org> fabre@gr.osf.org (Christian
>Fabre) writes:
>
>| Most of today architecture use 2's complement scheme to represent
>| signed integers. About other possibilities, like 1's complement,
>| I have the following questions:
>
>|  - What are their drawbacks ?
>1's complement and signed magnitude have -0 which plays havoc with
>things like bit masks.  Also, in 1's comp, addition is done via a
>subtractor.
>	...
>|  - Are they likely to pop-up in future processor design ?

Actually, 2's compliment is more rightly referred to as "radix's complement"
and 1's compliment is more rightly referred to as "radix-1's compliment" since
the "tricks" of 1's and 2's complement arithmetic work with any radix. When I
used to have to teach this stuff to college kids, I would always start of
using decimal numbers (which the kids were more comfortable with).

The recipe is simple:
	given C = A - B
	desired C = A + D
	where D is trivially derived from B

Radix's Complement:
	for each digit in B, subtract it from (RADIX -1) and place it into
	the corresponding place in D.
	D = D + 1;  (Ignore this step for Radix-1's complement)
	Perform the addition and ignore the carry.

	Negative values are those which are more than half the distance through
	the values. For base 10, if the left most digit is >= 5, the result is
	negative.

Example:

               (10's complement)
	98765      98765
       -12345  ==> 87655 (subtract each digit from 9, then add 1 to the total)
       ------     ------
	86420     186420 (Ignore carry)

Note that this is a "negative number minus a positive number." The 9's complement
result is off by one due to the dual representation of 0. This is inherent in all
Radix-1 implementations.

Another example:

	4567       4567
       -4384  ==>  5616
       -----      -----
        0183      10183 (Ignore carry)

Last example: (Above modified to have negative result)

	4567       4567
       -4684  ==>  5316
       -----      -----
        -117       9883 (Ignore non-existant carry)

	Convert to positive value:

	9999 
	9883
	----  (Subtract each digit from 'radix -1')
	0116
	   1  (add 1)
	----
	0117  (The result)

Sorry to take up such bandwidth, but with the discussion of BCD and integer 
implementation on here recently, it appeared that some of the very basics
-- 
________________________________________________________________________________
Robert Cousins                    rec@aim.com                  (408)748-8649x212
Aim Technology                                        Speaking for myself alone.
From: kludge@grissom.larc.nasa.gov (Scott Dorsey)
Newsgroups: comp.arch
Subject: Re: MINIMUM instruction set
Date: 13 Nov 1992 00:10:57 GMT
Organization: NASA Langley Research Center and Reptile Farm
NNTP-Posting-Host: grissom.larc.nasa.gov

Val Kartchner writes:
> 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?

Well, it's certainly practical.  The PDP-8, for example, had a total of
seven instructions, and while it wasn't any speed demon and wasn't the
best machine to program that I can think of, it worked and plenty of them
were sold.

It's possible to build a machine with a single instruction (subtract and
skip if equal), but definitely not practical.  I believe a student at U.
Waterloo actually constructed one as a class project; it was not very
useful though it was Turing-machine equivalent.
--scott