HDTenEightyP/NetNews huggingface dataset:
From: peter@ferranti.com (peter da silva)
Subject: Re: why no register + register addressing mode in R3000
Organization: Xenix Support, FICC
Date: Tue, 10 Nov 1992 17:26:36 GMT

In article <endecotp.721329802@cs.man.ac.uk> endecotp@cs.man.ac.uk (PB Endecott (PhD SFurber)) writes:
> 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?

Why not, if it gives you more performance? It's simple enough to get the
compiler to deal with it, so most programmers would never see it.

> Another feature that some processors have and others don't is
> auto-indexing.

I take it this is another name for autoincrement/autodecrement, or is
it something I don't know about?

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

This would be less useful, since most of the time autoin*ing is used for
reading a data stream, but sure... why not? It'd make memory-memory block
moves faster, and they'e very common. Probably improve your dhrystone
rating, too. :->

Another question is, is there any *other* use for the extra read/write
ports? Could they be used elsewhere?
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Newsgroups: comp.arch
From: iversen@dsfys1.fi.uib.no (Per Steinar Iversen)
Subject: Re: IDE faster than Mips SCSI disk
Reply-To: iversen@vsfys1.fi.uib.no
Organization: Department of Physics, University of Bergen, Norway
Date: Mon, 9 Nov 92 11:16:01 GMT


In article <k2.721304278@woodstock>, k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:

>tgcpwd@rw9.urc.tue.nl (Wim van Dorst) writes:
>
>>Klaus Steinberger writes:
>>>	1520363 bytes/second for writing the file
>>>	1736771 bytes/second for reading the file
>
>>Others have written results for ordinary 386s with plain IDE disk
>>in the range of 200-500 kB/s. I tried it at my home PC and I got
>>similar results. 
>
>>However, I always thought that those VAX/VMS machines at work were
>>awfully slow. So I tried iozone there too. It compiled without a
>>glitch, and gave results in various machines (workstations up to
>>large VAX-6410s) with various disks (RA type, RF type, other) 
>>results in the range 15-40 kB/s. 
>
>>What does this mean: Are the disks really that slow? Is the VMS
>>version of iozone different? Is the OS that significant?
>I did the same test with same results, and I suspect its due to
>a very bad implementation off the read/write call emulation in VAXCRTL .
>
>I did have VMS Posix running on my VAX, and it gives indeed better
>results. I'm seeing results in the 200 - 300 kBytes/sec range.
>(A little MVIII, with SMD disks, platter rate around 2Mb/sec).
>I did not know how well the Posix environment did emulate Unix
>system calls, so I think native VMS programs with their ugly $QIO
>interface will see better rates.
>

I too have tried IOZONE with/without POSIX 1.0. In general the Posix environment
is 3-6 times faster then under VMS. Most likely the problem is in VAXC, I can
read/write files with VAX FORTRAN, under ordinary VMS, at rates close to that 
found when the disks are mounted on Unix boxes - without any "ugly $QIO"s 
at all.

-psi

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     iversen@vsfys1.fi.uib.no              !
! Fysisk Institutt       ! BITnet:       iversen@cernvm.bitnet                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       +47 5212770                            !
! N-5007 Bergen          ! Fax:         +47 5318334                            !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 12 Nov 92 00:51:54 GMT
Organization: Auspex Systems, Santa Clara

>So, we now have non-simulated non-prototype-system numbers for the
>DEC 21064 chip and the HP 7100 chip.  The result is that the HP at 99
>MHz has about the SPECs of a 21064 at 160 MHz. 

Hmm.  As I remember, somebody from DEC at a session on topics such as
OSF/1-on-MIPS on Tuesday night at the San Antonio USENIX claimed that
HP-PA was "out of gas"; anybody know what his response to the above
figures are?
From: adrianc@sunfen.uk.sun.com (Adrian Cockcroft - Sun UK - Cambridge SE - SPARC Specialist)
Newsgroups: comp.arch
Subject: Full SBus card list
Date: 12 Nov 1992 13:45:14 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: adrianc@sunfen.uk.sun.com
NNTP-Posting-Host: sunfen.uk.sun.com

