HDTenEightyP/NetNews huggingface dataset:
From: mcvey@mpr.ca (Iain McVey)
Newsgroups: comp.arch
Subject: Re: Request Info Re Bus Trends & Intel 486s
Date: 28 Jul 92 18:03:50 GMT
Organization: MPR Teltech Ltd., Burnaby, B.C., Canada

In article <id.SLUR.RBG@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>> I think the important word here isn't "better", it's "cheaper."  With
>> motherboard, it's easier to put your system in a smaller box, use less
>> board space, and fewer connectors.  All that adds up to lower production
>> costs.
>
>This is true for systems that are essentially single-board-computers with
>expansion slots, like the Amiga 3000 or the typical Mac. In the PC world,
>though, you almost always have at least one or two cards in every system
>shipped: so you're using as much board space and as many connectors as a
>backplane design... plus making upgrades harder and more expensive.

I think it interesting that the motherboard has come full circle.

Remember the PC with its main memory and processor on the motherboard,
with peripherals such as serial and parallel ports and video adpaters on
expansion cards.

Now if you look inside a PS/2 model 95 et. al. you see that the
processor is on a card, the memory is on a card, and now the peripherals
have become part of the motherboard - built in serial, parallel, video,
mouse, etc.

It seems that the motherboard in this case has become a backplane, with
the bus controller and basic services on that backplane.

If there is too much overhead in the connections to the backplane, then
is it not a problem with the method of connection, not the idea of
connection?

- Iain -
-- 
Iain McVey (mcvey@mprgate.mpr.ca)   | -  Now auditioning for a new .sig
Software Designer                   | -  Entrys must be posted no later
MPR Teltech Ltd.                    |    than next thursday.
8999 Nelson Way, Burnaby, BC        | -  no agents, please.
Newsgroups: comp.arch
From: danw@hobbes.prime.com (Dan Westerberg)
Subject: Re: What's in a name?
Organization: Prime Computer
Date: Tue, 21 Jul 1992 04:02:16 GMT

In article <1992Jul20.092822.7666@spool.cs.wisc.edu>, mfrank@wilma.cs.wisc.edu 
(Matt Frank) writes:
> 
> Backwards compatability has always been a particular pet peeve of mine, so I
> feel the need to add my two cents worth.  I have two specific problems.
> 
[Text on problems deleted]

Backwards compatability is definitely a pain in the butt.  I've spent the last
3 years designing a new CPU for a proprietary architecture (Prime 50 Series)
that was originally a copy of a Honeywell machine from the early '70s.

However, Prime Computer has a strict compatability policy; with some minor 
exceptions, code written for one of our machines 15 years ago will still run 
today! This makes a very strong selling point to our customers, who potentially
have millions of dollars invested in our hardware/software.  Also, it keeps me
employed! :-)

If we were to say to our customers that their software would no longer be
compatible with a new machine, we would quickly lose our installed customer
base.  At that time, it would make sense for a customer to begin investigating
the benefits/tradeoffs associated with switching operations to an alternative
hardware platform (be it another proprietary system or a Unix system).  

So long as our hardware/software continues to perform the job expected by
our customers, they will stay loyal to our product line, since upgrading means
no down-time associated with training or porting of software/databases.

From an architectural point of view, I would *love* to start with a clean slate
and design a complete system with full flexibility of the instruction set and
it's capabilities.  However, the economics of the situation do not warrant such
a bold move.  I believe the original IBM PS/2 with the MicroChannel Architecture
is an excellent example of abandoning an installed customer base.

Just two cents worth from a CPU designer mired in backwards compatability. :-)

Dan W.

> 
> -Matt Frank (mfrank@cs.wisc.edu)
> My opinions are my own and may not be those of my employer (or anybody else
> for that matter).

ditto on opinions :-)!

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~  "These walls that still surround me      ~                                 ~
~   Still contain the same old me           ~     Dan Westerberg              ~
~   Just one more who's searching for       ~       danw@hobbes.prime.com     ~
~   The world that ought to be"             ~                                 ~
~                             - Neil Peart  ~  Prime Computer, Framingham, MA ~
~                                           ~                                 ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: narad@nonsequitur.Eng.Sun.COM (Chuck Narad)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 28 Jul 92 00:43:39 GMT
Reply-To: narad@nonsequitur.Eng.Sun.COM
Organization: Sun Microsystems
NNTP-Posting-Host: nonsequitur

