[PumpkinSpice]

It's this slow not because of the MCU, though, but because the author is emulating another architecture in software. It would be fairly sluggish on a PC too.

This is both very impressive in terms of the sheer amount of work that went into that, but also a tiny bit disappointing because it's not really Linux running natively on an 8-bit chip.

I suspect that native Linux is technically doable and would be a lot faster, but would require a lot of fiddling with the kernel, to the point where you'd be rewriting as much as you're keeping. A lot of assembly shims to port, gotta get rid of all the MMU code, etc. AVR chips in particular also also a bit weird because they follow the Harvard architecture - separate addressing for code and data, which is not something the Linux kernel is made for.

FWIW, modern 8-bit MCUs are actually pretty darn fast. They have clocks all the way to 50 MHz or so, single-cycle execution for most opcodes, some have DMA and other cool gizmos on the die. They are orders of magnitude faster than the 8-bit tech we had back in the 1980s.

[jdblair]

You could make a multi-tasking os with no memory protection (kind of like AmigaOS), and with a partially posix api. Is that still Linux?

[AlotOfReading]

That's basically just NuttX. Along similar lines is Zephyr, which is actually managed by the Linux foundation and broadly follows kernel conventions where reasonable.

[bestouff]

Yes, that's called uCLinux - linux without an MMU.

[swagempire]

Wait, isn't this Fuzix?

https://hackaday.com/2017/04/16/z80-fuzix-is-like-old-fashio...

[ladyanita22]

Yes, such a thing exists and its a build flag in the Linux kernel.

[DougMerritt]

Yep. IIRC the ubiquitous 8051 originally took 10-20 clocks just to execute a NOP, and everything else was even slower. For example.

[ladyanita22]

If we had to make a comparison, what would each Cortex M be equivalent to in microprocessors?

I wonder how fast is a Cortex M0, an M1, an M3, an M4 and a Cortex M7.

[PumpkinSpice]

It's really hard to meaningfully compare. They're designed for other things.

Most desktop or server CPUs prioritize massive parallelism, which is useful for OSes and multithreaded apps. In contrast, most MCUs have just one single-threaded core. CPUs are expected to run with sophisticated and bulky active cooling, so they reach speeds up to 3-5 GHz; in contrast, MCUs are almost always used without any added cooling and need to be power-efficient, so they seldom venture above 500 MHz. CPUs require external power controllers for dynamic voltage scaling to realize that performance. MCUs are often expected to run off a single supply, often something like "anywhere between 1.8 and 3.3 V". CPUs have a variety of hardware accelerators for operating on gobs of data (e.g., AVX vector instructions). In contrast, the most an MCU is typically expected to do is handle some low-resolution camera, and only some higher-end models have a hardware floating point unit.

Most benchmarks are optimized for desktop tasks too, so you can expect MCUs scores to be two orders of magnitude lower. But that doesn't mean they perform that much worse at the tasks they're intended for.

In situations where you need to do some real-time ML-based image classification, drive a 4K display, and stream H.265 videos, you generally don't reach for a traditional MCU, but for a CPU, with all the extra power supply complexity and thermal management issues this entails.

SoCs blur the line somewhat, because they often combine a CPU core, a graphics card, lots of memory, and a bunch of other things in a single package - making them essentially a fully-fledged computer that can run Linux, but is about as easy to integrate as an MCU. These are still slower than top-of-the-line desktops, but they're in the "one order of magnitude" territory.