After my recent posting I had many requests for the full list. I have posted it
to comp.sys.sun.hardware since it is over 100K and that seems like the most
appropriate place to put it. There are 340 products and services listed.

Regards Adrian

---
Adrian Cockcroft -  adrian.cockcroft@uk.sun.com or adrian.cockcroft@sun.co.uk
Sun Microsystems, 306 Science Park, Milton Road, Cambridge CB4 4WG, UK
Phone +44 223 420421 - Fax +44 223 420257	Sun Mailstop: ECBG01

Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Fri, 13 Nov 1992 20:40:50 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

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

Because it runs OpenVMS, and is price/performance competitive against
traditional VAX systems?

-- 

Rick Kelly	rmk@rmkhome.UUCP	unixland!rmkhome!rmk	rmk@frog.UUCP
From: kc@dcs.ed.ac.uk (Kenneth Cameron)
Newsgroups: comp.arch
Subject: Re: What's wrong with stack machines?
Date: 6 Nov 92 16:11:02 GMT
Reply-To: kc@dcs.ed.ac.uk (Kenneth Cameron)
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

In article <1992Nov5.144403.6359@sei.cmu.edu>  (Robert Firth) writes:
>very strong argument against building one?  If you disagree, then I have
>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.

Oh, you mean something like a train :-)
--
Kenneth@Edinburgh.ac.uk                                         kc@dcs.ed.ac.uk
4th Year Honours Student, Dept of Computer Science, The University of Edinburgh
Project: Acceleration of Constructive Solid Geometry Using a Custom VLSI Device
Newsgroups: comp.arch
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
From: don@zl2tnm.gen.nz (Don Stokes)
Date: 8 Nov 92 10:54:34 GMT
Distribution: world
Organization: The Wolery

torek@horse.ee.lbl.gov (Chris Torek) writes:
> Signed integers are not an absolute must, but precision greater than
> one penny is; most businesses seem to keep records to five digits or so.

Figures are only _published_ to five digits or so.  Bookkeeping must be
to the last cent, and auditors get upset if systems don't balance.  I've
seen programmers work their guts out to persuade things to balance to the
last few cents, usually because of floating point arithmetic on dollar 
(rather than cent) values....

Think about it: keeping only five digits of a billion dollar bottom line
could hide some pretty major fraud....  

I stuck to signed integers (a) for generality, and (b) because the places
where business bignums turn up are in things like balances and profit
figures, which can (unfortunately) be negative.

> >Machines that can handle 64 bit integers cleanly will make this problem
> >largely go away.  8-)
> 
> Hm, my kitchen arithmetic says that 2^64 only represents 1844 trillion
> dollars in mills.  At its current growth rate, the U.S. national debt
> will exceed this well within the next century.  Of course, by then the
> nation itself will be completely bankrupt, so this will not matter. :-)

My bc says that it's more like $184,647 trillion dollars.  That makes the US
national debt a potential problem if you calculate it in Bolivian pesos. 8-)

> Current 32-bit microprocessors are capable of handling 64-bit quantities
> moderately well.  Current versions of GCC support them directly.  64-bit
> integer arithmetic is well on its way to becoming established practise.

And about time too. 

--
Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand              +64-4-495-5052
From: plaw@girtab.usc.edu (Patrick Law)
Newsgroups: comp.arch
Subject: request of Cray information
Date: 12 Nov 1992 18:02:00 -0800
Organization: University of Southern California, Los Angeles, CA
Distribution: world
NNTP-Posting-Host: girtab.usc.edu



I am working on a simulator about Cray. However, I could only get
very limited literatures. Could anybody out there give me some
pointers about hardware description and implementation of Cray?
Thanks.

Patrick
From: jesup@cbmvax.commodore.com (Randell Jesup)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 8 Nov 92 00:51:57 GMT
Reply-To: jesup@cbmvax.commodore.com (Randell Jesup)
Organization: Commodore, West Chester, PA

