3 ms·

> The question for me would be whether this is truly a drop-in replacement for either disk or RAM a single device would not be a drop-in replacement of both RA

> The question for me would be whether this is truly a drop-in replacement for either disk or RAM a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. a replacement for one or another could be possible for today's machines, though. or both, if you have two devices with the correct connectors. but not both if they share address space. what does it mean for an operating system, or even an application, to "start up" when all that really means is moving data to RAM so it can be accessed quickly enough? when storage and RAM do finally converge, there will be no "boot" process in the conventional sense. you will power the device up and it will be ready instantly; everything is already "in RAM" the instant power is applied.

staticassertion 5y ago
Well, more than that happens when a program starts up. It's mapped in, libraries will be dynamically linked in, an address space has to be allocated, a process structure has to be allocated, memory has to be mapped as executable, etc. I don't think we would want "program on hard drive" and "program in memory" to be isomorphic for a bunch of reasons, one being security.
- naikrovek 5y ago
  There are mitigations for the security concerns; the new architecture I envision is a new architecture, we can do things correctly and intelligently. don't let your x86 experience cloud your view of what can be done. just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. > Well, more than that happens when a program starts up. of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. > I don't think we would want "program on hard drive" and "program in memory" to be isomorphic that is one of the biggest potential reasons to use the technology in question, and one of the biggest reasons that it is being worked on.
  - staticassertion 5y ago
    > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Sure, that'd be cool, like segmentation registers. > of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. That's fair but it did seem like a central part of your point was that "starting up" was equivalent to existing on disk - though I suspect I was misreading your post.
  - chx 5y ago
    > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Heh. Everything old is new again. I think the VM/370 was the first to do this in 1972.
rbanffy 5y ago
> a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. The AS/400 was like that - a single address space for everything. Its descendants still do that to this day as IBM's midrange server family (right below the mainframe line). We've kind of been there with Smalltalk and image-based Lisp machines - from within the image, everything seems persistent. It's not as cool as it seemed to be back then - being able to reset to a known clean state is useful and having no distinction between what is persistent and what shouldn't be creates some interesting problems. Worth noting though that computers that had ferrite core memories worked like that. RAM contents were intact after a power loss and the original internet routers, based on the Honeywell H316, shipped with their software loaded into the core memory.

staticassertion 5y ago

Well, more than that happens when a program starts up. It's mapped in, libraries will be dynamically linked in, an address space has to be allocated, a process structure has to be allocated, memory has to be mapped as executable, etc. I don't think we would want "program on hard drive" and "program in memory" to be isomorphic for a bunch of reasons, one being security.

naikrovek 5y ago
There are mitigations for the security concerns; the new architecture I envision is a new architecture, we can do things correctly and intelligently. don't let your x86 experience cloud your view of what can be done. just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. > Well, more than that happens when a program starts up. of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. > I don't think we would want "program on hard drive" and "program in memory" to be isomorphic that is one of the biggest potential reasons to use the technology in question, and one of the biggest reasons that it is being worked on.
- staticassertion 5y ago
  > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Sure, that'd be cool, like segmentation registers. > of course more than that happens. I am trying to make a point and not document the minutia of the entire boot process of a modern x86_64 computer. That's fair but it did seem like a central part of your point was that "starting up" was equivalent to existing on disk - though I suspect I was misreading your post.
- chx 5y ago
  > just like an MMU can restrict what process(es) can access a particular byte or block of RAM, something similar could restrict access to a common storage medium. Heh. Everything old is new again. I think the VM/370 was the first to do this in 1972.

rbanffy 5y ago

> a single device would not be a drop-in replacement of both RAM and SSD for today's computers. fundamental assumptions are made at the architecture level of today's computers which preclude RAM and bulk storage being anything but separate. The AS/400 was like that - a single address space for everything. Its descendants still do that to this day as IBM's midrange server family (right below the mainframe line). We've kind of been there with Smalltalk and image-based Lisp machines - from within the image, everything seems persistent. It's not as cool as it seemed to be back then - being able to reset to a known clean state is useful and having no distinction between what is persistent and what shouldn't be creates some interesting problems. Worth noting though that computers that had ferrite core memories worked like that. RAM contents were intact after a power loss and the original internet routers, based on the Honeywell H316, shipped with their software loaded into the core memory.