HDTenEightyP/NetNews huggingface dataset:
From: doconnor@sedona.intel.com (Dennis O'Connor)
Newsgroups: comp.arch
Subject: Re: RTX and SC32
Date: 9 Nov 92 09:10:08
Organization: Intel i960(tm) Architecture
	<ADAMS.92Nov5001909@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>
	<DOCONNOR.92Nov5085408@potato.sedona.intel.com>
	<ADAMS.92Nov7002912@PDV2.pdv3.fmr.maschinenbau.th-darmstadt.de>
NNTP-Posting-Host: potato.intel.com
In-reply-to: adams@pdv3.fmr.maschinenbau.th-darmstadt.de's message of Sat, 7 Nov 1992 00:29:12 GMT


adams@pdv3.fmr.maschinenbau.th-darmstadt.de (Adams) writes:
]  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.....

Intel i960(R) microprocessors run the price gamut, from under US$20
for low-end commercial chips to a lot more for full-blown mil-spec
chips. The CA I mentioned I think sells for well under $100.

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

Sounds like a DSP application. At best it sounds like a 16-bit app,
not a 32-bit one. There aren't many if any 16-bit RISC processors,
and comparing architectures with different word sizes is fraught
with dangers. After all, narrower structures are inherently faster,
tho not by as much as they used to be back in the 1-level-metal days.

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

Every year, as yeild figures rise and device geometries shrink,
there's more silicon available for a given price point.
--
Dennis O'Connor			doconnor@sedona.intel.com
From: obiliset@duke.ecs.umass.edu (Sashi V Obilisetty)
Newsgroups: comp.arch
Subject: question about alpha
Date: 11 Nov 92 18:01:37 GMT
Reply-To: obiliset@sulu.ecs.umass.edu
Organization: University of Massachusetts at Amherst

I guess the best way to ensure that there is no skew is to have
one big buffer, and then have lines from this driver feeding all
other modules requiring clocks. What I am concerned about is the
amount of heat/power dissipation that would occur due to this big
driver.
Won't it create a hot spot on the chip? The power supply is 3.3V, 
is this the reason why it works?

Also, the chip is designed using 0.75um process with min. channel
lengths of 0.5um. How can we have long lines running in this technology?
Wouldn't the transmission line effects become prominent at this point,
and therefore it makes sense to use distributed driving??

Will be glad if someone would clear these doubts.
Thank You.

Sashi
From: brzezins@hplredHPL.HP.COM (Dennis Brzezinski)
Date: Mon, 2 Nov 1992 23:04:51 GMT
Subject: Re: Request for refs on GTL
Organization: Hewlett-Packard Laboratories, Palo Alto, CA
Newsgroups: comp.arch

You will find a short overview of GTL in the 1992 ISSCC p 58..."A CMOS Low-
Swing Transmission-line Transceiver".  Bill Gunning is one of the authors.
No other direct reference is made, but databooks by LSI and National are
cited.  I have found GTL atractive when you must drive a multi-tapped 
bidirectional bus and only have a CMOS process.   You may find better solutions
for other topologies and technologies.  With the newer 3.3V processes, even
a NMOS-NMOS push-pull output can be faster and modest in its power requirements.
The larger ~2.5V swing of this push-pull means that you will not need a 
differential receiver or voltage reference.

Dennis Brzezinski
HP Labs, but these are my opinions alone.
Newsgroups: comp.arch,comp.misc,comp.programming,comp.parallel,comp.lang.misc,comp.lang.fortran
From: yu@lisp.cs.psu.edu (Chansu Yu)
Subject: test message
Organization: Penn State Computer Science
Date: Thu, 5 Nov 1992 18:57:16 GMT

This is test message.....
Sorry....


Newsgroups: comp.arch
From: luciano@athos.Berkeley.EDU (Luciano Lavagno)
Subject: Re: asynchronous DSP project at Berkeley
Reply-To: luciano@athos.Berkeley.EDU (Luciano Lavagno)
Organization: UC Berkeley IC CAD Group
Distribution: na
Date: Fri, 6 Nov 1992 01:28:05 GMT

