HDTenEightyP/NetNews huggingface dataset:
From: nickh@CS.CMU.EDU (Nick Haines)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: CLU break and continue (Was: Re: A challenge to the anti-goto)
Date: 9 Nov 92 20:03:05 GMT
Article-I.D.: cs.BxGt16.Bwt.1
	<1992Nov9.114323.22688@rdg.dec.com>
	<BRADLEY.92Nov9101822@marley.think.com> <BxGID2.8n9@exnet.co.uk>
Organization: School of Computer Science, Carnegie Mellon University
Originator: nickh@VOILA.VENARI.CS.CMU.EDU

In article <BxGID2.8n9@exnet.co.uk> dhd@exnet.co.uk (Damon) writes:

   I think the New Jersey implementation of ML also only takes a few
   instructions to get to an exception handler from the raising of the
   exception.  I'm no expert on how NJML is implemented, so maybe someone
   out there could explain how ML does it...

Simple, you just keep a pointer to the current exception handler lying
around somewhere (in a register, in the nil vector, on the stack). An
alternative is to make handler frames on the stack, and have
`exception pre-handler' code that trogs up the stack looking for it.
The sensible thing to do seems to be a combination of these things.

In the case of SML/NJ, there isn't a stack, so a register holds the
current handler (which is a continuation). In SML/NJ 0.80 on the MIPS,
for instance, the register is $30.

Nick Haines nickh@cmu.edu
Newsgroups: comp.arch
From: adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: RTX and SC32
Date: Sat, 7 Nov 1992 00:29:12 GMT
	<ADAMS.92Nov5001909@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>
	<DOCONNOR.92Nov5085408@potato.sedona.intel.com>
Organization: TH-Darmstadt

In article <DOCONNOR.92Nov5085408@potato.sedona.intel.com> doconnor@sedona.intel.com (Dennis O'Connor) writes:

... and I was cited:

>   adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
>   ] The FRP1600 does a 16x16 multiply in one cycle (100ns--80ns--66ns).
>   ]
>   ] A 10MHz FRP1600 does 16x16bit multiply at least 5 times faster than
>   ] a 33MHz AMD29000. 
>

 To say the least, I was comparing CPU architectures costing about the
 same. A 16 MHz AMD29k and an evaluation board of FRP1600 were priced
 the about same, less than 100 US$.

>   The Intel i960(R) CA microprocessor does a 32x32->32 bit multiply in
>   4 or 5 cycles, depending on the data. It does the multiply in

.... Remarks about Intel 960  discarded.

 One should remember, i960 was out of discussion because of price, at
 least here in Germany at evaluation time (about 1990). 800 US $ /chip
 were too much, cost for development systems not included.....

>   And remember, it takes 4 16x16 multiplies and 3 32-bit adds
>   ( minimum ) to do a 32x32 bit multiply. How long does that
>   take on the FRP1600 ?

 They had well known requirements, multiplying 12-14 bit operands with
 12-14 bit coeffizients. 32 bit multiplications were not necessary.
 Summing up 3 products, 16 bit were sufficient.

>   Some older RISC architectures didn't implement fast multiply
>   at first but added it in later products. There's no causal
>   relationship between architectural class ( RISC, CISC, Stack, VLIW )
>   and multiply speed.

 No, but silicon already gone for cache is not available for
 multipliers ;-<.

>   ] This example was not dedicated to any particular advantage of stack
>   ] machines, but to an area RISC chips did tend to loose.
>
>   The i960 CA RISC (mainly) microprocessor has been around for years.
>   You didn't compare to the right RISC chip.

PRICE in Germany. To say it frankly, i960 and development system were not
affordable.

>   ] For realtime and controller applications, FORTH chips and stack machines
>   ] may blow RISCs out of the water, yes, they run much faster....
>
>   The i960 family has delivered over 1 million units into embedded
>   and control applications. In typical Intel fashion, I tend to
>   measure an arhcitectures success by the revenue it generates ...
>   after all, the silicon itself is only one peice of the solution.

An i960 was neither required nor economical feasible. The guys implementing
it took the fastest and cheapest path. They started in FORTH with 
Harris and went on with FRP1600.

Yet to be convinced , adams
From: adrianc@sunfen.uk.sun.com (Adrian Cockcroft - Sun UK - Cambridge SE - SPARC Specialist)
Newsgroups: comp.arch
Subject: Re: DEC ALPHA Performance Claims
Date: 12 Nov 1992 13:41:25 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: adrianc@sunfen.uk.sun.com
NNTP-Posting-Host: sunfen.uk.sun.com

In article 2@cs.cmu.edu, lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>
>sharpe@adodem.enet.dec.com writes:
>	[ A list of the MFLOPS the Alphas get, inverting dense matrices.  ]
>	[ I have extended the list to give people a feel for the context. ]
>
>>
>>System                100x100 dp      1000x1000 dp
>>
>Compaq Deskpro 486/33	      1.4
>DEC 5000/200 (25 MHz R3000)   3.7
>Cray-1			     11		       31
>>DEC 3000/400S AXP           26.4              70.8
>>DEC 10000/610 AXP           42.5             111.6
>Convex C3810 (1 proc)	     44		      113
SPARCcenter2000 (20 proc)		     ~260 **
>Cray C90     (1 proc)	    387		      874
>

** this is a SINGLE Unix process that has been through a paralellising Fortran
compiler and is running in parallel on all 20 CPU's. Uniprocessor is about 20
and the MT synchronisation and non-parallelisable parts prevent the raw 400 MFLOPS
being delivered to a 1000x1000 DPLinpack. I will try to get the full table showing
results from 2-20 CPU's scaling pretty linearly, its not at hand right now (~260
is from memory, I think its a bit higher).

SPECrate92 figures are abut 8000 integer and 10000 fp for an 8 CPU system.

There is a lot of interesting system architecture in the SPARCcenter2000,
I hope to post a summary when I get a chance. The press release stuff has been
posted to comp.sys.sun.hardware if you want to read the marketing pitch.

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
From: duck@nuustak.csir.co.za (Paul Ducklin)
Newsgroups: comp.arch
Subject: What's become of the T9000?
Date: 5 Nov 92 14:23:43 GMT
Article-I.D.: nuustak.duck.720958486
Organization: CSIR, South AFrica
NNTP-Posting-Host: nuustak.csir.co.za

>The designers of the T9000 can tell you of one way, but another way is
                      ^^^^^
This CPU was announced (well, all but "released") last April in the USA.
In South Africa, a "launch" was held in about June along the same lines
as the US thrash (ie: the same videos, similar speeches about how great 
the chip "was", and how exciting wormhole routing was going to be).

I was pretty excited myself, what with the age of the T800 starting to 
show, and so forth. Since then, I've not had much time to work in the
parallel computing field, and I've heard/seen less than zilch about inmos
in the last year. So -- wot happened?

Has T9000 silicon ever appeared? Have inmos gone under? Will we ever see
the C104?

-- 
--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--
Paul Ducklin                                       duck@nuustak.csir.co.za

  CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
Xref: sparky comp.arch:10603 comp.lang.forth:3476
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: IDE faster than SCSI-2
Organization: Nanyang Technological University - Singapore
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 5 Nov 1992 09:47:12 GMT

[ Article crossposted from comp.unix.bsd,comp.os.linux ]
[ Author was Othman Ahmad (eoahmad@ntuix.ntu.ac.sg) ]
[ Posted on Thu, 5 Nov 1992 08:07:16 GMT ]

I posted an iozone benchmark using my 386/25Mhz machine which shows that
it is slightly slower than a SCSI-2 hard-disk. Now with a 486/33, IDE is
definitely faster than a EISA SCSI-2 486/50MHZ  hard-disk.
	Iozone uses normal unix system calls for writing to disks, after all,
that is how we write C programs.
	I may try to run a more sophisticated file system tester called
bi? later on.


 JUlian's machine 
 is a 50MHz EISA 486 with a 1.3GB drive attached via a Bustek 742a SCSI2
 adapter. It has 16MB of ram. Part of the disk (about 200MB is taken up 
 by mach2.6 and is unavailable to 386bsd.

I checked the load on this machine, it is very light. There is only another
user apart from I.

iozone 1

Writing the 1 Megabyte file, 'iozone.tmp'...1.766667 seconds
Reading the file...1.983333 seconds

IOZONE performance measurements:
	593534 bytes/second for writing the file
	528694 bytes/second for reading the file

Running on 486/33 with 256Kbyte RAM cache, maxtor 200Mbyte IDE hard-disk,
8Mbyte main RAM.

	Whereas the IDE runs XFree86 and open look window manager.
I only use 1 megabyte for test file size.

  IOZONE performance measurements:
	873813 bytes/second for writing the file
	452623 bytes/second for reading the file

	Both machine uses 386bsd 0.1 heavily patched, so the timing measurements
are consistent with each other.


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Xref: sparky comp.arch:10455 comp.lang.misc:3522
From: mjl-b@minster.york.ac.uk
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: CLU break and continue (Was: Re: A challenge to the anti-goto)
Date: 6 Nov 92 12:52:14 GMT
Reply-To: mjl-b@minster.york.ac.uk (Mathew Lodge)
Organization: Department of Computer Science, University of York, England

In article <184123@pyramid.pyramid.com> moliver@pyramid.com (Mike Oliver) writes:
>In article <1992Nov3.165005.18037@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
>>It should be noted that Ada and CLU have named loops and named breaks.
>
>I can't comment on Ada, but `break' in CLU (at least the version
>described in Liskov and Guttag's 1986 "Abstraction and Specification in
>Program Development") only has the ordinary single-level behaviour,
>which lets you escape from the smallest enclosing loop.

