Stretch Announces Chip That Rewires Itself On The Fly 311
tigre writes "CNET News reports on a chip startup call Stretch which produces the S5000, a RISC processor with electronically programmable hardware so that it can add to its instruction set as it deems necessary. Thus it can re-configure itself to behave like a DSP, or a (digital) ASIC, and perform the equivalent of hundreds of instructions in one cycle. Great way to bridge the gap between general-purpose computing and ASICs."
virus hitting the hardware (Score:5, Insightful)
New application-speed records to be set... (Score:5, Insightful)
Effective application speed was never based on a cycle count alone, because different processors can have better instruction sets for the given application. The main breakthrough here is that this chip leaves "user-definable" space in its instruction set so they can re-optimize the instruction set on the fly. Whatever you're running, its most commonly used functions can almost slide from being code to being "on the chip" and that's sure to speed up the experienced speed.
Yeah, I know its a
so does that mean... (Score:3, Insightful)
yawn ... (Score:4, Insightful)
[okay, okay, so it'll be -hell- fun to design codecs and other protocols that can switch their chipset dynamically, yeah, but i'd need 1000's of them deployed to have a real reason to do it...]
This is a setback for crypto-land... (Score:5, Insightful)
In short, the time-to-crack using consumer technologies for almost any form of crypto is about to take a step backwards. It won't "break" anything, but the brute force combinations will be able to be examined in a faster time, meaning higher standards will be needed for the same level of protection you have today.
Not surprising, these breakthroughs will always keep coming...
How is it possible? (Score:5, Insightful)
Reduced Benefits for Virtual Machines? (Score:4, Insightful)
Sounds good on paper, but... (Score:5, Insightful)
Yes sure, rewirable chips would be cool for certain applications, but how does one go about making it deal with multiple applications with multiple needs? You'd over load the CPU with a truckload of specialized instructions - which would probably slow it down. Granted, I see uses in things like mobile phones, but for multitasking machines, a 'Jack of all trades' chip is the way to go.
Re:This is a setback for crypto-land... (Score:2, Insightful)
Re:Not really new technology (Score:2, Insightful)
Re:Ummm... (Score:2, Insightful)
See the script [sfy.iv.ru]
new concept, but not new hardware (Score:4, Insightful)
This will be useful in places that they mentioned. Places where you do a lot of processing that takes many generic instructions but can be translated into a single string of descrete instuctions.
The more I think about it, this is the direction processors are going. We keep moving processors towards RISC based cores. We keep adding specialized paths for things such as multimedia. Eventually we WILL have half the processor being a purely RISC core and half being programmable hardware for specialized computational intensive instructions. I retract my initial view.
I do wonder though, what the life is on the hardware side. How many times can you reprogram the hardware before it starts to die. What is the error rate in reprogramming it? What happens when a few programmable transistors die?
Re:This is a setback for crypto-land... (Score:4, Insightful)
If you insist on putting words in their mouth, then yeah, you might consider it a set back. But that's your misunderstanding, not theirs. All reputable encryptors have accounted for Moore's Law in their cost/benefits tradeoffs. Since it doesn't take much encryption power before it requires computers larger then the Universe to crack it via brute force (and since "cracks" on good encryption are really typically just ways of collapsing the search space, not procedures that give immediate answers, often adding more bits will require Universe sized machines, too), this isn't that big a deal for encryption. Push your key size up and be done with it. Even conventional machines can handle that today, it just takes longer.
Real World Performance (Score:2, Insightful)
Natural questions come to mind like how quickly does the chip configure itself to optimize for the application, does the configuration only occur at start of the application, how many chip-configuring applications can it run concurrently, will it optimize for interpreted languages, can some configurations be made "permanent" to accommodate the OS used. I can see how this chip would optimize some specialized tasks, but I don't know if it will run well in an evironment where many different types of tasks are expected to run at the same time.
Another issue relating to the gaining acceptance is whether Stretch releases specs so that others can write their own compilers. Is Stretch pursuing a pure hardware strategy (not trying to sell compilers, create their own OS, etc)?
Re:virus hitting the hardware (Score:4, Insightful)
People developing along similar lines must have means of controlling the new circuitry so that hot spots don't form on the die. Especially if they provide analog capability. It could be too easy to set up a feedback that could really trash that part of the die.
Which brings up another thought: Do they have an on-board controller that tracks what parts of the die are usable and what aren't? If they do, they can have seriously high production yields.
In fact, I wouldn't be surprised if such a self-diagnostic utility made its way into modular dies with specialized circuitry. So a processor could run on two AMUs instead of three, and so forth.
Compelling market proposition? (Score:3, Insightful)
stop the madness. (Score:3, Insightful)
The same way you detect a virus on any machine that has been compromised, with another machine and or a thorough understanding of normal operation and running processes. Nothing new here. Evaluate the harm done by a potential compromise and take steps accordingly.
There is no practical difference between a hardware and a software compromise and the remedy is the same. Indeed, for critical purposes, there's little difference between a hardware compromise and a simple failure. You should anticipate it and not get burnt. The bottom line is know your shit and be in control when strange things happen.
Security is a process and must be applied system wide. If you don't have reasonable configuration control, you are already lost. If you run junky closed software that's full of bugs and does not keep track of uid, pid or processes themselves you are always in for a rough ride. The trouble given you there will distract your operators, like it did for the last big blackout. Every piece has to be taken considered in context. It's not hard, it just takes time, organization and judgment.
I hate how Ludites always look at any new tool and cry out, "look how awful [insert wonderful new power] is!"
Based on Tensilica Xtensa technology (Score:2, Insightful)
Re:virus hitting the hardware (Score:3, Insightful)
A Minor change in the instruction set would likely render the OS dysfunctional - and while that would certainly get attention - it would not propogate very well.
There is a math about viruses which requires them not to kill their hosts, and to do as little damage really as they can bear. Damaging viruses get high priority on fix lists and would get shut down more quickly than less harmful viruses.
I think a CPU change virus would be a rather self-defeating proposition.
Re:Insightful?! (Score:3, Insightful)