In article <LINDER.92Nov5175441@desperado.ERC.MsState.Edu>,
linder@ERC.MsState.Edu (Dan Linder) writes:
[...]
>Brodersen is well known in the DSP area so this probably influenced their
>decision.  It is interesting to note that the DSP processor uses
>microprogramming and Martin's processor only has a few instructions.  I
>suspect as well that the complexity of a modern RISC control unit is beyond
>current asynchronous techniques.  Are there any asynchronous methods that
>can efficiently combine the generation of a multitude of control signals
>while also making the complex logical decisions associated with big state
>machines?

You may look into some of the new approaches to asynchronous circuit synthesis,
for example:
1) methods based on burst-mode finite state machines (i.e. FSM's with a couple
of restrictions on the valid transitions to avoid possible synchronization
problems):
S. Nowick et al, "Automatic Synthesis of Locally-Clocked Asynchronous State
Machines", ICCAD 91
T.A. Chu, "Synthesis of Hazard-free Control Circuits from Asynchronous Finite
State Machine Specifications", TAU 92

2) methods based on Signal Transition Graphs (i.e. a formalization of timing
diagrams):
L. Lavagno et al, "Algorithms for Synthesis of Hazard-free Asynchronous
Circuits", DAC 91
C. W. Moon et al, ""Synthesis of Hazard-free Asynchronous Circuits from
Graphical Specifications", ICCAD 91
P. A. Beerel et al, "Gate-Level Synthesis of Speed-Independent Asynchronous
Control Circuits", TAU 92

By the way, burst-mode FSM's can be converted into STG's, so the methods in
group 2 can directly deal with a network of FSM's as well.

Please, let me know if you need more information on any of the above methods
(they have all been implemented as CAD programs, as far as I know).

Luciano
-- 
Luciano Lavagno            luciano@ic.Berkeley.EDU            +1-510-642-5012
Dept. of EECS, 207-69 Cory Hall, Univ. of California, Berkeley, CA 94720, USA
Newsgroups: comp.arch
From: peter@ferranti.com (peter da silva)
Subject: Re: integer/BCD/... dollars (was IEEE used for Dollars and Cents)
Organization: Xenix Support, FICC
Date: Mon, 9 Nov 1992 16:10:26 GMT

In article <27311@dog.ee.lbl.gov> torek@horse.ee.lbl.gov (Chris Torek) writes:
> Sorry, I meant `five digits past the decimal point', the decimal point
> being dollars.  These are apparently called `mills', i.e., thousanths
> of a cent ($0 + 0 cents + 0.001 cents = 1/1000 cents = 0.00001
> dollars).

Sorry, a "mil" is 1/1000 of a dollar. Gasoline is sold in even mil amounts
in this country. The derivation is:

	dollar
	dime, from latin for 10, 1/10 dollar
	cent, from latin for 100, 1/100 dollar
	mil, from latin for 1000, 1/1000 dollar

Previously, dollars had been divided in halves, quarters, and eighths (hence
"pieces of eight"). I don't know if a 125 mil coin (1/8 dollar) was ever
issued by any bank or mint, but it wouldn't surprise me.

Another consideration is that some goods (stocks, for example) are listed
down to the 1/8 or even 1/16th of a cent, so you need a word arranged like
this:

	type BIT[4] BCD;

	BCD cents[ndigits];
	union {
		BCD mils;
		BIT fraction[4];
	}

Plus, I would guess, a flag indicating the precision class of the value.
-- 
% Peter da Silva % 77487-5012 % +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: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Subject: Re: MINIMUM instruction set
Date: Fri, 13 Nov 1992 17:13:56 GMT
Organization: University of Iowa, Iowa City, IA, USA

> So here is a challenge: design a machine that uses no more than 4 bits
> per instruction (including operand fields), is Turing complete, not
> terribly inefficient and which can be built using far less hardware
> than current microprocessors. The latter would make it suitable for
> massively parallel systems.