davsmith@nic.cerf.net (David Smith) writes:
> All CPUs I have seen to date (not every CPU by any means - if you know
> of counter examples, please post) cannot do asynchronous address
> generation.  When they request a word of memory they want it *NOW* or
> within a cycle or two and will block until it arrives.
>

In a previous life I worked on a machine called the Culler-7 at (now
defunct) Culler Scientific Systems in Santa Barbara.  It was basically
an asymmetric machine with a RISC-like engine that did address
computation, scaler computation, program flow control, and data
scheduling (the A machine); and a CISC, microcoded FP engine with a
different register set, PF ALU and MPY units, a vector memory with
address stride engines, and a few other whizzy and interesting features
(the XY machine).  These days that structure is called VLIW; back then
we just called it wonderful :-)

The A and XY machines shared an instruction stream, but A was
single-cycle and XY was multi-cycle at the mercy of the u-Code.  A
scheduled data reads and writes to the main memory system, and both A
and XY could either consume read data or source write data.  The data
read FIFO was 3 deep (and the memory pipeline was 3 clocks plus
potential bus arbitration) so it was possible to schedule data way in
advance of the time it was used, if desired.  The compiler was able to
take advantage of this both for streaming vector data and for
preplanning much on the non-vectorized data accesses.

chuck/

disclaimer: speaking for myself, not for my emplyoer
Newsgroups: comp.arch
From: bs@gauss.mitre.org (Robert D. Silverman)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Research Computer Facility, MITRE Corporation, Bedford, MA
Date: Thu, 30 Jul 1992 14:04:43 GMT

In article <55535@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
 
There was a sequence of attributions. It is hard to keep track of who said what......

:>> >I'm glad you noticed it. We're agreed then that these idiot savants generate
:>> >code that is as fast as a human can write, if not the same sort of code. 
:>
:>> This is not always the case.  It is quite possible that a simple idea which
:>> a human can see is not within the category of those known to the compiler.
:>> No compiler can change the algorithm to one that it does not know about.
:>> I can, and do.
:
:>Yes, I quite agree, different problem spaces demand different algorithms for
:>solution. However, and this is the key point, it is (in 1992) extremely rare
:>that you encounter a constraint on the problem space due to the hardware that
:>has any significant effect on the choice of algorithm. Things like 64K segment
 
Oh contraire. Many modern RISC processors lack basic instructions to do
integer multiplication or division. [e.g. i860, Sparc (not Viking)] and
some others support 32 by 32 bit multiply --> 64, but not 64 by 32 bit divide.
This can have a STRONG influence on any sort of algorithm that requires 
multiple precision arithmetic.

:>limits, massively parallel hardware, or the absence of a FPU... yes. Things
:>like the presence or absence of autoincrement addressing... no. It's been many
 
As I said above: what about lack of integer multiply? A processor that can't 
do basic arithmetic is brain dead IMO.

--
Bob Silverman
These are my opinions and not MITRE's.
Mitre Corporation, Bedford, MA 01730
"You can lead a horse's ass to knowledge, but you can't make him think"
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Date: 24 Jul 92 13:27:59 GMT
Organization: Purdue University Statistics Department

In article <GLEW.92Jul23181843@pdx007.intel.com> glew@pdx007.intel.com (Andy Glew) writes:

>    Maybe true. But for a user, should he buy one $2000 21064 chip or another
>    two $1000 CY7C601!?

>This is a rather bogus discussion.

>The assumption seems to be implicit that, given the same technology,
>etc., a 64 bit architecture implies twice the performance of a 32 bit
>architecture.

>That's blatantly untrue, since the overwhelming majority of applications
>fit quite nicely into 32 bit address and data quantities, so from this
>point of view 32 = 64.

Of course it is blatantly untrue, unless you can do the 64-bit operations
and accesses as fast as 32 bit ones.  On at least one machine I am now
using, nobody should ever use the "single precision" (really half
precision) floating point arithmetic, because the hardware always
converts to double and then back, unless memory is at a drastic premium.

>There may be some applications that can benefit from >32 bit virtual
>addresses, e.g. the 40 bit virtual addresses of the MIPS R4000. I'm
>tempted to say that this implies 32 = 4/5 40, but of course there is
>overhead in evaluating extended precision arithmetic. The overhead may
>be more than 2x.  But then you have to downgrade that by the ratio of
>time spent manipulating such addresses.