In Ada you can escape to any level using a named loop. For example:

OUTER_LOOP: -- Named outer loop
loop
   loop
      loop
 	 -- some code
	 exit OUTER_LOOP; -- exit the outer loop
      end loop;
      -- ...
   end loop;
   -- ...
end loop;

>You're probably thinking of the `exit'/`except' mechanism, which allows
>you to escape from multiple loops (or from within a `proc', with the
>`signal' statement) by raising a condition which transfers control to
>the nearest enclosing handler for that condition.

This sounds a lot like the Ada exception mechanism. Briefly, when an
exception is raised, the run-time starts looking for a handler for that
particular exception. If there isn't one for that exception in the current
block, the call stack is wound back until one is found, or the top-level
subprogram is reached (when the program stops).

It gets to be more complicated than this, particularly if you use tasks.

>>           Named continues, to use C terminology, are an obvious corrollary,
>>but I don't believe that either Ada or CLU implements them (or even normal
>>continues, for that matter.)  
>
>CLU (again, the 1986 version) has the normal `continue', which
>terminates execution of the smallest enclosing loop and begins the next
>cycle, if one is required.

This sounds like normal use of the Ada exit statement, which exits the
enclosing loop.

>BTW, anti-goto purists will be happy to learn that CLU doesn't have a
>`goto' statement.

Ada does, but the labels are surrounded by << and >>, which makes them very
obvious during code review :-)

>Cheers, Mike.
>
>moliver@pyramid.com
>{allegra,decwrl,hplabs,munnari,sun,utai,uunet}!pyramid!moliver

Mat

| Mathew Lodge                      | "I don't care how many times they go    |
| mjl-b@minster.york.ac.uk          |  up-tiddly-up-up. They're still gits."  |
| Langwith College, Uni of York, UK |  -- Blackadder Goes Forth               |
Xref: sparky comp.arch:10543 comp.lang.misc:3550
From: alanm@cognos.com (Alan Myrvold)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: A challenge to the anti-goto (C code included!)
Date: 6 Nov 92 15:19:17 GMT
Article-I.D.: cognos.1992Nov6.151917.619
Organization: Cognos Incorporated, Ottawa CANADA

In article <1992Nov5.203759.8030@linus.mitre.org> bs@gauss.mitre.org (Robert D. Silverman) writes:
>I would suggest Mr. Myrvold, that you attend to your business and let
>Dr. Rubin attend to his.

You're probably right.

>There are times when readability, portability, and ease of maintenance are
>of primary importance. There are times when they don't matter at all. 

The code fragment posted could not be compiled, so what other purpose did
it have besides being read?
Posting code to comp.lang.misc is an invitation for it to be READ!  
It is a time when comments and whitespace are appropriate.

In some article long since expired from our system :
%% Lawrence Crowl wrote:
%% It's time for you to put up some work.  Write up a C (or Fortran, or some
%% ...
% And Herman Rubin responded
% I might be able to get a graduate student to do this on a versatile semi-
% portable "package" which I already have, not not programmed.
   
By refusing to learn the artistry of programming, Herman is spouting 
criticism from a position of ignorance.

So I understand now.  Herman is not a programmer, will never be one,
and his algorithms will probably never get out of the ivory towers, or
if they do, they will be so unportable that they  will not be able to
take advantage of new hardware performance increases, or be used by
people with hardware incompatible to his.
From: tmm@asns.tredydev.Unisys.COM (Tim McCaffrey)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 9 Nov 92 16:08:02 GMT
Organization: Unisys Corporation, Devon Engineering Offices

There is a big-name company (Unisys) building a blazing stack machine (A19).
Those CS depts. could look into getting MA825 desktop machines to do
their research with (same instruction set as the A19).  

					Tim McCaffrey
Not speaking for Unisys.
Newsgroups: comp.arch
From: morse@quark.mpr.ca (Daryl Morse)
Subject: Re: More Alpha AXP Performance Numbers
Organization: MPR Teltech Ltd., Burnaby, BC, Canada.
Date: 13 Nov 92 09:08:41


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

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

Sure, but in looking only at the performance data you're completely
missing the point of having different system configurations. Try and
tell me that a 1x150MHz workstation with 1Gbyte of memory and a 90
Mbyte/second bus will be as effective for all (read, large) problems
as a 6x200Mhz mainframe with 14Gbytes of memory and an 800
Mbyte/second bus. Add in cache sizes, redundancy, available ramdisk,
etc., and there's even less comparison.

--
Daryl Morse                     | Voice  : (604) 293-5476
MPR Teltech Ltd. 		| Fax    : (604) 293-5787
8999 Nelson Way, Burnaby, BC    | E-Mail : morse@mpr.ca
Canada, V5A 4B5                 |        : mprgate.mpr.ca!morse@uunet.uu.net
Newsgroups: comp.arch
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: MINIMUM instruction set
Date: Wed, 11 Nov 1992 20:08:17 GMT
Organization: University of Iowa, Iowa City, IA, USA

From article <4f0IQEm00WD5IXXKNc@andrew.cmu.edu>,
by "Jon C. R. Bennett" <jb7m+@andrew.cmu.edu>:
> 
> i think that perhaps a better question, and one which i think you almost
> answered is, "How many operations are needed...."
> the instructions that you present do the following
> 
> load > store > subtract > compare > branch
> 
> the only things i can think of that are missing are
> 
> shift > bit op (and,or,xor)

You don't need shift or bit-ops.  Shifts are equivalent to multiply and
divide operations.  Multiply can be done by repeated addition (which is
really repeated subtraction of negated addends), and division can be done
by repeated subtraction.

To test bit i of a word, shift the word until bit i is the sign bit.  To
do a logical and, just test all the relevant bits and construct the
appropriate result.

Of course, logical sufficiency is the only thing that concerns us, speed
doesn't matter, right?  If speed matters, then (and only then) do you bother
adding an add instruction, bit operations, shift instructions, and other
convenient stuff.
					Doug Jones
					jones@cs.uiowa.edu

Newsgroups: comp.arch
From: caperkin@ursa11.law.utah.edu (Charles Perkins)
Subject: Re: 600 transistor CPU (was: MINIMUM instruction set)
Summary: How small can we make a CPU?
Organization: University of Utah College of Law
Date: Thu, 12 Nov 92 22:03:01 GMT

The following article brings to mind an interesting question...
How small can we make a (reasonably useful) CPU?

In article <1992Nov12.164510.28248@dartvax.dartmouth.edu> stevel@coos.dartmouth.edu (Steve Ligett) writes:
>Somewhere I have a copy of an article (or two) titled
>
>"A design for a 16 bit processor using only 600 transistors"
>
>from Microelectronics Journal, Vol 15, Nr 3,
>copyright 1984 Benn Electronics Publications Ltd, London
>
>The machine has 4 instructions: three subtracts, and one bit clear.
>
>I'll try to find and reread the articles if it would be of interest.
>-- 
>steve.ligett@dartmouth.edu
>Sign in our Machine Room:  Before Leaving Please Lock Door Behind You

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.


-- 
8Chuck .2AlexanderTheGreat
perkins@ursa11.law.utah.edu
"I am not in denial."
Newsgroups: comp.arch
From: firth@sei.cmu.edu (Robert Firth)
Subject: Re: What's wrong with stack machines?
Organization: Software Engineering Institute
Date: Thu, 5 Nov 1992 14:44:03 GMT

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

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
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.
From: snail@lsl.co.uk
Newsgroups: comp.arch
Subject: Re: Mixing Greek/Latin in product naming (was: Re:<None>)
Date: 9 Nov 92 17:42:47 GMT
Organization: Laser-Scan Ltd., Cambridge

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? :-)
-- 
snail@lsl.co.uk      

You Have To Remember, You Need To Beleive,
The Time Has Past, Dust In The Leaves.
Newsgroups: comp.arch,comp.lang.misc
From: preston@miranda.cs.rice.edu (Preston Briggs)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Rice University, Houston
Date: Thu, 5 Nov 1992 17:09:34 GMT

mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin) writes:

>I don't disagree that occasionally gotos are cleaner than the
>available alternatives, but I wouldn't call Knuth an arbiter of good
>taste in programming style.  On the one hand, TeX the program is
>clearly written and contains some beautiful algorithms.  On the
>other hand, TeX the language is a wretched mess---it's almost
>impossible to write clear code in TeX.  So I'd say Knuth's record on
>programming style is very mixed.

I disagree.  It's easier to read and write programs in TeX than
in any other typesetting language around!

Isn't your complaint similar to saying

	Makita builds terrible tools because this power planer
	makes a terrible lathe.

Preston Briggs
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: Optimizing Old Code for i586
Date: 7 Nov 1992 18:11:14 GMT
Organization: Sun Microsystems, Mt. View, Ca.
NNTP-Posting-Host: flayout

In article <1992Nov6.194508.9171@tc.cornell.edu> elan@tasha.cheme.cornell.edu (Elan Feingold) writes:
>Write a program that takes a .exe file and performs the following analysis
>on it:
>	a) Break up the code into windows, bounded by branches.
>	b) Rearrange the code within the windows following the i586
>	   idea of being able to execute two instructions in a cycle if
>	   there are no dependancies.

This basic block scheduling is very limited since branches occur approximately
every 5 instructions (integer programs running on SPARC). It will buy you
some (around 10%) but much better performance can be achieved if the code
is recompiled with a compiler that can schedule instructions across basic
blocks, especially for integer programs. Key instructions to move "up"
in the code are loads, since they may have a long latency due to a cache
miss. Moving loads pass conditional branches introduces problems such
as possible additional page faults, segmentation error, etc. That's why
it is desirable to have some kind of support for speculative loads,
which brings the question:

Does the P5 have support for speculative loads?

- Marc Tremblay.
Sun Microsystems.
Xref: sparky comp.arch:10675 comp.lang.forth:3485