← Back to context

Comment by kjs3

6 hours ago

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.

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.

    • 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

    • 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.

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 :)

> 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?

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