>Finally, there are some applications that benefit from simply having
>larger integers.  John Mashey has mentioned robotics as one such area
>(although I have talked to robotics manufacturers who take a
>completely different approach). But, once again, you have to prorate
>the speedup according to the importance of the code being executed.

It is clear that you do not do any type of "honest" integer arithmetic,
or you could not possibly take this view.  

It would be rare indeed for a 32-bit machine to be able to do 64-bit
arithmetic at anywhere near the speed of a 64-bit machine.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch
From: bernie@metapro.DIALix.oz.au (Bernd Felsche)
Subject: Re: Request Info Re Bus Trends & Intel 486s
Keywords: Intel 486 Bus
Organization: MetaPro Systems, Perth, Western Australia
Date: Mon, 27 Jul 92 01:38:14 GMT

In <id.TJRR.XR8@ferranti.com> peter@ferranti.com (peter da silva) writes:

>In article <1992Jul20.003506.23290@theus.rain.com>
>  john@theus.rain.com (John Theus) writes:
>> However, Futurebus+ is a backplane bus, not a desktop bus. [...]

>Why is it that backplanes aren't more common on the desktop? Even for the PC

In a word: "$"

There are secondary reasons but....

It's more expensive to produce a processor board to plug
into a backplane, especially when the current technology
requires more real estate than that available withing the
standard form factor. This leads to complications such as
"overhead" connectoions to provide those signals which the
backplane bus does not pass.

You can do it without overhead connections, even with
"primitive" technology, by careful division of functional
blocks and archtecture design. However, it costs more to
make it that way than all on the one motherboard.

>world, they're available (under the ugly name "passive motherboard"), and until

Yes, you can now get a PC on a card to plug into a
backplane, but only because the technology is now available
and reasonably cheap.

>the IBM-PC came out they were the norm for multi-board systems (you had either
>single-board CPUs or S100 or equivalent). The only exception was the Apple II,
>and then the IBM-PC. Is it just tradition or is there something that makes a
>motherboard system inherently better?

I too would like to see the return of the desktop backplane,
but I know that I'm in the 5% (or less) minority of the
market which knows the advantages and doesn't mind paying a
small price to have them available.
-- 
+-----+ Bernd Felsche                     _--_|\  #include <std/disclaimer.h>
| | | | MetaPro Systems Pty Ltd          /      \ bernie@metapro.DIALix.oz.au
| | | | 328 Albany Highway,              X_.--._/         Fax: +61 9 472 3337
|m|p|s| Victoria Park, Western Australia 6100  v        Phone: +61 9 362 9355
Newsgroups: comp.arch
From: ed@weir.pa.dec.com (Ed Gould)
Subject: Re: 64-bit CPU vs 2 x 32-bit CPUs
Keywords: pins
Reply-To: ed@pa.dec.com
Organization: DEC Network Systems Lab, Palo Alto
Date: Sun, 26 Jul 92 04:45:48 GMT

> Since the DEC 21064 Alpha chip only supports 43-bit effective virtual
> addresses, the cost is approximately 43-32=11 pins.

According to the data sheet I have, the 21064 implements 43-bit virtual
addresses (even though all 64 bits are checked), but only 34-bit
physical addresses.  Hence, it's only *two* pins.  I can't imagine that
that's particularly significant.

--
Ed Gould	  ed@pa.dec.com		Digital Equipment Corporation
+1 415 688 1309	  Network Systems Lab	505 Hamilton Ave, Palo Alto, CA  94301

"Unison is only one form of harmony." -- LW
Newsgroups: comp.arch
From: rschnapp@metaflow.com (Russ Schnapp)
Subject: Re: SuperSPARC doesn't need superscalar compiler?!
Organization: Metaflow Technologies Inc.
Date: Wed, 22 Jul 1992 16:28:30 GMT

In article <MOSS.92Jul21091941@ibis.cs.umass.edu>, moss@cs.umass.edu (Eliot Moss) writes:
|> >>>>> On 21 Jul 92 01:42:07 GMT, lycmit@X1SUN6.CCL.ITRI.ORG.TW (Yin-Chih Lin)
|> >>>>> said:
|> 
|> Yin-Chih> ... one of the Sun Micro employees had adverted that the SuperSPARC
|> Yin-Chih> (superscalar SPARC which can issue 3 intructions at max performance)
|> Yin-Chih> does not require the superscalar compiler to obtain the best CPU
|> Yin-Chih> performance.
|> 

