In article <dIydnaVRvqAf-hbcRVn-***@rcn.net>, ***@aol.com writes:
:In article <EQHid.57319$***@attbi_s53>,
: glen herrmannsfeldt <***@ugcs.caltech.edu> wrote:
:>***@aol.com wrote:
:>
:>(snip)
:>
:>> Which came first? Ultrix 4.0 or MicroVAX 3100? If Ultrix 4.0
:>> was first, it can't have the [what I think of as] CPU driver
:>> for the 3100 in its image because the image was built before
:>> the hardware existed.
:>
:>The whole idea of an architecture, independent of the
:>implementation, is that software doesn't have to be written
:>for the specific machine.
:
:Rethink what you just said. We're talking about real OSes here
:of the olden days, not an app that claims it's an OS.
Most every VAX and many Alpha systems require(d) reworking the operating
system, as the architecturally-permissible differences among various
of the platforms were often substantial.
There were technical reasons why there were new releases of OpenVMS VAX
and of OpenVMS Alpha required for new hardware support -- with the advent
of DSR (Dynamic System Recognition) support within the operating system
and in the various platform consoles, the core operating system upgrade
requirements were often relaxed; so long as the new platform operated
like a supported platform, the operating system could bootstrap. But
these software-requirements were not completely eliminated.
:>There are plenty of people running old IBM operating
:>systems on newer machines. In one case, I had to change
:>one bit (in the executable image) because the architecture
:>did change, to get an old OS to run on a new machine.
Older releases on newer machines doesn't always work, and particularly
assumes the newer machine directly emulates an older machine -- the VAX
7000 model 800 series, for instance, could be configured to report
itself as a model 600 for just this reason. The VAX 7000 model 800
then reported itself as a model 600, which itself caused various levels
of confusion -- folks purchased a model 800, but the system would show
itself as a model 600 due to the emulation.
:Then it wasn't new architecture but an enhanced version of
:an old architecture. The KA, KI, KL, and KS were machines
:that were different but the same architecture. It meant that
:usermode code that ran on one could run on the other if, and
:only if, they did not have model-specific machine instructions.
:However, a monitor built for a KA would not run on a KL because
:[what I think of as] the CPU driver were different.
On OpenVMS, this would be the system-specific loadable code; the
system-specific loadable images. This support can and does vary
by platform, even within an architecture.
:Now, to get a CPU driver of one model to run on another model
:requires an emulation of the first model. This means that all
:instructions specific to the first CPU would have to trap when
:executed on the second model; then it's a small matter of
:programming to emulate the machine instruction.
There is (far) more to platform support than the instruction set.
The I/O layout and other aspects of the physical system can and
do vary across VAX platforms, across Alpha platforms, and even
Integrity boxes -- with each architecture, the platform differences
do decrease, but the differences have yet to disappear entirely.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com