HDTenEightyP/NetNews huggingface dataset:
From: stripes@pix.com (Josh Osborne)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Pix Technologies -- The company with no adult supervision
Date: Sat, 19 Dec 1992 14:27:21 GMT

In article <1992Dec19.012355.26665@ll.mit.edu> ejon@ll.mit.edu (Eric Jones) writes:
>In article <1gt111INNt3b@hpscit.sc.hp.com>, tim@computer.bri.hp.com (Tim Phipps) writes:
>|> In a previous article Phil Hallam wrote:
>|> [...The OS kernal only supports sequential files...]

[someone else said, no fseek means they are random access files... then: ]

>But isn't that exactly his point?  Sure you can write an ISAM file 
>structure using fseek (and if you're REALLY smart, you might even
>write an efficient one), but then how's anyone else going to use
>your files?

If you want others to access your files you make a lib that has functions
to access them.  For example: libdbm, libdbz, and libgdbm, and 4.4's libdb.

This has many benifits, and many drawbacks.  Take it elsewhere to disscuss
it, it's gone far astray from comp.arch (assuming comp.arch is really
comp.arch.hardware, as the FAQ seems to imply).
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Newsgroups: comp.arch
From: richk@grebyn.com (Richard Krehbiel)
Subject: Re: Any new instructions in a i486?
Organization: Grebyn Timesharing
	<1992Dec14.134109.3367@fasttech.com> <edm.724366309@wrs.com>
Date: Tue, 15 Dec 1992 01:46:50 GMT

In article <edm.724366309@wrs.com> edm@wrs.com (Ed McClannahan) writes:

>   The jist I got was that NeXTstep wants to maintain compatible File
>   Systems between 680X0 and X86 platforms.  To do this, they needed
>   to do a lot of byte swapping on the X86 platforms.  Since the 486
>   has a simple instruction to do it while the 386 does not, NeXT
>   just went with the 486.

This would explain why they chose to require the 486 instruction set.
It does not explain why NeXT Step 486 won't run on the Cyrix 486DLC,
which *has* the BSWAP instruction, like an Intel 486.

>   I think their justification was that you needed the horsepower of
>   the 486 to run NeXTstep anyway - atleast when you only look at X86
>   processors from Intel!  This assumption (of only considering
>   Intel's product line) may, indeed, be the real culprit as I think
>   the Cyrix ne-486 is quite capable of running NeXTstep from a
>   performance perspective.

If the Intel 486SX-25 is powerful enough, then the Cyrix 486DLC-40
certainly is, even considering the smaller cache.
-- 
Richard Krehbiel                                 richk@grebyn.com
OS/2 2.0 will do for me until AmigaDOS for the 386 comes along...
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Keywords: I/O, Point-to-Point, High Performance, Low Cost, Bus
Date: 16 Dec 92 20:59:08 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

Well... I've only read it through once, but my first impression
is that it would be a very elegent architecture for '94.  Passing 
packets of data around on smaller data buses isn't much of a 
new idea, but as a substitute for a wide PC expansion bus... 

Obviously in the era of the 8080 one would have been laughed
off the podium in making a suggestion that intrs and bus 
reqs could ever be handled in a timely manner.  Today, I
can't see it happening for '93, but then again chip designers 
amaze me at times.  

If we are talking about '94... let's just go all the way 
and have three pins: Vcc, Gnd, and fiber... OK, so maybe we
want one more Gnd :)  Really, though... if you are proposing to 
build in a lots of "smarts" into modem, floppy, lan, etc. type cards
then why not build in a fiber-optic interface?

Another thought when you were talking about wide-buses versus
your 8-bit proposal... someone is bound to bring up the fact 
that if your 8-bit bus is going to be sooooo fast with GTL, what 
is the problem with a 32-bit bus using GTL?  Of course, that 
would be PCI (or VL).

