Here is a taste of Monty Python. It's the Spam skit in Real Audio. One of their classic skits from Flying Circus. The movies are not to be missed either.
It's more complicated than that. OLAP applied complicated (usually proprietary) statistical algorithms to (entire) complex databases in order to extract information which isn't immediately apparent from just looking at a piece.
1. Pointy-Haired Boss...see that "boring" layer of computers known as Dilbert.
2. On Line Analytical Processing. Data Warehousing, Data Mining [insert other buzzword here. Not my cup of tea, certainly. But I'm not sure that you can call it the "boring" layer!
I just want to warn you that most of what the "expert" Richard Belgard has to say on the matter is nonsense. I sent a message to the Journalist who wrote the article, here it is:
I was reading your recent article regarding the Transmeta patents. I develop compilers and so have some background in the area of low level processor archetecture, specifically exception handling.
I'm not sure who Richard Belgard is but much of what he says regarding the patent is nonsense. He may know patents but his interpretation of the patent is largely misguided.
First, some corrections: Your article states: "Transmeta could be able to sell its chips at a lower, more-competitive cost by avoiding fees it would otherwise have to pay to license Intel patents"
While it may be true that Transmeta can save money by avoiding Intel's patents. That is not why this method will be more inexpensive. The reason the chip will be cheaper is because it is VLIW. That makes for a simpler processor design and more inexpensive chip. Many optimization functions are offloaded, making for a simpler chip. Simpler also translates into higher clock speeds (faster chip).
Later, the article says: "those instructions are stored in memory--either conventional memory or high-speed "cache" memory--so they can be called upon quickly. Because of this method, the Transmeta chip would be good at performing the same instructions over and over, a circumstance that wouldn't force the delays imposed by the translation process...That could make the Transmeta chip a good choice for something like a router..."
I'm not sure why the cache is focused apon so much. It really is an unimportant part of the patent. caches are used very commonly and it's use here is common sense. Regarding the sugestion that the chip may be good for something like a router, that's pretty silly as well. Routers and set top boxes are specialized and therefore don't need to emulate another processor. Using their own processor makes much more sense. Emulation would just be a waste.
Later: "Specifically, it describes when a step in the translation is complete enough that it should be stored in memory"
That is aproaching accurate, but isn't how I would describe it. I'll approach this one a little differently.
Problem: Emulation is slow because state (that is, a 'snapshot' of the processor's...well...state) must be stored for each instruction executed. This is in case an unexpected event or error occurs. This takes up time and makes it so that instructions cannot be reordered for efficiency.
Solution: Store memory writes in a buffer until a 'commit' happens. At this time the processor checks if any of the previous instructions generated an error. If not the buffer is written to permanent memory. If so, the processor can roll back to the point of the error and handle it appropriately.
I cannot stress enough how important this is from a feasability standpoint. This jumps over one of the major hurdles of emulation.
Another small point; Comparing this to AMD or Cyrix attempts is like apples and oranges. They have made clones. This is an emulator. That's why the mention of Intel's patents is a little strange in this context. It isn't intended to create an Intel clone (like AMD or Cyrix). This is an attempt to create a generic "processor agnostic" chip, capable of running anything, as far as I can tell...including Merced. It's important to also note that this chip can apparently run it's own native code as well.
If you have any questions, e-mail casey@sarahandcasey.com
I'd love to see us go metric, but I think we're about 200 years too late to make a conversion without destroying the economy.
So what you are saying is that all the other countries in the world (I think there are one or two minor exceptions) managed it but we can't? The UK and Canada switched in the 60's and 70's...when we were supposed to...hardly 200 years ago. The treaty of the metre was only signed in 1875. Again...not 200 years ago. It wasn't even standardized to SI until 1960! I sugest you read this for a history of metric.
Oh come on! That tired old argument has been used for years! Two points: 1. It's a one time cost. 2. The savings will be astronomical, even in the first year. Besides, they've been teaching us metric in school for years. It's not my problem if no one listened.
Thank You!!! I've been shaking my head over this for days. The only reason it's being called a hoax is because some mainstream media fell for it. I mean c'mon...it's like saying that The Onion is a hoax.
At what point am I going to stop just reading about the culture and the people (else) and all the neat toys and actually become a geek myself?
Well, you're thinking about it the wrong way. While University will get you credentials, you've got to do things...on your own. I for example, started delving in to the bowels of computers when I was 14. How to become a geek in 6 easy steps: 1. Get yourself a cheap computer. 2. Install Linux w/ EGCS and kernel. 3. Look at the kernel. 4. Change something that looks interesting. 5. Re-install your now broken Linux kernel. 6. Repeat as necesary.
Of course I'm oversimplifying here, but what I'm trying to say is that there is a point where planning ceases to become useful and turns into stalling. The ultimate objective here is that learning becomes effortless. You're no longer learning but doing something which happens to get assimilated into your "map"(to borrow the terminology in the essay). Don't learn so you can program...program so you can learn. Okay...I'm getting trite now, so I'm going to leave.
No, you're all reading this wrong. Look at the bottom of the patent, with the code samples. Notice the use of the word commit. That's basically an exception barrier. At that point, the stores actually occur. trapbarriers are used commonly on the Alpha. A number of instructions are executed, then when a trapb happens, any exception which occured in that block of code fires. This is a hardware method of rolling back stores to get the exact state at the time of exception without tracking state on an instruction by instruction basis. Allows for pipelining, scheduling, etc. Read this comment for more from me!
By fault I mean exception or error (which is exactly what the patent says...guess that's why I don't write patents!). That is, by nature, "exceptional". The problem, to expand furthur, is that checking for an exception slows down execution of the "normal" code path. That's why traps are used. The processor then only has to check at certain user (by that I mean compiler, usually) defined places. The problem is that this makes things more complex (and much slower, at least on the Alpha) when the exception actually occurs.
Heres a very small quote from the patent that should clear this up:
2. A gated store buffer for controlling the execution of memory store operations to system memory generated during execution of a sequence of instructions by a processor comprising:...
Remember, processor instructions eventually operate on data...data that will be permanently stored in memory! If you have an instruction that faults preceeding one or several store operations (I refer to instructions which store to RAM, as opposed to a cache or something) then a trab barrier (sorry, I'm using Alpha-centric terms here), you've changed the contents of the RAM erroneously(sp). The instructions should never have issued and RAM should not have been modified. That's where permanent memory stores come in.
Pick up a copy of the Alpha Architecture Reference Manual and look up trap shadows. Rollback can be very useful when pipelining instructions because there is no guarantee of precisely where a fault issued from. Precise exception trapping is slower and more complicated. Read this for more!
Take the code, translate it. Store it in the cache until it is verfied, then execute it.
I'm not sure that's quite right. What I gleaned was: Take the code, translate it, execute it, cache it at the same time, when a trap barrier of some sort is hit, verify no faults. If there are faults, roll back based on the cache to the exact point of the fault. This is very important! Read this comment for more information.
Slashdot Mirror
Here is a taste of Monty Python. It's the Spam skit in Real Audio. One of their classic skits from Flying Circus. The movies are not to be missed either.
To celebrate: Cans of SPAM for all techies!
Sadly, pythonline seems to be serving up the default "you installed Apache" web page today. Where'd the site go today of all days?!
That's right...They usually use name their projects internally by some location.
Unless you work at Intel, AMD, or Motorola.
:)
Ahem...you forgot us Digital/Compaq Alpha people!
Perhaps it really is a fitting name for this new chip after all?
Maybe...but I'd put my money on Itanic
Uhhh...no. Elves are short...about 4-5 feet tall on average.
Actually...yes. That is why the data warehousing applications tend to be proprietary. They hire statisticians and mathmaticians to deal with it.
It's more complicated than that. OLAP applied complicated (usually proprietary) statistical algorithms to (entire) complex databases in order to extract information which isn't immediately apparent from just looking at a piece.
1. Pointy-Haired Boss...see that "boring" layer of computers known as Dilbert.
2. On Line Analytical Processing. Data Warehousing, Data Mining [insert other buzzword here. Not my cup of tea, certainly. But I'm not sure that you can call it the "boring" layer!
That message was actually from me...someone ate my cookies!
I just want to warn you that most of what the "expert" Richard Belgard has to say on the matter is nonsense. I sent a message to the Journalist who wrote the article, here it is:
I was reading your recent article regarding the Transmeta patents. I develop compilers and so have some background in the area of low level processor archetecture, specifically exception handling.
I'm not sure who Richard Belgard is but much of what he says regarding the patent is nonsense. He may know patents but his interpretation of the patent is largely misguided.
First, some corrections:
Your article states: "Transmeta could be able to sell its chips at a lower, more-competitive cost by avoiding fees it would otherwise have to pay to license Intel patents"
While it may be true that Transmeta can save money by avoiding Intel's patents. That is not why this method will be more inexpensive. The reason the chip will be cheaper is because it is VLIW. That makes for a simpler processor design and more inexpensive chip. Many optimization functions are offloaded, making for a simpler chip. Simpler also translates into higher clock speeds (faster chip).
Later, the article says: "those instructions are stored in memory--either conventional memory or high-speed "cache" memory--so they can be called upon quickly. Because of this method, the Transmeta chip would be good at performing the same instructions over and over, a circumstance that wouldn't force the delays imposed by the translation process...That could make the Transmeta chip a good choice for something like a router..."
I'm not sure why the cache is focused apon so much. It really is an unimportant part of the patent. caches are used very commonly and it's use here is common sense. Regarding the sugestion that the chip may be good for something like a router, that's pretty silly as well. Routers and set top boxes are specialized and therefore don't need to emulate another processor. Using their own processor makes much more sense. Emulation would just be a waste.
Later: "Specifically, it describes when a step in the translation is complete enough that it should be stored in memory"
That is aproaching accurate, but isn't how I would describe it. I'll approach this one a little differently.
Problem: Emulation is slow because state (that is, a 'snapshot' of the processor's...well...state) must be stored for each instruction executed. This is in case an unexpected event or error occurs. This takes up time and makes it so that instructions cannot be reordered for efficiency.
Solution: Store memory writes in a buffer until a 'commit' happens. At this time the processor checks if any of the previous instructions generated an error. If not the buffer is written to permanent memory. If so, the processor can roll back to the point of the error and handle it appropriately.
I cannot stress enough how important this is from a feasability standpoint. This jumps over one of the major hurdles of emulation.
Another small point; Comparing this to AMD or Cyrix attempts is like apples and oranges. They have made clones. This is an emulator. That's why the mention of Intel's patents is a little strange in this context. It isn't intended to create an Intel clone (like AMD or Cyrix). This is an attempt to create a generic "processor agnostic" chip, capable of running anything, as far as I can tell...including Merced. It's important to also note that this chip can apparently run it's own native code as well.
If you have any questions, e-mail casey@sarahandcasey.com
Y2K is a one time cost, too
Apples and Oranges.
I'd love to see us go metric, but I think we're about 200 years too late to make a conversion without destroying the economy.
So what you are saying is that all the other countries in the world (I think there are one or two minor exceptions) managed it but we can't?
The UK and Canada switched in the 60's and 70's...when we were supposed to...hardly 200 years ago. The treaty of the metre was only signed in 1875. Again...not 200 years ago. It wasn't even standardized to SI until 1960! I sugest you read this for a history of metric.
Uhhh... 1/100th of an inch is .254 mm. 1/10th of a mm is .1 mm. That means the millimeter is more acurate. (shaking my head in disbelief)
Oh come on! That tired old argument has been used for years! Two points: 1. It's a one time cost. 2. The savings will be astronomical, even in the first year. Besides, they've been teaching us metric in school for years. It's not my problem if no one listened.
It's just these sorts of instances which make me proud to be an American.
Simpler?
Cheaper?
Less error prone?
Who cares! That's why I use hexidecimal for all of my Imperial measurement needs!
Thank You!!! I've been shaking my head over this for days. The only reason it's being called a hoax is because some mainstream media fell for it. I mean c'mon...it's like saying that The Onion is a hoax.
At what point am I going to stop just reading about the culture and the people (else) and all the neat toys and actually become a geek myself?
Well, you're thinking about it the wrong way. While University will get you credentials, you've got to do things...on your own. I for example, started delving in to the bowels of computers when I was 14.
How to become a geek in 6 easy steps:
1. Get yourself a cheap computer.
2. Install Linux w/ EGCS and kernel.
3. Look at the kernel.
4. Change something that looks interesting.
5. Re-install your now broken Linux kernel.
6. Repeat as necesary.
Of course I'm oversimplifying here, but what I'm trying to say is that there is a point where planning ceases to become useful and turns into stalling. The ultimate objective here is that learning becomes effortless. You're no longer learning but doing something which happens to get assimilated into your "map"(to borrow the terminology in the essay). Don't learn so you can program...program so you can learn. Okay...I'm getting trite now, so I'm going to leave.
No, you're all reading this wrong. Look at the bottom of the patent, with the code samples. Notice the use of the word commit. That's basically an exception barrier. At that point, the stores actually occur. trapbarriers are used commonly on the Alpha. A number of instructions are executed, then when a trapb happens, any exception which occured in that block of code fires. This is a hardware method of rolling back stores to get the exact state at the time of exception without tracking state on an instruction by instruction basis. Allows for pipelining, scheduling, etc. Read this comment for more from me!
Not quite...It can execute instructions without checking for exceptions then rollback state to match where the exception occurs.
By fault I mean exception or error (which is exactly what the patent says...guess that's why I don't write patents!). That is, by nature, "exceptional". The problem, to expand furthur, is that checking for an exception slows down execution of the "normal" code path. That's why traps are used. The processor then only has to check at certain user (by that I mean compiler, usually) defined places. The problem is that this makes things more complex (and much slower, at least on the Alpha) when the exception actually occurs.
Heres a very small quote from the patent that should clear this up:
...
2. A gated store buffer for controlling the execution of memory store operations to system memory generated during execution of a sequence of instructions by a processor comprising:
Remember, processor instructions eventually operate on data...data that will be permanently stored in memory! If you have an instruction that faults preceeding one or several store operations (I refer to instructions which store to RAM, as opposed to a cache or something) then a trab barrier (sorry, I'm using Alpha-centric terms here), you've changed the contents of the RAM erroneously(sp). The instructions should never have issued and RAM should not have been modified. That's where permanent memory stores come in.
Pick up a copy of the Alpha Architecture Reference Manual and look up trap shadows. Rollback can be very useful when pipelining instructions because there is no guarantee of precisely where a fault issued from. Precise exception trapping is slower and more complicated. Read this for more!
Take the code, translate it. Store it in the cache until it is verfied, then execute it.
I'm not sure that's quite right. What I gleaned was: Take the code, translate it, execute it, cache it at the same time, when a trap barrier of some sort is hit, verify no faults. If there are faults, roll back based on the cache to the exact point of the fault. This is very important! Read this comment for more information.