[erwan577]

One of the idea I take from the piece is that CPU design success is intimately tied to the software ecosystem of the day and Memory Management Units were a big thing for C langage multitasking.

I wonder if Rust or similar could make the MMU transistors and energy budget redondant.

Disclaimer: I am a 68k fan.

[Someone]

> I wonder if Rust or similar could make the MMU transistors and energy budget redundant.

The MMU does two things:

- shields processes from each other

- creates the illusion that the machine has more memory that in it has

To do away with the former without giving up its benefits, the CPU would, somehow, have to know the code it runs won’t interfere with other processes. It could trust a particular compiler to produce code that’s safe, and rust could provide such a compiler, but then, the CPU would have to prevent Mallory (https://en.wikipedia.org/wiki/Alice_and_Bob#Cast_of_characte...) from producing a binary that he claims was created by that rust compiler, but isn’t.

One way would be to make the CPU run that compiler. The CPU then would not be able to run anything else than code compiled by that rust compiler. That may be seen as prohibitive.

Even if it isn’t, the CPU probably would not want to commit to being tied to one particular compiler. Checking that the actual output of the compiler is safe may be easier. That’s one reason why byte codes were invented. They decrease the coupling between programming language and CPU, allowing evolution of a compiler (often even compiler_s_, supporting multiple languages) independent of the byte code.

So, yes, you could use rust for the first item, but you probably don’t want to. Technologies such as the JVM, Microsoft CLR, or WASM are more suited for that kind of stuff.

Also, if you want to give processes the illusion that the machine has more memory that in it has, you would still need a MMU. It could be a bit simpler, but it still would be a MMU.

[adwn]

> I wonder if Rust or similar could make the MMU transistors and energy budget redondant.

No, those concerns are completely independent of each other. Rust's memory safety protects from accidentally accessing the wrong memory within the same address space, while the MMU protects against accessing (accidentally or intentionally) any memory in other address spaces.

In addition, the address translation done by the MMU has many more applications, like swapping, memory-mapped files, shared memory, copy-on-write after fork, or stack guard pages, none of which can be done by software alone.

[flohofwoe]

> ...accessing the wrong memory within the same address space

On systems without MMU there's only one shared address space (like on the Amiga, you only had lightweight processes/threads called Exec Tasks which all ran in the same global address space).

Rust could definitely help to isolate memory accesses of applications that all run in the same address space.

[erwan577]

Rust should help with the stability issues that plagued the 80s/90s before fully enforced memory protection. Now I wonder if MMU really brings other benefits.

In my latest workstation, I do not use virtual memory to use the disk as extra memory for my running software, i use compressed memory as a disk cache. 30 years of progress has changed the requirements and usecases. Maybe the MMU will survive in a different form that would require a new name.

I read the 4k virtual memory pages and TLB caches are becoming a performance bottleneck so this needs to be redesigned anyway.

[jabl]

Hypothetically, sure. One can imagine a system getting rid of virtual memory, and instead using e.g. some kind of capability system to prevent programs from reading memory they're not allowed to. In reality, there's so much software that assumes each process gets its own private address space that I find it very hard to imagine what a transition to this new MMU-less world would look like. Maybe something CHERI-like as an intermediate step?

[noobermin]

Btw, giving rust like safety is even more fine-grained than this, it would have to ensure ownership for pieces of memory within one program, which seems amazingly tedious to do in hardware.

[jabl]

Well, that's what CHERI does, more or less.

[noobermin]

Thanks for the name, after looking it up, it sounds interesting.

[noobermin]

We had a "sample" of this, at least according to the author, although it was in a less savory direction from those who care about memory safety and things like that: The M1 was optimized to run js shit faster apparently, which he claims is why the CPU is better for mobile machines (macbooks). Supposedly rust is too new for a new arch to design around it.

Tbh, and may be this is just the limits of my imagination, but I'm not sure what rust's guarantees would have on the ISA level, they usually concern safety on the application level. Systems programming in general still needs loads of unsafe blocks to actually work (see the debate a few weeks ago where Linus Torvalds critiqued a patch where rust folks wanted to change memory allocators in Linux so they could play nicer with safe rust code).

Like, ownership and move semantics are really a higher level concept and anything that happens within a single page the MMU will not care about with machines today, so this wouldn't be a small evolution but a completely different kind of arch. Again, may be I'm just to uninformed or lack the imagination.

[klelatti]

Here is the JS reference in the article.

> For example, they added a lot of great JavaScript features, cognizant of the ton of online and semi-offline apps that are written in JavaScript. In contrast, Intel attempts to optimize a chip simultaneously for laptops, desktops, and servers, leading poorly optimizations for laptops.

Now there is a JS feature in the M1. It's the FJCVTZS instruction "Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero" which ensures this conversion follows the JS specification. [1]

And this does indeed improve JS performance for Arm CPUs. But why does JS behave this way? Because it was specified to follow what x86 does!

So to say that 'M1 is optimised for JS but x86 isn't etc' is just plain wrong.

Also: - Apple didn't do it Arm did. - It has nothing whatsoever to do with memory management.

[1] https://stackoverflow.com/questions/50966676/why-do-arm-chip...

[masklinn]

Indeed, the few things I do already know of what the article talks about (very much including the javascript feature of the M1 you outline) are completely wrong, that makes the entire thing extremely suspect.

An other banger:

> Apple also does crazy things like putting a high end GPU (graphics processor) on the same chip.

They’re good but they’re not especially high-end, unless compared to other embedded GPUs like the ones in AMD’s APU, which… are rather comparable overall, and also single-die.

[klelatti]

I find it very frustrating. There are nuggets of interesting and relevant historical info and the central message of 'ISA isn't the most important thing for high end CPUs' is something I'd broadly agree with.

But it's all mixed with factual errors and iffy opinions (the Patterson and Hennessy textbook really isn't 'horrible').

[flohofwoe]

WASM would probably be a better fit for this problem. But I believe that software security ultimately needs to be tackled on the hardware level. It would be a bleak future if I'm forced to write programs for some platforms in a specific 'secure' high level language, this would hamper progress by competition in the programming language design space.

[pvg]

Memory Management Units were a big thing for C langage multitasking.

How do you figure? The article outlines MMU development since well before C, it's not like people came up with memory protection because of C.

[kragen]

PoohBear, it's because Smalltalk, Oberon, and J2ME systems didn't need MMUs. People came up with MMUs because of low-level languages, a category which includes assembly and C. But we're just rehearsing debates that are half a century old.

(On the other hand, the B5000 had hardware memory protection despite being programmed in Algol. The B5000 inspired Smalltalk, which inspired Oberon and Java. But its memory protection didn't use an MMU.)

[erwan577]

I was a user at the time, and also a reader of many computing magazines.

GUI environments of the 80s all brought multitasking with them, and system stability was mediocre to very bad... All writers pointed to memory protection as the cure of all this. See also Mac os history for a more detailed usecase.

Rising software size and complexity made the industry abandon assembly programming for higher level languages and for GUI apps this quickly meant C/C++.