I think that for palmtops (or in '94 wrist-tops) definitely need 
lower pin count without cause a big loss in performance... and the 
hot-socket is definitely the way to go when presented with limited
slots... but I'm a little concerned about suggestions to bring 
such a technology to the desktop.

I *do* agree that ISA and EISA has GOT to go... as a guy who has
his PC at home stuffed with serial/modem ports, video capture
boards, and LAN cards, I don't enjoy juggling the limited number
of IRQs, ROM areas, and time slices...

Just think about the fiber proposal... I wasn't joking.

Later,
Tom

-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is Yes, and We are All FREE!"  | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
From: zaphod@madnix.uucp (Ron Bean)
Subject: Re: Heat Output of New uPs
Organization: ARP Software
Distribution: usa
Date: Sat, 12 Dec 1992 00:59:35 GMT

nigel.allen@canrem.com (Nigel Allen) writes:
 
>Any ideas for (safely) implementing a laptop based on one of these
>chips?  If I remember correctly, I think 10-20 watts was about the
>heat output of the Kenner Easy-Bake Oven.  I can't picture putting
>one of those on my lap for a 2-3 hour plane trip.
 
   I could be wrong, but I thought the Easy-Bake Oven had a pair
of 100-watt lightbulbs in it. I doubt that you could do much
cooking with 20 watts (anyone tried frying an egg on a '486?).
 
==================
zaphod@madnix.UUCP (Ron Bean)
uwvax!astroatc!nicmad!madnix!zaphod

Newsgroups: comp.arch,comp.sys.dec,comp.sys.sgi,comp.sys.hp
From: ejon@ll.mit.edu (Eric Jones)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Reply-To: ejon@ll.mit.edu (Eric Jones)
Organization: MIT Lincoln Laboratory
Date: Sat, 19 Dec 92 01:23:55 GMT


In article <1gt111INNt3b@hpscit.sc.hp.com>, tim@computer.bri.hp.com (Tim Phipps) writes:

|> In a previous article Phil Hallam wrote:

|>: 6) File system limited to sequential file, forcing 
|>: applications to create their own file system on top of 
|>: the UNIX one, thus preventing any standardization or
|>: application independent optimization.

|>(Snore) Try "man fseek".
|>
|>Phippo the Hippo.
|>

But isn't that exactly his point?  Sure you can write an ISAM file 
structure using fseek (and if you're REALLY smart, you might even
write an efficient one), but then how's anyone else going to use
your files?

Eric
Newsgroups: comp.arch
From: peter@ferranti.com (Peter da Silva)
Subject: Re: IBM's FIRST RISC System/6000(tm) based Shared Memory Parallel Processor
Keywords: mp shared-memory parallel multiprocessor risc smp
Organization: Xenix Support, FICC
Date: Sun, 13 Dec 1992 21:57:18 GMT

chased@rbbb.Eng.Sun.COM (David Chase) writes:
> I've had this nagging suspicion for about a year that people building
> MP's were working awfully hard to maintain coherency where it just
> didn't matter.  Given that most of the programming languages tell you
> to lock your data if it is shared, the "we're guarding against this"
> examples always looked like buggy programs to me.

I guess that depends on what the consequences of running these buggy
programs are. Are they guarding against bringing the whole system down
(unacceptable) or simply crashing a single application (acceptable)?
-- 
%Peter da Silva/77487-5012 USA/+1 713 274 5180/Have you hugged your wolf today?
/L{lineto}def/C{curveto}def/F{0 562 moveto 180 576 324 648 396 736 C 432 736 L
482 670 518 634 612 612 C}def/G{setgray}def .75 G F 612 792 L 0 792 L fill 1 G
324 720 24 0 360 arc fill 0 G 3 setlinewidth F stroke showpage % "Peerless"
Newsgroups: comp.arch
From: dfox@quack.sac.ca.us (David Fox)
Subject: Relatively long cycle time in 486 LOOP instruction
Keywords: 486 LOOP instruction cycle
Organization: The Duck Pond public unix: +1 408 249 9630, log in as 'guest'.
Date: 16 Dec 1992 06:02:51 UTC

Hi.  This is my first posting to this newsgroup.

I and others on a different network have had an ongoing thread about
386/486 assembler programming in general.  One has posted recently
that the 486's LOOP and JMP [E]CX instructions seem to take an
inordinately long time, compared to other instructions that branch.

I don't have a 486 hardware manual, so I cannot be absolutely sure
of the timings, but apparently the LOOP instruction seems to eat
at least 3 cycles more than we think it should.

At most, the various parts of a LOOP instruction (decrementing the
ECX register, testing against zero) should only take maybe two
clocks.  However, the information I got on the clock timings for
LOOP consumes about three cycles in addition to the time we think
the decrement, test, and jump take.

Is the 486 doing anything special in a LOOP instruction to justify
these three extra cycles?  Specifically, is it doing something extra
with the flag register to ensure that the flags don't get modified
in the process?
--
David Fox
dfox@quack.sac.ca.us

Newsgroups: comp.arch
From: stripes@pix.com (Josh Osborne)
Subject: Re: Comparison of Alpha, MIPS and PA-RISC-II wanted
Organization: Pix Technologies -- The company with no adult supervision
Date: Sun, 20 Dec 1992 16:31:22 GMT

In article <BzIxqo.C90@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
>In article <BzIG5M.GDo@pix.com>, stripes@pix.com (Josh Osborne) writes:
[..."filetypes" in Unix should be done at the lib (user) level, but
this isn't a good comp.arch topic...]
>But it is the paucity of software that prevents anything more novel than
>floating point accelerators for standard Von Neumann machines gaining wide
>acceptance.

You forget bitblt'ers, and line drawers.

[I am word wraping the following text...]
>If you want to discuss hardware, you cannot ignore the software aspect. Take
>the above for instance. In RMS the filestore offers high level functionality.
>In UNIX only low level functionality is offered. Now let us consider the
>difficulties of producing an intelligent filestore:
>
>VMS/RMS,
>	Done years ago with the HSC. Nothing special about VMS here of course. ICL 
>were offering intelligent filestores that could do sorting years ago.
>
>UNIX,
>	Because the filestore knows only about the fopen, fseek, fread, fwrite and
>fclose operations it is easy to interface to any sequential device. However
>when the filestore receives an instruction it is only told *what* to do.
>There is no clue as to *why* to do it. In this circumstance it is very 
>difficult to do any form of intelligent cacheing.

The we need a way for user level code to tell the OS what file info is
important to cache, and what isn't.  Then you can be almost as efficent
as VMS/RMS (you will have extra context switch overhead for the extra
syscalls), but you will still be able to allow any user to create new
filetypes.
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
From: rmk@rmkhome.UUCP (Rick Kelly)
Newsgroups: comp.arch
Subject: Re: Any new instructions in a i486?
Date: 20 Dec 92 05:17:09 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats

In article <PCG.92Dec19162224@decb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>On 13 Dec 92 05:00:19 GMT, johnl@iecc.cambridge.ma.us (John R. Levine) said:
>
>(somebody)> NeXTStep is said to not run on the Cyrix 486 chips because
>(somebody)> "they are not real 486's".  No one has come up with a
>(somebody)> reliable reason _why_ NeXT doesn't think they are "real
>(somebody)> 486's" or why NeXTStep won't run on them.
>
>The most probable reason seen so far is that there are some small
>supervisor state differences between the Cyrix and the Intel part.  If
>so, I would venture that it is about enabling (and then flushing at the
>right moment) the cache on the Cyrix.  It is not necessary to do so, but
>if one does not (and one has to do so on most old 386-like motherboards
>on which the Cyrix part is usually mounted) then performance is little
>better than with a 386.
>
>johnl> I don't have any real data, but I expect the problem is that the
>johnl> Cyrix chip doesn't have a floating point unit.
>
>No, this cannot be the reason. As a rule the Cyrix 486DLC CPU chip is
>sold with the Cyrix Fasmath (a 387) coprocessor, the combo being touted
>quite reasonably as a 486DX equivalent.
>
>Moreover NeXTStep is said to run on the 486SX Intel chips, and those
>don't have a corprocessor either.
>
>FUD, FUD. Ah Intel, Intel. :-)


I don't see where this has anything to do with Intel.  Cyrix decided that
they could make some money by cloning a best selling CPU chip.  Obviously,
they have missed something.  A curious individual with a 486DLC system, a
486DX system, two logic analyzers, and two NeXTStep bootdisks should be
able to track down the problem.

-- 

Rick Kelly	rmk@rmkhome.UUCP	unixland!rmkhome!rmk	rmk@frog.UUCP
From: rf@cl.cam.ac.uk (Robin Fairbairns)
Subject: Re: Any use for Branch if Even/Odd ?
Organization: U of Cambridge Computer Lab, UK
Date: Sat, 12 Dec 1992 14:31:16 GMT

In article <endecotp.723992157@cs.man.ac.uk>, endecotp@cs.man.ac.uk (Phil Endecott) writes:
|> Can anyone think of a use for the branch if even and branch if odd
|> instructions on the Alpha?  I'm completely baffled.

It's a VMS-ism.  All VMS routines return a completion code.  If it's
odd, the routine succeeded (and there are oodles of ways it can
succeed, sometimes); if it's even the routine failed.

All very smooth and neat - VMS has some dinkum ideas in there if you
pay attention.
--
Robin (Campaign for Real Radio 3) Fairbairns       rf@cl.cam.ac.uk
U of Cambridge Computer Lab, Pembroke St, Cambridge  CB2 3QG, UK
"They had twelve years to lay in wait for us" - Bush supporter on Nov 4
From: leichter@zodiac.rutgers.edu
Newsgroups: comp.arch
Subject: Re: Any use for Branch if Even/Odd ?
Date: 15 Dec 92 19:32:24 GMT
Organization: Rutgers University Department of Computer Science

In article <Bz9C2z.Cno@pgroup.com>, lfm@pgroup.com (Larry Meadows) writes:
	> I haven't seen this mentioned -- in VMS Fortran, logicals are TRUE
	> if odd and FALSE if even.  Someone said that BLISS was the same way.
	> Of course, this gives fits when mixing Fortran and C, or trying to
	> retain VMS Fortran compatibility on non-VMS systems.

What ARE you talking about?  FORTRAN has a first-class Boolean datatype, which
has exactly two values in its value space:  .TRUE. and .FALSE. .  Boolean
values are neither odd nor even; they are just plain not arithmetic.  You
can't use arithmetic values in Boolean contexts, nor can you use Booleans in
arithmetic contexts.  The internal representation of a Boolean is simply not
observable, unless you play inherently non-portable games (like overlaying an
INTEGER with a LOGICAL).

The standard internal representations for truth and falsehood in both VAX C
and FORTRAN are 1 and 0.  Any function in either that returns a Boolean will
be treated by the other has having the appropriate meaning.

Don't judge the whole world by C standards; it'll just give you a headache.

							-- Jerry
Xref: sparky comp.arch:11807 comp.sys.dec:6565 comp.sys.sgi:18232 comp.sys.hp:14267
From: jog@kpc.com (Rajeev Jog)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 18 Dec 92 19:38:49 GMT
Organization: Kubota Pacific Computers Inc.

simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:

Dear Compaq'ers: please look at SCI again.

> We have received this response from several people.  We 
> disagree.  For one SCI had a physical topology (a ring) that 
> is not suitable for expansion I/O.  Yes, we know you can run 
> the ring to and from the same board and create a topology 

A ring is not the only topology for SCI.  A ring is *convenient* 
for several applications, however any topology that can
be devised from point-to-point links works.

> around here) were trying to solve different problems with 
> cost, not bandwidth, being the major one.  The fact that the 
> 'C' in SCI stands for coherent I think brings out one of the 
> differences in approach.  We needed an I/O interface and 

