Hacker News Reader

The reality is that 70-90% of a CPU is SRAM (cache and registers), and only a small portion is actual logic and even that is replicated across multiple cores. Factor in the extremely redundant gpu on the SoC with its own cores and SRAM along with the I/O controller and those billions of transistors boil down to a tiny amount of actual unique logic circuits. Still very impressive, but helps put things in perspective.

10 pct of 10 billion is still a billion ;)

> Those manuals indicate just a fraction of the complexity that lies inside of the device -- they describe features that I can use, not even how those features are implemented or made.

And even then:

1) There's parts of the manual which are brief summaries, written with the assumption you're already familiar with the larger standards they interface with. The SDIO and USBOTG sections of the reference manual come to mind in particular, not to mention all the external manuals it takes to describe the ARM Cortex-M architecture.

2) That's a fairly simple microcontroller. (Given the page count, it sounds like you're working with STM32F401.) The STM32H7 series reference manual is 3500+ pages.

> I recommend reading a datasheet of a chip sometime. It will put into perspective how much complexity there is in just a few millions of transistors.

I do miss working directly with small, simple (relatively), cheap chips. I don't miss dealing directly with the low level bus protocols though. I still have stress nightmares about diagnosing can bus and i2c bus problems with an oscilloscope. Like in the stress dream I'll either forget some important details about the protocol and not understand what is going on at all, or I will remember everything in perfect detail but be unable to speak and explain what's wrong to the other person who's there working on the issue.

The

    Intel® 64 and IA-32 Architectures Software Developer’s Manual Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D, and 4

has over 5000 pages!

[0] https://www.intel.com/content/www/us/en/developer/articles/t...

I'm out of date by a couple of years, but the last I knew, the ARM Architecture Reference Manual (amusingly, also called the ARM ARM) is around 8000 pages. Though, it carries similar corpus from the ARMv7 manual, now bottled as AArch32.

Some people might be wondering "huh, why number them in this weird way?!"

It's because they were originally 3 volumes. volume 2 is the ASM reference, 3 is the "how to do things" reference (System programming guide). Volume 1 is more of a general reference so maybe that's why it didn't grow so much.

If you want to gain a deeper understanding of how computers work, write an emulator of something relatively simple — GameBoy for example. This is kinda disillusioning. With the bugs you'll inevitably make, you'll understand how very, very, very dumb computers actually are. A CPU just fetches an instruction from memory, executes it, and updates the program counter. It does this indefinitely, for as long as power is applied. No magic whatsoever.

The GameBoy CPU is simple and easy to understand, sure, but modern ones are built upon the same basic principles, it's just that they run at much higher clock speeds and add lots and lots of parts (caches, pipelining, speculative execution, register renaming, multiple ALUs, SIMD ...) to execute as many instructions per clock cycle as possible. Also virtual memory support — MMU, TLB, all that stuff.

For the other side, if you want to build a CPU out of logic gates, there was a web-based game where you did exactly that. I don't remember the URL, sorry.

> you'll understand how very, very, very dumb computers actually are

That’s not true for any post 1995 desktop CPU.

They just adhere to that model and pretend that that’s all they’re doing but in reality there’s layers of supercomputers inside the CPU: micro-op cache, branch predictor, reorder buffer, rename buffer.

They extract hidden parallelism out of the code, run it in blazing fast multiple instructions per clock cycle (!), and pretend that nothing out of the order happened.

CPUs are extremely complex and extremely smart. They can have errors in their implementation where the unseen branches that it executed can be accessed by some processes, etc. But there’s nothing dumb about CPUs. They are made of a million man-hours of engineering.

The designs are smart. The CPUs themselves are still dumb, which is precisely the reason why speculative execution bugs exist. It's magic up until the point all the tricks spill out. In the end, it's always just logic gates wired together to do certain things — whether it's a Z80 or an M2 Max. All this layered complexity is simply the product of 50 years of iterative improvements.

I think this is just doubling down and simplifying CPUs to the point of uselessness.

What's the difference between a logic gate and when my index and thumb have a static charge jump between them? About a couple trillion dollars of research.

> In the end, it's always just logic gates wired together to do certain things

That seems to me a highly reductive point of view. The whole is always more than the sum of its parts.

"just" and "executes" are doing a hell of a lot of heavy lifting here

