After personal computers arrived in the 1970's they went through a series of revolutionary changes delivered by a series of different platforms. It's been over a decade since we've seen anything truly revolutionary, will we see a revolution again? I believe we could not only see revolution again, we could build it today.
Permalink for comment
To read all comments associated with this story, please click here.
The article mentions some good ideas on the third page. Here's my take on them:
In my ideal platform, we'd dump the "jumble of binaries" model and go to a "code database" model. Instead of shipping programs as binaries, programs would be shipped in a low-level intermediate representation. At installation, the intermediate code would be submitted to a central controller, which would compile the IL to native code and store it in a cache. This central controller would sit at the lowest levels of the system, even below the bulk of the OS.
The spiffy part of all this is that it'd allow for all sorts of cool optimizations:
1) Code could be optimized for each processor.
2) Analysis could easily cross library boundries, allowing optimizations like inlining of library code.
3) "Optimistic" optimizations could be applied, and backed out when the original assumptions that enabled them no longer applied.
4) IL code could be compiled via a safe compiler, which would allow us to get rid of memory protection between processes, and between the OS and user programs.
The performance benefits of this approach could be very significant, especially given the high-cost of protection-level transitions on modern processors, and their large dependence on compiler-time instruction scheduling and register allocation. This would also allow the underlying CPU architecture to become completely irrelevant. The only thing that would need to change when targeting a new CPU would be the code-generator in the central controller.
The article mentions some good ideas on the third page. Here's my take on them:
In my ideal platform, we'd dump the "jumble of binaries" model and go to a "code database" model. Instead of shipping programs as binaries, programs would be shipped in a low-level intermediate representation. At installation, the intermediate code would be submitted to a central controller, which would compile the IL to native code and store it in a cache. This central controller would sit at the lowest levels of the system, even below the bulk of the OS.
The spiffy part of all this is that it'd allow for all sorts of cool optimizations:
1) Code could be optimized for each processor.
2) Analysis could easily cross library boundries, allowing optimizations like inlining of library code.
3) "Optimistic" optimizations could be applied, and backed out when the original assumptions that enabled them no longer applied.
4) IL code could be compiled via a safe compiler, which would allow us to get rid of memory protection between processes, and between the OS and user programs.
The performance benefits of this approach could be very significant, especially given the high-cost of protection-level transitions on modern processors, and their large dependence on compiler-time instruction scheduling and register allocation. This would also allow the underlying CPU architecture to become completely irrelevant. The only thing that would need to change when targeting a new CPU would be the code-generator in the central controller.