Hacker News Reader

Comment by kjs3 | Hacker News Reader

Interesting combination of 'remarkable' and 'wtf' that we fling nuclear weapons around with the computational equivalent of a couple of TRS-80s[1]. I can only imagine the sighs of relief from the devs when things like the MIL-STD-1750a and later rad-hard SPARC and PPC variants came along.

[1] yes...I know the TRS-80 had a z80, not an 8085. Close enough.

View on HN

On the flip side, the fact that those processors were enough to steer spacecraft make me feel like there’s also a decent amount of remarkable wtf in how much compute we have now and how little we get out of each instruction on average compared to what people were doing with these z80 equivalents.

When you don't have the overhead of an operating system with decades of backward compatibility cruft, a scheduler, a virtual memory controller, and a file system you can accomplish amazing things with simple processors. Bare metal is something I'd encourage every programmer to try.

Yeah exactly, we now have so many layers of stuff. On top of vmem & OS, add high def displays, and today’s corporate firewall and malware scanning. I wouldn’t be surprised if just booting my Win 11 laptop, logging in, and launching Teams uses more compute than the entire Galileo mission used over its entire 8 year run. :P

Even without the layers & cruft though, the raw perf is astounding to those of us who remember 8 bit 1Mhz microprocessors. Today’s gamers are used to double-digit teraflops(!) of compute, just to render all the pixels for Minecraft or Fortnite.

I don’t know if there’s a better way these days, but for me Arduino has been an easy & super fun way to futz with a tiny bare metal microprocessor.

I actually have a 8085 Primer Trainer that I built/used in the 90s for school. [1] Programmed with pushbuttons and 7 segment LEDs. No backup memory so if you shut it off it lost it's program and you had to start over.

Not a programmer by trade, I prefer hardware...had no idea until recently how valuable the training was. We learned BASIC and 8085 machine code as well as building logic circuits from discrete parts. Then I used basically no code myself for 15 years until I learned Arduino. Knowing the basics certainly helped me know what was going on. From there it was just syntax for languages.

[1] https://flic.kr/p/2mkG7gC

on the other hand, now we have claude mythos... which is wtf returns even for a very large number of instructions...

You don't need much calculation power to manage a 30-min ballistic trajectory.

The inertial navigation system is the very crazy part, along with the nuclear fusion warhead design itself.

https://youtu.be/AazmxNs5kmE?is=2LE2q3rBSWDyTs7j

I was under the impression that the Trident II could do terminal phase maneuvering, so not a straight ballistic trajectory, but fair enough.

It controls the fusing, not positioning.

https://thebulletin.org/2017/03/how-us-nuclear-force-moderni...

Even hypersonic weapons with precision terminal guidance use truly ancient CPUs. Physics limits of molecular materials places a very low upper bound on the amount of compute required.

The rate at which an object in the physical world can alter its trajectory is ultimately limited by the strength of molecular bonds in the material it is made from. Exceed that limit and the object will disintegrate. This upper bound is extremely slow from the perspective of a CPU, making it computationally trivial. A computer can react orders of magnitude faster than the quickest physical objects.

I imagine you're correct about course correction speed, although I'd also expect that the materials and their properties are quite classified at present.

I would also imagine that there could be processing necessary that is mostly unrelated to manoeuvering speed (inlet/control surface management, etc). Perhaps some hypersonic experts could weigh in and let us know :)

The theoretical limits of materials science is undergrad chemistry. Among other things, the bond energy between atoms in a molecule tells you how much energy is required to break them. The strongest possible bond is less than 3x the energy of the ubiquitous carbon-carbon bond of organic chemistry. There is a bit more to it than this e.g. the lattice structure also matters, but you get the gist. You can specify an energy that is not particularly high that is known to exceed that required to destroy all molecular materials.

Real materials are considerably worse than theoretical and you also have to optimize for other properties. The classified part is often more about the processes for fabricating specific materials. This can be extremely non-obvious and difficult.

All the exposed surfaces of a hypersonic missile are themselves limited by material physics. A major problem in hypersonic research was material surfaces degrading so quickly that they lose precision of control. The CPU can send commands but the physical materials of the guidance system don't respond in a reliable way due to the material degradation.

Fun problems.

> I can only imagine the sighs of relief from the devs when things like the MIL-STD-1750a and later rad-hard SPARC and PPC variants came along.

What, so that they can debug in Chrome and put the fusing and inertial navigation processes in isolated web views?

The Apollo missions to the Moon didn't need much computational power either:

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

> [1] yes...I know the TRS-80 had a z80, not an 8085. Close enough.

Clearly you meant the TRS-80 Model 100.

Reply on news.ycombinator.com