There are probably another order of magnitude more computers in a 'computer' than Gwern estimates.
Consider:
- Power management chips (of which there are dozens) each containing programmable MCUs
- Batteries, of course, contain one or more MCUs each
- Clocks
- 'Glue' MCUs for things like DMA controllers and USB controllers. (USB controller firmware has been exploited from the port side, and it's not upgradeable)
- Supervisors
- RGB LEDs (!)
- SD cards have several (see Bunnie's work)
- Ethernet, WiFi and Bluetooth controllers contain several small and usually a few large computers each
Some of these have fully-baked ROM code, some are programmed and modifiable through flash, and some have firmware written at driver load time to save money.
Many of those /are/ programmable. Here's the code we used to get code execution on an SD card bought at the markets in Shenzhen (the project I did with bunnie, referenced above): https://github.com/xobs/ax2xx-code
The factory needs to get code on there somehow, and usually the method isn't documented. Oftentimes it's not locked down.
I'm considering anything that runs firmware. I wouldn't consider e.g. a regulator with configurable voltage via resistor divider to count.
I would consider a switchmode PSU where the main switch FET is driven by a microcontroller running firmware (they can then have an I2C/SPI input to allow programmable voltage control). There are probably dozens of these in any modern computer.
I once knew a hardware engineer who worked on a team designing cutting-edge equipment. His mantra was “just use a PIC chip”. He had all sorts of war stories about other engineers coming to him with power regulator designs they just couldn’t get right. He’d often add a PIC chip or two and have the firmware dev write a few routines in C. Problem solved.
PIC chips are small, they are everywhere, they are very useful for adding complex, software-defined behavior (including DSP) at the circuit component level, and they are full general-purpose CPUs with onboard RAM and programmable ROM.
Sprinkling a ton of micros around a board can create a small nightmare for the software developers though, just working out what version of the firmware is running on each chip on the board can become a painful task. (if the software is 'simple enough', this may not be a problem, but it does tend to grow...)
Often you're unaware that these things contain firmware. They're just sold as e.g. 'bluetooth controller', but internally, there's a largish processor, a chunk of RAM and firmware in ROM mask. The firmware versioning is implicit in the chip revision.
(Of course, this just moves the problem around; it's not uncommon for a chip revision to break software elsewhere in the system.)
> At what point do you consider a chip a 'computer'?
IANACS, but I'd say the point at which it becomes capable of running Turing-complete languages. This probably covers anything that has a firmware, save maybe if there exist firmwares programmed in limited languages that can't execute arbitrary computation.
Consider:
- Power management chips (of which there are dozens) each containing programmable MCUs
- Batteries, of course, contain one or more MCUs each
- Clocks
- 'Glue' MCUs for things like DMA controllers and USB controllers. (USB controller firmware has been exploited from the port side, and it's not upgradeable)
- Supervisors
- RGB LEDs (!)
- SD cards have several (see Bunnie's work)
- Ethernet, WiFi and Bluetooth controllers contain several small and usually a few large computers each
Some of these have fully-baked ROM code, some are programmed and modifiable through flash, and some have firmware written at driver load time to save money.