melvin@cygnus (Steve Melvin) (03/22/89)
In article rogerk@mips.COM (Roger B.A. Klorese) writes: >In article slackey@BBN.COM (Stan Lackey) writes: >>The MICROvax architecture does NOT include >>string instructions, other than MOVC3 (and MOVC5?). Some DEC-supplied >>software includes emulation to ease the transition. Generating the >>in-line emulation using a reduced instruction set is NO PROBLEM, right? > >There *IS NO* MicroVAX architecture. There is a MicroVAX *implementation* >of the VAX architecture, which implements some instructions in software. >This is very different. Actually, it's not quite this simple, the distinction between 'architecture' and 'implementation' starts to get a little fuzzy here. There exists at DEC an official document which describes 'The VAX Architecture.' Part of this document is a set of approved subsetting rules. That is, DEC specifies how and in what groups things may be 'unimplemented' and still be VAXes. The subsetting rules describe what the hardware must do if it encounters an unimplemented instruction (i.e. what kind of exception to generate, etc.) What the operating system does with that exception is *not* part of the specification. The microvax I and the microvax II each have their own applications of these subsetting rules. Thus, in one sense, there is indeed a 'microvax architecture,' or more correctly a 'microvax II subset of the VAX architecture.' The point is that it is an interface description independent of implementation details so could validly be considered to be an architecture. That is, I could naturally build another machine which exactly implements the microvax II subset using completely different technology. In another sense, the subset characteristics of a VAX are merely 'implementation dependencies' rather than variations on the architecture. There are other differences between different VAX implementations which more naturally fall into this category. For example, differences in the set of privileged registers or how the I/O space is mapped to physical addresses are not really what we think of when we consider the 'VAX architecture.' The point is that every VAX does things differently. Most of these differences are not visible at the unprivileged instruction level, but even two 'complete' implementations, are not indistinguishable at the user level. I've written a program that can tell the difference between a 780 and an 8600 without using any privileged instructions, without generating any exceptions and without using any timing information (hint: the trick is very obscure, you won't find it in the architecture reference manual). The distinction between 'architecture' and 'implementation' is often convenient and useful, but other times not meaningful. It may be nice to think of the 'VAX Architecture' as a pure interface description that gets identically implemented by a family of processors. In reality, each of these processors implements a different interface, but each of these different interfaces is similar in a way that is useful (more so in some cases than in others :-). ---- Steve Melvin ...!ucbvax!melvin melvin@polaris.berkeley.edu ----