"Avatar" appeared in the Habitat system (http://www.communities.com/paper/lessons.html), in '85 or '86, before Snow Crash was published ('91 or '92). Habitat died in the USA, but apparently enjoys some continued existance in Japan. I think the term, as used in Habitat, was coined by Chip Morningstar.
AMD _had not yet_ used Rambus for the K7. In fact, they haven't used any memory at all -- they system chips they currently offer are licensed from Via, and support only support single data phase SDRAM, not DDR-SDRAM. They have licensed Rambus. You can read about it at http://www.amd.com/news/prodpr/9890.html, http://www.ebnonline.com/digest/story/OEG19981008S 0002, http://www.techweb.com/wire/story/TWB19981012S0015 , and plenty of other places. I suspect they're waiting on Intel and plentiful RIMM supplies before releasing this, it's technology so far unproven in a PC yet. Also, AMD needs to bring system-chip technology in-house, especially now that they're potentially in competition on the CPU side with VIA. And, in fact, as the benchmarks you found show, Rambus bridged to a 100MHz P6 bus is no great shakes -- there's more latency than SDRAM, but it can't possible reach the CPU any faster than SDRAM can. Do the math. However, it can result in an overall faster system performance, especially if you're stressing the AGP bus, IF they built a good North Bridge architecture to support this. I have no idea if Intel did this or not in the i820. On a 200MHz FSB, things are very different; even with the latency issues, the fully effective transfer rate is doubled over regular SDRAM, and it can still benefit from the enhanced architectural tricks possible in the North Bridge. But you do need some newer ideas to fully benefit from Rambus, and I rather suspect Intel's first Rambus controllers are about as good as their first PCI controllers were. Even so, they can't use the performance today. AMD could. And in fact, AMD needs to support the K7 with a real 200MHz memory system of some kind if they hope to get a really significant performance lead over Intel. Hopefully they will, whether its DDR-SDRAM, 128-bit SDRAM, or Rambus.
>RDRAM on the other hand can run up to 800 MHz. The heat sync looks rather cute, but the memory >is tragically flawed by it's miniscule 16 bit bus (as opposed to the 64 bit SDRAM bus to the front side system bus). If you take a look, you'll find that the 64-bit FSB on today's P6 machines is simply a reaction to this architectural feature of the P6 bus. The SDRAM chips themselves are usually 8 or 16-bit wide devices, ganged to deliver a 64-bit bus. You can't do this same ganging on Rambus as easily, but you can certainly support several Rambus channels for fewer controller chip pins than you need for a 64-bit SDRAM bus. Today, it's not necessary -- a 100MHz P6 bus is only going to use about 1/2 the bandwidth of one Rambus channel. So this is not the doom you think. What Rambus buys for Intel, more than anything, is an easy way to move memory off the P6 bus. This will allow more I/O efficient system chips, as PCI and AGP now can have a direct channel to memory that doesn't get directly in the way of P6 activity. So even if the PIII can only use 800-900MB/s on the 1600MB/s Rambus channel, with proper buffering in the North Bridge chip, AGP and PCI will get a piece of this without conflicting as much with the CPU. This is also what you get with the EV6 bus, though in this case, by definition. And of course, Rambus isn't the only way. You can get the same bandwith with one Direct Rambus channel, a 64-bit DDR-SDRAM bus, or a 128-bit SDRAM bus (a staple on Alpha machines for years). The problem is doubling this. Two Direct Rambus channels are practically a no-brainer. 128-bit bus SDRAM-DDR might be possible in modern BGA packaging, but it's cutting it close. A 256-bit plain old SDRAM bus is not going to happen in commodity PCs. Now double it again. This is why Intel's been interested in Rambus.
Actually, AMD recently took a Rambus licence. Which only made sense once they had a system chip architecture (licensed from VIA, possibly a competitor now that VIA has bough the high-end Cyrix stuff). Clearly, the Rambus retreat is based on Intel's inability to get their new i820 chipset working properly. They were counting on this to make a big splash for Christmastime, and so anyone making Direct Rambus likely has stockpiles already. Knowing that's not going to happen, it makes perfect sense they're running SDRAM now, especially with the rise in SDRAM pricing. After all, the main allure of Direct Rambus for the memory vendors was higher margins. You can get that now, at least for a little while, with SDRAM, and there's no sense in making more Rambus now. Rambus itself has been proven in the consumer maket -- the Nintendo 64 uses the original 8-bit Rambus design, at 500MHz (technically, 250MHz DDR). The interesting thing is that Intel can't use Rambus anyway, now; they're priming the pumps for some future migration. One 16-bit Direct Rambus at 800MHz (technically, 400MHz DDR) peaks out at 1600MB/s, but a 100MHz P6 bus peaks out at 800MB/s. Sure, they'll run it up to 133MHz in the i820 (VIA has a 133MHz P6 bus chipset already), but it's not something you need Rambus for. AMD, on the other hand, has this hot EV6 bus. They're running it at 200MHz, but it's already going 400MHz in Alpha machines. It's kind of silly to run this on a PC100 bus. So AMD can actually take full advantage of one Direct Rambus channel. In fact, if they want to boost I/O performance, two channels wouldn't be out of line. Of course, AMD could get to a real 200MHz data rate using 100MHz DDR SDRAM (supposedly ALi is doing an EV6 chipset to support this). So they don't really need Direct Rambus, either. Unless they're planning a 400MHz FSB migration, too...
I bet their "x86 64" is a 64-bit version of the "RISC-86" internal op-set that Athlon uses, or something similar. Of course, all modern x86 chips are really RISC engines that run RISCified x86 op-codes of one form or another. This originated at NexGen, before AMD bought them or Intel used similar techniques in the P-Pro and PII. The original Nx586 could actually run "naked" RISC-86 instructions, though no one used it that way. Now, if you take the concept forward ten years, you could define and perhaps clean up the RISC-86 instruction set as an orthogonal set with more registers, but still very x86 flavored. To the point, in fact, where the op-code translator can take the true x86 op-codes and produce 32-bit versions of the RISC-ops, but they could run naked as well, this all being determined via a context bit somewhere, to allow an OS to switch modes. Pop this onto a Slot-A module, and they might actually have something, in the ability to upgrade today's 32-bit systems in-place and compatibly. The EV6 bus of Slot-A is already proven on Alpha 21264 64-bit systems, it's not screaming to be replaces as Intel's P6 bus is. Intel, of course, announced long ago that Merced would run on a yet-to-be-described "Slot M", and suggested a version of the Pentium would lead that bus in, but this hasn't happened yet. That's not to suggest any RISC-86 notion is going to be as clean or elegant as EPIC, PPC, MAJC, or anything cool and new. On the other hand, x86 has never been about what's cool, but what's practical. AMD could pull off a coup of practicality if this Sledgehammer thing comes out in a timely fashion. That would pretty much have to be before IA-64 is established anywhere buy in UNIX servers.
No one has to license an instruction set, there's never been any special protection for this. Of course, Intel may have specific protection, in the form of patents, which would prevent anyone from cloning an IA-64 machine, or make it difficult. I would expect that AMD studied the IA-64 architecture, legally and technically, before making the rather bold decision to strike out on their own. At least that keeps things interesting. I suspect the rationale will fall out eventually. Could be they think the world will be slow to move to IA-64, that they'll be able to release faster chips before Intel does, or that there are just too many technical and legal stumbling blocks in the way of IA-64 clones.
Not necessarily. PowerPC is very nice these days, with AltiVec and all. But it's still fundamentally a 32-bit processor. If 64-bit matters, IBM and Mot are going to have to take the 64-bit architecture of the Power3 down to the PowerPC level. And stop battling amongst themselves on who is and isn't going to support what feature. And get some real momentum behind an Open PPC platform with some real OS choices (the hell with Apple), maybe produce a G4 processor on the EV6 bus, to let it drop in to existing (or soon to exist) commodity motherboards. And so on...
Folks seem to have the idea that companies, chip or otherwise, are somehow single-tasking entities. This couldn't be further from the truth. Most chip companies work on several projects in parallel, and if it's a competitive line such as CPUs or 3D graphics chips, these projects overlap (this has been SOP at Intel & Motorola, for example, since the 80s). AMD previously mentioned that the design team derived from the NexGen team, the folks who did the K6, are not the people behind the K7. So, presumably, they aren't sitting around playing Quake III, they're working on something new. More than likely, it's a CPU, and since these folks have proven pretty hot on architecture in the past, doing so in the present wouldn't be a surprise. As for Athlon, it's in production. Unless they do any more true versions of the chip (eg, K7-2, etc) or have major production problems, there is no chip designer work left on the Athlon project anyway. Whatever they're doing now is more than likely process tweaks, die shrinks, etc. That's different people, unless there's some redesign necessary along with a shrink -- anyway, not enough work to occupy a whole uP design team. So these guys are likely on to bigger and better things now, too.
Even going back to Transmeta's first patent of last year, it's clear they're doing some kind of CPU technology, in which a target instruction set (say, x86) is dynamically recompiled and cached in a native, probably VLIW ISA. On the surface, this is not all that different than what DEC's FX!32 and some Java JITs so. But in both of those cases, there's no hardware to deal with. Transmeta's first patent dealt primarily with the hardware emulation tricks. This seems to be a contination of some of their ideas from the first patent. When you take any target ISA and convert it into something else, there is never a 1:1 instruction correspondence. But if you're optimizing and, even more, if you're targeting a VLIW machine, you're going to want to combine the functionality of a block of x86 code into a block of VLIW code, as much as that's possible. No inherent instruction boundaries remain in this new code. Which is fine, until you hit an exception. At that point, your emulation needs to emulate a machine exception. The problem is, just where, in the actual x86 code, did this take place? Transmeta's first patent dealt with the issue of tracking and resyncing to the emulated instructions. This deals with ensuring that a backtrack isn't visible outside of the "black box" x86 that the whole emulation provides.
Slashdot Mirror
"Avatar" appeared in the Habitat system (http://www.communities.com/paper/lessons.html), in '85 or '86, before Snow Crash was published ('91 or '92). Habitat died in the USA, but apparently enjoys some continued existance in Japan. I think the term, as used in Habitat, was coined by Chip Morningstar.
AMD _had not yet_ used Rambus for the K7. In fact, they haven't used any memory at all -- they system chips they currently offer are licensed from Via, and support only support single data phase SDRAM, not DDR-SDRAM. They have licensed Rambus. You can read about it at http://www.amd.com/news/prodpr/9890.html, http://www.ebnonline.com/digest/story/OEG19981008S 0002, http://www.techweb.com/wire/story/TWB19981012S0015 , and plenty of other places. I suspect they're waiting on Intel and plentiful RIMM supplies before releasing this, it's technology so far unproven in a PC yet. Also, AMD needs to bring system-chip technology in-house, especially now that they're potentially in competition on the CPU side with VIA. And, in fact, as the benchmarks you found show, Rambus bridged to a 100MHz P6 bus is no great shakes -- there's more latency than SDRAM, but it can't possible reach the CPU any faster than SDRAM can. Do the math. However, it can result in an overall faster system performance, especially if you're stressing the AGP bus, IF they built a good North Bridge architecture to support this. I have no idea if Intel did this or not in the i820. On a 200MHz FSB, things are very different; even with the latency issues, the fully effective transfer rate is doubled over regular SDRAM, and it can still benefit from the enhanced architectural tricks possible in the North Bridge. But you do need some newer ideas to fully benefit from Rambus, and I rather suspect Intel's first Rambus controllers are about as good as their first PCI controllers were. Even so, they can't use the performance today. AMD could. And in fact, AMD needs to support the K7 with a real 200MHz memory system of some kind if they hope to get a really significant performance lead over Intel. Hopefully they will, whether its DDR-SDRAM, 128-bit SDRAM, or Rambus.
>RDRAM on the other hand can run up to 800 MHz. The heat sync looks rather cute, but the memory >is tragically flawed by it's miniscule 16 bit bus (as opposed to the 64 bit SDRAM bus to the front side system bus). If you take a look, you'll find that the 64-bit FSB on today's P6 machines is simply a reaction to this architectural feature of the P6 bus. The SDRAM chips themselves are usually 8 or 16-bit wide devices, ganged to deliver a 64-bit bus. You can't do this same ganging on Rambus as easily, but you can certainly support several Rambus channels for fewer controller chip pins than you need for a 64-bit SDRAM bus. Today, it's not necessary -- a 100MHz P6 bus is only going to use about 1/2 the bandwidth of one Rambus channel. So this is not the doom you think. What Rambus buys for Intel, more than anything, is an easy way to move memory off the P6 bus. This will allow more I/O efficient system chips, as PCI and AGP now can have a direct channel to memory that doesn't get directly in the way of P6 activity. So even if the PIII can only use 800-900MB/s on the 1600MB/s Rambus channel, with proper buffering in the North Bridge chip, AGP and PCI will get a piece of this without conflicting as much with the CPU. This is also what you get with the EV6 bus, though in this case, by definition. And of course, Rambus isn't the only way. You can get the same bandwith with one Direct Rambus channel, a 64-bit DDR-SDRAM bus, or a 128-bit SDRAM bus (a staple on Alpha machines for years). The problem is doubling this. Two Direct Rambus channels are practically a no-brainer. 128-bit bus SDRAM-DDR might be possible in modern BGA packaging, but it's cutting it close. A 256-bit plain old SDRAM bus is not going to happen in commodity PCs. Now double it again. This is why Intel's been interested in Rambus.
Actually, AMD recently took a Rambus licence. Which only made sense once they had a system chip architecture (licensed from VIA, possibly a competitor now that VIA has bough the high-end Cyrix stuff). Clearly, the Rambus retreat is based on Intel's inability to get their new i820 chipset working properly. They were counting on this to make a big splash for Christmastime, and so anyone making Direct Rambus likely has stockpiles already. Knowing that's not going to happen, it makes perfect sense they're running SDRAM now, especially with the rise in SDRAM pricing. After all, the main allure of Direct Rambus for the memory vendors was higher margins. You can get that now, at least for a little while, with SDRAM, and there's no sense in making more Rambus now. Rambus itself has been proven in the consumer maket -- the Nintendo 64 uses the original 8-bit Rambus design, at 500MHz (technically, 250MHz DDR). The interesting thing is that Intel can't use Rambus anyway, now; they're priming the pumps for some future migration. One 16-bit Direct Rambus at 800MHz (technically, 400MHz DDR) peaks out at 1600MB/s, but a 100MHz P6 bus peaks out at 800MB/s. Sure, they'll run it up to 133MHz in the i820 (VIA has a 133MHz P6 bus chipset already), but it's not something you need Rambus for. AMD, on the other hand, has this hot EV6 bus. They're running it at 200MHz, but it's already going 400MHz in Alpha machines. It's kind of silly to run this on a PC100 bus. So AMD can actually take full advantage of one Direct Rambus channel. In fact, if they want to boost I/O performance, two channels wouldn't be out of line. Of course, AMD could get to a real 200MHz data rate using 100MHz DDR SDRAM (supposedly ALi is doing an EV6 chipset to support this). So they don't really need Direct Rambus, either. Unless they're planning a 400MHz FSB migration, too...
I bet their "x86 64" is a 64-bit version of the "RISC-86" internal op-set that Athlon uses, or something similar. Of course, all modern x86 chips are really RISC engines that run RISCified x86 op-codes of one form or another. This originated at NexGen, before AMD bought them or Intel used similar techniques in the P-Pro and PII. The original Nx586 could actually run "naked" RISC-86 instructions, though no one used it that way. Now, if you take the concept forward ten years, you could define and perhaps clean up the RISC-86 instruction set as an orthogonal set with more registers, but still very x86 flavored. To the point, in fact, where the op-code translator can take the true x86 op-codes and produce 32-bit versions of the RISC-ops, but they could run naked as well, this all being determined via a context bit somewhere, to allow an OS to switch modes. Pop this onto a Slot-A module, and they might actually have something, in the ability to upgrade today's 32-bit systems in-place and compatibly. The EV6 bus of Slot-A is already proven on Alpha 21264 64-bit systems, it's not screaming to be replaces as Intel's P6 bus is. Intel, of course, announced long ago that Merced would run on a yet-to-be-described "Slot M", and suggested a version of the Pentium would lead that bus in, but this hasn't happened yet. That's not to suggest any RISC-86 notion is going to be as clean or elegant as EPIC, PPC, MAJC, or anything cool and new. On the other hand, x86 has never been about what's cool, but what's practical. AMD could pull off a coup of practicality if this Sledgehammer thing comes out in a timely fashion. That would pretty much have to be before IA-64 is established anywhere buy in UNIX servers.
No one has to license an instruction set, there's never been any special protection for this. Of course, Intel may have specific protection, in the form of patents, which would prevent anyone from cloning an IA-64 machine, or make it difficult. I would expect that AMD studied the IA-64 architecture, legally and technically, before making the rather bold decision to strike out on their own. At least that keeps things interesting. I suspect the rationale will fall out eventually. Could be they think the world will be slow to move to IA-64, that they'll be able to release faster chips before Intel does, or that there are just too many technical and legal stumbling blocks in the way of IA-64 clones.
Not necessarily. PowerPC is very nice these days, with AltiVec and all. But it's still fundamentally a 32-bit processor. If 64-bit matters, IBM and Mot are going to have to take the 64-bit architecture of the Power3 down to the PowerPC level. And stop battling amongst themselves on who is and isn't going to support what feature. And get some real momentum behind an Open PPC platform with some real OS choices (the hell with Apple), maybe produce a G4 processor on the EV6 bus, to let it drop in to existing (or soon to exist) commodity motherboards. And so on...
Folks seem to have the idea that companies, chip or otherwise, are somehow single-tasking entities. This couldn't be further from the truth. Most chip companies work on several projects in parallel, and if it's a competitive line such as CPUs or 3D graphics chips, these projects overlap (this has been SOP at Intel & Motorola, for example, since the 80s). AMD previously mentioned that the design team derived from the NexGen team, the folks who did the K6, are not the people behind the K7. So, presumably, they aren't sitting around playing Quake III, they're working on something new. More than likely, it's a CPU, and since these folks have proven pretty hot on architecture in the past, doing so in the present wouldn't be a surprise. As for Athlon, it's in production. Unless they do any more true versions of the chip (eg, K7-2, etc) or have major production problems, there is no chip designer work left on the Athlon project anyway. Whatever they're doing now is more than likely process tweaks, die shrinks, etc. That's different people, unless there's some redesign necessary along with a shrink -- anyway, not enough work to occupy a whole uP design team. So these guys are likely on to bigger and better things now, too.
Even going back to Transmeta's first patent of last year, it's clear they're doing some kind of CPU technology, in which a target instruction set (say, x86) is dynamically recompiled and cached in a native, probably VLIW ISA. On the surface, this is not all that different than what DEC's FX!32 and some Java JITs so. But in both of those cases, there's no hardware to deal with. Transmeta's first patent dealt primarily with the hardware emulation tricks. This seems to be a contination of some of their ideas from the first patent. When you take any target ISA and convert it into something else, there is never a 1:1 instruction correspondence. But if you're optimizing and, even more, if you're targeting a VLIW machine, you're going to want to combine the functionality of a block of x86 code into a block of VLIW code, as much as that's possible. No inherent instruction boundaries remain in this new code. Which is fine, until you hit an exception. At that point, your emulation needs to emulate a machine exception. The problem is, just where, in the actual x86 code, did this take place? Transmeta's first patent dealt with the issue of tracking and resyncing to the emulated instructions. This deals with ensuring that a backtrack isn't visible outside of the "black box" x86 that the whole emulation provides.