Path: utzoo!attcan!uunet!lll-winken!lll-tis!oodis01!uplherc!sp7040!obie!wsccs!terry
From: terry@wsccs.UUCP (Every system needs one)
Newsgroups: comp.arch
Subject: Re: Today's dumb question...
Summary: You neglect one thing
Message-ID: <533@wsccs.UUCP>
Date: 17 May 88 02:42:19 GMT
References: <503@xios.XIOS.UUCP> <2676@pdn.UUCP> <674@cernvax.UUCP>
Lines: 178

In article <674@cernvax.UUCP>, hjm@cernvax.UUCP (Hubert Matthews) writes:
> Dear All,
> 
>      I see the thorny subjects of RISC v. CISC and scalar v. vector have
> reared their ugly heads again, but in a different guise - multiprocessing!
> 
>      Allow to point out some of the ENGINEERING issues involved:
> 
> 	- the cost of a computing system is primarily a function of size, 
> 	  weight and the number of chips or pins;
> 
> 	- to go really fast and to be efficient, the hardware should be simple;
> 
>      So what am I trying to point out?  Merely that a large amount of hardware
> in present-day machines is there because of difficulties in software.

Let me point out that the entire purpose of hardware is to run the software.
Further, difficulties in software can generally be divided into 2 parts:

	1)	Difficulties based in the inherent complexity of a
		software structure. (we will ignore this, as some
		structures can not be easily reduced.
	2)	Difficulties caused by inadequate/bad hardware design...
		such as multiple instructions to cause a commonly
		desired result rather than a single instruction, badly
		implemented flags/overflow/branching/testing, etc.

> For example, take the common-place example of your local UNIX or VMS box.
> Inside these beasts is a *lot* of hardware to keep one user away from his
> fellow hackers.

Let me point out that this is a largely policy and/or design issue, NOT one
of software.

	1)	The concept of "keeping a user away" from data is one more
		of philosophy, rather than necessity.  Those people who
		refer to themselves as hackers, and those that refer to
		them as hackers using the word correctly, generally are not
		the security problem on systems, unless sensitive data needs
		to be protected from outside eyes as well as damage.  People
		who damage/destroy/alter data are not known as hackers; they
		are know as assholes.  There are many good reasons why data
		should be kept away from all but a select group of people,
		national security, to name one.
	2)	The requirement of "a *lot* of hardware" is a silly one which
		has been imposed by hardware designers refusing to attend to
		security issues which are better relegated to hardware.
		Instead, security is generally implemented as additional
		hardware not because it is necessary to do so, but because
		hardware designers have yet to see the merits of VLSI when
		applied to anything other than a CPU or it's support chips;
		most hardware security measures could easily be implemented
		in a single chip or in software.

> An equally large amount of hardware is provided for the demand-paged
> virtual memory system.

I think you are mixing your models here.  A virtual memory system need not
support demand paging, and a demand paging system need not imply virtual
memory.  If hardware designers understood what the machine was supposed to
do when it was put together more clearly than is made apparent by this
statement, perhaps there would not be this problem.  In addition, most
hardware designers use MMU chips to alleviate this problem entirely.

> Add to that a healthy(?) helping of cache chippery

I believe the memory cache was invented by a HARDWARE company so that their
HARDWARE would appear faster than their competitors.  Caching is, at times,
helpful; however, it can also be a great inconvenience, especially when one
is trying to design a mutliprocessor system or implement memory-mapped I/O.
When you are using dual-ported RAM to communicate with other hardware because
the designer was unable to cause the hardware to run at a reasonable rate
if the communication took place via interrupts, it is horribly inconvenient
to have your I/O cached, and perhaps lost.

[I realize I'm going to get a lot of flack here from people who love DMA
 and hate interrupts, such as the designers of message-passing operating
 systems, but consider this: a well designed computer system with an
 interrupt-based architecture can not lose data as long as you stay within
 system performance limits.  Synchronization of data flow in software is
 always subject to a number of failure modes, not the least of which is
 directly related to prioritization of tasks.]