|> Of course, you are right that in general a good schedule for a non-superscalar
|> may not be the best schedule for a superscalar that does not have enough
|> resources available on each cycle. For example, a non-superscalar might be
|> able to issue one register to register multiply every cycle, given one fully
|> pipelined multiplier. A superscalar that issues N instructions per cycle would
|> need N fully pipeined units to guarantee not to stall, but most code probbaly
|> does not need N fully pipelined multipliers.
|> 

...and there are other reasons why issue might stall on a superscalar
machine.  Even if there were, for instance, three multipliers, a conventional
superscalar machine could not issue the following sequence in a single frame:

	smul %g1,%g2,%g3
	smul %g3,%g4,%g3
	smul %g3,6,%g1

(i.e., calculating %g1 * %g2 * %g4 * 6).  There are a couple of kinds of
data hazards here.  While this is a very contrived example, it points out
one of the additional intricacies of generating code for conventional 
superscalar processors.  

There are, of course, solutions to superscalar design that allow
unrecompiled code to execute at a very substantial performance
improvement...

---

...Russ Schnapp
                        Email: uunet!metaflow!rschnapp or rschnapp@metaflow.com
Metaflow Technologies   Voice: 619/452-6608x230;  FAX: 619/452-0401
La Jolla, California    Unless otw specified, I`m speaking only for myself!
Newsgroups: comp.arch
From: eletanjm@nuscc.nus.sg (TAN JIN MENG)
Subject: BUSES
Organization: National University of Singapore
Date: Thu, 23 Jul 1992 09:22:11 GMT

I'm a tyro in this group. So please be gentle ;-).

I'm just wondering...

With all this talk about current and future buses for desktop machines
(EISA, TurboChannel etc), a lot of concern seems to be on the speed of
the bus (as opposed to for example interrupt/device management or the
ability to use different speed devices efficiently).

It seems to me that many if not most applications do not need (relatively 
speaking) such a high bandwidth. Even with an application such as FDDI, 
the bandwidth is shared by many machines anyway and also software bottleneck 
becomes more significant at those speeds. 

Software controls the rate at which you exercise the bus at these high speeds.
Also, if I get my file within 0.5 sec as opposed to 1.0 sec, will I
notice enough to pay for the hardware? 

Aren't there other aspects of system design (including software) that we
should look at to get optimum cost/benefit? 

Faster is always sexier I know.

Anyone care to have a go?

jin meng

PS. I admit that there will be always a need for high speed buses for
special purposes. I am talking more about general desktop machines.
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.arch
Subject: Re: Sun 600MP Benchmark Anomaly
Date: 27 Jul 92 15:55:59 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <JIM.92Jul24155432@hunter.cs.strath.ac.uk>, jim@cs.strath.ac.uk (Jim Reid) writes:

| So does this mean that this "symmetrical multi-processor SunOS" isn't
| really what it claims to be? If only one CPU at a time can be executing 
| interrupt service code, what we've got is an OS with one dedicated
| (but not fixed) I/O processor.

The post from Sun seemed (to me) to indicate that there were problems
with the current kernel, but that the hardware allowed ints to be
dispatched to any processor. I read that as allowing multiple processors
to service interrupts, assuming that the software sets the "next int"
register to another processor.

There are tradeoffs to having multiple processors handle interrupts, and
if the latency is low enough with one processor you are possibly better
off with using only one and avoiding all the context switches. If one
can't keep up, then you will have to take the CS overhead and use them
all. I'm reassured that Sun has left this open to software change, and
I'm sure if people complain about how it works in Solaris 2.0 Sun will
change it.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
	It never ceases to amaze me that otherwise rational people, able to
	understand calculus, compound interest, and the income tax form, can
	continue to believe that poker is a game of chance.
Newsgroups: comp.arch
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: What's in a name?
Date: Sun, 26 Jul 1992 00:52:48 GMT
Organization: U of Toronto Zoology

In article <1992Jul25.075130.7192@spool.cs.wisc.edu> mfrank@wilma.cs.wisc.edu (Matt Frank) writes:
>Both the Apple ][ and Mac are examples of non backwards compatible products
>enjoying great success.  So are CD players.  Although it was before my time,
>aren't CP/M, minicomputers, DB2 and UNIX other examples?

Some of these examples aren't really backward compatibility, because there
was no previous base to be compatible with.  Minicomputers, for example,
mostly went into applications or organizations that had never been
computerized before.  It wasn't that common to see applications moved off
mainframes onto minis (although it did happen).

CDs are a good example of the basic rule for breaking backward compatibility:
it has to be worth it.  A quick rule of thumb is that an incompatible system
has to be an order of magnitude better to convince most people to convert.
Incremental improvements aren't enough.  CDs give better sound, yes, but
most people were reasonably happy with the sound from a good turntable.
CDs won because they have better sound, *and* they don't wear out, *and*
their physical form is more convenient, *and* they hold more, *and*
neither they nor their player needs much in the way of cleaning or regular
replacement, *and* you don't have to flip them over halfway through, *and*
they make convenient and powerful digital remote controls easy.  None of
these things by itself is an order of magnitude, but the combination is.

If you want to see bad backward-compatibility constraints, look at the
phone system.
-- 
There is nothing wrong with making      | Henry Spencer @ U of Toronto Zoology
mistakes, but... make *new* ones. -D.Sim|  henry@zoo.toronto.edu  utzoo!henry
Newsgroups: comp.arch
From: dag@ossi.com (Darren Alex Griffiths)
Subject: Re: what is a non-split transaction bus called?
Organization: Open Systems Solutions Inc.
Distribution: na
Date: Fri, 24 Jul 1992 20:47:48 GMT

noah@cs.washington.edu (Rick Noah Zucker) writes:


>P.S. Unless you have a reason to, please just use e-mail.

I'd also be interested in the answer, so know you have a reason to post

   Cheers,
    --dag
_______________________________________________________________________________
Darren Alex Griffiths               | dag@nasty.ossi.com
Open Systems Solutions, Inc         | (510) 652-6200 x139
Fujitsu                             | Fax: (510) 652-5532
6121 Hollis Street                  | Berkeley is famous for two exports
Emeryville, CA 94608-2092           | LSD and unix, this isn't a coincidence.
_______________________________________________________________________________
From: rrt@mpd.tandem.com (Robert Teisberg)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 23 Jul 92 15:09:27 GMT
Article-I.D.: devnull.2105
Reply-To: rrt@amadeus.UUCP (Robert Teisberg)
Organization: /etc/organization

In article <2369@nic.cerf.net> davsmith@nic.cerf.net (David Smith) writes:
>All CPUs I have seen to date (not every CPU by any means - if you know
>of counter examples, please post) cannot do asynchronous address
>generation.

The CDC 6600 and its descendants did this (why does it seem that every
clever idea in machine architecture was invented many years ago by
Seymour Cray :-).  To load from memory, you stuffed an address in
register A1, A2, A3, A4 or A5 and sometime later the contents of that
address appeared in the corresponding X register.  To store, you
stuffed an address in A6 or A7 and eventually the contents of X6 or X7
found its way to memory at that address.  As I recall (do any other
old CDC hands know better?), the only reason the CPU stalled due to
memory access was a scoreboard conflict or a memory bank conflict.  If
your memory access pattern was either sequential and contiguous or
random, bank conflicts were rare, since the 6600 used interleaved
memory just as davsmith recommends elsewhere in his article.

-- 
Bob Teisberg @ Tandem Computers, Inc. | rrt@mpd.tandem.com
14231 Tandem Blvd.                    | (512) 244-8119
Austin, Texas  78728                  |
Any resemblance to the opinions of a real person or corporation is concidental.
From: mash@mips.com (John Mashey)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 24 Jul 1992 22:49:15 GMT
Organization: MIPS Computer Systems, Inc.
NNTP-Posting-Host: winchester.mips.com

In article <nmcad0g@rhyolite.wpd.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>>                      .  How about other worlds?  Which is more common,
>> cache coherent or cache incoherent I/O?  I believe John Mashey already
>> noted that on the R3000 I/O was non-coherent, but on the R4000 I/O is
>> coherent.

>Without intending to contradict John, since I don't recall what he
>wrote, please note that not all currently shipping R4000 systems have
>coherent I/O.

I don't remember saying exactly this.
1) R3000 systems can be built with or without coherent I/O.
2) R4000 systems can be built with or without coherent I/O.

3) People have usually tended to build uniprocessors without coherent
I/O, for simplicity & lower cost, and multicprocessors at least
sometimes with coherent I/O, to avoid complex cache flushing.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
DDD:  	408-524-7015,  or 524-8253
USPS:	(soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
Xref: sparky comp.arch:8380 alt.folklore.computers:11281 comp.benchmarks:1200