I wonder if Rust or similar could make the MMU transistors and energy budget redondant.
Disclaimer: I am a 68k fan.
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.
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.
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.
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.
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.
> 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...
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.
But it's all mixed with factual errors and iffy opinions (the Patterson and Hennessy textbook really isn't 'horrible').
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.
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++.
(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.)