It's true that 33% of the name is "COHERENT", but in reality,
the overhead is not a whole lot (coherence adds 2 bits in the packet
header) and you can quite easily skip the coherence aspects of the
protocol if you want to, *while leaving yourself the option to add
it in future parts*.

-- 
Rajeev Jog
------------------------------------------------------------------------------
Kubota Pacific Computer Inc.                                   +1 408 727 8100
2630 Walsh Avenue, Santa Clara, CA. 95051-0905, USA.               jog@kpc.com
Newsgroups: comp.arch
From: obiliset@honey.ecs.umass.edu (Sashi V Obilisetty)
Subject: Motorola RISC architecture
Reply-To: obiliset@sulu.ecs.umass.edu
Organization: University of Massachusetts at Amherst
Date: Wed, 16 Dec 1992 14:07:23 GMT

Hi all:

I am looking for references describing the RISC architecture in 
Motorola machines(88000 series). Any pointers would be appreciated.

Thank you

sashi
From: tdbear@dvorak.amd.com (Thomas D. Barrett)
Newsgroups: comp.arch
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Date: 18 Dec 92 13:08:22 GMT
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <1992Dec17.190553.17417@twisto.eng.hou.compaq.com> simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:
>
>Uh, why do you assume an ASIC is required?  

Chris, what else would be small enough to pack and unpack all of the
sideband signals (irqs, reqs/acks, parity, etc.).  That is why I made
the statement about using fiber optics instead of the 8-channels of
data... packetizing the sideband signals is great, but the technology
won't be available until '94 or late '93.  Sooooo, why not use the
fiber technology which should be around then?  A Vcc, 2 GNDs, and 1
fiber cable :)

