Industry-Wide Notebook Flaw Found
Thanks to "plato_capital"
Msg: 113890 on another board.
<<<Industry-Wide Notebook Flaw Found
Tom Krazit, IDG News Service
Hewlett-Packard (news - web sites) plans to let notebook customers swap out certain memory modules that HP says are compromised by a recently discovered design flaw, the company says.>>>
I wonder if this problem gives Transmeta an edge over Intel, AMD, VIA.
<<Intel's processors use power-management techniques such as throttling back the clock speed or shutting down portions of the chip when those areas or transistors are not required by a particular instruction stream. When the chip does this, it puts the memory module into what is called self-refresh mode, Kasik says. The memory chip can move into or out of this state thousands of times a second, he says.>>
Wow! It would seem to me purely from the lay observor's perch that Intel may have a problem here that Transmeta might not.
The problem is explained as possibly coming from clock speed throttling, which is not new, but possibly the increased frequency was a cause of the problem.
However, a more complicated problem might be created by Intel's other methodolgy of power saving - it's "rolling blackout" (my terminology) method of saving on computing power.
It would probably be a complicated issue to get "sectors" up "on line again" at the same time putting the memory module in and out of it's self-refresh mode, and coordinating this with every sector. Unless they use an overall swtich, but then how would that be different from the first solution Intel uses, the clock speed throttling?
From another angle, the advantage of using the market, "open source" is competitive innovation, of course. An advantage of making everything yourself is you can ensure compatability.
But Intel's sector-shut down methodology of power saving may cause a disadvantage - an incompatibility problem, with (here) the memory modules. What I am picturing is an octupus playing "patty-cake" with an unlimited number of unsynchronized outside manufactured memory modules. And these clock synchronizations would be dynamic on-the-run (sometimes called "on-the-fly") synchronizations, with possibly different delivery speeds, and if application driven, possibly in different combinations. Ouch!
Would Transmeta have the same problem or would the natural elegance of their CMS preclude this. I would presume they would be throttling down their VLIW engine, as the x86 "engine" is actually "virtual". So, to use my probably simplistic analogy, they would only have to play patty-cake between their VLIW engine and their x86 emmulation, in other words, one-partner-patty-cake (clock sychronization), all of which of course, would be done in-house.
And to go back to the first of Intel's methdologies (the clock speed throttling), Intel is throttling the X86, whereas, presumably, Transmeta is throttling the VLIW engine, and not the x86 virtual engine, "above". Could that not also make a difference? Eliminating compatability issues by stabilizing the x86 virtual engine's engaged presence (my term)?
Anybody have a clear idea or opinion on this? It's all very cloudy to me of course because my lack of specific knowledge and no technical training adds to my murk.
All in all, I would think, as a layperson, that Transmeta's elegance (as in the first two considerations) and ability to patch things up in a day with a software solution ( a third consideration) would be preferable to the rest of the industry when compared to Intel's Octupus patty-caking Centrino.
And who'se going to pay for HP's recall, I wonder?
Usually, simple is better.
JMHO, TIA, regards, etc. etc. and I would like to say I appreciate everyone's responses, if any, even those saying I should keep my day job, but would like to take any responses "off the air", probably. Busy and poor as a church mouse, and definitely not an engineer.
_tal
Market Data 
Markets 
AI
