4 ms·

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

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.

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.