Some bits in the instruction activate some logic gates in the instruction decoder that, in turn, activate and deactivate other logic gates in the control logic, and eventually the appropriate functional unit inside the CPU is configured for the thing the instruction calls for and does it. Like the ALU adding two numbers together. If it's an architecture that uses microcode, like everything x86, I suppose the instruction decoder instead (or additionally?) outputs a microcode ROM address.

> there was a web-based game where you did exactly that

This is the one I played some time ago: https://nandgame.com/

You don’t really need to go in the millions to appreciate the complexity of a chip. The famous Motorola 68000 had actually 68000 transistors.

As far as I understand, chips are basically made of parts. CPU, of course, then one part for USB peripheral, another for USART, another for ADC and so on. Every peripheral is more or less a complete and isolated device. So if it's possible to get hands on this peripheral datasheet (I think it's called IP) written for chip designers, that would reveal complete complexity of the given part of the MCU.

Also I don't really have an idea, but I wouldn't be surprised, if a very significant part of transistor budget has been spent on SRAM or something similar, which is not very fascinating.

> A billion is a tough number to understand

I love using the money analogy for this:

"If you earned $1 every single second, that's $60 per minute, $3,600 per hour, $86,400 per day. More than most people make in a year!

Assuming no tax or expenditure whatsoever, it would take only 11 days to become a millionaire at that salary.

It would take over 31 _years_ to become a billionaire.

And that's only a mere $1 billion, some people are worth _hundreds_ of billions."

I don't think it's nearly as complex as you think. The important measure isn't transistors, but the amount of concepts formed by composing transistors together.

There's no way in hell people can make sense of 19 billion separate concepts. Likely what's going on in the chip is just repeated patterns designed to make a very simple machine operate really really quickly.

But of course I'm not denying the complexity. But the 19 billion implication here is a bit too much. It's likely just as complex as say linux.

> There's no way in hell people can make sense of 19 billion separate concepts. Likely what's going on in the chip is just repeated patterns designed to make a very simple machine operate really really quickly.

You are right about human designed chips. If you use something like simulated evolution or backpropagation or some other techniques from machine learning or mathematical optimization, you can get machines with billions of parts but not necessarily any clear pattern nor repetition.

The human brain might be an example of such a mechanism.

The human brain IS an example of such a mechanism.

We've done it artificially as well with machine learning and genetic algorithms.

The amount of concepts in the neural network of an LLM is too large for us to fully understand.

At best we can only hope to understand these things as a sort of curve fitting optimization problem.

I was using some weasel words, because the human brain does have some structure that we can decipher. Specific injuries to the brain, even in different people, tend to cause the same specific problems. (With heavy emphasis on 'tend to', this is not deterministic, like removing the 'e' key from your keyboard.)

We can do the same with LLMs. We can tease out some macro structure behaviors by looking at intermediate output from the feed forward network.

But you see how this is far from true understanding. It's like removing the WiFi module from a PC and you lose WiFi, therefore you know the WiFi module does WiFi stuff but in the end this action contributes nothing towards cohesive understanding of the PC.

>I sometimes have to take a moment, because I remember descriptions of alien technology from sci-fi books. Complexity, opaqueness, power. Chips.

Sufficiently advanced technology is indistinguishable from magic.

The wizzards can channel the power of lightning through rocks to produce porn, what a time to be alive.

hm, I dont feel the same way

you should do some coding closer to the chip

some bitshifting, some bit level manipulation

you dont have to be good at assembly, just do a hello world and make a mental visualization of the registers being hit

look up the OPCODES in your specific chipset , make some code to hit that specifically

make a process that does it as fast as possible and benchmark it, do it faster or slower on a different chipset, or a resource constrained environment

it makes it all really easy to follow and visualize

That's not even close to the chip. Dabbling around with the ISA doesn't tell you much about the micro architectural features of the chip. I'm sure "do some bit twiddling" is absurd advice for someone who has written a driver.

is all of it absurd advice? its about breaking abstract problems into smaller digestible problems to get a mental map

I dont think you need to write a driver for that map

Better advice would be to look at some of the open source RISC-V cores. They are nowhere near as complex as Apple's Axx silicon (probably not even 0.1%) but they demonstrate at least some of what goes on at the lower levels.

It's the power of abstraction.

It's turtles all the way down.

i do web development, not versed on the iot stuff.

i tried to read an Espressif ESP32 manual, blew my fucking mind on how complex it is relative to how cheap it is.

The expensive part is usually the engineering itself. Once the chip has been designed, manufacturing is relatively cheap. You can even get reasonably-capable MCUs for as little as $0.10!

Beautifully written!