Tom
-- 
| Tom Barrett (TDBear), Sr. Engineer | tom.barrett@amd.com
| AMD PCD / Austin, TX  78741        | v:512-462-6856 / f:512-462-5155
| "No is Yes, and We are All FREE!"  | CO made a #2 no-no... PU!
| My views may not be shared by the organization of origin
From: moss@cs.cmu.edu (Eliot Moss)
Newsgroups: comp.arch
Subject: paper available on Transactional Memory
Date: 11 Dec 92 22:38:41 GMT
Article-I.D.: CRAFTY.MOSS.92Dec11173841
Reply-To: moss@cs.cmu.edu
Distribution: comp
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)

Recently Maurice Herlihy and I completed our technical report titled
"Transactional Memory: Architectural Support for Lock-Free Data Structures".
It describes a concept and implementation (ok, design) of means to accomplish
essentially arbitrary multi-word atomic updates on shared memory
multiprocessors. It piggybacks off any ownership-based cache coherency
protocol and it eminently suitable for RISC design. (One way to think of it is
as a logical way of extending Load-Linked / Store-Conditionally to multiple
memory words.)

You can obtain this report, which is official DEC CRL 92/07, via anonymous ftp
from ibis.cs.umass.edu in pub/papers/crl-92-07.ps.Z (or omit the .Z if you
want straight PostScript). The report includes a number of interesting
simulation results for both a bus-based (snoopy) cache protocol and a
directory based one. Maurice and I would be most interested in people's
comments and reactions. Muarice can be reach via herlihy@crl.dec.com; I can be
reached via moss@cs.umass.edu.
--

