HDTenEightyP/NetNews huggingface dataset:
From: bbaker@beta.tricity.wsu.edu (Bill Baker)
Newsgroups: comp.arch
Subject: Call for Papers: Hardware Accelerators for VLSI Design
Date: 6 Nov 92 20:35:04 GMT
Article-I.D.: serval.1992Nov6.203504.13291
Organization: Washington State University Tri-Cities, Richland WA
Originator: bbaker@beta.tricity.wsu.edu


                          
                            Call for Papers

                            Special Issue on

                 Hardware Accelerators for VLSI Design

VLSI DESIGN: An International Journal of Custom-Chip Design, Simulation and
Testing

A special issue of the VLSI Design Journal will be devoted to Hardware 
Accelerators for VLSI Design.  Topics of interest include, but are not 
limited to, the following:

	* Accelerators for logic simulation
	* Accelerators for analog simulation
	* Mixed analog/digital simulation acceleration
	* Parallel architectures for simulation acceleration
	* Placement, routing, and design-rule-check engines
	* Parallel, distributed simulation algorithms
	* Accelerators for VLSI testing and fault simulation

Instructions for Submitting Manuscripts

Manuscripts should be no more than 25 double-spaced pages (about 6000 words)
in lenth including all figures and references.  Papers must not have been
previously published or currently submitted for publication elsewhere.
Manuscripts should have a title page that includes the title of the paper,
full name(s) and affliation(s) of the author(s), complete physical and
electronic address(es), telephone number(s), and an abstract.

DEADLINES

	* Four copies of the full manuscript are due by March 1, 1993
	* Notification of acceptance is July 1, 1993.


Send Submissions and Questions to:

Dr. Ausif Mahmood, Guest Editor
School of Electrical Engineering and Computer Science
Washington State University at Tri-Cities
100 Sprout Road
Richland, WA 99352

Phone: (509) 375-9234
Email: mahmood@beta.tricity.wsu.edu


Dr. George W. Zobrist, Editor-in-Chief
Department of Computer Science
University of Missouri-Rolla
Rolla, MO 65401

Phone: (314) 341-4492
Email: c2816@umrvmb.umr.edu
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.arch
Subject: Re: Hardware Support for Numeric Algorithms
Followup-To: comp.arch
Date: 7 Nov 92 09:01:14
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)
	<1992Oct22.164414.12708@newshost.lanl.gov> <Bx78zu.395@rice.edu>
	<1992Nov4.183718.5242@newshost.lanl.gov> <2230@titccy.cc.titech.ac.jp>
Reply-To: tmb@idiap.ch
NNTP-Posting-Host: arolla.idiap.ch
In-reply-to: mohta@necom830.cc.titech.ac.jp's message of 6 Nov 92 12:31:52 GMT

mohta@necom830.cc.titech.ac.jp (Masataka Ohta) 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.
>
>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.

Thank you:  you are providing an excellent example of why
Preston is right:

(1) The optimization you just performed is machine specific: the optimal
amount of loop unrolling depends on the precise characteristics of
your hardware and may even differ from workstation to workstation of
the same type.

(2) You just introduced two serious bugs.