> and what do you get - yes, a machine built upon boards the size of a small
> squash court!

You work for IBM, right? ;-)

> None of this hardware is simple, and applies to both the uniprocessor
> and the multiprocessor case.

I agree, but I have to modify this with the statement that this is only
true in the case of badly designed hardware.

>      Now, add in the magic multiprocessor devices and all hell breaks loose on
> the hardware front (not to mention the software - groan).

Exactly... "groan".  Software is always more complicated than hardware -
that's why software takes longer.  Add into this the apparent inability
of hardware designers to comprehend what is necessary for software AND
hardware to be smaller/faster/sooner, and you have machines which are so
radically different in operational concept from what needs to be done
that programmers who have to deal with the hardware are more often than not
prone to mistakes.  And built upon this are the users concepts of what "needs
to be there"... the actual bottom line.  To get from hardware to bottom line
can often take 7 or more layers of software fixing or bypassing bad (or
worse, ill-informed) design decisions made at the hardware level.  This is
the sort of atrocity that made it impossible to write decent terminal
emulators on CP/M systems: the UART hardware was often capable of getting
characters in excess of 19200 baud; the screen was often capable of displaying
characters at rates in excess of 38400 baud.  The bottoleneck was that when
the screen scrolled, the hardware locked out serial interrupts, thus causing
lost data from the serial channel.  There were exceptions, but not many.

> Everyones favourite trick seems to be finding evermore complicated ways
> of getting large numbers of CPUs to talk to the memory all at once.  Just
> imagine an ever increasing number of waiters trying to get in and out of
> the same kitchen all at once through one door, and you can see the mess.
> OK, let's increase the number of doors ... in hardware terms this means
> separating the memory into several pages which can be accessed simultaneously,
> thereby increasing the effective bandwidth of the memory.

Not everyones.  This is only true in cases where bad implementations have
occurred, in both hardware and/or software.  Extreme paralellism is only
useful for things which lend themselves to paralellism, and even then the
only truly useful emergence from the whole paralell mess has been data-
flow architectures, such as GoodYear's, for use in finite element modelling
or fluid-dynamics, and things such as the Sequent/NCR/Sperry/Multiflow
systems when applied to large numbers of users or online transaction
processing.  In these instances, it is, with very little intercommunication,
like having a number of computers with shared resources, in the same box...
not a bad idea, if you want to save money.  I have yet to sit down at one
of these machines and type "make" and have a seperate processor allocated
to each compile.

> Is this really admitting that shared memory is not necessary?

Shared memory is *not* something to just throw at a problem.  As you admitted,
increased bandwidth improves performance.

> Surely the highest bandwidth is achieved when each processor has its own
> memory which it shares with noone else?  It also makes the hardware a lot
> smaller.

Absolutely not.  Think of an infinite memory plane with processors "crawling"
over it, doing what needs to be done... somewhat like many small spiders
cooperating to perfect a web which none could complete by themselves.  This,
I think, is a representation of the ideal dataflow machine.  It might even be
useful, if we could figure out how to talk to it.

> 	- virtual memory is useful only when an application won't fit in
> 	  physical memory.  But memory is cheap, so with lots of Mbytes
> 	  who needs it, especially if the program is written well.

Memory is no longer cheap.

> 	- multi-user machines are too complicated to be both fast and simple.

Due to inappropriate hardware implementation, yes.

> 	- shared-memory is not necessary; it's a software issue that shouldn't
> 	  be solved in hardware.

How do you propose it be resolved in software, given hardware "protection"?
This is an inane idea, and perpetuates the major problem with breaking
software down into a true field of engineering.  Given the complexity of
software as compared to hardware, it may be impossible to derive a formula
method of producing software; perhaps it will always be an art.  But there
are things which could be done in hardware to make it easier and less arcane
than it currently is.  The current problem is one of hardware not resembling
the soloution which is the goal.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'Admit it!  You're just harrasing me because of the quote in my signature!' |