J. Eliot B. Moss, Associate Professor	Visiting Associate Professor
Department of Computer Science		School of Computer Science
Lederle Graduate Research Center	Carnegie Mellon University
University of Massachusetts		5000 Forbes Avenue
Amherst, MA  01003			Pittsburgh, PA  15213-3891
(413) 545-4206, 545-1249 (fax)		(412) 268-6767, 681-5739 (fax)
Moss@cs.umass.edu			Moss@cs.cmu.edu
Newsgroups: comp.arch
From: hyatt@cis.uab.edu (Robert Hyatt)
Subject: Re: RISC assemblers question
Organization: University of Alabama at Birmingham
Date: Fri, 18 Dec 1992 22:19:47 GMT

In article <75756@apple.apple.COM> tim@Apple.COM (Tim Olson) writes:
>In article <Dec.17.10.16.36.1992.17493@cadenza.rutgers.edu> masticol@cadenza.rutgers.edu (Steve Masticola) writes:
>
>|I've met a couple of people who have attempted to write assemblers for
>|RISC machines, who say that it's a difficult job. Can someone give me
>|an inkling as to why?
>
>From my experience, it's just the opposite.  RISC processors tend to
>have a few simple instruction formats, fixed fields, etc.  Also, with
>the limited number of addressing modes in RISC processors, parsing
>becomes almost trivial.
>


