Re: What is an N-bit machine?

jgd@cix.co.uk (John Dallman) writes:

In early computer designs, arithmetic registers were much longer than
addresses, the classic examples being machines with 36-bit words and 15-
to 18-bit addresses.
>
Large logical address spaces started with the IBM 360, which had 32-bit
arithmetic registers and 32-bit address registers. You couldn't put
32-bits worth of physical memory in a machine for over a decade after it
appeared, but it was allowed for in the architecture.
>
Nowadays, the bit-ness of a machine seems to be the *smaller* of the
arithmetic registers and the address space. This became true in the early
1970s, as far as I can see, and the terminology became confused around
then. A few examples from that period:
>
Classic "8-bit" microprocessors, such as the 8080 or 6800 have 8-bit
arithmetic and 16-bit addressing.
>
The PDP-11 has 16-bit arithmetic and 16-bit addressing, plus
bank-switching.

In the early 1980s the width of the data bus of the main
implementation of an architecture was considered to be defining the
bitness of the architecture.  This is especially noticable in the
68000, which was usually described as 16-bit CPU, despite having
32-bit address and 32-bit data registers, because it has a 16-bit data
bus.  I think that even Motorola called it a 16-bit CPU. With low-cost
variants such as the 8088, the 68008, and later the 386SX, that idea
was not kept up.

And later, when the bus sizes outgrew the address sizes (IIRC the
Pentium has a 64-bit data bus; these days desktop processors have
128-bit wide memory interfaces (but they are 4x32 bits with DDR5) plus
24 lanes or more of PCIe or alternatives), this concept was not kept
up, and we arrived at today's architecture-oriented concept of making
the address register size determine the bitness.  This works pretty
well also for what is considered to be the bitness of the S/360, the
PDP-11, and the VAX.  But it means that the 68000 is a 32-bit
processor, and I think that's the current general opinion.

Where this concept does not work:

For the earlier 36-bit architectures with registers that hold two
15-bit or 18-bit addresses, this concept does not really work.

The CDC-6600, which has 60-bit X (data) registers and 18-bit A and B
(address) registers, this concept does not work well, either.  We do
not consider it to be an 18-bit architecture.  And I expect that the
18-bit limitation is not deeply rooted in the architecture, and it
could be expanded up to 60 bits without big problems, because the
addreses take 60 bits in memory just as the data.

For 8-bit CPUs, at least for the 6502 16-bit addresses never exists in
architectureal registers (apart from the very implicit PC), only as
effective addresses and in the PC.  However, it's parent 6800 has a
16-bit index register and a 16-bit stack pointer, and the 8008 has the
H and L registers which together form a 16-bit address.  So for these
architectures the address size does not determine what is generally
considered the bitness of these CPUs.

The original 8086 has 16-bit arithmetic and a strange 20-bit addressing
scheme.

But, as the protected mode of the 80286 shows, the intent was to use
16-bit addresses in programs (possibly in multiple segments), not
20-bit addresses.  Software did not follow this intent, though.  In
any case the instruction set makes addressing beyond 16-bit addresses
so cumbersome that calling it a 16-bit architecture is justified even
with the newer, architectural concept of bitness.

Modern architectures have arithmetic and address registers that are the
same size.

There was a movement from specialized registers such as the 68000s
address and data registers to general-purpose registers (e.g., in the
386 and the original RISCs).  But then SIMD extensions were introduced
starting in the mid-1990s, and they introduced wider SIMD registers
that usually only contain data, not addresses (but Intel introduced
scatter/gather instructions that also use SIMD registers for
addressing).  We still use the size of the proper address registers
when we consider the bitness of an architecture.

OTOH, we also talk about the bitness of the SIMD extension: SSE and
ARMv8 Neon uses 128 bits.  But the tendency towards making the
SIMD-width an implementation option as in ARM SVE and AFAIK the RISC-V
V extension means that we will not use the width of the SIMD extension
as an architectural concept, but it will probably increase the usage
of the width of the SIMD extension for describing particular
implementations.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>