Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!cornell!batcomputer!pyramid!prls!mips!hansen
From: hansen@mips.UUCP
Newsgroups: comp.arch
Subject: Wirth's "challenge" (was Re: RISC)
Message-ID: <902@mips.UUCP>
Date: Thu, 12-Nov-87 00:05:23 EST
Article-I.D.: mips.902
Posted: Thu Nov 12 00:05:23 1987
Date-Received: Sat, 14-Nov-87 12:54:10 EST
References: <1656@geac.UUCP> <863@winchester.UUCP> <197@m2.mfci.UUCP>
Lines: 77
Keywords: RISC,array

In article <197@m2.mfci.UUCP>, colwell@mfci.UUCP (Robert Colwell) writes:
> I notice that nobody has taken up Wirth's challenge at the ASPLOS-II
> conference concerning the dangers inherent in the current approach of
> "performance above all else".  He mentioned items like undetected
> integer overflows and broken floating point processing as being the
> norm.  I bet he knows this, but he didn't mention it.  The
> problem is that when you've got several streams of floating point
> operations in the air at the same time, you could have a royal mess
> if any one of them takes an exception AND you have to handle it a la
> IEEE.

The MIPS R2010 floating-point coprocessor has _both_ precise floating-point
exceptions, and overlapped execution of several floating-point operations.
(Integer overflow exceptions, in fact all exceptions, are precise also.) All
the required hooks to support full IEEE floating-point exception handling
are present in the hardware and operating system environment; unfortunately,
there aren't any standard language bindings for IEEE exception handling in
the common languages. The hardware problems of handling exceptions adequately
are easily solvable - the language design problems are much harder.

As the title of Wirth's paper "Hardware Architectures for Programming
Languages and Programming Languages for Hardware Architectures" imply, the
hardware and software issues are inextricably linked. In fact, many of the
lossages in existing instruction sets are echoes of common practice that has
been buried in the definition of common languages. For example, the lack of
overflow checking and array bounds checking in C may have started as a
reflection of the hardware architectures in place at the time C was
designed, but now to build a new machine that supports C, you must provide
arithmetic operations without overflow checking, and the means to address
arrays without bounds checking. A particular example that Wirth provides is
the utterly stupid definition of integer division that gives mathematically
useless answers for negative dividends - I've tried to specify division
instructions that do it right on the last three architectures I've worked
on, and was thwarted each time by the requirement to provide division the
way the languages define it.

Wirth then makes some comments to the effect that RISC design techniques
that I personally think are way off the mark. In my mind at least, RISC has
always meant a greater reliance on software technology, i.e., more complex
compilers, and RISC designers have made conscious decisions to move
complexity from hardware into software. To criticise RISC simply by saying
that it doesn't fulfill the promise of simpler compilers is vacuous,
because such a goal was never intended. In fact, compiler optimization
techniques that RISC relies on so heavily are based on the notion
that a computer program is "a static text amenable to mathmatical analysis
and logical reasoning," the very notion he asserts that hardware designers
have lost sight of.

Wirth closes the paper by telling us that hardware designers was better stop
relying on simulation and more on formal deductive reasoning and proofs of
design correctness. However, he has lost sight of the prosaic fact that
large hardware designs, like large software designs, aren't amenable to
unassailable proofs of correctness of the entire design. OK, let's all see
by an electronic show of hands, how many people manage to prove that all
their software programs entirely meet the requirements of a bulletproof
formal specification.  (Uh huh. I though so.)

Enough of the details; Wirth's basic argument is that architectures and
programming languages should support each other, and basically be designed
together. In the abstract, this possition is unassailable; however, the need
for compatibility with old, badly designed languages will require that
compromises be made in architectures. It is the saddest fact of life in the
computer industry that the mistakes of the past will live virtually forever,
because the wrong choices in language design will force continued wrong
choices in architecture, which will perpetuate the bad choices in language
design. My severe disappointment with Wirth's paper is that he chooses to
place the blame on architecture designers, rather than take his fair share
of the blame as a language designer.

P.S.: Finding fault with the design of Pascal [yes, I know it's not his
ultimate work] is shooting fish in a barrel.

-- 
Craig Hansen
Manager, Architecture Development
MIPS Computer Systems, Inc.
...{ames,decwrl,prls}!mips!hansen or hansen@mips.com