Date:        Mon, 27 Jul 1998 12:50:01 -0700
    From:        Jonathan Stone <jonathan@DSG.Stanford.EDU>
    Message-ID:  <199807271950.MAA12185@Smeg.DSG.Stanford.EDU>

I have been watching this argument, with some amusement, and while I
know I don't know enough about the issues involved (what will be affected
by what choice) to take a position on the desired answer, this ...

  | Um, Todd, they are _not_ two architectures. They're the same chips, so
  | they're the same architecture.  End of story.

seems to me to be at the root of the disagreement.

To me, at least, the architecture is a LOT more than just the chip.  The
chip is the chip, and is a part of the architecture, but no more than that.
Not only that, but different chips can be one architecture, and one chip can
support multiple architectures (any chip can).

The architecture is the environment presented to the end user - it includes
all kinds of crud beyond the chip - eg, on alphas it includes the PALcode
that happens to be loaded.   It also includes the ABI (what a function call
is supposed to look like), the kernel interface (the interface provided bty
the kernel) and the base libraries (libc, probably libm).

Defects in chips (like missing floating point, or multiply, etc) can be made
up by the kernel, so applications can believe that the hardware exists (if
they desire), or can be exposed to the application - all this is a part of the
definition of the architecture.

If you're writing the kernel, the libraries, or the toolchain, you need to
know how to make the architecture work, and you're going to need a more precise
definition of what really exists out there.  But for everyone else, what
is needed is the basic architecture definition, anything which requires that
architecture should simply run on the system.

kre

ps: as an obvious case of the chip not defining the architecture, consider
the mac powerpc chip, with the virtual pc software running on it - the
architecture there is an x86 based one, but there is no x86 type chip in sight.