(3) Finally, you cheated. Usually, limits don't work out that nicely
(even if you get them right) so that you need special case code (e.g.,
Duff's device) to handle the special cases.

There are a few cases where hand optimizations like these are
justified in C (e.g., the X11 blitter code). But don't fool yourself
and others into believing that they are "easy" or "portable".

Some problems with C pointers are fixable with a "noalias"
declaration, so the situation may get slightly better. But,
ultimately, C is a poorly designed language for truly aggressive
optimization and high-performance computation, even if you are willing
to do a lot of work by hand.

					Thomas.

PS: I still use C/C++ for much of my work, because usually
pragmatic issues like interfacing with existing libraries are
more important to me than getting the best optimizations.
From: ucacmsu@ucl.ac.uk (Mr Stephen R Usher)
Newsgroups: comp.arch
Subject: Re: IDE faster than Mips SCSI disk
Date: 10 Nov 92 16:05:39 GMT
Organization: Bloomsbury Computing Consortium, London

In article <6215@tuegate.tue.nl> tgcpwd@urc.tue.nl 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?

VMS I/O is a dog when used in the way iozone does. Iozone, written in C
using the standard I/O library has to use the VMS RMS sub-system, then
"low-level" open(), read() and write() calls are very high level under VAXC.
To get any sort of I/O performance under VMS you have to go low-level with
SYS$QIO system calls, and only then with very large block reads and writes.

>
>Since this threads seems to acknowledge the presence of people
>knowledgeable on hard disk, I thought I might as well ask this.
>
>Met vriendelijke groeten, Wim `Blue Baron' van Dorst
>-- 
>---------------------------------------------------------------------
>Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
>(-: baron@clifton.hobby.nl  tgcpwd@urc.tue.nl  WvD@Akzo.400net.nl :-)
>---------------------------------------------------------------------

Steve

PS. I wish there were a (68)030BSD which would run on my Atari TT as well as
386BSD :-).
--
Addresses:-
JANET:-		ucacmsu@uk.ac.ucl or	steve@uk.ac.ox.earth (preferable)
Internet:-	ucacmsu@ucl.ac.uk or	steve@earth.ox.ac.uk (preferable)
Newsgroups: comp.arch
From: martyi@nubbins.wpd.sgi.com (Marty Itzkowitz)
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Reply-To: martyi@sgi.com
Organization: Silicon Graphics, System Software Division
Date: Tue, 10 Nov 1992 16:40:54 GMT

I don't know of any 1/8 dollar coins, but the US mint issued half-cent
and half-dime coins (half-dime in silver, labeled as such,
not just 5-cent piece in nickel-alloy).  It also issued 2-cent and 20-cent
copper, 3-cent nickel, and 3-cent silver pieces, and all sorts of gold
coins, from $1 on up.

But we certainly digress from computer architecture....

	Marty Itzkowitz
Newsgroups: comp.arch,comp.lang.misc
From: daveb@harlqn.co.uk (Dave Berry)
Subject: Re: A challenge to the anti-goto
Organization: Harlequin Ltd, Cambridge, UK
Date: Thu, 5 Nov 1992 11:19:43 GMT

It's easy to get rid of these gotos.  Every goto can be replaced by a
tail-recursive function call.  This can be compiled into the same machine
code.  Here is Herman's example, gratuitously rewritten in ML.

(Note: I decided not to make the program functional, for clarity.  Also
for clarity I left out all occurrences of the dereference operator.  I
don't know if an existing ML compiler would produce code as efficient as
the original C - they aren't usually optimised for this sort of work.
But that's not the point - you could write this in C if your compiler
optimises tail-recursion.)

(Another note: In both ML and C it would be possible (and possibly
advisable) to use other features of the language to structure some
parts of this program.)


let
  val n = ref 0
  val m = ref 0
  val b = ref B

  fun start() =
  ( g := ...;
    body()
  )

  fun body() =
    case g of
      1 => add()
    | 2 => ()
    | 3 => start()
    | 4 => label2()
    | 5 => start()
    | 6 => start()
    | 7 => (g4 := 1; label3())
    | 8 => ( h := ...;
             g4 := h>>1;
             if h&1 then
             ( g4+=2;
	       label3()
             )
             else
               label4()
           )
    | _ => if g > 8 andalso g <= 12 then
             start()
           else
           ( g16 := (g-9)>>4;
             g &= 3;
             if g=1 then
	       label5()
             else if g=2 orelse g=3 then
	       start()
             else
             ( h := ...;
	       g4 := (h+1)>>1;
	       if h&1 then
	       ( j := 6;
	         labelh()
	       ) 
	       else
	       ( j := 7;
	         g := ...;
	         if g mod 3 <> 2 then start() else loop()
	       ) 
             ) 
    	   )

  fun add() = (n += 1; start ())

  fun loop() =
    if bit then
      labelh ()
    else
    ( j += 1;
      g := ...;
      if (2<<(g-1)/j)&1 = 0 then
	start()
      else
	loop ();
    )

  fun labelh() =
  ( i := C(j);
    b >>= 1;
    if i=j orelse i=0 then
      labelh()
    else
    ( m |= b;
      case i of
	1 => ()
      | 2 => label2()
      | 3 => label3()
      | 4 => label4()
      | _ => label5()
    )
  )

  fun label5 () =
  ( b >>= g16;
    m |= b;
    g := ...;
    if bit then
      if g&1 then label2() else ()
    else
    ( g4 := (g+1)>>1;
      if g&1 then label3() else label4()
    )
  )

  fun label4() =
  ( g := ...;
    if g4 < g then
    ( m |= (b>>g4 | b>>g);
      ()
    ) else
    ( m |= b>>g;
      if bit then () else (b >>= 1; label3())
    )
  )

  fun label3() =
  ( b >>= g4;
    m |= b;
    b <<= 1;
    label2()
  )

  fun label2() =
  ( g = ...;
    m |= (b>>g);
    ()
  )
in
  start()
end;
Newsgroups: comp.arch,comp.lang.forth
From: peter@ferranti.com (peter da silva)
Subject: Re: What's RIGHT with stack machines
Organization: Xenix Support, FICC
Date: Wed, 11 Nov 1992 16:19:14 GMT

In article <lg0eheINNs7l@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
> On the other hand, if what you are optimizing is ROM usage,
> high-performance commodity micros might just run little byte-code
> interpreters.  Of course, one trick to making your interpreted code
> run faster is to compile little fragments, which is sort of a
> generalization of scheduling at run-time.

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...
-- 
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,comp.lang.misc
From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
Subject: Re: Hardware Support for Numeric Algorithms
Keywords: n
Organization: Purdue University Statistics Department
Date: Fri, 6 Nov 1992 10:54:09 GMT

In article <1992Nov6.075459.13348@coe.montana.edu> osycs@giac1.oscs.montana.edu (Craig Spannring) writes:

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

>Large scale computing demands that you to avoid the unreadable
>micro-optimizations that Herman is suggesting.  If one of your little
>attempts at optimizing the code ends up producing incorrect results
>then you've just wasted months of research time.  Meanwhile your
>colleagues that have programs producing correct results are getting
>published and getting grants.  How much research and computing time are
>you wasting with buggy programs?

As I see it, every one of the "micro-optimizations" I used is something
which is totally natural to someone who has not been brainwashed out of
gotos.  The code I posted originally was buggy do to an attempt to avoid
gotos in situations for which I was aware of alternatives which would not
slow down to code.

>The second problem with these 'optimizations' is that they aren't.
>Herman seems to be most concerned with saving a few clock cycles per
>iteration.  The only significant performance gains will be found be
>using an algorithm that uses fewer iterations.  Example-  Even a highly
>optimized bubble sort will run slower than an unoptimized quick sort
>for the large data sets you are refering to.

You are partially correct here.  I can get an improvement in the code
which produces different results, and uses the same average number of
resources of each type, by changing the algorithm to start out

start:	g = ...;
	n += (g-1);
	g = ...;
	if (g==1) goto label1;

and have each situation here have the g value 1 less.  This now 
reduces the average number of uses of start: per output of n and m
by a factor of 2 to 1.54.  Other "micro-optimizations", which some
of my correspondents found, can make speedups.  But they use some
code "duplication" (really duplication but with some initialization
removed) and at least as many gotos.  By using vectorization tricks,
which instead of producing a fixed number of outputs produce a
variable number, and by using vector insertions, that this type of
program can be significantly speeded up.

Additional performance improvements can be obtained by instead
ending the higher g's off and using a fallthrough to label1, 
as 77% of the loop exits do this.  This is the situation both
in this modified code and the original.  This can be done by
exporting most of the instructions into another block; would
your optimizing compilers find this?  Certainly not without
being given the 77% information above in some manner.
	
-- 
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: cook@bebop.esd.sgi.com (Doug Cook)
Subject: Re: Alpha AXP Press Release
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Wed, 11 Nov 92 21:28:54 GMT


In article <1992Nov11.154417.198@ryn.mro4.dec.com>, bhandarkar@wrksys.enet.dec.com writes:
> 
> Digital Equipment Corporation today introduced Alpha AXP computing: a complete
> set of systems, software, applications, and services, with new business
> practices, that provides a universal platform enabling unlimited open computing
> possibilities. 
> 
> Alpha AXP computing -- the first advanced 64-bit, twenty-first century
> architecture -- is a major technology milestone for the computing industry. For
> Digital, it reflects a renewed determination to help customers succeed. Alpha
> AXP computing enables users: 

Can we please keep the marketing BS out of this newsgroup? Performance
numbers are fine, particularly when correlated with issues
of computer architecture. But this kind of posting should be elsewhere.
Thanks, 

	-Doug


Doug Cook  	(cook@sgi.com)		| 
Software Engineer, ISD Digital Media    |    "Exuberance is Beauty."
Silicon Graphics, Inc.			|		-Wm. Blake
Newsgroups: comp.arch
From: bhandarkar@wrksys.enet.dec.com (Dileep Bhandarkar)
Subject: DEC Alpha AXP System Performance
Keywords: Alpha, AXP, SPEC, DEC
Organization: Digital Equipment Corporation
Date: 10 NOV 92 10:39:00    

Here is a summary of SPEC results for Alpha AXP Systems announced today.

DEC 10000 Model 610 AXP, @200 MHz

	SPECmark89 	184.14
	SPECint89       104.52
	SPECfp89        268.60

	SPECint92	106.54
	SPECfp92	200.36


DEC 7000 Model 610 AXP, @182 MHz

	SPECmark89	167.43
	SPECint89	 95.06
	SPECfp89	244.18

	SPECint92	 96.58
	SPECfp92	182.11


DEC 4000 Model 610 AXP, @160 MHz

	SPECmark89	136.23
	SPECint89	 83.73
	SPECfp89	188.45

	SPECint92	 83.51
	SPECfp92	143.10


DEC 3000 Model 500 AXP, @150 MHz

	SPECmark89	121.50
	SPECint89	 73.47
	SPECfp89	169.89

	SPECint92	 74.30
	SPECfp92	126.0


DEC 3000 Model 400 AXP, @133 MHz

	SPECmark89	108.14
	SPECint89	 65.80
	SPECfp89	150.6

	SPECint92	 65.32
	SPECfp92	112.2

Newsgroups: comp.arch,comp.lang.forth
From: bayko@mercury.cs.uregina.ca (John  Bayko)
Subject: Re: What's RIGHT with stack machines (Was Re: What's wrong...)
Date: Sat, 14 Nov 1992 00:33:55 GMT
Organization: University of Regina, SK, Canada
Keywords: stack computers, embedded control, AT&T, Crisp, Hobbit

In article
    <1992Nov12.204852.807@boole.uucp>
    NetCmmnd@boole.uucp (System Administrator)
writes:
>Where are the Hobbit people in this thread?

    I don't have anything on the Hobbit, but here's a (really very)
brief description of its predecessor from the Great Microprocessor list...
I doubt it's really useful, and probably not error free, but hopefully
interesting...


Great Microprocessors of the Past and Present (V 4.0.0)

[...]

Part III: AT&T CRISP, CISC amongst the RISC (1987)

    The AT&T CRISP was inspired by the Bell Labs C Machine project,
aimed at a design optimised for the C language. Since C is a stack
based language, the processor is optimised for memory to memory stack
based execution, and has no user visible registers (stack pointer is
modified by special instructions, an accumulator is in the stack), with
the goal of simplifying the compiler as much as possible.
    Instead of registers, a thirty-two entry 32 bit two ported stack
cache is provided. This is similar to the stack cache of the AMD 29000
(in CRISP it's much smaller but is easily expandable), but CRISP has no
global registers. Addresses can be memory direct or indirect (for
pointers) relative to the stack pointer without extra instructions or
operand bits. The cache is not optimised for multiprocessors.
    CRISP has a 512 byte instruction prefetch buffer, 
but decodes the variable length (2, 6 or 10 byte) instructions into a
thirty-two entry decoded instruction cache. Branches are not delayed,
and a prediction bit directs speculative branch execution. The decode
unit folds branches into the decoded instructions, so a predicted
branch does not take any extra clock cycles, saving execution time. The three
stage execution unit takes instructions from the decode cache. Results
can be forwarded when available to any prior stage as needed.
    Though CISC in philosophy, the CRISP is greatly simplified compared
to traditional CISC designs, and features some very elegant design
features. AT&T prefers to call it a RISC processor, and performance is
comparable to RISC designs.

John Bayko.
Newsgroups: comp.arch
From: fabre@gr.osf.org (Christian Fabre)
Subject: Integers implementation
Organization: Open Software Foundation
Date: Fri, 6 Nov 1992 14:45:02 GMT

--
Hello,

I have a question about integers representation.

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 advantges ?
 - What are their drawbacks ?
 - Are they usefull for any given set of aplications ?
 - Are they likely to pop-up in future processor design ?

Any input welcome, please reply by news.

	Christian.

#include <disclamer.h>
-----
  Christian Fabre, OSF-RI, 2 avenue de Vignate, 38610 Gieres, France.
     		fabre@gr.osf.org --  Tel: +33 76.63.48.90
     		fabre@ri.osf.fr  --  Fax: +33 76.51.05.32
From: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
Newsgroups: comp.arch
Subject: Performance of Alpha on SPECfp92 (alvinn and ear)
Date: 12 Nov 1992 17:16:09 GMT
Organization: Sun Microsystems, Inc.  Mt. View, Ca.
Distribution: world
Reply-To: tremblay@flayout.Eng.Sun.COM (Marc Tremblay)
NNTP-Posting-Host: flayout


The performance of the new machines announced by DEC on some
on the SPECfp92 programs, more specifically alvinn and ear,
is quite impressive.

Some of the performance can be explained by the size of the external
cache, which is 4 Mbytes per cpu for the mainframe-class machines,
but that alone doesn't explain all the gains (vs. similar processors).

First let's look at the difference between the low-end (133 MHz),
an hypothetical low-end scaled to 200 MHz and the one-processor
mainframe (200 MHz with large external cache):

Machine.......:    A		    B		   C
Model.........:	3000/400	hypothetical	10000/610
clock.........:	133 MHz		200 MHz		200 MHz
External Cache:	512K		4M		4M

		(SPECratios)
benchmark:	alvinn	ear
machine A:	263.6	397.1
machine B:	396.4	597.1
machine C:	502.9	605.7
improv (C/B)	27%	56%

I assume that most of the improvement from machine B to machine C
comes from the external cache size. Maybe someone from DEC could
comment on the latency of the various external caches?
Does the external cache on the 200 MHz machine have the minimum
3-cycle latency?

Now, let's compare machine B with an hypothetical 200 MHz HP machine.
The numbers I will use are from the 100 MHz (really 99 MHz)
HP machine recently announced scaled to a 200 MHz machine.

Machine.......:    D
Model.........:	HP/hypothetical
clock.........:	200 MHz
Cache (I+D)...:	512K

		(SPECratios)
benchmark:	alvinn	ear
machine B	396.4	597.1
machine D	353.8	516.8
improv (B/D)	10.6%	15.5%
  
Considering that this hypothetical HP machine has 2 cycle latency
floating-point operations, much closer caches, muladd capabilities,
smaller mispredicted branch penalty, etc., these numbers are quite
surprising. They represent a swing of maybe 30% in the opposite 
direction. DEC must be doing something pretty fancy with their
compilers. Could someone from DEC comment on what kind of
optimizations were used on alvinn and ear?

Thanks,

- Marc Tremblay.
Sun Microsystems.
Newsgroups: comp.arch,comp.lang.misc
From: mhcoffin@tolstoy.uwaterloo.ca (Michael Coffin)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: Dept. of Computer Science, University of Waterloo
	<BwIwEB.J1A@mentor.cc.purdue.edu>
	<CLIFFC.92Oct22082750@athene.rice.edu>
	<1992Oct22.144843.3236@cis.uab.edu>
	<1992Oct22.163955.12161@newshost.lanl.gov>
	<GLEW.92Nov4072629@pdx007.intel.com>
Date: Thu, 5 Nov 1992 12:59:39 GMT

In article <GLEW.92Nov4072629@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:
> Emphasize. As usual, Knuth is an arbiter of good taste in programming
> style. For example, his example of programming state machines with gotos
> is cleaner than the usual case state/variable structure.  His suggestion of 
> never allowing fallthrough into a label often clarifies code.

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.

-mike

Xref: sparky comp.arch:10549 comp.lang.lisp:2835