mo@bellcore.com writes:
>"Stacks always go in memory, and you always go to the stack."

>What I have not seen in the literature (which doesn't mean it doesn't
>exist, just that i haven't seen it) is a comparison of a stack machine
>design with the equivalent complexity budget of modern RISC machines
>to such modern processors.  By complexity budget I mean one that spends
>as much logic on cache and memory system complexity as the fast RISC
>machines do.   (including the related trickle-down complexity like
>dealing with out-of-order completion in the pipe, if required)

	Actually, I would also count the register file (which, combined with
the data cache, is the equivalent of the stack cache/data cache of a stack-
based machine - and register files often eat up a lot of space and complexity
on classical RISCs).

	It would be interesting to see if there are any good solutions; not
many people have looked into it very seriously recently.

-- 
To be or not to be = 0xff
-
Randell Jesup, Jack-of-quite-a-few-trades, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Disclaimer: Nothing I say is anything other than my personal opinion.
Xref: sparky comp.arch:10425 comp.lang.misc:3503
From: ferris@turtle.fisher.com
Newsgroups: comp.arch,comp.lang.misc
Subject: <None>
Date: 6 Nov 92 11:16:15 CDT
Organization: Fisher Controls International, Austin, TX

Since this discussion is posted in comp.architecture shouldn't we be
discussing the possibility of a goto-less object code?

I believe that it is possible at the micro-code level but not at the
machine level. However, I can envision something like:

SET FLAG TO VALUE
INTerrupt
...
...
:INTerrupt address
DO CASE
   CASE FLAG 1
        PROCESS
   CASE FLAG 2
        PROCESS
   CASE FLAG N
...

The INTerrupt command could be used to cause case-type processing
based on a flag setting.

Now, can anyone suggest a reason for implementing a goto-less processor?
Isn't the reason for goto-less code to eliminate the programmer's
tendency to create indecipherable code? Why would anyone in their
right mind implement a goto-less CPU?

Jeff



Newsgroups: comp.arch
From: shyamal@seas.smu.edu (Shyamal Prasad)
Subject: Re: MINIMUM instruction set
Organization: SMU School Of Engineering and Applied Science
Date: Wed, 11 Nov 1992 18:06:49 GMT

In article <1992Nov10.235849.19192@fcom.cc.utah.edu> val@news.ccutah.edu (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?
>

Pardon the theoretical slant - but a Turning machine is *the* RISC, is
it not? That would be much less than seven instructions (I do not 
remember exactly how the turning machine instructions work :-), and
each could go really *fast*.....

Programming would be a bit (!) if a nightmare though, but I wonder if
it would be more difficult than a move machine or something. I am 
however saying this from memory and off the cuff so I may be all
wrong.
-- 
Shyamal Prasad, Department of Computer Science
Southern Methodist University, Dallas TX 72275
Newsgroups: comp.arch,comp.lang.misc
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 5 Nov 1992 20:24:12 GMT

In article <1992Oct29.153514.22927@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
:
:I write programs for correctness and maintainability first, THEN worry
:about little details such as performance. If you create something that's
 
You've probably never done any large scale computing.

I measure the run time of my algorithms in MIPS-YEARS.  A MIPS-YEAR
is a 1 MIPS machine running for 1 year, or approximately 3.1 x 10^13
instructions.  Jobs that take several hundred MIPS-YEARS are not uncommon.

Needless to say, there are people who have to worry about speed FIRST,
and that other considerations are (almost) irrelevent.

I wish you people would stop insulting Herman simply because his requirements
leads to code that is different from your petty and self-righteous 
pre-conceived notions about coding style.

:wrong, or that has to be scrapped in a year because nobody can understand
:it, who cares how fast it runs?
 
Not everyone writes commercial code, or code for customers. Maybe it's
a research project that will end in a year. Stop being so provincial.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
Newsgroups: comp.arch
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: What's wrong with stack machines?
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Fri, 6 Nov 1992 09:46:39 GMT

In article <1dckvsINN7mb@uniwa.uwa.edu.au>, john@gu.uwa.edu.au (John West) writes:
|> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
|> >Surely typical stack-language programs can be mechanically
|> >transformed (recompiled) into non-stack forms.
|> 
|> And typical non-stack-languages can be transformed into stack forms. So?
|> You lose a lot of efficiency going both ways. There is no way a conventional
|> processor is going to run converted stack code as well as a stack machine.

But there is:

@InProceedings{ertl92,
  author = 	"M. Anton Ertl",
  title = 	"A New Approach to Forth Native Code Generation",
  crossref =	"euroforth92",
  pages = 	"73--78",
  abstract =    "RAFTS is a framework for applying state of the art
		 compiler technology to the compilation of Forth.  The
		 heart of RAFTS is a simple method for transforming
		 Forth programs into data flow graphs and static
		 single assignment form. Standard code generation and
		 optimization techniques can be applied to programs in
		 these forms. Specifically, RAFTS uses interprocedural
		 register allocation to eliminate nearly all stack
		 accesses. It also removes nearly all stack pointer
		 updates. Inlining and tail call optimization reduce
		 the call overhead. RAFTS compiles all of Forth,
		 including difficult cases like unknown stack heights,
		 {\tt PICK}, {\tt ROLL} and {\tt EXECUTE}. And last,
		 but not least, RAFTS is designed for interactive
		 Forth systems; it is not restricted to batch
		 compilers"
}

@Proceedings{euroforth92,
  key = 	"EuroForth '92",
  booktitle = 	"EuroForth '92",
  year = 	"1992",
  organization = 	"MicroProcessor Engineering",
  address = 	"Southampton, England"
}

The EuroForth Proceedings will also appear in the Proceedings of the
Asilomar FORML conference.

Looking at the work done on Scheme, Prolog, Smalltalk and especially
SELF, I am convinced that there's hardly any programming language that
cannot be compiled into efficient code for RISC machines, if you give
us (the compiler guys) a few years. This is probably true for other
architectural classes, too. E.g., stack machines.

|> Likewise, a stack machine is going to have a tough time on the converted
|> non-stack code.

Phil Koopman has done some work on this. See his posting.

|> The problem is that there hasn't been enough work done on stack languages.

Or on stack machines.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Newsgroups: comp.arch
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: ************* Architecture Project HELP ************
Date: Wed, 11 Nov 1992 22:44:45 GMT
Organization: University of Iowa, Iowa City, IA, USA

In article <1992Nov9.195547.10130@cc.umontreal.ca>
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.
> Does anyone have any suggestions as to which topic I should choose?

Explain what happened to capability based architectures -- see, for example,
Levy's "Capability Based Computer Systems", Digital, 1984.  It was a great
idea, with strong coupling to what we now call object oriented systems,
yet hardly anyone cares about such systems today.

To add insult to injury, it's worth noting that the Intel 80x86, where x>1,
is a fairly general capability based hardware architecture, but no operating
system for this family that I know of takes significant advantage of this.

					Doug Jones
					jones@cs.uiowa.edu
Newsgroups: comp.arch
From: djakman@fwi.uva.nl (Kemal  Djakman)
Subject: Mainframe >> PC, why?
Organization: FWI, University of Amsterdam
Date: Sat, 7 Nov 1992 01:56:49 GMT

Hi all,
 
Lately I've been seeing that the PC is getting more and more powerful.  We
have seen 66Mhz 80486 with the 'Pentium' coming up.  Large RAM (upto 64Mb).
Bigger (upto 1.2 Gb) and faster (downto 14ms) hard disk.  Caching disk
controller with up to 64Mb, 10Mb transfer rate.  EISA bus / local bus.
Fast display adapter with graphic coprocessor. etc. etc.
 
I'm sure that the technology used in mainframes does not stand still and
they are also much more powerfull than their predecessors.  And I think
they still deliver much more power than the best the PC has to offer.
 
But, my question is, what makes the (current) difference in power for the
mainframes against the PCs?  Does their harddisk spin faster? or just
the data transfer rate is much higher?  Or the bus can handle much more
traffic (wider bandwidth)?  Or because they often have more than one CPU?
Or higher Mhz?  Or their RAM is under 20ns?  Or any architecture difference
I'm not aware of?
 
I'm curious about all this and would appreciate if anybody can enlighten me
on this.
 
---kemal---

Xref: sparky comp.arch:10457 comp.lang.misc:3524
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Hardware Support for Numeric Algorithms
Date: 6 Nov 92 12:31:52 GMT
Followup-To: comp.arch
Organization: Tokyo Institute of Technology

In article <1992Nov4.183718.5242@newshost.lanl.gov> jlg@cochiti.lanl.gov (J. Giles) writes:
>In article <Bx78zu.395@rice.edu>, preston@dawn.cs.rice.edu (Preston Briggs) writes:
>|> [...]
>|> Using C as an assembler is doable, in that you can express (almost)
>|> every optimization in the source code.  The result is machine dependent,
>|> ugly, unmaintainable, and I don't recommend it to anyone, but doesn't
>|> really require any additional optimization -- very similar to assembly
>|> language programming.
>
>This is not quite true.

Wrong.

>The rationale document for ANSI C explicitly
>recognizes the optimization penalty inherent in pointers and suggests
>that remedies to this be a priority in future versions of the standard.
>Yes, if avoid procedure calls (at least, all those whose arguments
>are pointers), 

Automatic optimization by compilers have little to do with the above
mentioned *HAND* optimization.

You can transform the following program

	f(a,b,c)
	double *a,*b,*c;

	for(i=0;i<4*N;i++)
	{	a[i]+=b[i]*c[i];
		...

to

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

by hand, knowing that the area for a, b and c does not overlap.

> do your own common expression elimination, do your
>own strength reduction, etc. - if you do all those things and many
>more, the optimization penalty from using C *almost* goes away.

Actually, as some (or, these days, large) amount of optimization is
performed by compilers, and as many machines share similar machine
dependent behaviour, the C version is not so machine dependent, ugly
nor unmaintainable.

>It's easier to use assembly directly.

Thus, it is easier to use C.

						Masataka Ohta
From: mhopper@emperor.gatech.edu (Michael A. Hopper)
Newsgroups: comp.arch
Subject: Re: some details on Pentium.
Keywords: RISC Pentium (tm)
Date: 9 Nov 92 04:22:43 GMT
Organization: Computer Engineering Research Lab, Georgia Tech.

In article <9322@blue.cis.pitt.edu.UUCP> mchst12@pitt.edu writes:
>There was some recent discussion of how Pentium works.  As it happens, Intel
>

...stuff deleted

>and a couple of read-modify-write thingies.  That's right: x86 is mostly
>load/store.  Of course, it's got variable-length instruction coding, two
>different layers of memory protection, and too, too few registers, so noone 
>is ever going to call it a RISC.
>
>To restate: Pentium is organized like a modern RISC, but with a microscopic
>register set, variable-length instructions and a little 'stunt-box' on the
>middle-right to compose complex operations.
>
>regards, Mark

As I understand it, the x86 is NOT ANYWHERE NEAR a load/store architecture.
Load/store means that the data is loaded from memory into a register before
being used in any ALU operations.  The x86 allows all sorts of memory 
referencing for most (all?) of its ALU operations.  Examples:
	
		inc [BX]	; increment data in memory pointed to by BX.
		add AX [BX]	; register indirect addressing in ADD op.

Just wanted to clear this up.

-Mike


-- 
| mhopper@cerl.gatech.edu |   ' ) ) ) o  /_       ' )  /                
| Office: CRB 388         |    / / / /  /\_) __    /__/______   _   __  __
| Phone: (404) 894-9111   |   / / (_/\_/  \_/_/_  /  / (_) /_)_/_)_/_/_/ (_
| Home:  (404) 723-1718   |                               /   /