Talk:Intel 4004

Word size

Per the data sheet, it's actually sort of an 8-bit computer:

• Instructions are all multiples of 8 bits long
• Instruction addresses (in jumps, etc) are 8 bits long
• Immediate data is sometimes 8 bits wide
• Register pairs, the target of 'load immediate' instructions, are 8 bits wide
• Some data is 8 bits wide (in the FIN instruction, the data goes to a register pair, so 8 bits wide)

On the other hand:

• The accumulator is only 4 bits wide
• The ALU (and thus all data handling in arithmetic instructions) is only 4 bits wide
• Some data is 4 bits wide (it's not clear if in the LDM instruction, the 'DDDD' bits are immediate data, or the address of the data [probably immediate]; either way, it goes to the accumulator, so only 4 bits wide)

So, it's truly half and half. Because instructions and addresses are 8 bits long, I would say its word size is 8 bits. But I can see an argument for saying it's a 4-bit machine. Addresses on the early PDP-10's are only 18 bits, so address length is not definitive to word size. Similarly, the PDP-10's full support for half-word math is sort of irrelevant. The two conclusive things in 'word size' seem to be i) instruction size, and ii) ALU size (which defines the longest data item it can handle in hardware). But that last isn't absolutely definitive - PDP-11's with hardware floating point handle multi-word data. And the UNIVAC I has a word size of 72 bits, with two instructions per word! I give up!!

Interestingly, it seems to have limited support for off-chip RAM; the 16 4-bit-wide internal registers seem to be the primary locations for writing data; there's no 'store' instruction. But SRC seems to send an address out, for later used by the Wxx instructions. And the CM-RAM[1023] lines seem to control "4002 RAM chips". Jnc (talk) 20:58, 11 July 2023 (CEST)

I don't think there's any exact definition of the "bit widthness" of a processor. And maybe that's just as well, as people would never be able to agree on one. And obviously many processors will defy a neat classification.

Maybe we all have a hierarchy of features we'd like to consider in order to assign a number. I'm my view, instruction width isn't at the top of my list. Address space width even less soo, e.g. consider "8-bit" processors usually have a 16-bit address space. I think the ALU and register size the the most important aspect for me. (Hopefully they match, but I'm sure there are the odd example were they don't.)

For the 4004 specifically I haven't even studied it at all, I just went by the common wisdom which has it a 4-bit processor.

There's also the 68000 which is supposedly "16/32-bit". Instructions are architected to be 16-bit units. The data bus and ALU are also 16 bits wide, but that's more of a hardware implementation detail. The programming model is pretty much 32 bit throughout.

Larsbrinkhoff (talk) 13:57, 12 July 2023 (CEST)

I've been thinking about it, and I'm still somewhat lost. I think actual ALU width isn't such a big deal (e.g. the LSI-11's ALU is only 8 bits wide); it's more the 'architectural' ALU size - i.e. the size of the largest data item the instruction set will handle.

I'd forgotten the 68K had 16-bit instructions (even though I used them for several years, including writing a debugger for it); I think I just had this idea that the PDP-11 got as much out of a 16-bit instruction as one could, so the 68K 'must' have had a 32-bit instruction. The 68000 had a 24-bit address bus, and a 16-bit data bus; but the 68020 had 32-bit wide address and data buses - with the same instruction set. So the physical bus width is kind of like the 'actual ALU' width - less important than the architectural width.

So the architectural address space and data size are important. Jnc (talk) 17:46, 12 July 2023 (CEST)

Hey, I have a list of all thing things that might be used for computer 'sizes' - along with counter-examples (e.g. bus width and the 68K). Can you think of a counter-example for the accumulator/register size? Jnc (talk) 04:29, 13 July 2023 (CEST)

I think in my view register/accumulator size and ALU width is the most important critera deciding the bitness. I'm not aware of any counter-examples, but then that may be because of my bias. I'm sure somewhere out there, there must be some wacko computer where the ALU doesn't match the register(s).

Having thought about it a little more, I have a strong impression people don't consider internal hardware implementation details overly important for deciding bitness. For example, a microcoded processor may have a very small hardware ALU to implement the architectural ALU. The 68000 and LSI-11 are examples of this, and I think some of the low end 360 models too. So I believe the abstract programming model is more important.

Regarding address width, in recent times it does seemingly almost almost match register size. This goes back at least to the PDP-11, which really feels like one of the first "modern era" programming models. But before that, many architectures had the idea that a full address should fit in an instruction: e.g. most earlier DEC computers. For that era at least, address width doesn't seem like an important consideration for bitness.

Also in that early era, many machines were "word oriented", where a single word size really permeated almost all aspects of the computer: addressing unit, registers, ALU, instruction size, etc. With byte addressable computers, this has changed, and there are more opportunities for mixing and matching different word sizes throughout the machines. Larsbrinkhoff (talk) 09:07, 13 July 2023 (CEST)

The Z80 has a 4-bit ALU.. though it hides that by loading 8-bit values through internal latches. And 8-bit microprocessors typically have a 16-bit address range, but we think of them as 8-bit CPUs. After 32-bit CPUs had been on the market for some years, address range started to feel more important than data width, and the shift to 64-bit was more about address range than general register width. Things have changed over the years. Minis used to have more physical memory than their CPU address range, for example, and that's been the other way around for the last few decades. Tor (talk) 10:13, 13 July 2023 (CEST)

Good point. I agree bitness in recent years (or for more capable processors) has shifted to the size of the virtual address space (sometimes including metadata bits, e.g. Aarch64). Larsbrinkhoff (talk) 15:13, 13 July 2023 (CEST)

The lower-end 360 models did indeed have a narrower data paths; the Model 30 was 8 bits, the Model 40 was 16, etc. Good points that the importance of various measures changed overtime. Jnc (talk) 23:08, 13 July 2023 (CEST)