如何定义X is an N-bit CPU

As has been discussed here, and in that old BYTE article, there is a *long*
history in computing that the phrase "X is an N-bit CPU" meant that tha
architecturally-visible size of the integer (or general-purpose) registers
was N bits.

Bus width is an *implementation* issue, and members of the same family can,
and often do, have a wide range of bus widths, and different bus widths in
different places (such as L2 caches, system bus, etc) ...

Family        Architecture        Bus widths
S/360        32            8, 16, 32, 64 (at least)
PDP-11        16            16, 32, 64 (at least)
VAX        32            32, 64 (at least)
X86 (386->)    32            16, 32, 64
68K        32            8, 16, 32, 64
MIPS (32)    32            32
MIPS (64)    64            32, 64, 128, 256
                    (note R8000 cache-bus <-> memory
                    == 256, and various members' L2 cache:
                    128 bits)

Size of FP registers is also irrelevant to common nomenclature: nobody calls
an X86 an 80-bit chip; many 32-bit architectures have 64-bit FP registers.

This common practice:
    - is not necessarily right.
    - is sometimes disobeyed by marketing.
    - but has been the common practice for a long time.

Traditionally, if a CPU was labeled N-bit:
    - integer registers were N bits
    - (convenient) addresses were N bits, or perhaps slightly less.
See BYTE, September 1991, page 136 for a big table of these for
various machines.

External bus widths, floating point widths, segmented addresses, etc,
have generally been irrelevant [for example, S/360s were 32-bit,
but had implementations of 8, 16, 32, and 64-bit busses, etc]

The MC68000 (ignoring high 8 bits) was a direct repeat of the S/360:
both 32-bit machines with 24-bit addresses, and no high-byte check,
and similar consequences.

Sometimes a CPU usefully supports 2 sizes of N, i.e.,
    X86: 16 & 32
    Alpha, MIPS R4K & later: 32- and 64-bit
at which point one may see both sizes used for operating systems,
i.e., using the smaller size of existing OSs, then converting to
the larger size over time.

User programs also vary, with several systems being willing to
mix user-level codes of different sizes.

Sometimes marketing diverges from engineering practice...
and these days, the tendency is to attempt to label something as 64-bit
if anything is 64-bit anywhere :-)

Despite the horror that this creates in various people, some people
use C with 64-bit "long long" and 32-bit pointers to get speedups on
32-bit code where big addresses are not relevant, but bigger
integer performance is, i.e., like on Nintendo N64s or various other
embedded applications.