These days a modem decodes the incoming analog signal (carrier tone(s) modulated into jumps within a 2D constellation in an IQ phase space) with complex DSP algorithms that funnel ultimately into a decision algorithm that spits out ones and zeros.
Maybe 3COM has come up with a new way of implementing the DSP RX recovery algorithm that reduces latency (for example not using as many delayed sampling taps, sampling the incoming signal at a higher rate etc). I doubt they could do much with the transmit side.
All in all, they might be able to reduce your modems contribution to ping latency by a small amount (ms's, 10's of ms?) but it is likely swamped by normal variability in the quality of service in the rest of the net.
Conclusion: maybe not a lie but still mostly marketing nonsense.
AMD's finances have been distressed before and they always seem to manage to pull through. If the motherboard and third party chipset issues can be sorted out and AMD can sell the parts they have demonstrated they can make it will go along way to ameliorating their balance sheet woes. The average selling price (ASP) of the K6 line is well below $100 while ASP of the K7 is well above $100. Granted the K7 costs a bit more to make than say the K6-2, but the big difference is the K7 is perceived as a very desirable processor rather than something someone buys because they cannot afford a Pentium III.
If something unforseen happened that threatened to throw AMD into chapter 11 I'd bet dollars to donuts that you would see Compaq, IBM and HP get together and jointly invest $1 billion or so in return for an equity stake. Intel sells about $20 or $25 billion of CPUs per year and Compaq/IBM/HP probably account for at least $5 billion worth of that. If AMD went under how much do you think Intel would charge them then? Beyond the monetary fallout would be the shift in power in favour of Intel. As much as I'd like to watch Mike Dell finally discover that Intel doesn't have friends just interests, we don't need another M$.
Interesting comment from presumably a upper middle class North American. Unfortunately the mostly placid and content, high-living, energy-consuming, SUV driving populace of the western democracies represents a small minority of the population of this planet (fortunately for the planet).
The "average" person out of that 6 billion leads a live of quiet desperation living in a slum on the outskirts of a large city. He tries to scratch a meager existence for him and his family while trying to stay out of the attention of the military and quasi-military dictatorship running his nation state. The amazing scenes of the western consumer society flickering on the TV owned by the local blackmarket thug must seem pretty remote.
We don't even need any more people to ruin this planet. All we need is the for the poorest's 5 billion to achieve the living standard of the richest billion. If western countries's populations are starting to fall then so much the better since a westerner probably has the environmental impact of 5 or more third world citizens. The real chilling events to look forward to are forced mass population movements as sea levels starts to rise and increasing military conflicts over sources of fresh water.
I don't profess to live a life of poverty or have solar panels on my house. But at least I am not oblivious to the real state of the population of this world. I know I'm alright but many people aren't.
Have you ever heard of cache? If you aren't blowing 1.5 or 2 million transistors on an x86 translator to stick on the front end of an OOO instruction execution engine then maybe you'd have more room for cache. And when CPUs start integrating great masses of DRAM on the die (like the M32RD) or doing serious stuff with SMT it won't be bloated x86 cores that will be called on.
Actually I did read the article. The historical background wasn't bad. I even read the university paper linked and that was just a plain waste of time.
As for your comments, I don't know of a single RISC processor that doesn't take "multiple cycles to process" an instruction. The classic 5 stage RISC scalar pipeline for example takes at least five clocks to process an instruction in its entirety. Or perhaps you're groping in the dark for the concept of instruction execution latency. There was no tablet handed down from Mt Olympus by John Cocke and Seymour Cray that says all RISC instructions must have a one cycle latency. Find me a RISC processor that implements FP arithmetic instructions with less than three clocks of latency. If the Altivec instructions take more than a single clock of latency then pipeline them, tell the compiler what their latencies are so it schedule around them if it can and be done with it.
You claim to understand it, so please try to explain to this simple engineer why "traditional" RISC is dead? Did someone add a bit count instruction or a reciprocal square root approximate and suddenly the instruction count went over some magic number?* Or maybe its this out of order execution stuff that's got you "new age" or "third way processor" advocates thinking that RISC and CISC have merged. Whip out a programmers reference manual for the 386 and the MIPS R2000. Now do the same thing for the Pentium III and the MIPS R14K. A decade and a half later and the two ISA's don't seem to have gotten much closer to me. It must be implementation then, the block diagrams have much the same names now. I tell you what, if I could get a circuit schematic for the 32 bit adders in the R2000 and the 386 could you examine them and tell me which came from the RISC CPU and which came from the CISC CPU? No? Yet the RISC CPU yielded far higher performance than that CISC CPU even with smaller off-chip cache, older semiconductor technology and one third the transistor count.
The only people who promulgate the view that RISC and CISC processors have somehow merged into some bizarre hybrid of the two seem to be those under the hypnotic influence of marketing department of the vendors for the few remaining CISC processor families. Those who are actually designing RISC processors don't seem to have difficulty in telling them apart.
*The only rule in the RISC school of processor design that relates to how many instructions a RISC ISA should or should not is that you don't add another instruction unless your performance increases for your target applications by a worthwhile amount even after considering the impact of adding the new instruction on the microarchitecture and cycle time of likely implementations.
re: CISC vs RISC has very little effecton the performance of the computer.
Sorry but you are quite wrong. If you compare RISC and CISC processors built with equivalent technology from the mid-80's to today there is an obvious difference in performance. Here's some "best of breed" matchups (RISC vs CISC):
1) MIPS R2000 vs Intel 386
2) HP PA-7150 vs 0.8 um (5V) Pentium
3) Alpha 21064 vs NVAX (same damn process!)
4) Alpha 21164A vs Pentium Pro
5) Alpha 21264A vs Pentium III (Katmai)
In each and every one of these matchups the CISC part comes out a distant second.
BTW, I am eagerly looking forward to see how the 0.18 um Alpha EV68 stacks up against Coppermine and K7, and how EV7 stacks up against Williamette;-)
Your computer course instructor was partially right. True RISC processors do avoid microcode and exclusively use hardwired control logic.
But modern CISC implementations use hardwired control logic for most common simple instructions and resort to microcode for the more arcane, multi-cycle CISCy instructions. It is theoretically possible to hardwire all control logic in any CISC implementation but it would be time consuming, buggy, and have little payback. The last x86 to rely exclusively on microcode was the 386.
Last year over 150 million 32 and 64 bit RISC processors were sold. This year the figure is likely to greatly exceed 200 million or roughly twice as many as all x86s from all the vendors. In general purpose computing, around $50 billion worth of RISC-based systems were sold last year. Hardly seems like an idea on the scrapheap to me:)
I am sick and tired of people who cannot fathom the difference between an abstract instruction set architecture (ISA) and a chip implementation with functional units, gates, and flops. The terms RISC and CISC refer to ISAs. If you build a CISC processor using many of the same implementation tricks that are commonly used in RISC processors then fine for you. But you still have a CISC MPU. RISC and CISC have always shared many implementation details be it triple ported register files, on-chip cache or a 32 bit adder.
Look at this way. Lets say CISC is analogous to a bungalow while RISC is a two story house. These are architectural differences. Lets say that in the early days of house building bungalows were always built out of brick with load bearing walls while two story houses were wood framed. If some joker comes along and builds a bungalow with wood frame technology it suddenly doesn't make his edifice a two story house even though it may be a big improvement on earlier bungalows.
While CISC has generally caught back up to near RISC for integer performance once MPU complexity reached about 3 to 5 million transistors the ISA differences do matter. For example, an out-of-order x86 with a translator front end and register renaming might have 16 or 32 physical GPRs instead of the eight architected GPRs. But the compiler cannot address these physical registers, it only sees eight. This means that an x86 compiler will have to spill values to memory much more often than a RISC compiler and it will not be able to exploit performance enhancing techniques such as register assignment to local and globals variables and software pipelining nearly as well as a RISC.
There is also the baggage effect with CISC architectures. For example, nearly every x86 instruction modifies flag bits as well as GPRs. This means that the flags become a central dependency choke point that requires a lot of attention to address. CISC ISAs also invariably have multiple instruction sizes. This means that a CISC CPU will typically require an extra pipe stage or two to sort out instruction boundaries regardless of how "RISC-like" the backend looks.
People who believe the Intel party line of "x86 was CISC but is now RISC" should pay attention to what Intel is doing rather than saying. They are busy spending billions to develop a new RISC-like 64 bit architecture to carry them into the future. It is true AMD will stretch x86 to 64 bits but they had to change the x86 floating point programming model to a RISC like flat register file with three address instructions to even attempt to close the distance on FP code. And AMD's future success in keeping up with IA-64 and SMT superscalar RISC implmentations is far from asured.
There are obviously many different kinds of chips but for processors and ASICs the trend is towards larger and larger die sizes. The three main factors in this are 1) need for more I/O and power pins, 2) Advances in semiconductor processing facilities and equipment have reduced defect density over the years to make larger chips practical, and 3) For processors especially, an increasing fraction of the chip is memory which can be protected to a large extent by redundancy.
The eight bit micros like the Z80, 6800, and 8080A had die sizes of around 20 - 22 mm2 and 40 pins. In the 16 bit era the die sizes were around 40 to 80 mm2 and pin count ranged from 40 to 68. The early 32 micros like the 68020 and 386 were about 85 to 100 mm2 in size and used 114 to 132 pins.
In the start of the modern PC era the emphasis was on performance and features and die size was pushed hard with the anticipation of multiple process shrinks to allow the part to enter the manufacturing sweet spot of around 100 to 150 mm2 for inexpensive and high volume production.
The Pentium and Pentium Pro (P6) were both introduced around 300 mm2 but didn't reach high volumes until shrunk into more advanced processes. The Pentium shrank from 306 mm2 in 0.8 um, to 163 mm2 in 0.5 um, to 91 mm2 in 0.35 um (with caches doubled in size and MMX added).
The largest processor today is the PA-8500 which checks in at a whopping 475 mm2 in 0.25 um. But remember this chip is nearly 3/4 cache SRAM (1.5 Mbyte). The 8500 is probably the largest chip that can fit in the field of exposure with the current generation of optical steppers.
We can expect mainstream processors to get larger in the future because of the trend towards integrating level 2 and even level 3 caches on-chip. Memory redundancy makes these larger chips practical while the growing disparity between fast wide issue CPUs and main memory performance makes large on-chip caches mandatory. For embedded processors and CPU cores in system on a chip type applications the die size is typically kept from shrinking much below 50 mm2 by bonding pad spacing requirements ("I/O limited").
He is being careful with what he says alright. But he probably has nothing to worry about. The securities laws in Canada are a sick joke and the regulatory agencies are lapdogs to the securities industry. Unless the regulators execute a search warrant and find a to-do list in your hand writing that has "3) do insider trading today" checked off you are probably ok.:-O
In a famous incident, a mining company exec "A" was buddy of a former premier of British Columbia we will refer to "B". A deal for an American company to acquire this mining concern falls through and A places a phone call to B. B hangs up the phone, calls his broker and dumps all his holdings in A's company. Within hours the failed acquisition becomes public and the value of A's company's stock falls precipitously. "B" manages to avoid losses on the order of a million bucks. Both the regulatory agencies in BC and Ontario were unable to convict either A or B on insider trading! B claims that the phone call from A was just to discuss weather, sports etc. I think there was an just recently an out of court settlement to end the investigation.
It may sound weird to an American who is used to being careful with securities regulations, but I actually envy you with your SEC. They might sometimes act like Nazis but at least a**holes like Mike Cowpland would have to be a lot less brazen when they hose (or appear to hose) their investors.
The previous G4/500 was announced but availability was at a later date. Then Mot announced the G4/500 bug which even threw even this later date into question. IMHO this means there was only two G4 models going into this latest setback.
Is this is another examples of Macophiles being so desperate to hold onto the dream that they even consider vapourware real? Maybe it caused by the same underlying inferiority complex that leads them to argue in defence of the BYTEmark suite despite its badly flawed underlying methodology:)
We are so used to reading stories about PC manufacturers cutting prices and/or introducing faster models that this is kind of a man bites dog story.
It may also indicate that Apple is having problems with their new G4 motherboard. IIRC, the original G4/400 used the older G3 system motherboard while the G4/450 and future G4/500 were to use a new motherboard designed to exploit exploited the wider buses and other features of the G4. If they are now only offering 350 and 400 MHz G4 systems these are probably the old G3 motherboard. It might also indicate that Motorola is getting worst than expected yields in their higher speed bins for the G4. The good news for Apple is that IBM will second source the G4; the bad news is they won't be able to ramp up until next year.
Meanwhile, the prices in the x86 world will fall further as Coppermine arrives in a few weeks and AMD introduces a 750 MHz K7. Isn't competition great?
The N64 uses the original rambus technology. The stuff Intel is trying to shove down everyone's throat is direct rambus - two generations beyond the Nintendo memory.
We knew that eventually Intel and Rambus would solve the glitches with the 820 chipset. But the big question who wants 820 based PCs? Intel is unlikely to be able to show much performance benefit of DRDRAM over PC100 let alone PC133 or DDR. Most PC programs play quite nicely in a two level cache hierarchy and don't much resemble McCalpin's STREAM memory bandwidth benchmark. DRDRAM has a lot of latency problems, especially those related to management of which memory devices are kept active and which are put into low power modes. Also since DRDRAM yields at 800 Mbps/pin are so abysmal most mainstream 820 based PCs shipped in the next few quarters will have down-binned 600 or 700 Mbps RIMMs in them which will make them look bad compared to PC100 SDRAM.
Now what about cost? It is estimated that a typical 820 based PC will have about a $250 cost premium over a 440BX based PC with PC100. What is the cost difference to the PC buyer $300? $400? There are no simple fixes for this problem. The economics of DRDRAM hurt in so many places - larger die size, low AC functional yield, sky high test costs, uBGA packaging costs, module and motherboard costs (you need special PWBs with tightly controlled characteristic impedance for those rambus transmission lines). These problems are so significant that the only DRAM vendor still building DRDRAMs is Toshiba and that is because it is contractual supplier to Sony for Playstation 2's.
I would only opt for this technology if I knew my wife or I carried a defective gene that could transmit a serious disease to my children. But the thought of designer children is reprehensible. Each of my three children is a unique individual with their strengths and weaknesses. It is the sum of our set of traits that make us individuals.
You only have to look at the monolith of popular culture with its winner take all approach to celebrity to predict where designer children lead to. How many tall blond children with perfect teeth and the athletic abilities of Michael Jordan could the world stand?
Aside from the vapid uniformity of such a world there is the serious question of loss of genetic diversity. We are already seeing this in the agriculture industry with every farmer wanting to grow the most profitable strain of wheat or raise a herd of only the most prolific breed of milk producing cows. Extensive genetic engineering of children to culturally determined norms could lead to a world where a new disease, which today might only affect a fraction of the population, might threaten the extinction of the human race (not that it would be much of a loss by that stage).
Another troubling vision is corporate ownership of genetic traits. We already have patented lifeforms and crops genetically engineered by company A to only thrive with company A's fertilizers and herbicides. Will "trait agencies" spring up to buy the genetic information from individuals with outstanding abilities in some specific area like mathematics or athletics? If you have an un-engineered child with natural mathematical abilities could you be sued for fringing on that company's IP? Could parents be sued later in life by un-engineered children for disadvantaging them in the life competition for jobs and spouses? Would third world children be genetically engineered to resemble voluptuous movie stars for a life of slavery and prostitution. A scary world indeed!
You spin an interesting story but much of it seems to be speculation and erroneous speculation at that. Tuesday I had a good long chat with the principal engineer in charge of chipsets at Intel. The 820/rambus problem is understood and related to mixing and matching RIMMs from different manufacturers in systems with all three sockets populated. I won't go into details but it is not an inherent and irrevocable problem with DRDRAM but rather a pretty usual teething problem. Same thing happened when PC66 SDRAM came out and again when PC100 came along. No one claimed that SDRAM was inherently unworkable did they? Rambus's technical problem in 820 boards will be sorted out.
The real issue is economic and whether rambus can provide a compelling reason for its adoption in PCs in the face of its much higher costs. I have my own opinion on that and it differs from the Intel guys. But Sun has voted for rambus with a DRDRAM controller in their 5200 MAJC chip. And Compaq has continued the pattern of the Alpha EV7 and announced that the eight issue EV8 would also have DRDRAM controllers built in. Many people and companies other than Intel have made expensive votes of confidence in rambus.
Re:not much info about the chip
on
K8 Details
·
· Score: 1
Does one need supportive evidence to predict that a duck will quack rather than bark?
For starters Intel has gone to unusual lengths to delay filing IA-64 patents as long as possible and when they did file it was often under shell companies like Idea Corp. (Cupertino Ca) to further hinder disclosure of IA-64 features. Also the IA-64 design team includes lawyers specializing in IP (MPR, look it up yourself)
This does not suggest that Intel is in any hurry to make IA-64 an open architecture. It does suggest that Intel is laying the groundwork for a tough legal offensive against anyone attempting to clone IA-64.
Quack, quack.
Re:not much info about the chip
on
K8 Details
·
· Score: 1
Do you know how the x86 cloners got around Intel's x86 patents? Basically they build them in a fab whose owners have patent cross licensing agreements with Intel (AMD is a special case but that is a story for another day). A landmark legal case established that a fab owner's license covered an x86 clones built in that fab regardless of whose design it was.
Intel was sure steamed about that ruling and has taken steps to ensure that no one can gain access to IA-64 in the same way. IA-64 has dozens of features that are patented or in the process of being patented. It is not good enough to be able to build a CPU that is 99% compatible with IA-64. Look at Lexra; they designed a MIPS clone embedded core but couldn't include the unaligned load and store instructions because SGI/MIPS had patents on the concept and implementation. In the end Lexra couldn't claim MIPS compatibility. This doesn't seem to have hurt Lexra but the embedded control world is a completely different market than desktop computers, servers, and workstations.
Aside from that, IA-64 is huge creaking edifice designed by a two company committee. In terms of ease of implementation Alpha is a much simpler and streamlined design. And with equivalent semi technology the EV68 Alpha wipes up the floor with the merced IA-64 and is much compact too (roughly half the die size). Alpha can likely be licensed by AMD and design assistance, both official and unofficial, would flow in AMD's direction. Also, many of AMD's key designers are ex-Alpha designers. Contrast that with IA-64 where much of the ISA will be hidden in secret "Appendix H's" and the public information will not always correspond to Intel hardware. Intel tied up AMD in court on and off for a decade over x86. They will be happy do the same for IA-64 and will have the benefit of the legal lessons learned in the first war.
Re:not much info about the chip
on
K8 Details
·
· Score: 1
Sorry, but IA-64 goes way beyond PA-RISC. There are a number of features in IA-64 that are not in PA-RISC and are the subject of patents. These include the way the predicate registers are saved, the advanced load mechanism, the way NAT bits are used and so and so on. Cloning PA-RISC 2.0 gets you nowhere.
IMHO a 64 bit x86 is an abomination that should never see the light of day. But unless AMD has long term plans to abandon the general purpose desktop MPU business for low and medium performance embedded control applications they have to be a player in 64 bits. A bilingual x86 CPU with an Alpha mode makes more sense to me but even there AMD would have to be careful not to infringe on IA-64 IP.
Re:not much info about the chip
on
K8 Details
·
· Score: 1
Well the K8 is touted as a 64 bit chip but this can mean different things to marketing weasels than to engineers. If it is a true 64 bit ISA then it will be very interesting to see what they did. AMD had two choices in making a 64 bit chip.
The first is to build an IA-32 x86 chip and then add a mode that extends the x86 ISA with 64 bit registers, integer and logical operations, and flat addressing ("64 bit x86").
The alternative is to build a bilingual CPU that can execute both IA-32/x86 in one mode and a 64 bit ISA in another. There is really only one choice for the latter that makes sense - Alpha. AMD already licenses EV6 interface technology from Compaq and an Alpha ISA license would be an extension of it. It couldn't be Intel's IA-64 for two simple reasons: 1) details of IA-64 are only gradually entering the public domain, and 2) Intel has many aspects of IA-64 patented and cloning it would be like entering an infinitely deep legal minefield.
I suspect the K8 is the former, a 64 bit extended x86 although the apps and os software availability problems seem formidable. M$ has its hands full with x86 and now IA-64 versions of windoze and there already is an ideal 64 bit ISA to run Linux on - Alpha:)
Slashdot Mirror
Don't forget TTL logic
Quad pumped huh? I guess that means that it transfers data on both the rising, falling and... oops we seem to have run out of clock edges.
The only thing quad pumped is Intel's marketing machine. BTW, the EV6 bus used for Alphas and K7's goes up to 400 M transfers/sec, *for real*.
These days a modem decodes the incoming analog signal (carrier tone(s) modulated into jumps within a 2D constellation in an IQ phase space) with complex DSP algorithms that funnel ultimately into a decision algorithm that spits out ones and zeros.
Maybe 3COM has come up with a new way of implementing the DSP RX recovery algorithm that reduces latency (for example not using as many delayed sampling taps, sampling the incoming signal at a higher rate etc). I doubt they could do much with the transmit side.
All in all, they might be able to reduce your modems contribution to ping latency by a small amount (ms's, 10's of ms?) but it is likely swamped by normal variability in the quality of service in the rest of the net.
Conclusion: maybe not a lie but still mostly marketing nonsense.
AMD's finances have been distressed before and they always seem to manage to pull through. If the motherboard and third party chipset issues can be sorted out and AMD can sell the parts they have demonstrated they can make it will go along way to ameliorating their balance sheet woes. The average selling price (ASP) of the K6 line is well below $100 while ASP of the K7 is well above $100. Granted the K7 costs a bit more to make than say the K6-2, but the big difference is the K7 is perceived as a very desirable processor rather than something someone buys because they cannot afford a Pentium III.
If something unforseen happened that threatened to throw AMD into chapter 11 I'd bet dollars to donuts that you would see Compaq, IBM and HP get together and jointly invest $1 billion or so in return for an equity stake. Intel sells about $20 or $25 billion of CPUs per year and Compaq/IBM/HP probably account for at least $5 billion worth of that. If AMD went under how much do you think Intel would charge them then? Beyond the monetary fallout would be the shift in power in favour of Intel. As much as I'd like to watch Mike Dell finally discover that Intel doesn't have friends just interests, we don't need another M$.
"Six Billion and Feeling Fine" ?
Interesting comment from presumably a upper middle class North American. Unfortunately the mostly placid and content, high-living, energy-consuming, SUV driving populace of the western democracies represents a small minority of the population of this planet (fortunately for the planet).
The "average" person out of that 6 billion leads a live of quiet desperation living in a slum on the outskirts of a large city. He tries to scratch a meager existence for him and his family while trying to stay out of the attention of the military and quasi-military dictatorship running his nation state. The amazing scenes of the western consumer society flickering on the TV owned by the local blackmarket thug must seem pretty remote.
We don't even need any more people to ruin this planet. All we need is the for the poorest's 5 billion to achieve the living standard of the richest billion. If western countries's populations are starting to fall then so much the better since a westerner probably has the environmental impact of 5 or more third world citizens. The real chilling events to look forward to are forced mass population movements as sea levels starts to rise and increasing military conflicts over sources of fresh water.
I don't profess to live a life of poverty or have solar panels on my house. But at least I am not oblivious to the real state of the population of this world. I know I'm alright but many people aren't.
flamebait?
I was getting his attention
If presenting cold hard quantitative facts is flame bait then I am out of here.
Have you ever heard of cache? If you aren't blowing 1.5 or 2 million transistors on an x86 translator to stick on the front end of an OOO instruction execution engine then maybe you'd have more room for cache. And when CPUs start integrating great masses of DRAM on the die (like the M32RD) or doing serious stuff with SMT it won't be bloated x86 cores that will be called on.
Actually I did read the article. The historical background wasn't bad. I even read the university paper linked and that was just a plain waste of time.
As for your comments, I don't know of a single RISC processor that doesn't take "multiple cycles to process" an instruction. The classic 5 stage RISC scalar pipeline for example takes at least five clocks to process an instruction in its entirety. Or perhaps you're groping in the dark for the concept of instruction execution latency. There was no tablet handed down from Mt Olympus by John Cocke and Seymour Cray that says all RISC instructions must have a one cycle latency. Find me a RISC processor that implements FP arithmetic instructions with less than three clocks of latency. If the Altivec instructions take more than a single clock of latency then pipeline them, tell the compiler what their latencies are so it schedule around them if it can and be done with it.
You claim to understand it, so please try to explain to this simple engineer why "traditional" RISC is dead? Did someone add a bit count instruction or a reciprocal square root approximate and suddenly the instruction count went over some magic number?* Or maybe its this out of order execution stuff that's got you "new age" or "third way processor" advocates thinking that RISC and CISC have merged. Whip out a programmers reference manual for the 386 and the MIPS R2000. Now do the same thing for the Pentium III and the MIPS R14K. A decade and a half later and the two ISA's don't seem to have gotten much closer to me. It must be implementation then, the block diagrams have much the same names now. I tell you what, if I could get a circuit schematic for the 32 bit adders in the R2000 and the 386 could you examine them and tell me which came from the RISC CPU and which came from the CISC CPU? No? Yet the RISC CPU yielded far higher performance than that CISC CPU even with smaller off-chip cache, older semiconductor technology and one third the transistor count.
The only people who promulgate the view that RISC and CISC processors have somehow merged into some bizarre hybrid of the two seem to be those under the hypnotic influence of marketing department of the vendors for the few remaining CISC processor families. Those who are actually designing RISC processors don't seem to have difficulty in telling them apart.
*The only rule in the RISC school of processor design that relates to how many instructions a RISC ISA should or should not is that you don't add another instruction unless your performance increases for your target applications by a worthwhile amount even after considering the impact of adding the new instruction on the microarchitecture and cycle time of likely implementations.
re: CISC vs RISC has very little effecton the performance of the computer.
;-)
Sorry but you are quite wrong. If you compare RISC and CISC processors built with equivalent technology from the mid-80's to today there is an obvious difference in performance. Here's some "best of breed" matchups (RISC vs CISC):
1) MIPS R2000 vs Intel 386
2) HP PA-7150 vs 0.8 um (5V) Pentium
3) Alpha 21064 vs NVAX (same damn process!)
4) Alpha 21164A vs Pentium Pro
5) Alpha 21264A vs Pentium III (Katmai)
In each and every one of these matchups the CISC part comes out a distant second.
BTW, I am eagerly looking forward to see how the 0.18 um Alpha EV68 stacks up against Coppermine and K7, and how EV7 stacks up against Williamette
Your computer course instructor was partially right. True RISC processors do avoid microcode and exclusively use hardwired control logic.
But modern CISC implementations use hardwired control logic for most common simple instructions and resort to microcode for the more arcane, multi-cycle CISCy instructions. It is theoretically possible to hardwire all control logic in any CISC implementation but it would be time consuming, buggy, and have little payback. The last x86 to rely exclusively on microcode was the 386.
Last year over 150 million 32 and 64 bit RISC processors were sold. This year the figure is likely to greatly exceed 200 million or roughly twice as many as all x86s from all the vendors. In general purpose computing, around $50 billion worth of RISC-based systems were sold last year. Hardly seems like an idea on the scrapheap to me
I am sick and tired of people who cannot fathom the difference between an abstract instruction set architecture (ISA) and a chip implementation with functional units, gates, and flops. The terms RISC and CISC refer to ISAs. If you build a CISC processor using many of the same implementation tricks that are commonly used in RISC processors then fine for you. But you still have a CISC MPU. RISC and CISC have always shared many implementation details be it triple ported register files, on-chip cache or a 32 bit adder.
Look at this way. Lets say CISC is analogous to a bungalow while RISC is a two story house. These are architectural differences. Lets say that in the early days of house building bungalows were always built out of brick with load bearing walls while two story houses were wood framed. If some joker comes along and builds a bungalow with wood frame technology it suddenly doesn't make his edifice a two story house even though it may be a big improvement on earlier bungalows.
While CISC has generally caught back up to near RISC for integer performance once MPU complexity reached about 3 to 5 million transistors the ISA differences do matter. For example, an out-of-order x86 with a translator front end and register renaming might have 16 or 32 physical GPRs instead of the eight architected GPRs. But the compiler cannot address these physical registers, it only sees eight. This means that an x86 compiler will have to spill values to memory much more often than a RISC compiler and it will not be able to exploit performance enhancing techniques such as register assignment to local and globals variables and software pipelining nearly as well as a RISC.
There is also the baggage effect with CISC architectures. For example, nearly every x86 instruction modifies flag bits as well as GPRs. This means that the flags become a central dependency choke point that requires a lot of attention to address. CISC ISAs also invariably have multiple instruction sizes. This means that a CISC CPU will typically require an extra pipe stage or two to sort out instruction boundaries regardless of how "RISC-like" the backend looks.
People who believe the Intel party line of "x86 was CISC but is now RISC" should pay attention to what Intel is doing rather than saying. They are busy spending billions to develop a new RISC-like 64 bit architecture to carry them into the future. It is true AMD will stretch x86 to 64 bits but they had to change the x86 floating point programming model to a RISC like flat register file with three address instructions to even attempt to close the distance on FP code. And AMD's future success in keeping up with IA-64 and SMT superscalar RISC implmentations is far from asured.
There are obviously many different kinds of chips but for processors and ASICs the trend is towards larger and larger die sizes. The three main factors in this are 1) need for more I/O and power pins, 2) Advances in semiconductor processing facilities and equipment have reduced defect density over the years to make larger chips practical, and 3) For processors especially, an increasing fraction of the chip is memory which can be protected to a large extent by redundancy.
The eight bit micros like the Z80, 6800, and 8080A had die sizes of around 20 - 22 mm2 and 40 pins. In the 16 bit era the die sizes were around 40 to 80 mm2 and pin count ranged from 40 to 68. The early 32 micros like the 68020 and 386 were about 85 to 100 mm2 in size and used 114 to 132 pins.
In the start of the modern PC era the emphasis was on performance and features and die size was pushed hard with the anticipation of multiple process shrinks to allow the part to enter the manufacturing sweet spot of around 100 to 150 mm2 for inexpensive and high volume production.
The Pentium and Pentium Pro (P6) were both introduced around 300 mm2 but didn't reach high volumes until shrunk into more advanced processes.
The Pentium shrank from 306 mm2 in 0.8 um, to 163 mm2 in 0.5 um, to 91 mm2 in 0.35 um (with caches doubled in size and MMX added).
The largest processor today is the PA-8500 which checks in at a whopping 475 mm2 in 0.25 um. But remember this chip is nearly 3/4 cache SRAM (1.5 Mbyte). The 8500 is probably the largest chip that can fit in the field of exposure with the current generation of optical steppers.
We can expect mainstream processors to get larger in the future because of the trend towards integrating level 2 and even level 3 caches on-chip. Memory redundancy makes these larger chips practical while the growing disparity between fast wide issue CPUs and main memory performance makes large on-chip caches mandatory. For embedded processors and CPU cores in system on a chip type applications the die size is typically kept from shrinking much below 50 mm2 by bonding pad spacing requirements ("I/O limited").
I believe he was also charged with making false statements to investigators.
He is being careful with what he says alright. But he probably has nothing to worry about. The securities laws in Canada are a sick joke and the regulatory agencies are lapdogs to the securities industry. Unless the regulators execute a search warrant and find a to-do list in your hand writing that has "3) do insider trading today" checked off you are probably ok. :-O
In a famous incident, a mining company exec "A" was buddy of a former premier of British Columbia we will refer to "B". A deal for an American company to acquire this mining concern falls through and A places a phone call to B. B hangs up the phone, calls his broker and dumps all his holdings in A's company. Within hours the failed acquisition becomes public and the value of A's company's stock falls precipitously. "B" manages to avoid losses on the order of a million bucks. Both the regulatory agencies in BC and Ontario were unable to convict either A or B on insider trading! B claims that the phone call from A was just to discuss weather, sports etc. I think there was an just recently an out of court settlement to end the investigation.
It may sound weird to an American who is used to being careful with securities regulations, but I actually envy you with your SEC. They might sometimes act like Nazis but at least a**holes like Mike Cowpland would have to be a lot less brazen when they hose (or appear to hose) their investors.
"Still three models of G4"?
:)
The previous G4/500 was announced but availability was at a later date. Then Mot announced the G4/500 bug which even threw even this later date into question. IMHO this means there was only two G4 models going into this latest setback.
Is this is another examples of Macophiles being so desperate to hold onto the dream that they even consider vapourware real? Maybe it caused by the same underlying inferiority complex that leads them to argue in defence of the BYTEmark suite despite its badly flawed underlying methodology
We are so used to reading stories about PC manufacturers cutting prices and/or introducing faster models that this is kind of a man bites dog story.
It may also indicate that Apple is having problems with their new G4 motherboard. IIRC, the original G4/400 used the older G3 system motherboard while the G4/450 and future G4/500 were to use a new motherboard designed to exploit exploited the wider buses and other features of the G4. If they are now only offering 350 and 400 MHz G4 systems these are probably the old G3 motherboard. It might also indicate that Motorola is getting worst than expected yields in their higher speed bins for the G4. The good news for Apple is that IBM will second source the G4; the bad news is they won't be able to ramp up until next year.
Meanwhile, the prices in the x86 world will fall further as Coppermine arrives in a few weeks and AMD introduces a 750 MHz K7. Isn't competition great?
The N64 uses the original rambus technology. The stuff Intel is trying to shove down everyone's throat is direct rambus - two generations beyond the Nintendo memory.
We knew that eventually Intel and Rambus would solve the glitches with the 820 chipset. But the big question who wants 820 based PCs? Intel is unlikely to be able to show much performance benefit of DRDRAM over PC100 let alone PC133 or DDR. Most PC programs play quite nicely in a two level cache hierarchy and don't much resemble McCalpin's STREAM memory bandwidth benchmark. DRDRAM has a lot of latency problems, especially those related to management of which memory devices are kept active and which are put into low power modes. Also since DRDRAM yields at 800 Mbps/pin are so abysmal most mainstream 820 based PCs shipped in the next few quarters will have down-binned 600 or 700 Mbps RIMMs in them which will make them look bad compared to PC100 SDRAM.
Now what about cost? It is estimated that a typical 820 based PC will have about a $250 cost premium over a 440BX based PC with PC100. What is the cost difference to the PC buyer $300? $400? There are no simple fixes for this problem. The
economics of DRDRAM hurt in so many places - larger die size, low AC functional yield, sky high test costs, uBGA packaging costs, module and motherboard costs (you need special PWBs with tightly controlled characteristic impedance for those rambus transmission lines). These problems are so significant that the only DRAM vendor still building DRDRAMs is Toshiba and that is because it is contractual supplier to Sony for Playstation 2's.
Well stated.
I would only opt for this technology if I knew my wife or I carried a defective gene that could transmit a serious disease to my children. But the thought of designer children is reprehensible. Each of my three children is a unique individual with their strengths and weaknesses. It is the sum of our set of traits that make us individuals.
You only have to look at the monolith of popular culture with its winner take all approach to celebrity to predict where designer children lead
to. How many tall blond children with perfect teeth and the athletic abilities of Michael Jordan could the world stand?
Aside from the vapid uniformity of such a world there is the serious question of loss of genetic diversity. We are already seeing this in the agriculture industry with every farmer wanting to grow the most profitable strain of wheat or raise a herd of only the most prolific breed of milk producing cows. Extensive genetic engineering of children to culturally determined norms could lead to a world where a new disease, which today might only affect a fraction of the population, might threaten the extinction of the human race (not that it would be much of a loss by that stage).
Another troubling vision is corporate ownership of genetic traits. We already have patented lifeforms and crops genetically engineered by company A to only thrive with company A's fertilizers and herbicides. Will "trait agencies" spring up to buy the genetic information from individuals with outstanding abilities in some specific area like mathematics or athletics? If you have an un-engineered child with natural mathematical abilities could you be sued for fringing on that company's IP? Could parents be sued later in life by un-engineered children for disadvantaging them in the life competition for jobs and spouses? Would third world children be genetically engineered to resemble voluptuous movie stars for a life of slavery and prostitution. A scary world indeed!
You spin an interesting story but much of it seems to be speculation and erroneous speculation at that. Tuesday I had a good long chat with the principal engineer in charge of chipsets at Intel. The 820/rambus problem is understood and related to mixing and matching RIMMs from different manufacturers in systems with all three sockets populated. I won't go into details but it is not an inherent and irrevocable problem with DRDRAM but rather a pretty usual teething problem. Same thing happened when PC66 SDRAM came out and again when PC100 came along. No one claimed that SDRAM was inherently unworkable did they? Rambus's technical problem in 820 boards will be sorted out.
The real issue is economic and whether rambus can provide a compelling reason for its adoption in PCs in the face of its much higher costs. I have my own opinion on that and it differs from the Intel guys. But Sun has voted for rambus with a DRDRAM controller in their 5200 MAJC chip. And Compaq has continued the pattern of the Alpha EV7 and announced that the eight issue EV8 would also have DRDRAM controllers built in. Many people and companies other than Intel have made expensive votes of confidence in rambus.
Does one need supportive evidence to predict that a duck will quack rather than bark?
For starters Intel has gone to unusual lengths to delay filing IA-64 patents as long as possible and when they did file it was often under shell companies like Idea Corp. (Cupertino Ca) to further hinder disclosure of IA-64 features. Also the IA-64 design team includes lawyers specializing in IP (MPR, look it up yourself)
This does not suggest that Intel is in any hurry to make IA-64 an open architecture. It does suggest that Intel is laying the groundwork for a tough legal offensive against anyone attempting to clone IA-64.
Quack, quack.
Do you know how the x86 cloners got around Intel's x86 patents? Basically they build them in a fab whose owners have patent cross licensing agreements with Intel (AMD is a special case but that is a story for another day). A landmark legal case established that a fab owner's license covered an x86 clones built in that fab regardless of whose design it was.
Intel was sure steamed about that ruling and has taken steps to ensure that no one can gain access to IA-64 in the same way. IA-64 has dozens of features that are patented or in the process of being patented. It is not good enough to be able to build a CPU that is 99% compatible with IA-64. Look at Lexra; they designed a MIPS clone embedded core but couldn't include the unaligned load and store instructions because SGI/MIPS had patents on the concept and implementation. In the end Lexra couldn't claim MIPS compatibility. This doesn't seem to have hurt Lexra but the embedded control world is a completely different market than desktop computers, servers, and workstations.
Aside from that, IA-64 is huge creaking edifice designed by a two company committee. In terms of ease of implementation Alpha is a much simpler and streamlined design. And with equivalent semi technology the EV68 Alpha wipes up the floor with the merced IA-64 and is much compact too (roughly half the die size). Alpha can likely be licensed by AMD and design assistance, both official and unofficial, would flow in AMD's direction. Also, many of AMD's key designers are ex-Alpha designers. Contrast that with IA-64 where much of the ISA will be hidden in secret "Appendix H's" and the public information will not always correspond to Intel hardware. Intel tied up AMD in court on and off for a decade over x86. They will be happy do the same for IA-64 and will have the benefit of the legal lessons learned in the first war.
Sorry, but IA-64 goes way beyond PA-RISC. There are a number of features in IA-64 that are not in PA-RISC and are the subject of patents. These include the way the predicate registers are saved, the advanced load mechanism, the way NAT bits are used and so and so on. Cloning PA-RISC 2.0 gets you nowhere.
IMHO a 64 bit x86 is an abomination that should never see the light of day. But unless AMD has long term plans to abandon the general purpose desktop MPU business for low and medium performance embedded control applications they have to be a player in 64 bits. A bilingual x86 CPU with an Alpha mode makes more sense to me but even there AMD would have to be careful not to infringe on IA-64 IP.
Well the K8 is touted as a 64 bit chip but this can mean different things to marketing weasels than to engineers. If it is a true 64 bit ISA then it will be very interesting to see what they did. AMD had two choices in making a 64 bit chip.
:)
The first is to build an IA-32 x86 chip and then add a mode that extends the x86 ISA with 64 bit registers, integer and logical operations, and flat addressing ("64 bit x86").
The alternative is to build a bilingual CPU that can execute both IA-32/x86 in one mode and a 64 bit ISA in another. There is really only one choice for the latter that makes sense - Alpha. AMD already licenses EV6 interface technology from Compaq and an Alpha ISA license would be an extension of it. It couldn't be Intel's IA-64 for two simple reasons: 1) details of IA-64 are only gradually entering the public domain, and 2) Intel has many aspects of IA-64 patented and cloning it would be like entering an infinitely deep legal minefield.
I suspect the K8 is the former, a 64 bit extended x86 although the apps and os software availability problems seem formidable. M$ has its hands full with x86 and now IA-64 versions of windoze and there already is an ideal 64 bit ISA to run Linux on - Alpha