Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Link to Original Source
At CES today, Microsoft announced full blown windows coming to ARM. This is a very Apple like move for Microsoft, but without the whole "oh we had this running for 5 years before releasing it". Sounds like we are in for driver incompatibilities a million times worse than the Vista transition. Even worse, given that Windows biggest selling point is legacy application compatibility, requiring all third
That said, the problem of reconstructing a brain from DNA is something like trying to understand a self modifying genetic algorithm containing multiple parallel automata. To explain, I am going to conflate a couple of concepts. Self modifying code is reasonably well known. Consider a system where the hardware is an FPGA (i.e. can be reconfigured on the fly) and the program running on it a mix of a boot loader, independent hardware accelerated automata/agent programs, and some kind of feedback. The program contains an initial boot loader to load some data onto the FPGA, set up some accelerators and the capability to reprogram the FPGA. Then, it loads up some small agents, and some feedback controls. These agents run in parallel for a while, reconfiguring the hardware and/or the software of other agents or groups of agents, while the feedback control allows the minor selective mutation (through say bit stream corruption) of the programming. Some of the interactions of well definied automata are clear, but mutated automata interact in new and therefore unmodeled ways. The end result is the brain.
To sum it up, the DNA is just a small piece of the self modifying base code for the first initialization of the FPGA. The way the final FPGA is mapped depends on environmental factors (eg. which agent fired first, how did selection happen, small biases arising from the physical nature of the FPGA being propagated to wild changes in the end result). Thus, modeling just the base pairs is not sufficient as the interactions of the automata from the base pairs must be modeled as well.
Itanium was their clean room redesign, and look what happened to it. Outside HPCs and very niche applications, no one was willing to rewrite all their apps, and more importantly, wait for the compiler to mature on an architecture that was heavily dependent on the compiler to extract instruction level parallelism.
All said, the current instruction set innovation is happening with the SSE, and VT instructions, where some really cool stuff is possible. There is something to be said for the choice of CISC architecture by Intel. In RISC ones, once you run out of opcodes, you are in pretty deep trouble. In CISC, you can keep adding them,making it possible to have binaries that can run unmodified on older generation chips, but able to take advantage of newer generation features when running on newer chips.
The official roadmap for processes and feature sizes (called process nodes) are published yearly by the International Technology Roadmap for Semiconductors, a consortium of all the fabs. According to the 2009 lithography report. 25nm Flash is supposed to hit full production in 2012, thus inital deployments happen a couple of years before. Effectively Toshiba seems to be hitting the roadmap.
The takeaway being, theres nothing to see here, its progress as usual. The big problem is what happens under 16nm. Thats the point at which current optical lithography is impossible, even using half or quarter wavelength, and EUV with immersion litho.
The solution on the other hand seems pretty simple. Make the chipset block writes to the TSEG for the SMRAM in hardware (by disabling those lines) and use some extra hardware to prevent those lines from being loaded into cache. Finally, make every bios SMRAM update contain a parity and create tools that allow SMRAM parity check.