Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!lll-winken!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <16353@cup.portal.com>
Date: 28 Mar 89 18:00:50 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <15702@clover.ICO.ISC.COM> <27681@apple.Apple.COM> <15695@winchester.mips.COM> <22974@ames.arc.nasa.gov> <13404@steinmetz.ge.com> <5798@pdn.nm.paradyne.com> <16231@cup.portal.com> <5855@pdn.paradyne
Organization: The Portal System (TM)
Lines: 23

>Hmmm...  Isn't there an important connection between the chip implementation
>technology (e.g., silicon transisitors, quantum circuits, photonics, vacuum
>tubes...) and the problem of designing an efficient implementation of a
>logical architecture?  Logical architectures that cannot be efficiently
>implemented in NMOS might have no such problems in an optical computer.
>If it is the logical architecture that is the primary determinant, then
>whether something is a RISC depends on the current implementation technology.
>
>Or am I missing something?

Uh, I don't know, you lost me somewhere here.  All I want to say is that
RISC can be defined by a set of *architectural* features.  To be sure,
that set was constructed with the implementation implications in mind.
If a new set of implementation technologies, or techniques, comes along,
then we'll have to define a new, er, "post-RISC", or whatever, set of
*architectural* guidelines that leads to a set of architectures that is
consistent with the new implementation technology.  If optical technology
calls for instructions that have, oh, I don't know, 14 source operands,
then we need to change things!  However, note that technology differences
do not change the basic state-machine model of computation.  Until we do
change the basic model (to what?  I don't know!  I'm trying to think of
it actually...), instructions can't change a whole lot, at least not
qualitatively.