I proposed an idea that might help in my Computer Architecture News paper
entitled "the Minimal CISC" (June 1988).  In that paper, I proposed a
not-too inefficient machine using only 3 bits per instruction (operand
fields included).  Here's a 4 bit per instruction improvement that's not
half bad (you can do quite a bit better if you let some 4 bit instructions
interpret the next nibble as a 4 bit operand:

Notation:  X = top word on stack
           Y = word under top word on stack
	   push(t) -- push word with value T on stack
	   pop -- pop one word off stack

NOP	0000 No op                                \
ZERO    0001 X := X << 1                           \
ONE     0010 X := (X << 1) + 1                      | This much is exactly
DUP     0011 push(X) (duplicates top word on stack) \ my minimal CISC
STORE   0100 M[Y] := X; pop; pop;                   / instruction set.
LOAD    0101 X := M[X];                             |
SUB     0110 Y := Y-X; pop;                        /
BNEG    0111 if Y<0 then PC := X; endif; pop; pop;/
ZZERO	0000 X := X << 2;                         \
OONE    0001 X := (X << 2) + 3;                    \
PUSHZ   0010 push(0);                               |
NEG     0011 X := -X;                               \
AND     0100 Y := Y & X; pop;                       /
CALL    0101 swap(PC,X);                            |
BZERO   0110 if Y=0 then PC := X; endif; pop; pop; /
BPOS    0111 if Y>0 then PC := X; endif; pop; pop;/

PUSHZ = DUP;DUP;SUB, but we add it for fast pushing of small constants;
ZZERO = ZERO;ZERO, but we add it for faster pushing of constants;
OONE  = ONE;ONE, but we add it for the same reason.
NEG is added so that ADD can be done by the macro NEG;SUB;
NEG allows one's complement with the macro NEG;PUSHZ;ONE;SUB;
Unconditional branch is done with PUSHZ;{push address};BZERO;

If the word size is N bits, it takes N instructions, in the worst case,
to push an N bit constant.  101010... is the worst case.

Instructions are packed 2 per byte, and labels must be word aligned.  NOP
instructions are used to align labels to a word boundary.

				Doug Jones
				jones@herky.cs.uiowa.edu

Newsgroups: comp.arch,comp.lang.misc
From: lawrence@snake38.cs.wisc.edu (Thomas Lawrence)
Subject: Re: Hardware Support for Numeric Algorithms
Organization: /usr/lib/news/rn/organization
Date: Wed, 11 Nov 1992 14:57:18 GMT

Well, I can't speak for anyone other than me, but here is a technique I
find useful when I have to develop code that runs screamingly fast yet is
rather complex when "optimized" by hand.

First, I develop some working algorithm that's SIMPLE enough to understand
by looking at it.  This means it has absolutely no performance helpers.
(No caches, hash tables, etc.)  I debug that code to make sure it works
properly (basically debugging my algorithm, and not worrying about any
optimizations).  [Note that there may be goto's in the code; I don't
deal with that.  I've gotten into the habit of using them instead of
do-while loops in some cases.]

THEN I go and put COMMENTS around the entire code so that the compiler
won't see it.  I use the simple code as guidelines for developing more
efficient code.

The end result is a source file containing
  - Some straight-forward but inefficient code which is enclosed in comments
    so that when I come back 3 months from now, I can use it to see what I
    was trying to do.
  - Some twisted, optimized code (with comments indicating what was done
    to it from the original model, so I can fix it 3 months from now).

If it happens that I have to scrap the optimized code in a few months because
I forgot what it did, that's ok because I still have the original working
version in the text file which I can modify as necessary.  Or if I want
I can modify the optimized version.  It leaves the options open.
From: mjl-b@minster.york.ac.uk
Newsgroups: comp.arch
Subject: Re: Optimizing Old Code for i586
Date: 10 Nov 92 17:03:30 GMT
Reply-To: mjl-b@minster.york.ac.uk (Mathew Lodge)
Organization: Department of Computer Science, University of York, England

In article <1992Nov6.194508.9171@tc.cornell.edu> elan@tasha.cheme.cornell.edu (Elan Feingold) writes:
>OK, I don't read this group, so I don't know if this has been talked about
>much already, but I woke up last night at about 4AM in a cold sweat 
>and with this wierd idea:
>
>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.  The idea is that since the 586 only
>	   "looks ahead" one instruction, one helps the process by spending
>           time reorganizing the code in the .exe to maximize the chance that
>  	   the i586 will be able to execute two consecutive instructions 			   concurrently.
>
>Is this a really stupid idea?
>Would the performance increase be anywhere noticiable?
>Will compilers for the i586 probably perform this optimization?

If it turns out to be a useful win, then probably, yes. However, code motion
can cause problems for error handling, and particularly for exception
handling (in those languages that support it -- eg Ada)

>|  Elan Feingold       |  .sig currently undergoing renovation...         |

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               |
Newsgroups: comp.arch,comp.cad.cadence,comp.lang.verilog,comp.lang.vhdl
From: duncan@super.org (Duncan A. Buell)
Subject: Workshop on FPGAs for computing
Organization: Supercomputing Research Center (Bowie, MD)
Date: Fri, 6 Nov 1992 17:00:30 GMT

CALL FOR PAPERS: IEEE Workshop on FPGAs for Custom Computing Machines

   April 5-7, 1993    The Inn at Napa Valley, Napa, California

PURPOSE:
To bring together researchers interested in the use of Field
Programmable Gate Arrays as computing elements to present recent work.
While papers of a theoretical nature are welcomed, it is anticipated
that this workshop will focus primarily on the current opportunities
and problems in this new and evolving technology for computing.  A
proceedings will be published by the IEEE Computer Society.

SHORT PAPERS OR ABSTRACTS (10 pages) SHOULD BE SUBMITTED BEFORE
JANUARY 9, 1993 TO ONE OF THE TWO CONFERENCE CO-CHAIRS.

This workshop is sponsored by the IEEE Computer Society and the TC
on Computer Architecture.

CoChairs:    Ken Pocek (west coast)    Duncan Buell (east coast)
             Intel                     Supercomputing Research Center
             Mailstop SC1-03           17100 Science Drive
             3065 Bowers Avenue        Bowie, Maryland 20715
             Santa Clara, CA  95052    301-805-7372                      
             408-765-2363              301-805-7602 (fax)                      
             408-765-2949 (fax)        duncan@super.org            
             kpocek@sc.intel.com

ORGANIZING COMMITTEE:
Lynn Abbott , VPI           Fred Furtek, Concurrent Logic  
Jeffrey Arnold, SRC         Leon Maissel, IBM  
Peter Athanas, VPI          Richard Newton, U Cal-Berkeley
Apostolos Dollas, Duke U    Jonathan Rose, U Toronto  
Tom Kean, Algotronix        Steve Trimberger, Xilinx 
Wally Kleinfelder, SRC      David Van den Bout, N. Carolina State U 

SOLICITATION::
Papers are solicited on all aspects of the use or applications of
(usually multiple) FPGAs as (usually reconfigurable) computing
elements in attached or special purpose processors or coprocessors,
especially including but not limited to
*** coprocessor boards for augmenting the instruction set of
    general purpose computers;
*** attached processors for specific purposes (e.g. signal
    processing) or general purposes;
*** languages for programming FPGA-based computers;
*** tools and environments for programming FPGA-based computers;
*** application domains suitable for FPGA-based computers;
*** architecture emulation using FPGA-based computers.

[An attempt will also be made to have general panel discussions by the
major software and hardware vendors on what to expect in the near
future in capability for FPGA-based systems.]

Individuals wishing to be put on an email list for further information
about this workshop should send email with name, regular mail address,
and email address to Duncan Buell.
From: arnold@clipper.ingr.com (Roger Arnold)
Newsgroups: comp.arch
Subject: Re: fiber/silicon and Thz clocks?
Summary: use frequency multiplexing
Date: 12 Nov 92 01:58:46 GMT
Organization: Intergraph Advanced Processor Division - Palo Alto, CA

In article <17033@mindlink.bc.ca>, Nick_Janow@mindlink.bc.ca (Nick Janow) writes:
> craig@sics.se (Craig Partridge) writes:
> 
> > For example, 1 terabit per second, on an 128-bit wide bit path is about a
> > 0.1 ns clock cycle, which is only a modest improvement over what DEC
> > reputedly hopes to achieve for Alpha clock cycles in the future.  Now going
> > serial to parallel would presumably require some pico-second logic
> > somewhere, but maybe that's possible.
> 
> The serial/parallel conversion might be handled with innovative techniques,
> taking advantage of physics.  What is the physical distance between optical
> pulses travelling through silicon (or some similar material)?  If that
> distance is small enough, it might be possible to do a "flash" conversion,
> with sensor elements in a linear optical path, each detecting whether there
> was a positive optical pulse within it at the time of a central clock pulse.

About .2 mm, if it worked that way.  But it doesn't.  What you'd actually
have would be 128 light frequency channels carried in one fiber, each 
channel modulated at 10 GHz.  Or 256 channels modulated at 5 GHz, or
whatever works.  Heavy duty frequency multiplexing, at any rate.  The
receiving end has a corresponding number of tuned receivers, one per
frequency channel.

> Likewise, a linear array of laser elements could be pumped or not, according
> to a digital word input.  A word-sized string of optical pulses could be sent
> at once.
> 
> It needn't even require linear arrays.  Non-linear optical techniques could
> stretch or shrink optical paths, or beam splitters, etc, could find a use.
> Brute force "one optical emitter and detector plus shift registers"
> techniques shouldn't be necessary.
> 
> Hmmm, should I patent this idea?  :)

