NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/arch/9045

Text File | 1992-08-25 | 6.0 KB | 126 lines

Path: sparky!uunet!pipex!unipalm!uknet!gdt!aber!aberfa!pcg
From: [e-mail] (Piercarlo Grandi)
Newsgroups: comp.arch
Subject: Re: A Little History
Message-ID: <[e-mail]>
Date: 26 Aug 92 00:52:48 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
    <[e-mail]>
Sender: [e-mail] (USENET news service)
Reply-To: [e-mail] (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth
Lines: 109
In-Reply-To: [e-mail]'s message of 24 Aug 92 22: 04:08 GMT
Nntp-Posting-Host: aberdb

On 24 Aug 92 22:04:08 GMT, [e-mail] (Rick Smith) said:

smith> (Piercarlo Grandi) writes:

pcg> Well, this brings us to a more general sort of argument about
pcg> architecture, and that is the design rationale issue. It is very
pcg> rare that an architecture description is accompanied by its design
pcg> rationale, by the guiding principles behind it. ...

smith> True, but fortunately not always true. Bell et al did that
smith> "Computer Engineering" book at DEC, and there were articles
smith> discussing the rationales behind the IBM/360 architecture when
smith> the family first appeared.

Ah, but this is the easy target. For some reason computer architecture
is one of the architectural fields of computer science where rationales
are better documented. There was that CACM issue on important historical
archictectures, and most important books on the subject have extensive
historical and rationale sections. Hennessy & Patterson, but also my
other favourite, the Roland Ibbett (on high performance computers, that
is as deep or deeper as Hennessy&Patterson, and shorter -- but it is
mostly qualitative).

pcg> While mathematicians often design their theories according to some
pcg> implicit but intentional principles, computer science architects so
pcg> often seem unable to make their design principles explicit.

pcg> I tend to surmise that this is because they don't have any, as such
pcg> a large portion of computer science architecture is done by more or
pcg> less blind trial and error.

smith> Well, not completely blind. Developers have a variety of
smith> requirements they try to meet and varying criteria for measuring
smith> success.

Ah, but here I was more or less obliquely referring to computer
*science* architecture, I was not limiting myself specifically to
computer architecture. And for non hw architectures, e.g. OS and
language designs, criteria are much fuzzier, and rationales hard to
discern. Why ever a certain aspect of a language was thrown in is almost
never explained.

There are exceptions; for example Ada's rationale, unconvincing as it is
at times. But there are glaring holes. For example, about the entire
design rationale for Pascal is Hoare's article on types in "Structured
Programming", but this fact is *never* mentioned in the Pascal books,
even those by Wirth. I happened to read Hoare's article only _after_
having started to program in Pascal, and I realized how much I had been
missing out because I did not know why Pascal was like that. And very
few people did, which is a pity, because from Pascal those (hidden!)
design rationales have percolated into many other languages, and have
been immensely influential.

smith> [ ... design rationales are important in a monetary sense, as
smith> they represent very expensive know how ... ]

Ah yes, but this does not apply for research projects, and there things
are as mysterious as in the commercial world, laudable exceptions excepted.

smith> In a sense this increases the value of historical reports, since
smith> there are often close parallels between today's problems and
smith> yesterday's solutions.

Standing on the shoulders of giants, and being bound to repeat the
mistakes of the past if you don't know them... Ah , so true.

pcg> At times I think that little new is computer science architecture
pcg> has happened since 1975. A bit of this is the effect of backwards
pcg> compatibility, which usually means compatibility with architectures
pcg> designed in the late fifties or early sixties (the MacIntosh, DOS
pcg> and Unix being the most obvious examples).

smith> I think it's just because there aren't that many things you can
smith> do with a uniprocessor in the von Neumann style.

Probably very true for hw architectures. But what about popular sw
architectures? They tend to be twenty-thirty years behind the state of
the art. I really think that backwards compatibility, especially with
the constrainst imposed by MSI implementations of early microprocessors,
is the culprit. Hey, the Mac OS technology is middle sixties vintage
(OS/MFT!), and most UIs are not as sophisticated as what the PARC people
were doing only a few years later.

smith> I think the future of computer architectures is in various forms
smith> of parallelism not addressed by the von Neumann tradition.

Pious hope, I am afraid. Research in this field has been going on
forever, and without much progress. Architectures here seem wedded to
particular application shapes, and almost all variations have been tried
out, and only a few have been found cost effective. But some particular
application shapes are so important...

smith> Refinements of uniprocessors will simply mix and match older
smith> solutions based on new situations of size, speed, and
smith> reliability.

Ah, well said. We can only hope that technologists will enliven the scene
by giving us dramatically new tradeoff points, as they did when they
invented two very different RW memory technology points (SRAM, DRAM)
where previously there had been only one RW and one RO.

I have great hopes for solid state mass storage (ferroelectric,
holographic, for example), which would alter radically the tradeoffs
points for filing systems, causing a veritable revolution in OS and
database architectures.
--
Piercarlo Grandi                   | JNET: [e-mail]
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: [e-mail]