Its quite different what modern x86 CPUs do and what Transmeta tries to do. Or else they wouldn't have much to sell either.
The decoding modern x86 CPUs do is part of any CPU's execution process: fetch from RAM, decode, execute. Because x86OPs are too complex do desing a OoO engine, they break it into smaller pieces. But so does the PowerPC970. And even with P4's trace cache, the transformation is linear: 1 x86OP always yields the same N internalOPs.
Dynamic code translation (like code morphing) is more complicated. First the CPUs executes the translation software, which will read data from memory (the x86OPs to be translated) and then will write translated code to RAM. Only then the CPU will execute the translated code.
Transmeta tries to get it's edge from optimization and caching of translated code. But optimization is itself a CPU intensive process and there isn't that much information on the x86OP stream to optimize on.
Actually RISC compilers are known to use a lot more optimizations than CISC, because the ISA gives more freedom. Exotic stuff like loop pipelining comes to mind..
Maye a S/390:-D. Actually, OS usually eat up a piece of address space. For example, in a normal 32 bit Linux system each process can only have up to 3 GiB of memory -- the last 1 GiB is reserved for the kernel. I'm not sure how much Windows reserves, but I think its 2 GB.
Your comment, though correct, has absolutely nothing to do with the phenomena know as jitter related to CD Digital Audio Extraction.
Put simple, the problem lies in the fact that you can't accurately seek any bit on a CD-ROM (or HardDisk,etc for that matter). You need to add extra bits to the media so the drive can know where its at. Thats what syncronization headers are for. In a CD data track, there are syncronization headers for every 1024 bytes block. But in Audio tracks, there isn't such thing. So, you can only accurately seek the begining of the track. Therefore, the DAE process must be continous. If, by some reason (e.g., the host system can't sustain the I/O throughput), its interrupted it won't be possible to accurately resume it from where it was interrupted. Innacurately resuming it leads to errors, known as _jitter_. The alternative is to restart the extraction from the begining of the track.
That said, let me point out: this phenomena isn't always present. It only shows up if there are problems: dirty/scrateched CDs, bad CD-ROMs or systems too busy to sustain I/O, etc. So, with little effort its possible to achieve accurate extractions.
Also, the US IV, by definition, will be almost twice as fast as the US III for throughput, because it is two US III chips in one.
First, UltraSparc IV will be a Out-of-Order CPU. Any comparisson with the In-Order UltraSparc III ends here.
Second, "two chips in one" is misleading. It will be a CMP chip: multiple cores on one die, sharing external interfaces and higher levels of cache.
Thirdly, the performance gain of doubling the number of cores per die (or the number os CPUs in a system) doesn't mean it can provide twice the throughput.
The PRIVEK and PUBEK MAY be created by a process other than the use of TPM_CreateEndorsementKeyPair. If so, the process MUST result in a TPM and endorsement key whose properties are the same as those of a genuine TPM and an endorsement key created by execution of TPM_CreateEndorsementKeyPair in that TPM.
Making it short: though the TPM should NEVER export the PRIVKEY, a TPM may be programmed with a set of known keys.
You got confused with the FAQ. TCPA is not about proving futher means for software to determine access control. Thats what we already have. But software can be and is modified to ignore security control.
It works the other way arround: the TPM module will allow the software to access secure data only IF the software environment has the right integrity metrics. TCPA doesn't require anybody to enter a password. The keys needed to access the data are stored in the TPM (hardware), which will NERVER give them back out. It should be possible however to setup the TPM module with a set of known keys -- that should be stored in a safe place -- so you can access your data in an emergency.
Once the TPM gave it access to data, its up to the software (usually the OS) to provide proper access control to the data, as usual.
But you got the end result right: hard disk thieves are locked out, among other things.
Can you exemplify a TCPA based DRM system that presents a bigger threat than current, non-TCPA based, DRM systems?
Make sure a remote system is running in a trusted state.
Make sure data stored localy in a trusted environment can only be accessed by that trusted environment And by trusted environment, I mean an OS you installed,configured and control. This by oposition to thinks like:
Someone booted an OS they control in your machine and access/modified the data stored in it.
Someone took the harddrive and pluged it into a machine they control.
It doesn't forbid you to run any software, nor it requires that TPCA enabled software to be certified by some entity. You'll still have to trust the hardware and the software to do the right thing, as you do in the present. Nor does it seem to have much aplications for DRM.
Oversimplified, TCPA works like this. A TCPA system will have a hardware module (the TPM) with two functions:
It provides metrics of the software environment, in such a way that if is very hard to find two environments who don't share a root of trust but that yield the same integrity value.
It can encrypt/decrypt/sign data, but always based on the current metric. For example, it will only decrypt a piece of data if the integrity metrics have the same values they had when the data was encrypted. The key used to do this are stored in the TPM itself, who MUST NEVER give them back.
Therefore, the only ways someone can get to your secure data bypassing the enviroment you control is to:
Find a bug in the implementation
Do a chip level analysis of the TPM to get the keys stored in it. This can be done.. by major chips manufacters and a half-dozen other companies.:-)
Break cryptograpy..
There is a lot more to it, of course, like having multiple entities to preserve privacy among other other things. Check the specs, they're on the web for some reason.
However, he states that regular apps that donot require larger than 32-bit ints will see no performance increase on x86-64. My question is this: Would it be possible to "double up" the calculations by cramming more data into a single instruction if one were only using 32bit ints?
Yes and no.
Yes, its possible, if you have proper instructions.
IA-32 already has SIMD (Single Instruction Multiple Data) extensions (MMX/SSE/SSE2) that do this for 128 bit data packs. Using SSE2 for example, you can add 2 pairs of 64 bit integers, 4 pairs of 32 bit integers, 8 pairs of 16 bit integers or 16 pairs of 8 bit integers in a single instruction.
However, the instructions that operate with the General Purpose Registers don't suport this technique.And though they expanded the GPRs to 64 bit in x86-64, you still have the same 128 bit SIMD extensions as IA-32 and no SIMD capabilites with the GPRs.
So, the x86-64 ISA doesn't offer a real advantage over IA-32 in this sense. If you take a look at the capabilites of SSE2, you see that extending the GPRs to 64 bit doesn't offer a big advantage for integer numerical calculations. The reason to do so is addressing: like in IA-32 (and most ISAs), GPRs are used to store and perform calculations with addresses. So, to deal with 64 bit addresses, you need 64 bit GPRs and instructions.
f they had wanted to actually make money for their shareholders, they would have priced it at the same price as the fastest Intel chip. They would have marketed it harder. They would have offered it from the start with Linux or maybe (especially given the time period) BSD. They would have killed that True64 crap.
No, this comment is crap. A low-volume high-end CPU like the Alpha can in no way compete with a x86 CPU's price.
Linux? BSD? 10 years ago? Against a very respected Unix like Tru64? In what planet do you live?
The first thing you don't get: IA-64 is as much HP's baby as it is Intel's. Or maybe even more..
The reason why HP & Intel are ditching Alpha is because it never proved profitable. Developing this kind of high-end MPUs has become an economic problem: they are too expensive to develop.
Take a look arround. Alpha is fast but not profitable. Others, like PA-RISC, MIPS and UltraSparc lack performance (you can argue PA-RISC and even maybe MIPS development has been dismissed in favour of Itanium, but not UltraSparc).
Only IBM's POWER seems to have a future, thanks to IBM's investment in highly automated development methods.
IA-64 is HP and Intels solution to the problem: an ISA created to get by without complex Out of Order implementations.
Analog vs Digital.
In a perfect world, you would be correct. While converting an analog signal to digital you lose data (ou said in another way, you introduce quantization noise).
That noise has not to do with the 44.1 kHz samplig rate but with the 16 bits samples. Acording to Nysquist's theorem, if you're sampling at a 2N Hz rate, you can sample signals ups to N Hz without losing information.
So, why does the world keeps moving towards digitalized signals??
Because the world isn't perfect. In every system there is noise. But while in analogic signal will be affected more or less afected by any noise, digital signals may pass trough unchanged any noise that isn't powerfull enough to match the 0/1 treshold.
And vynils aren't an exception. Though they don't suffer from quantization noise, as they are analog, they end up introducing much more noise than CDs. So, CDs in fact have better quality.
However, there are vynils albuns that sound better than their CD versions. But this has to do with the production o the album, that was biased to get the best out of vynils and not CDs.
Filesizes are roughly similar for the same bit rate, for any of these formats -- bitrate = encodedsize/length.
You may however notice that the OggVorbis encoder often will produce files with an higher (and sometimes lower) bitrate than expected. This is due to the encoder's design, somewhat biased towards VBR encoding, and not very accurate when targeting a given bit rate.
However, OggVorbis sound better than MP3 for the same bitrate.
As for listening tests, these formats are targeted for humans, and part of the compression process is to throw away information, selected according to the response of the human ear. In the end, its how good it sounds to humans that matters. Any test software would have to be based on some model of human ears.
Slashdot Mirror
Its quite different what modern x86 CPUs do and what Transmeta tries to do. Or else they wouldn't have much to sell either.
The decoding modern x86 CPUs do is part of any CPU's execution process: fetch from RAM, decode, execute. Because x86OPs are too complex do desing a OoO engine, they break it into smaller pieces. But so does the PowerPC970. And even with P4's trace cache, the transformation is linear: 1 x86OP always yields the same N internalOPs.
Dynamic code translation (like code morphing) is more complicated. First the CPUs executes the translation software, which will read data from memory (the x86OPs to be translated) and then will write translated code to RAM. Only then the CPU will execute the translated code.
Transmeta tries to get it's edge from optimization and caching of translated code. But optimization is itself a CPU intensive process and there isn't that much information on the x86OP stream to optimize on.
Actually, there is no standard form of type punning in standard C.
In the GCC domain, the union is the correct way. Doing it with pointers is undefined behaviour.
Actually RISC compilers are known to use a lot more optimizations than CISC, because the ISA gives more freedom.
Exotic stuff like loop pipelining comes to mind..
Maye a S/390 :-D.
Actually, OS usually eat up a piece of address space. For example, in a normal 32 bit Linux system each process can only have up to 3 GiB of memory -- the last 1 GiB is reserved for the kernel.
I'm not sure how much Windows reserves, but I think its 2 GB.
Your comment, though correct, has absolutely nothing to do with the phenomena know as jitter related to CD Digital Audio Extraction.
Put simple, the problem lies in the fact that you can't accurately seek any bit on a CD-ROM (or HardDisk,etc for that matter). You need to add extra bits to the media so the drive can know where its at. Thats what syncronization headers are for.
In a CD data track, there are syncronization headers for every 1024 bytes block. But in Audio tracks, there isn't such thing. So, you can only accurately seek the begining of the track.
Therefore, the DAE process must be continous. If, by some reason (e.g., the host system can't sustain the I/O throughput), its interrupted it won't be possible to accurately resume it from where it was interrupted.
Innacurately resuming it leads to errors, known as _jitter_. The alternative is to restart the extraction from the begining of the track.
That said, let me point out: this phenomena isn't always present. It only shows up if there are problems: dirty/scrateched CDs, bad CD-ROMs or systems too busy to sustain I/O, etc.
So, with little effort its possible to achieve accurate extractions.
a) Its not a rummor. /. sometime ago
b) Its RFC compliant.
c) There was a lot of fuzz here on
Also, the US IV, by definition, will be almost twice as fast as the US III for throughput, because it is two US III chips in one.
First, UltraSparc IV will be a Out-of-Order CPU. Any comparisson with the In-Order UltraSparc III ends here.
Second, "two chips in one" is misleading. It will be a CMP chip: multiple cores on one die, sharing external interfaces and higher levels of cache.
Thirdly, the performance gain of doubling the number of cores per die (or the number os CPUs in a system) doesn't mean it can provide twice the throughput.
Isn't the NTFS filesystem, avaliable for Windows NT, 2000 and XP, journaled?
Right... and can you tell me from where in the specs you concluded that? No? Darn!
Making it short: though the TPM should NEVER export the PRIVKEY, a TPM may be programmed with a set of known keys.
You got confused with the FAQ. TCPA is not about proving futher means for software to determine access control. Thats what we already have. But software can be and is modified to ignore security control.
It works the other way arround: the TPM module will allow the software to access secure data only IF the software environment has the right integrity metrics. TCPA doesn't require anybody to enter a password. The keys needed to access the data are stored in the TPM (hardware), which will NERVER give them back out. It should be possible however to setup the TPM module with a set of known keys -- that should be stored in a safe place -- so you can access your data in an emergency.
Once the TPM gave it access to data, its up to the software (usually the OS) to provide proper access control to the data, as usual.
But you got the end result right: hard disk thieves are locked out, among other things.
Can you exemplify a TCPA based DRM system that presents a bigger threat than current, non-TCPA based, DRM systems?
Make sure a remote system is running in a trusted state.
Make sure data stored localy in a trusted environment can only be accessed by that trusted environment
And by trusted environment, I mean an OS you installed,configured and control. This by oposition to thinks like:
Someone booted an OS they control in your machine and access/modified the data stored in it.
Someone took the harddrive and pluged it into a machine they control.
It doesn't forbid you to run any software, nor it requires that TPCA enabled software to be certified by some entity. You'll still have to trust the hardware and the software to do the right thing, as you do in the present. Nor does it seem to have much aplications for DRM.
Oversimplified, TCPA works like this. A TCPA system will have a hardware module (the TPM) with two functions:
It provides metrics of the software environment, in such a way that if is very hard to find two environments who don't share a root of trust but that yield the same integrity value.
It can encrypt/decrypt/sign data, but always based on the current metric. For example, it will only decrypt a piece of data if the integrity metrics have the same values they had when the data was encrypted. The key used to do this are stored in the TPM itself, who MUST NEVER give them back.
Therefore, the only ways someone can get to your secure data bypassing the enviroment you control is to:
Find a bug in the implementation
Do a chip level analysis of the TPM to get the keys stored in it. This can be done.. by major chips manufacters and a half-dozen other companies. :-)
Break cryptograpy..
There is a lot more to it, of course, like having multiple entities to preserve privacy among other other things. Check the specs, they're on the web for some reason.
Yes and no.
Yes, its possible, if you have proper instructions.
IA-32 already has SIMD (Single Instruction Multiple Data) extensions (MMX/SSE/SSE2) that do this for 128 bit data packs. Using SSE2 for example, you can add 2 pairs of 64 bit integers, 4 pairs of 32 bit integers, 8 pairs of 16 bit integers or 16 pairs of 8 bit integers in a single instruction.
However, the instructions that operate with the General Purpose Registers don't suport this technique.And though they expanded the GPRs to 64 bit in x86-64, you still have the same 128 bit SIMD extensions as IA-32 and no SIMD capabilites with the GPRs.
So, the x86-64 ISA doesn't offer a real advantage over IA-32 in this sense. If you take a look at the capabilites of SSE2, you see that extending the GPRs to 64 bit doesn't offer a big advantage for integer numerical calculations. The reason to do so is addressing: like in IA-32 (and most ISAs), GPRs are used to store and perform calculations with addresses. So, to deal with 64 bit addresses, you need 64 bit GPRs and instructions.
No, this comment is crap. A low-volume high-end CPU like the Alpha can in no way compete with a x86 CPU's price.
Linux? BSD? 10 years ago? Against a very respected Unix like Tru64? In what planet do you live?
The first thing you don't get: IA-64 is as much HP's baby as it is Intel's. Or maybe even more..
The reason why HP & Intel are ditching Alpha is because it never proved profitable. Developing this kind of high-end MPUs has become an economic problem: they are too expensive to develop.
Take a look arround. Alpha is fast but not profitable. Others, like PA-RISC, MIPS and UltraSparc lack performance (you can argue PA-RISC and even maybe MIPS development has been dismissed in favour of Itanium, but not UltraSparc).
Only IBM's POWER seems to have a future, thanks to IBM's investment in highly automated development methods.
IA-64 is HP and Intels solution to the problem: an ISA created to get by without complex Out of Order implementations.
Analog vs Digital.
In a perfect world, you would be correct. While converting an analog signal to digital you lose data (ou said in another way, you introduce quantization noise).
That noise has not to do with the 44.1 kHz samplig rate but with the 16 bits samples. Acording to Nysquist's theorem, if you're sampling at a 2N Hz rate, you can sample signals ups to N Hz without losing information.
So, why does the world keeps moving towards digitalized signals??
Because the world isn't perfect. In every system there is noise. But while in analogic signal will be affected more or less afected by any noise, digital signals may pass trough unchanged any noise that isn't powerfull enough to match the 0/1 treshold.
And vynils aren't an exception. Though they don't suffer from quantization noise, as they are analog, they end up introducing much more noise than CDs. So, CDs in fact have better quality.
However, there are vynils albuns that sound better than their CD versions. But this has to do with the production o the album, that was biased to get the best out of vynils and not CDs.
You may however notice that the OggVorbis encoder often will produce files with an higher (and sometimes lower) bitrate than expected. This is due to the encoder's design, somewhat biased towards VBR encoding, and not very accurate when targeting a given bit rate.
However, OggVorbis sound better than MP3 for the same bitrate.
As for listening tests, these formats are targeted for humans, and part of the compression process is to throw away information, selected according to the response of the human ear. In the end, its how good it sounds to humans that matters. Any test software would have to be based on some model of human ears.