LaurieWired Profile picture
May 23 4 tweets 3 min read Read on X
I miss the insanity of 80s processor design.

Intel’s iAPX 432 was a “micromainframe”.

It had no general purpose registers, supported object orientation *directly*, and performed garbage collection on-chip.

It was also 23x slower than an 8086. Here's why it failed. Image
Image
Intel targeted Ada so aggressively that C support was an afterthought.

Problem was, particularly at the time, the Ada compiler was extremely untuned and immature.

Scalar instructions were basically never used; *everything* was huge object-oriented calls. Image
Image
The “micromainframe” moniker wasn’t just marketing. One I/O chip could stitch together 63 CPUs on a single bus.

Essentially memory safe in-hardware; dangling pointers were impossible at the ISA level.

Partners like BiiN suggested using the CPU for nuclear-reactor control. Image
Image
Although the iAPX 432 was a commercial flop, the design lineage was appealing to unique, military applications.

Huges Aircraft used 35 i960 MXs (a rad-hard RISC chip birthed from the 432) for the main avionics of the F22.

The equivalent of 2 Cray super-computers on a single aircraft!

If you’d like to learn more about this unique ISA, check out Ken Shirriff’s blog. He goes into great detail about the history of the i960 design, and the 432 roots:
righto.com/2023/07/the-co…Image
Image

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with LaurieWired

LaurieWired Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @lauriewired

Sep 3
It’s time to get rid of frame rates.

In weird corners of the internet, researchers and standards committees discuss frameless video containers.

Sensor data as a continuous function, down-sampled to any frame rate you want.

Here's what it'll look like in 10 years: Image
Image
There’s two schools of thought, depending on the crowd you hang around.

NeurIPS folks tend to like continuous-time fields (software).

Hardcore EE types discuss event-based sensing (hardware, timestamps).

Bear with me, it's easier than it sounds: Image
Image
Consumers are gonna see continuous-time fields first.

It doesn’t require new cameras or hardware.

Take a video, re-encode frames into “extracted features”, decode with a ML model, refit to any framerate.

Popular topic at NeurIPS, MPEG Standard is already discussing it. Image
Read 5 tweets
Sep 2
Much like humans, CPUs heal in their sleep.

CPUs are *technically* replaceable / wear items. They don’t last forever.

Yet, the moment stress is removed, transistor degradation (partially) reverses.

It's called Bias Temperature Instability (BTI) recovery: Image
Image
Transistors are little switches.

When you hold a switch on, especially when it’s hot, a bit of charge gets stuck where it shouldn’t.

Every time that happens, it gets a little bit harder to switch.

In other words, the transistor gets a little “lazier”. Image
Over 10 years, in a modern processor, the ALU can slow down 6%!

FPGAs get hit even harder. Run it hard (slightly over-volted), and you’re looking at a few % a year of slowdown.

Not something the average user would notice, but definitely has to be accounted for. Image
Image
Read 5 tweets
Aug 29
I’ve been on a filesystem kick, and it’s interesting to see the DNA of older ideas pop up in modern designs.

BeFS was crazy in the 90s; the whole architecture was basically a searchable database.

Skimming through their book…it sounds a lot like current Apple FS design. Image
Image
Turns out there’s a good reason for that.

“Practical File System Design”, was written by Dominic Giampaolo in 1999, for BeOS.

Giampaolo joined Apple in 2002, where he became lead architect for…APFS.

Released in 2016, it's funny to see the same ideas 17 years later. Image
Image
In some ways, BeFS is still the more “modern” filesystem!

BeFS embedded search into the FS itself, Apple keeps the indexing+search layer separate.

Both love B-trees, per-file metadata, and 64-bit structures.

It's really not *that* different. Image
Read 4 tweets
Aug 21
Why do most uninterruptible power supplies still use old, lead-acid battery tech?

Nearly every battery in your house (phone, watch, even electric car) is lithium based...except UPSs.

It all has to do with battery chemistry. Lead-Acid has some unique advantages: Image
Image
Contrary to what you might think; lithium batteries are not a “straight upgrade”.

Lead-Acid handles being “floated” at near ~100% capacity for years.

Considering UPS’s spend 99.9% of their life sitting at full charge…waiting for an outage, it's an ideal use-case. Image
Lithium-based cells *hate* sitting at 100%.

The thermal management, per-cell protection, and balancing electronics are significantly more complex than lead-acid’s simple float charge.

Lithium UPSs do exist, but they are pricey and make some huge compromises. Image
Read 4 tweets
Aug 19
The West has a blindspot when it comes to alternative CPU designs.

We’re so entrenched in the usual x86, ARM, RISC-V world, that most people have no idea what’s happening over in China.

LoongArch is a fully independent ISA that’s sorta MIPS…sorta RISC-V…and sorta x87! Image
Image
Of course, Loongson (the company) realizes that most software is compiled for x86 and ARM.

Thus, they decided to add some hefty translation layers (LBT) built into the hardware.

LBT gives you for extra scratch registers, x86+ARM eflags, and an x87(!) stack pointer. Image
LoongArch is a *hefty* ISA; about ~2,000 instructions.
To put it in perspective, base RISC-V is like 50.

That said, it’s pretty clean to read. All instructions are 32 bits, and there are only 9 possible formats.

Certainly easier to decipher than modern x86. Image
Read 4 tweets
Aug 15
lp0 is a Linux error code that means “printer on fire.”

It’s not a joke. In the 50s, computerized printing was an experimental field.

At LLNL (yes, the nuclear testing site), cathode ray tubes created a xerographic printer.

...it would occasionally catch fire. Image
Image
State-of-the art at the time, the printer was modified with external fusing ovens hit a whopping…

1 page per second!

In the event of a stall, fresh paper would continuously shoot into the oven, causing aggressive combustion. Image
As tech later advanced to drum machines, the fire “problem” didn’t go away.

High speed rotary drums could cause enough friction during a jam to self-combust.

Even minor hangups needed immediate intervention. Image
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us!

:(