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.
If you married these two current together, replaced the risc core in the Stretch with Transmeta's core you would have the best of both worlds.
Here is how I think it would work:
1. Write your program in c/c++ (other language)
2. Profile your code with the stretch tools to find locations for custom logic acceleration.
3. Compile your code to an "intermediate representation" with lots of optimisation hints (static optimisations) in the code.
4. When the software is installed it is compiled to the target hardware using hints found in the code, leaving some hints in.
5. When the code in running on the cpu it is being monitored by "code morphing" software to apply runtime optimisations and possibly find new code for custom logic acceleration.
The advantages I see for this approach are:
1. Always haveing highly ptimised code for your hardware: runtime optimisations for your actual usage patterns, better optimisations than Transmeta’s code morphing because of the static analysis.
2. Simpler/better code morphing software because of the pre-compiling to match the code morphing instruction set.
3. The ability to create new custom logic on the fly to enhance/ accelerate the code morphing software.
4. Software developers can take easy advantage of the Stretch FPGA abilities.
5. When improved cpus come out, new designs or with more resources the software can take advantage of it. ( Might require a installation recompile on cpu upgrade.)
6. Allow hardware acceleration of virtual machines by the code morphing software: Possibly look like coprocessors to the OS. (reduces the levels of abstraction / emulation. Eg java on JVM->X86->code morphing becomes java on code morphing) New instruction sets or virtual machines could be added by a plug in interface to the code morphing layer. The number of plug-ins per cpu would probability be small, but off set by the multiple cpus (eg 4)
I would like to tie two ideas together, 1: Untying distributed software from the target CPU hardware and 2: The use of FPGAs to provide custom logic/hardware acceleration.
These ideas are based the two products below.
http://www.transmeta.com/crusoe/index.html
http://www.stretchinc.com/products.php
If you married these two current together, replaced the risc core in the Stretch with Transmeta's core you would have the best of both worlds.
Here is how I think it would work:
1. Write your program in c/c++ (other language)
2. Profile your code with the stretch tools to find locations for custom logic acceleration.
3. Compile your code to an "intermediate representation" with lots of optimisation hints (static optimisations) in the code.
4. When the software is installed it is compiled to the target hardware using hints found in the code, leaving some hints in.
5. When the code in running on the cpu it is being monitored by "code morphing" software to apply runtime optimisations and possibly find new code for custom logic acceleration.
The advantages I see for this approach are:
1. Always haveing highly ptimised code for your hardware: runtime optimisations for your actual usage patterns, better optimisations than Transmeta’s code morphing because of the static analysis.
2. Simpler/better code morphing software because of the pre-compiling to match the code morphing instruction set.
3. The ability to create new custom logic on the fly to enhance/ accelerate the code morphing software.
4. Software developers can take easy advantage of the Stretch FPGA abilities.
5. When improved cpus come out, new designs or with more resources the software can take advantage of it. ( Might require a installation recompile on cpu upgrade.)
6. Allow hardware acceleration of virtual machines by the code morphing software: Possibly look like coprocessors to the OS. (reduces the levels of abstraction / emulation. Eg java on JVM->X86->code morphing becomes java on code morphing) New instruction sets or virtual machines could be added by a plug in interface to the code morphing layer. The number of plug-ins per cpu would probability be small, but off set by the multiple cpus (eg 4)