They kind of already do. From what we know, the SSD is connected directly to the M1 internal bus and the on-chip controller emulates NVMe protocol to communicate with the OS. The next logical step is to drop NVMe altogether and just go full custom, potentially exposing the SSD storage as byte-addressable physical RAM in a common address space. This would allow the kernel to map SSD storage directly, eliminating the need for any logical layer and dramatically improving latency. But I have no idea about these things and I don't know whether there are any special requirements that would make such direct mapping approach non-viable.
Saw this because ChrisA quoted it, and here's the reason it's not viable: NAND flash memory isn't byte-addressable. To read a single byte, you must read the entire page containing that byte, and a page is generally at least 2112 bytes (intended to be used as 2048 bytes data + 64 bytes extra for ECC data or other overhead). Additionally, page read latency is quite high compared to memory technology like DRAM. Things are even worse for writes, where there's a larger erase block size which means you really cannot write to random pages as doing so implies erasing a bunch of other pages first. So long as NAND flash is the memory technology of choice for high capacity SSDs, byte addressability is impossible.
(Intel/Micron 3D Xpoint, aka Optane memory, is byte addressable nonvolatile memory. It has random performance close to DRAM, but lower density and thus higher cost per bit than NAND flash. You've probably heard of Optane SSDs, but Intel also has support for Optane DIMMs in some Xeon processors, which is the kind of interface you need if you want to have nonvolatile storage exposed directly to the CPU. However, the cost has made it a non-starter for consumer systems, even in SSD form.)
Another point about Apple Silicon SSDs - There is no emulation of NVMe protocol going on. It's just a NVMe SSD with some proprietary Apple extensions to NVMe designed to offload FileVault encrypt/decrypt to the SSD controller.
Yes. It is about time to revisit Multics.
Just over 50 years ago, in 1969, The OS called "Multics" was released. It was revolutionary, but one feature really was brilliant. It used a unified RAM and storage. Just like the above quote, the OS did not make a distinction between the files on the disk and RAM. It was all just byte addressable random access storage. This was done in 1969 so the idea is not new.
Multics had a normal file system. (though when I say "normal", I should mention that it actually pioneered a lot of the file system attributes we now regard as "normal".)
It didn't unify RAM and storage in any way we cannot do today, right now, on macOS or Linux. What I think you're interpreting as unifying RAM and storage was just that the standard API for interacting with files on Multics was the equivalent of mmap() on UNIX-descended operating systems like macOS.
There has been operating systems research around the concept of truly globally persistent RAM, but as far as I know nobody has ever built anything like a general purpose desktop computer based on it.