With a lot of the things that are given patents these days, sure, why
not?  A little more clutter isn't likely to make much difference.

> --
> 
> Nick_Janow@mindlink.bc.ca

--
Roger Arnold
arnold@clipper.ingr.com
Newsgroups: comp.arch
From: elwin@maidavale.media.mit.edu (Lee W Campbell)
Subject: Fujitsu VPP500 vector parallel machine
Organization: MIT media lab
Date: Fri, 13 Nov 1992 14:00:20 GMT

I've been looking at the IEEE Computer Society magazine for Nov.'92. There
is a photo of what looks like a water-cooled backplane with a bunch of
motherboards plugged into it. There is also the following blurb:

   Fujitsu Ltd. has developed a supercomputer that delivers 355 billion
floating-point operations per sec with 222 processors. The VPP500 vector
parallel processor features a proprietary crossbar network that allows
simultaneous communication to move between individual processing
elements (PE's) at 800 Mbyte/sec with each PE operating at 1.6 Gflops.

   Distributed global memory space reaches a capacity of 55,000 Mbytes.
This allows memory space physically incorporated in each PE to be used
for storage as well. Programmers can thus us traditional programming
methods to develop high speed parallel programs.

   The upgradable LSI system uas fabricated from gallium arsenide and
runs UNIX SVR 4. System pricing begins at approximately $10 million. The
company plans commercial shipment in Sept. 1993.


   This raises alot of questions. Are there any Fujitsuans on the net
who might be able to post archetectural details?

Is this a new instruction-set architecture, or is it compatable with
something else?

How does it do on benchmarks like big linpacks, or preferably, SPECrate?
Is Fujitsu a member of SPEC?

How many chips make up the CPU of one PE? What's the clock rate? How
big is the cache? is main memory DRAM? How fast?

Lots more questions come to mind, but lets see if anybody out there can
answer any of these...

				- Lee Campbell  <elwin@media.mit.edu>
From: gxj@dcs.ed.ac.uk (Graham Jones)
Newsgroups: comp.arch
Subject: References on Decoupled architectures
Date: 12 Nov 92 16:36:04 GMT
Organization: Department of Computer Science, University of Edinburgh

Can anybody recommend any articles/books/papers on decoupled architectures ?

Thankyou 

Graham Jones
From: paulk@kpc.com (Paul Kalapathy)
Newsgroups: comp.arch
Subject: Re: DEC Alpha AXP System Performance
Date: 11 Nov 92 14:35:55 GMT
Organization: Kubota Pacific Computer Corporation, Santa Clara, CA

In article <BxIM38.L9F.2@cs.cmu.edu> lindsay+@cs.cmu.edu (Donald Lindsay) writes:
>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. 

I suspect that the main reason for this is that HP has had considerably
more time for their compilers to mature on the PA.  Remember that the
Precision Architecture has been around since the mid-80's whereas the
Alpha architecture is new.

	-Paul
From: pete@jura.uucp (Pete Bevin)
Newsgroups: comp.arch
Subject: Re: MINIMUM instruction set
Date: 12 Nov 92 18:25:27 GMT
Reply-To: pete@sst.icl.co.uk (Pete Bevin)

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?

You can get away with four instructions in the following (rather
inefficient) Turing-Machine-equivalent architecture.  Allow yourself a
number of registers, each of which can hold large enough numbers for
what you want to do.  Then, you only need:

	Z(register):        Zero a register
	S(register):        Increment a register (`S' for `successor')
	T(r1, r2):          Transfer value from r1 to r2
	J(r1, r2, address): Jump to address if r1 and r2 hold the same
			    value.

In fact, you can get away without the T instruction, because T(r1, r2)
is the same as:

		Z(r2)
	loop:	J(r1, r2, finished)
		I(r2)
		J(r1, r1, loop)

You wouldn't want to program it, but I guess it's fairly easy to reason
mathematically about it.

Pete.
Xref: sparky comp.arch:10563 comp.lang.misc:3558