The problem is that the assembler writer apparently never knows when his
job is finished.....  :^)  He/she keeps writing, handling more special
cases, etc.  The final product IS a difficult project.  However, I would
prefer a simple assembler, not one that tries to "think" for me.  An 
example is the one from Cray Research.  It doesn't "get in the way" of
my bad (or good) coding practices.


-- 
!Robert Hyatt                    Computer and Information Sciences   !
!hyatt@cis.uab.edu               University of Alabama at Birmingham !
From: lusol@Lehigh.EDU (Stephen O. Lidie)
Newsgroups: comp.arch
Subject: Re: Elegance vs Speed (was re: Comparison of Alpha ...)
Date: 18 Dec 92 17:57:06 GMT
Organization: Lehigh University, Bethlehem PA

In article <PCG.92Dec10143958@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo
Grandi) writes:
>On 8 Dec 92 00:00:21 GMT, gordie@kaleida.com (Gordie Freedman) said:
>
>gordie> On a NeXT, learn how to use the dictionary, spell-checker, etc.
>gordie> in one app and you know how to do it for them all.
>
>Amazing! We already had all this in Multics... What has happened in the
>past 25 years? :-)
>--
>Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
>Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
>Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk
>
 Unix got in the way ?
Newsgroups: comp.arch
From: simonich@croatia.eng.hou.compaq.com (Chris Simonich)
Subject: Re: COMPAQ PROPOSED SCALABLE I/O ARCHITECTURE
Organization: Compaq Computer Corp.
Date: Thu, 17 Dec 1992 19:05:53 GMT

In article <1992Dec17.100528.62134@cc.usu.edu> ivie@cc.usu.edu (CP/M lives!) writes:
>In article <1992Dec16.235011.17202@twisto.eng.hou.compaq.com>, simonich@croatia.eng.hou.compaq.com (Chris Simonich) writes:
>> Very well put.  However, wouldn't it be MUCH cheaper if you used a byte wide
>> interface instead of 32 bit wide interfaces?  The same architecture with
>> the Compaq Proposal saves a lot of pins on the control block.
>> I don't know all that much about Tc, but I've been told that each channel
>> requires about 60ish pins on the controller once data, control, and power/
>> gnd pins are taken into account.  The Compaq proposal requires 20ish pins
>> per channel on the controller.  One could save 120 pins on the controller
>> for this case by using the Compaq Proposal rather than Tc.  A 120 pin savings
>> translates into a significant cost savings.
>
>Well, working for a small company that can't afford to run out and spin
>ASICs for every design, I would much rather deal with a TURBOchannel that
>can be managed with a few PALs and jellybeans than a lower pin-count bus
>that requires an ASIC to unpack that packets.
>-- 
>
>Roger Ivie                      "My God! That computer is full of Pentium!
>ivie@cc.usu.edu                  It's a wonder that you haven't been turned
>                                 into mutants!"

Uh, why do you assume an ASIC is required?  Anyway, the intermediate nodes
of the network may be used over and over in any new design.  The only time
you would have do design anything new is if you changed the system interface.
--
======================================================
Christopher Simonich        simonich@twisto.compaq.com
Compaq Computer Corp.       [713] 374-1898
======================================================
Newsgroups: comp.arch