HDTenEightyP/NetNews huggingface dataset:
From: zalman@adobe.com (Zalman Stern)
Subject: Re: Cyrix 486
Organization: Adobe Systems Incorporated
Date: Wed, 8 Apr 1992 21:40:50 GMT

In article <1992Apr08.145102.26915@eng.umd.edu> sysmgr@king.eng.umd.edu  
(Doug Mohney) writes:
> In article <1992Apr7.224947.19354@cis.uab.edu>, hyatt@cis.uab.edu  
(Robert Hyatt) writes:
[Much griping about naming of Intel x86 compatible processors. Including  
desires to shoot marketing people.]

The new Cyrix chip does implement the entire i486 architecture. (If it  
doesn't, then Cyrix is being misleading.) In common parlance, people don't  
distinguish between the architecture (called i486) and the implementations  
(80486DX, 80486SX, CY486SLC, etc...). The computer buying public really  
doesn't care about the i486 architecture. To them, "486" means "fast" or  
"sleek and sexy."

The notion that computer performance be determined analytically (say by  
using relevant benchmarks) is alien to most of the PC world. Similar  
differences in performance to those of the various i486 chips can occur  
because of differences in the cache and I/O subsystems. Should we shoot  
the marketeers for calling a slow badly designed system a 486?

--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
Newsgroups: comp.arch,alt.folklore.computers
From: peter@ferranti.com (Peter da Silva)
Subject: Re: chip-on-chip technology
Followup-To: alt.folklore.computers
Organization: Xenix Support, FICC
Date: Tue, 7 Apr 1992 18:00:02 GMT

In article <1223@eouk15.abcl.co.uk> pcockere@abcl.co.uk (Pete Cockerell) writes:
> #define

> is pronounced `pound-define' (not `hash-define')

No, it's pronounced `number-define'. :->
-- 
/F { dup /Courier findfont exch scalefont setfont } def /S { show } def /L { 12
mul 36 add 36 exch moveto } def 24 F 2 L (Have you hugged your wolf today?) S
12 F 1 L (Peter da Silva, Ferranti International Controls Corporation) S
0 L (Sugar Land, TX  77487-5012;  +1 713 274 5180) S
From: ajv@roi.csd.mot.com
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 19:38:58 GMT

helz@ecn.purdue.edu (Randall A Helzerman) writes:
>I take it to mean that you can plug it right into an existing 386sx motherboard?
>If so, how much faster will it be than the old 386sx was?

If it has the timings of a i486, much faster.  A lot of the common operations
dropped from their 3-cycle-and-up timings to a single cycle.

					Andy Valencia
					ajv@roi.ca41.csd.mot.com
Xref: sparky comp.arch:4832 comp.lang.lisp:1338
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Ideas for new LISP Machines
Organization: Massachusetts Institute of Technology
Date: Sat, 11 Apr 1992 22:58:49 GMT

In article <JINX.92Apr11164830@chamarti.ai.mit.edu>
	jinx@zurich.ai.mit.edu writes:

>*	   (3) The load of register 11 is completely overlapped with other
>*	   operations, so indirect calls are not slowed by the presence of
>*	   an environment pointer.  The only cost is the extra word of memory.

>Well, I don't believe that.  The pipeline slot taken by that
>instruction is a slot that another instruction is not using;

On an RS/6000 there is a minimum of 5 cycles between loading the link
register and executing the branch target instruction.  This can be overlapped
with other instructions.  Most other architectures have a smaller number of
delay cycles in this situation (either because branches to variable addresses
are faster or because there aren't enough delay slots), so the tradeoffs are
different.

The xlc compiler calls a function to implement calls to function pointers,
so the compiler has no opportunity to schedule instructions between the
link register set and use.  gcc does the call inline.

>  When procedures are implemented as
>a structure containing an instruction address and an environment
>pointer, each procedure must have a pointer to every other procedure
>that it calls.

In the case of C, this isn't true.  The RS/6000 only needs to generate a
pointer for calls to a different module (for example, from a program to a
shared library).  The compilers generate PC-relative calls and the linker
handles the case where more is needed.

--
    John Carr (jfc@athena.mit.edu)
From: jdg@cs.man.ac.uk (Jim Garside)
Newsgroups: comp.arch
Subject: Re: And now for something completely different...
Date: 10 Apr 92 13:49:16 GMT
Reply-To: jdg@cs.man.ac.uk (Jim Garside)
Organization: Department of Computer Science, University of Manchester UK


Travis C Hayes writes :

> The traditional shift/add and shift/subtract (for division) method seems to
> be somewhat of a time waster. Could it possibly be enhanced by adding some
> extra hardware to detect when the desired result has been achieved and thus
> avoid shifting and bit testing all the remaining high-order bits (which would
> all be zero anyway after the result was achieved)? Since in many multiplies
> one of the numbers is likely to be small (bits near the msb end not set)
> this idea would seem to save some time. Any ideas? Do any architectures do
> this?

Add to the list:
SGS-Thomson (Inmos) Transputer
Two multiply instructions `mul' and `prod'.  `prod' has early termination
on small numbers (including small negative numbers on current models)
whilst `mul' does not.

Jim Garside
Newsgroups: comp.arch
From: preston@dawn.cs.rice.edu (Preston Briggs)
Subject: Re: Condition Codes and RISC arch.
Organization: Rice University, Houston
Date: Mon, 13 Apr 1992 16:44:23 GMT

>(Dale Morris) posts:
>> 
>>   if(a==b)
>>     c--;
>>   else 
>>     d+=10;
>> 
>> could be coded in PA instructions without any branches, as follows:
>> (for clarity, let me assume that a,b,c, and d are already in registers
>> 1,2,3, and 4)
>>	
>> 	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
>> 	addi	-1,r3,r3	; c <- c-1
>> 	sub,=	r1,r2,r0	; compare a and b, nullify next if equal
>> 	addi	10,r4,r4	; d <- d+10

linley@hpcuhe.cup.hp.com (Linley Gwennap) writes:
>Actually, the example can be coded in three instructions:
>
> 	sub,<>	r1,r2,r0	; compare a and b, nullify next if not equal
> 	addi,tr	-1,r3,r3	; c <- c-1, always nullify next instruction
> 	addi	10,r4,r4	; d <- d+10
>
>If a<>b, the first instruction nullifies
>the second and executes the third.  If a==b, the second instruction is
>executed, which nullifies the third.  Three cycles, no branches.

Can the compiler find either of these solutions from the source code?

Preston Briggs
Newsgroups: comp.arch
From: robert@sys.sweden.dg.com (Robert Claeson)
Subject: Re: 88K family computers?
Date: Thu, 9 Apr 1992 08:43:26 GMT
Distribution: usa
Organization: Data General AB, Akalla, Sweden

In article <4drS=mu00awU06U357@andrew.cmu.edu>, "Josh N. Pritikin"
<jpab+@andrew.cmu.edu> writes:

|> > Aydin Contols (Real-Time Workstation line)
|> > CETIA (Cetia line)
|> > Data General (Aviion line)
|> > Dolphin Server Technology (Triton lin)
|> > Encore Computer (Encore 91, Encore 93, Infinity 90)
|> > Harris (Night Hawk line)
|> > IPC Corp (IPC Serve 88000)
|> > McDonnell Douglas (Series X line)
|> > Modcomp (Real/Star Modcomp line)
|> > Motorola (Delta Series 8000 line and MPC line)
|> > OMRON (Luna-88k)
|> > Sanyo Icon (SI line)
|> > Unisys (S/8400)
|> 
|> So which of these are actually making workstations or minicomputers?

I'm pretty sure that Data General makes workstations AND servers (or call
them minicomputers if you want) -- I'm typing this into mxrn on a
workstation talking to an NNTP server on a server host. Dolphin makes
servers as do Encore and Motorola. Omron makes at least workstations (nice
ones). I THINK that Harris makes servers (they may do workstations as well;
please correct me if I'm wrong) as do McDonnel Douglas. The Unisys machine
is said to be a server-class system.

-- 
Robert Claeson            Internet: robert@sys.sweden.dg.com (the world)
Data General AB                     robert@sys.dg.se (preferred for
Europe)
Box 28                    Tel: +46 (0)8-92 55 00
S-164 93 KISTA, Sweden    Fax: +46 (0)8-751 36 22
Newsgroups: comp.arch,comp.lsi.cad
From: inyup@python.icsl.ucla.edu (Inyup Kang)
Subject: Asynchronous VLSI Design.
Followup-To: comp.arch
Organization: UCLA Integrated Circuits & Systems Laboratory
Date: 4 Apr 92 07:47:36 GMT


Hi, folks.

I'm going to start do research on the asynchronous VLSI design, 
somewhat biased to Signal Processing (because it's my schools emphasis),
and hopefully write the result on this research on my Ph.D. dissertation.
I have read the Seitz's, Sutherland's, and Jacobs'.
But not yet Molnar's (blame me for my laziness).
My question is 
	"The Asynchronous Stuff is still alive and remain fancy?"
	"Anybody do research on this topic?"

Any your help will be appreciated.
Please, reply to my e-mail address, then I will post the current status
of this stuff.

Take care of everything.
--
 Inyup Kang // inyup@icsl.ucla.edu, ..!(uunet,ucbvax)!icsl.ucla.edu!inyup
From: sproven@cs.strath.ac.uk (Simon B Proven IE91)
Newsgroups: comp.arch
Subject: Re: Condition Codes and RISC arch.
Date: 8 Apr 92 13:25:20 GMT
Distribution: comp
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.

In article <1992Apr06.192940.169927@rrz.uni-koeln.de> se@IKP.Uni-Koeln.DE (Stefan Esser) writes:
>In article <1992Apr4.173725.11509@vax5.cit.cornell.edu>, r4ty@vax5.cit.cornell.edu writes:
>|> 
>|> would now be compiler like this:
>|> 
>|>        cmp a, b
>|>        dec.eq c
>|>        add.ne 10, d
>
>Hmm, does 'dec.eq c' clear the ZERO flag if 'c' comes out != 0 ???
>Then 'd+=10' would be errenously executed after decrementing 'c' ...
>
>... just to remind you, that conditional execution has its advantages,
>but can't be applied everywhere ...

Well the ARM designers thought of this.  In the ARM IS for all data
operations, there is an "S" bit which controls whether the instruction
will update the flags or not.  Thus the ARM version of that code is:

	CMPS a,b
	SUBEQ c,c,#1
	ADDNE d,d,#1

However with CMP, the S option is omitted as it is implied for CMP

>Some questions:
>
>Does the ARM processor set the flags after each instruction, or after 
>each arithmetik operation (like intel processors) or after operations 
>working on 'data' registers (like the 68k family) ?

It sets the flags only on data instructions and a certain subset of
load instructions (where the destination is the PC, as the flags are
held within the PC).

>Is there any processor that has a general 'set condition codes' bit
>in each instruction ?

The ARM has the 'set condition codes' bit on all data operations and
on LDM (LoaD Multiple) operations.  If a ^ is added after LDMFD R13!,{PC}
then the instruction will load both the PC and the flags from the
stack otherwise just the PC will be loaded.  For all data ops, the
S bit is allowed.

>-- 
> Stefan Esser,  Institute of Nuclear Physics,  University of Cologne,  Germany
> se@IKP.Uni-Koeln.DE                                           [134.95.192.50]

+-- Simon "Mad@Bike" Proven ---------------------------------------------+
|- _ -  - _ -   .__o    /  <sproven@cs.strath.ac.uk> or                  |
|-  -  - _ -  _-\_<,   /   <caa650@ccsun.strath.ac.uk>                   | 
\____________(*)/'(*)_/____Real_peeps_ride_bike_:)_______________________/
Xref: sparky comp.arch:5059 comp.ai:2017
From: bae@Auspex.COM (Brian Ehrmantraut)
Newsgroups: comp.arch,comp.ai
Subject: Re: Voice Recog. on Desktop
Date: 15 Apr 92 21:54:25 GMT
Followup-To: comp.ai

In article <1992Apr15.172528.30412@alliant.com>, tj@alliant.com (Tom Jaskiewicz) writes:
> The first company with the hardware/software to allow a driver to "write"
> memoes is going to make a lot of money.

	Think appropriate technology.

	It's called a dictaphone, and it's $30.00 at your local personal
electronics pusher.  

		:-)

-- 
		Brian A. Ehrmantraut

BELL:   voice:(408) 492-0900  fax: (408) 492-0909  
USnail:	Auspex Systems, 2952 Bunker Hill Lane, Santa Clara, CA 95054
From: odkahn@eos.ncsu.edu (OPHER DANIEL KAHN)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 14:30:50 GMT
Organization: North Carolina State University

> i think the cyrix chip is more like a 386sx with extra 486 features added
> (i.e. any extra instructions etc) a 486 style (but smaller) cache
> and, doubtless, more efficient implementation of existing instructions
> (e.g. a dedicated multiplier core i think). its packaged like a 386sx
> as there are an awful lot of those out there and many people might
> like a 250% performance improvement for what is not much more than
> a chip swap.
|> david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 625

That sounds great, but the way I understand it they get 50-70%
performance improvement when running small code segments out of the
1K cache, and only 20-40% on larger applications (this is over a 
25MHz 386SX).  That's a far cry from the 250% you talk about...
*************************************************************************
Opher D. Kahn                       <<            Why Me?              >>
NC State University                 <<                                 >>
odkahn@eos.ncsu.edu                 <<    Why Not You For A Change?    >> 
*************************************************************************
From: des@frogland.inmos.co.uk (David Shepherd)
Newsgroups: comp.arch
Subject: Re: Cyrix 486
Date: 7 Apr 92 12:52:50 GMT
Organization: INMOS architecture group

In article <1992Apr6.131334.22658@cis.uab.edu>, hyatt@cis.uab.edu (Robert Hyatt) writes:
>I am confused here.  The 386sx has only 24 bits worth of address lines (16mb
>real address space) as opposed to the 386dx with it's 32 bit addressing (again,
>real addressing not virtual which both are equal at).  The 486sx is not a
>pin-compatible chip to the 386sx (both Intel chips here, not AMD) as the 486sx
>is still a full 32-bit address bus chip.  Does this mean that AMD has built
>a 486-compatible chip with only a 16mb real memory addressing capability?  Seems
>foolish if they did.

i think the cyrix chip is more like a 386sx with extra 486 features added
(i.e. any extra instructions etc) a 486 style (but smaller) cache
and, doubtless, more efficient implementation of existing instructions
(e.g. a dedicated multiplier core i think). its packaged like a 386sx
as there are an awful lot of those out there and many people might
like a 250% performance improvement for what is not much more than
a chip swap.

--------------------------------------------------------------------------
david shepherd: des@inmos.co.uk or des@inmos.com    tel: 0454-616616 x 625
                inmos ltd, 1000 aztec west, almondsbury, bristol, bs12 4sq
		"i speak latin to god,   spanish to men,   french to women 
		 and german to my horse."             - charles v of spain
Newsgroups: comp.arch
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Use of "crashme"
Organization: Intel Corp., Hillsboro, Oregon
Date: Tue, 14 Apr 1992 23:27:15 GMT

    >> ........  Nea[r]ly every company that came out with a machine running unix,
    >> ported the code, bugs and all, and presumably did not fix the bugs because of
    >> the fear of being struck by a lightning bolt from the unix gods...
    > 
    >   ... or because they do not have the resources to re-fix these bugs each
    >   time they receive a new port... there's enough to do in that realm 
    >   already, I presume, with X, NFS, etc..

    ... Hmmm, I wonder....   Do these 'resellers', when they detect and/or fix
    a bug, bother to report said bug to *their* supplier, so that the _originator_ 
    of said bug can fix it?   Any re-sellers wish to comment on this?

I formerly worked at Gould CSD, working on a BSD based UNIX system
which was one of the first outside-of-SUN ports of NFS, and later at
Motorola MCD on SVr4.

I can assure you that we *did* detect/fix bugs, and report them to our suppliers:
    BSD
    AT&T
    SUN

Berkeley was the only group that was at all willing to accept fixes from outside.

Both AT&T and SUN had a great big "Not Invented Here" attitude - they
would refuse to accept fixes, or fixes would go into a big black hole,
or the next release would have "fixed" the bug you reported, but with
code different from what you reported - and their fix wouldn't be
correct, or...

Hell... one fellow added comments to a rather abstruse code section,
and they were not allowed to be added to the next official release.

--

Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497

This is a private posting; it does not indicate opinions or positions
of Intel Corp.

Intel Inside (tm)
Newsgroups: comp.arch
From: rcarter@gaudi.nas.nasa.gov (Russell L. Carter)
Subject: Re: PFLOP cooling reqs WAS Re: Cray Soap Opera
Keywords: Alpha, Gallium Arsenide
Organization: NAS, NASA Ames Research Center, Moffett Field, CA
Date: Wed, 8 Apr 92 21:33:25 GMT

In article <1992Apr8.143114.1926@craycos.com> sog@craycos.com (Steve Gombosi) writes:
>In article <1992Apr8.042130.23242@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>>In article <1992Apr06.174145.10353@skynet.uucp>, ice@skynet.uucp (Ice) writes:
>>|> Cray 2 was the hottest
>>|> thing back then; all of 1 billion MFLOPS at peak. 
>>                             ^^^^^^^^^^^^^^
>>That's pretty good. I wonder why the MITSF switched to an XMP if they had a
>>machine doing 1000 TFLOPS? :-)
>
>It was a health hazard. With the clock rate needed to achieve that FP
>performance, the damned thing was radiating UV like crazy ;-).
>
>Steve Gombosi
>sog@craycos.com

Just think of how many houses you could heat with it, though. ;-)

Russell
Newsgroups: comp.arch
From: bgoffe@seas.smu.edu (Bill Goffe x3806)
Subject: Reference on Future Computing Performance?
Organization: School of Engineering and Applied Science
Date: Fri, 10 Apr 1992 01:11:09 GMT

I'm finishing up a paper and I'd really like to include a reference
to predictions of future computing power on the desktop. I've been
been using Gordon Bell's article in the Communications of the ACM,
September, 1989, but it is becoming dated. To be precise, the last 
date he made a prediction for is 1992 (on the Linpack 100x100, double
precision, he predicted 20mflops standard, 200mflops w/ vector unit).

Can anybody point me to something later that covers the mid to late
1990s?

Bill Goffe
bgoffe@zebra.seas.smu.edu
From: borella@toadflax.UCDavis.EDU (Mike Borella)
Newsgroups: comp.arch
Subject: Parallel Machine trace data
Date: 16 Apr 92 23:22:39 GMT
Reply-To: borella@cs.UCDavis.EDU (Mike Borella)
Organization: UC Davis, EECS Division of Computer Science


I'm looking for trace data on memory access for parallel 
machines.  Basically anything will do, but in specific,
I'm looking for traces of parallel program execution on a 
multi-processor, multiple memory module machine.  Traces in 
any form would be fine.

If you have data that you'd be willing to share, or know
of a place I could find some, please email me.

-Mike Borella
 borella@cs.ucdavis.edu
From: shap@xanadu.com (Jonathan Shapiro)
Newsgroups: comp.arch
Subject: Re: Ideas for new LISP Machines
Date: 15 Apr 92 06:49:30 GMT
Article-I.D.: xanadu.1992Apr15.064930.15358
Organization: Xanadu Operating Company

In article <Apr.11.06.57.22.1992.8365@brushfire.rutgers.edu> gaynor@brushfire.rutgers.edu (Silver) writes:
>leinen> The transition to 64bit-addressing that has just started seems like a
>leinen> good opportunity to convince chip designers that this makes sense.

Well, yes and no.

There is another question worth asking in the course of this
discussion, namely: what features should be included in a general
purpose architecture that are general purpose features with particular
utility to the LISP community, and break the universe if absent.

For example, certain processors (e.g. i386) have no mode in which they
fault on unaligned references.  This is fine for conventional
programs, but prevents LISP systems from using the low order bits as a
two-bit type tag (assuming 32 bit LISP model).

On the 486, and on some other processors, there is a user-settable
mode bit that allows the user to say that they want to fault on
unaligned references even though the architecture could handle it.
This was added, I understand, specifically for support of tagged types
(though in a smart hardware implementation this bit could bypass a
at least one and maybe two clocks worth of fetch logic per load).

I've looked at a bunch of code generation options for LISP math, and
no code has yet convinced me that type tags are a win on architectures
that can do the low address fault.

Anyone able to show otherwise?

FYI, on the SPARC architecture, the LISP vendors have stopped using
the tagged math instructions.  The tag bit code turned out to be the
wrong choice.  SPARC chose 00 as the fixnum code, which really wants
to be a pointer tag.

Franz, Lucid therefore (I understand) use the alignment trick.
Newsgroups: comp.arch
From: sson@bones.caedm.byu.edu (Stacey Son)
Subject: Re: 88K family computers?
Date: Fri, 10 Apr 92 12:05:12 MDT
Organization: Brigham Young University, Provo UT USA
In-reply-to: ggw@wolves.uucp's message of Thu, 9 Apr 1992 16:20:35 GMT
Reply-To: sson@ee.byu.edu
	<4drS=mu00awU06U357@andrew.cmu.edu> <1992Apr9.162035.24485@wolves.uucp>
Distribution: usa

>>>>> On Thu, 9 Apr 1992 16:20:35 GMT, ggw@wolves.uucp (Gregory G. Woodbury) said:
Greg> X-Md4-Signature: a2f74ffbd21b23e5db374ba372d7f227

Greg> The Encore machines are "high-end" mini or mainframe type computers, as
Greg> is the (unlisted) Tadpole board product.   I could NOT get a response
Greg> from Sanyo/Icon about their products.


Sanyo/Icon makes (or did make) mini multiuser servers that runs UNIX.
We have some of their outdated 68020 based models stored in our
computer junk room.  They where going to give us one the 88K based
models but they run into money problems.  I believe they are still
around but most of their good engineers have left the company.

--
Stacey D. Son                           459 Clyde Building      
Operations Manager                      Provo, UT 84602
Brigham Young University                Voice:(801)378-5950 FAX:(801)378-6586
College of Engineering & Technology     Email: sson@ee.byu.edu
From: tom@ssd.csd.harris.com (Tom Horsley)
Newsgroups: comp.arch
Subject: Re: Generic Top Secret Microprocessor Development Plan
Date: 14 Apr 92 12:52:42 GMT
	<1992Apr9.132601.11541@decuac.dec.com> <411@idtg.UUCP>
	<DOCONNOR.92Apr12223346@pima.inews.intel.com>
Organization: Harris Computer Systems Division
In-reply-to: doconnor@pima.inews.intel.com's message of 13 Apr 92 05:33:46 GMT

>>>>> Regarding Re: Generic Top Secret Microprocessor Development Plan; doconnor@pima.inews.intel.com (Dennis O'Connor) adds:

doconnor> Especially if the package has 800 pins, with a diamond substrate
doconnor> and freon channels to duct away the 200 watts of power the chip
doconnor> dissipates ! :-)

Actually, this seems ideal for a toaster. Just mount the chip inside the
box right next to the bread...
--
======================================================================
domain: tahorsley@csd.harris.com       USMail: Tom Horsley
  uucp: ...!uunet!hcx1!tahorsley               511 Kingbird Circle
                                               Delray Beach, FL  33444
+==== Censorship is the only form of Obscenity ======================+
|     (Wait, I forgot government tobacco subsidies...)               |
+====================================================================+
Newsgroups: comp.arch
From: staylor@fudd.rtp.dg.com (Steve Taylor)
Subject: Re: chip-on-chip technology
Date: Tue, 14 Apr 92 17:05:35 GMT
Organization: Data General Corporation, RTP, NC.

>As near as I can tell, flip-chip (solder bump technology) has pretty much

Isn't Flip-Chip still a registered trademark of Digital Equipment for
their convenient line of logic-functions-on-a-circuit-board products, 
introduced in the early sixties?
From: tmm@dvnspc1.Dev.Unisys.COM (Tim McCaffrey)
Newsgroups: comp.arch
Subject: Re: Tagged Architectures.
Date: 10 Apr 92 17:20:20 GMT
Organization: Unisys Corporation, Devon Engineering Offices

The Burroughs Large Systems (B5500 to B7900) from the 60's, 70's and
early 80's have now been succeeded by the Unisys A Series.  The largest
of these systems, the A19, out performs the largest IBM mainframes.


				Tim McCaffrey