Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!oddjob!gargoyle!ihnp4!homxb!mtuxo!mtune!codas!usfvax2!pdn!alan
From: alan@pdn.UUCP (Alan Lovejoy)
Newsgroups: comp.arch
Subject: Re: What should be in hardware but isn't
Message-ID: <1430@pdn.UUCP>
Date: Fri, 25-Sep-87 09:39:47 EDT
Article-I.D.: pdn.1430
Posted: Fri Sep 25 09:39:47 1987
Date-Received: Sun, 27-Sep-87 04:02:11 EDT
References: <581@l.cc.purdue.edu> <8646@utzoo.UUCP> <705@gumby.UUCP>
Reply-To: alan@pdn.UUCP (0000-Alan Lovejoy)
Organization: Paradyne Corporation, Largo, Florida
Lines: 17

In article <705@gumby.UUCP> earl@mips.UUCP (Earl Killian) writes:
>extended precision hardware, not transcendental instructions.  In some
>ways, this is the RISC approach: when someone says "I need X to do Y",
>first ignore X, and then figure out the right way to provide
>general-purpose building blocks to accomplish Y.

Interesting.  Sounds like my philosophy for programming language design:
the best way to provide a feature is to build the proper abstraction
mechanisms and primitive operations into the language that will provide
the most general solution to the problem which makes the feature
desirable.  The analogy with 'primitive operations' in hardware is
clear, but what's the hardware equivalent of an abstraction mechanism?
Perhaps some of the features of the Smalltalk Virtual Machine represent
hardware abstraction mechanisms.  I think user-definable microcode routines
would also qualify.  Hmmm...

--alan@pdn