Merced Architecture Specs 114
Hasdi R Hashim wrote in to tell us that Intel has released theInstruction Set for the merced. You'll enjoy it if you're the sort
that gets off on this stuff anyway..
"
This discussion has been archived.
No new comments can be posted.
Merced Architecture Specs
Related Links Top of the: day, week, month.
Money is the root of all evil, and man needs roots.
Re:PDF?! (Score:1)
Re:Moron Anonymous Cowards... (Score:3)
However, in this case, I would not be offended if the knucklehead's IP address somehow leaked out.
Re:PA Risc (Score:2)
Re:Virtualization (Score:1)
We won't know for sure until the rest of the documentation (for system programming) is out, but the answer is probably no. Eg. in section 3.1.11 the CPUID instruction is described as unpriviledged with no mention of trapping possibilities.
I laughed, I cried... (Score:2)
Thad
The good news: IA64 sports MMX! (Score:3)
And what about this CPUID reg 2 - Processor Serial Number? I thought we agreed that that was not a Good Thing.
I though this IA-64 was going to be a 'fresh start' sort of thing. Like rid the old crap. I know IA has never been RISC, but even CISC doesn't seem to apply anymore.
Now put yer hands together fer Backwoods Compatibility.
Breace.
Re:Moron Anonymous Cowards... (Score:1)
IDs are common (Score:1)
Where is the rest? (Score:5)
Personally, I don't see how IA-64 has any market. For several years it will remain over-priced for the workstation market. So, that leaves it "targetting" a server market. But given Intel history, can we truely trust them with our terra-byte databases and other critical *server* operations. Well... lets see the history and then decide:
Intel reliablity example 1) Pentium 60-90 is released:
Intel Marketing: The Pentium has a FPU that is up to 10 times faster than the i486 (notice, FPU is a key feature at this point!)
Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU
Intel Responce: Error only occurs in 12th decimal place and hence is not important. No CPU is 100% error free and this error would only occur once in a million years by the average computer user. For those that it is important to, a software fix is possible, the speed difference caused by the software fix should not be a problem for the user (Pentium FPU importance and speed is downplayed by Intel)
Internet FAQ responce: A simple division problem can reproduce the bug with errors occuring in the *9th* decimal place
IBM responce: FPU's handling of subtraction/addition can create the situation where the bug is reproduced in the next division step. A speadsheet user will run into the bug on average of once a *day*. IBM will discontinue it's pentium lines until Intel fixes the problem.
Intel reliabilty example 2) EIDE pre-fetch and Intel's motherboards with PC-Tech EIDE chipset and "Intel Inside" quality assurance
Intel Marketing: computers performance should become much faster because of Intel's push to support pre-fetch capablity in EIDE controllers and OS developers should take advantage of this feature whenever possible with no exception (pre-fetch is a key feature!)
Intel to MicroSoft: the PC-Tech EIDE chipset has a known bug which will corrupt the data with pre-fetch is enabled. When Windows '95 detects this chipset it should disable pre-fetch
Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives. The problem is impossible to diagnose until PowerQuest discovers the bug Intel was already aware of and releases information on it. OS/2 and Linux patches appear shortly after the PQ announcement. These patches increase reliablity and hurt performance by disabling the buggy pre-fetch implimented on the PC-Tech EIDE chipset
Intel's responce: pre-fetch does not have that much of a performance gain (complette contradiction to previous Intel documentation) and disabling the pre-fetch should have no noticable impact. Since the offical (non-beta) version of Windows '95 does this fix for the PC-Tech chipset since the beginning, this bug is a non-issue
Moral of story: "Intel inside" quality assurence on their motherboards only assures reliabilty of drivers for MicroSoft Operating Systems. It provides no quality assurence of the system performance or reliablity following Intel's "documentation"
Intel reliablity example 3) F00F bug
Intel marketing: the Pentium architechure is a huge improvement over i486 and is Intel's workstation and *server* quality CPU (server capablity is a key feature)
Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu
Intel responce: the problem should never occur in actual code and should it occur then it only requires the user to turn off and back on the machine hence this is not really a problem (The key feature of server quality is clearly downplayed here. How often do the users even have direct access to a server to restart it?)
So, is IA-64 another Intel reliablity example? According to Intel (no CPU is 100% error free), yes, it is another example that "Intel Inside" is a *warning label* that Intel "quality" assurance has been provided. History has shown that the only quality that Intel assures is that what Intel marketting considers key features WILL NOT operate as documented and Intel is prepaired to downplay the importance of the key feature.
So, IA-64 will be priced to target the "server" market. But in it's first three years of production will it be as *documented* and provide the same *quality*, reliablity, and *work-around free* performance that proven 64 bits systems do (such as IBM RS/6000, UltraSparc CPU and clones, Compaq/DEC Alpha)? History has spoken, has it not?
Oh. And I think my question still stands. Where is the REST of the IA-64 documentation (that IA-64 will fail to follow)? :-)
Re:PDF?! (Score:1)
HTML is markup language, not really supporting a good layout mechanism. (CSS allows formatting of text, but is not really designed to allow for complete control of the layout)
I think it would be about time to move on from pure HTML and not try to incorporate layout into a structuring language. Document structure could still be encoded in HTML, but do an open, simple, text-based PDF-type layout-language-standard on top of that.. (What about PostScript, I guess that's too cumbersome, or not cut out for this job?)
Granted, documents such as this don't really require fancy layouts, and would be okay in just plain old HTML, but they probably don't have the time to convert all their PDF's into HTML. (The PDF's are needed anyway for printed versions)
Re:Moron Anonymous Cowards... (Score:1)
Re:Yeah, but what about IRQs ? (Score:1)
I can think of some specialist uses for 64 IRQs such as lots and lots of IDE/SCSI/serial/NIC etc controllers (ie big honking servers), but your average user would rarely, if ever, need more than 24-32 (easy to run out with 16, as we all know).
Re:I laughed, I cried... (Score:5)
Cheers,
- Jim
IA-64 Comments: The Compiler / Financing (Score:3)
An example is the "static branch prediction". The compiler will evaluate a comparison for a branch that is always, or never, taken. It'll pass that hint along to the processor to help avoid a misprediction penalty. (Of course, "passing a hint to the processor" means embedding the likely answer in the code.)
It also mentions that the IA-64 compiler views code with a "wider scope" that in some way increase parallel execution. That point really isn't well developed.
Another interesting idea is if you have a branch that could either execute "B" or "C", it can signal the processor to execute BOTH forks. Nice for code the has hard to predict branches.
A great deal of the new features they talk about deal with speculation... speculative data and working the commands in a different order. Some interesting ideas with looping, too.
I'm not a EE, but this looks like it has some smart features built in that aren't normally thrown into a CPU.
My analysis of the Merced docs (Score:1)
yesterday concerning Merced, and i have read between the lines. Let me
know if you think i'm off-base with these assumtions:
1) Merced will max out at 750Mhz in it's first implementation. In the 8
page Application Developer's Arch Gde, they state that Merced will
acheive 6Gflops in it's first implementation, and that it is acheieved
with 4 Multiply-Accumlate units (FMAC). Each unit can do 2 flops, so the
chip can do 8 flops per clock. 6Gflops, divided by 8 flops per clock
gives a clock cycle of 750Mhz. And IF the chip could go faster, i would
think Intel would use those higher numbers. So i think it's safe to
think that 750Mhz is all that Intel can produce at first.
2) Since the maximum Gflops rating would include all FMAC units (that's
the assumtion i'm using), then that would indicate that the Mecrd chip
will execute 2 LIW instructions per clock. Each LIW word has 3
instructions, which is not enough to send 4 FMAC instructions, so Merced
must be able to send 2 of the 128-bit instruction words to the execution
units.
3) Assuming #2 is right (it might not be), then Merced can perform 6
instructions (3 in each LIW word) per clock for a maximum MIPS of 4500
instructions per second (yes, yes, i know how useless MIPS is for
benchmarking). Or, because of the FMAC units doing 2 ops, 10,000 Mops,
or 10 billion operations per second.
I'll be reading the 400+ page Intel doc today, and i hope to find more
information about memory access. The above rates assume that the chip
can get enough bandwidth to use all the units above. Just the
instructions alone mean that Merced needs 24Gbytes/second (256-bits per
clock, 750Mhz) of cache/CPU bandwidth.
Re:I laughed, I cried... (Score:2)
that I fear isn't really happening. This,
combined with the ability to have more eyes
looking at current work, would certainly make
it nice (imho) to have at least a cvs read-only
server with their current work...
Re:Moron Anonymous Cowards... (Score:2)
However, crap should be dealt with. Rob should be able to track down the IPs of the offending people and contact their ISP. If anything, it's a form of abuse that most respectable ISPs won't allow (the same holds true for newsgroup postings in many cases, so I think the rules can be made to apply to these sorts of things). If the person continually offends and the ISP refuses to come around, Rob can either a) block the ISP (preferred) or b) post an e-mail address where
Either way, the system isn't at fault here; abusive users are. Deal with the problem, not the symptom.
Re:Where is the rest? (Score:5)
There is only one problem that can kill an CPU architecture: lack of address space. Nowadays we already have Freebsd.org that uses 4 GB, some people whinning because Linux only gives 2 GB (or 3 GB) to user programs, and many people complaining because Linux as a 2 GB limit on files. I personnaly was lucky enough today that Microsoft couldn't design an extensible filesystem, so that I was able to copy the default installed 2GB FAT partition to a Linux partition. It is clear that the x86 (IA-32) architecture is dying ; IA-64 is a necessary evolution. Would you use a 8 bit processor with 256 bytes or 64Kbytes addressable memory today ? No. Or do you think that 4 GB should be enough to anyone ? Hennessy&Patterson give a list of some machines that died because of lack of address space: PDP-8, PDP-10, PDP-11, i8080, Intel 8086, AMI 6502, Zilog Z80, Cray-1, Cray X-MP. They also say something like "in the 90ies, when the 32 bits will come to their limits, it would be interesting to see is the same choices about addressing and segmentation will be done again". If you are saying that IA-64 has no market right now, then it would means that Intel has brought to us innovation faster than necessary. This isn't necessary evil.
You then complain about Pentium bugs: Reality: i486 correctly calculates FPU, Pentium does not. Anyone can make a random number generator that outperforms the i486 FPU
Intel's "secret bug" effects on OS/2 & Linux users: data corruption occurs when Intel motherboards with the PC-Tech chipset and two hard drives.
Reality: the CPU fails to meet Intel's own documented specs to throw an exception to F00F and instead halts allowing a method of implimenting a denial of service attack either accidently or purposily against the "server" quality cpu
So ok the first one was a serious CPU bug that could have been avoided by tests. But you fail to give an exact account of all the bugs of others CPU, so you can't tell whether Intel is bad or not.
Also, since Intel is mainly in the consummer market, I don't expect it to send instantly an Intel Bunny People to change my CPU at once, when they discover a bug. This is bad and wrong, true, but this is expected ; most companies would operate that way ; they try to minimize, and lie, etc... because it would be a net loss of revenue. It's up to the consumer to defend himself (up to the law to provide the ways to defend himself, and up to the magazines to have competent enough journalists to report hidden problems, up to the user to buy these magazines, etc...). Look, my CD burner is a Philips CD-2600. I bought it, then I discovered people were saying lots of bad things about its reliability ; and then latter, mine died (now replaced by my vendor by one which happens to work "most of the time"). Did Philips come to change my CD ? No. When you go to www.philips.com, CD-R section, do you find information about possible problems on CD-2600 ? No. Is Intel worse than others companies ? I don't know ; I do know that many chipsets for miscellaneous cards have also their share of bugs.
Your point is valid for the server market ; but maybe Intel managers aren't too stupid to release completly untested insufficiently tested IA-64 chips, when they are targeting the server market. What do you think ? The quality manager comes and says to the boss, Andy Grove: "I need 1 month and $100000 to release a broken IA-64 (broken with a probability of 99.99% on simple applications), 12 months and $1 million for a probability of grave bugs of 1%, or $100 millions for a probability of 0.0001%". Andy Grooves asks "how does the 0.0001% compares to Alpha?". The manager answers "it is a bit higher, maybe 3 times, but same order of magnitude". So now what do you think Grove says ? "Go for the $100000, I had always dreamed to screw the entire planet! Our reputation will be ruined, and Intel will go bankrupt! Hooray!!!" ?????? I know this is slashdot.org, but try to be a little rational.
Maybe you are complaining that Intel can't design chips ? But at equal frequency brand new design such as PowerPC are only 10% faster than the PII crippled with all its compatibility stuff. Frankly I've seen major design blunders much more frequently in software (Redmundian, or in Unix, thus inherited by *BSD/Linux). When I was using a 286, I sure was pissed to have a processor with such a poor/baroque design ; but now I have a PII, and it is pretty respectable.
For undocumented features, some of them are not disclosed to keep the competition to make a 100% compatible clone, and some because they don't want people to use minor features that will cripple the future evolution of the processor.
Keeping the competition from doing a clone is not cool, but again is to be expected (but then, people aren't obligated to make clones, right ? Look at the miscellaneous RISC. Nobody does a Windows 2000 clone nowadays). We have to make pressure on Intel for it to avoid lame techniques that would be the consequence of its monopoly, though.
Keeping some non-vital information secret, is a defensive technique, in order to keep the users from doing something stupid, such as gaining 1% speed but at the expense of crippling to future processors with backward compatibility for their hacks, and maybe forbidding a 2x speedup. An example would be downloading microcode ; if users knew how to, and did that, then Intel would be forced to keep all the next CPUs compatible with this user-defined microcode ; maybe they would have to add a layer of indirection on next generation processor: microcode for microcode (much like nowadays x86 are translated in RISC86 instructions. If you could wrote directly RISC86 instructions, then Merced would have to translate also your RISC86 instructions to IA-64, at a performance cost). Well, maybe only if some clown at Redmond had done that, trying to optimize the in-kernel IIS server in order to improve on some benchmark, but you get the idea.
I'm tired of people critizing Intel on shaky grounds ; it is true that there are more cleaner designs than the IA-32 architecture, and maybe better than the IA-64, but what we have is somewhat decent. If you want to criticize, please do compare to other companies.
Re:Moron Anonymous Cowards... (Score:3)
There was an excellent example a few months back. In one of the Free vs. Proprietary Holy Wars, an AC posted details of a lawsuit that his company was involved in as a thought-provoking case study. He (or she) would have been fired for doing this non-anonymously.
From what I can see reading at -1, maybe a third of AC posts are garbage, and most of the rest are at best average, but I see no reason to get rid of AC just because of the actions of a handful of twits. This is the second time that a lone idiot has spammed a thread. A solution that only attacks those twits would be nice.
Both banning IPs and limiting AC posts from an IP run into the problem of ISPs allocating IPs dynamically, and firewalls remapping users to a single IP address. However, it still might be the best solution (I'm open to other suggestions).
Or log IP and time for each post, so that Rob can contact the ISPs of abusers and get them LARTed. But that would be a lot of work for Rob.
Re:Moron Anonymous Cowards... (Score:1)
Just because there are some asshole ACs out there doesn't justify disabling all AC access. Even the IP/domain limit could be detrimental to the freedom of commentary here.
What do I see when I bump my threshold to -1? Yes, there are asshole ACs. But the thing that I really see is that Moderators are useful and NECESSARY on slashdot.
Its like the rockman said. "You see what you want to see. And you hear what you want to hear."
Felix
New Space heater... (Score:1)
Linux/IA-64 (Score:1)
occuring out in the "Open" now? Hmmmm?
Re:I laughed, I cried... (Score:1)
Haha, nice pun (Score:1)
Re:Yeah, but what about IRQs ? (Score:1)
That said, I'd forgotten about the SMB boards having more IRQs. Thanks for the heads up.
Re:IA-64 Comments: The Compiler / Financing (Score:1)
BSD ports collection, anyone?
Re:I shan't use Intel again (Score:1)
2) You are comparing 2 chips that aren't even for sale yet. I'm not sure that i'd feel comfortable comparing the 2002 ford taurus to the 2005 Toyota Camry.
3) The Merced is not designed in any way to be an upgrade to an existing chip. It is so totally different, and needs a different motherboard. A Mac example would be the 68K to PPC transistion. At that time, you couldn't just change the chip either (but you could get a card that replaced part of the motherboard ASICs).
4) Motorola is doing ok, just not in personal computers. One could ask why the PPC failed in the mainstream, but if there are only 2 options, MacOS and now BeOS, it just won't be a big seller. Ask instead where Pink, Taligent, Solaris PPC, AIX and OS/2 went. I think that the PPC couldn't take off like it should have without something to run on it.
5) You are comparing the G4 and Merced, but really they are for very different areas of the marketplace. I don't think anyone is suggesting that the Merced is for personal computer like the G4 is. Merced is for very high end workstations, and honking big servers.
6) i should tell you that I too am a Mac person. I'll never buy Intel or MS, ever. So i understand some of your feelings, but i just thought that your points were a little off base.
-r.
forward binary compatibilty (Score:2)
--
Re:forward binary compatibilty (Score:2)
Unless Windoze NT, Linux, and other IA-32 (and future IA-64) operating systems begin supporting "fat" type executable formats, executables compiled for IA-64 won't work on IA-32 systems.
There may also be byte-ordering and little/big endian issues involved, if you are also talking about having data that is IA-64 and IA-32 compatible.
Personally, "fat" executable formats don't appeal to me. Waste of disk space and file transfer time, if you ask me. Uh yeah, I want to download a 30MB application that will work on IA-64 and IA-32 vs a 20MB one that works on IA-64 (or IA-32) only... NOT. Sure, it might make life easier for Joe lUser, but those people can go buy a Mac if they really want to.
Re:Virtualization (Score:1)
Re:Quick summary: FDIV approximated. (Score:1)
There is a x86-OS compatibility mode. How well it works remains to be seen.
Re:PA Risc (Score:1)
Linux/ia64 being done already [was: Re:Linux/IA-64 (Score:4)
is a nice summary (including pictures of all the
slides and the boot screen):
http://marc.merlins.org/linux/linuxexpo99/Day3/
Re:Cmdrtaco must.. (Score:1)
This is a new beast... (Score:1)
Re:How does it stack up to other chips (Score:2)
Of course, that's only one factor. It's almost impossible to say how it's going to stack up against the competition when it gets released. The competition isn't sleeping...
Merced is positioned at the high-end, so it should be very fast. It'll probably be quite expensive at first, until Intel starts to phase out the Pentiums.
Cheers,
- Jim
Re:I laughed, I cried... (Score:5)
Glad to hear it.. always nice to see more users added to the Alpha Linux community. You also may want to wait a while until the AMD K7 hits the market. As you probably know, the K7 and 21264 (EV6) processors use the same bus protocol. It is widely rumoured that mainboards which accept either the K7 or an Alpha processor are in development.
That will be a very powerful option, especially for Compaq - using the same components, sell K7 systems to the usual userbase and Alpha system to the power user/server market.
Very sneaky indeed.
Re:In other CPU news. (Score:1)
You can still run x86 code on the Merced. The IA-64 architecture has two compatibility modes:
1. A 32-bit operating system compatibility mode (basically, the Merced running as a Pentium). I'm not sure what the speed will be on this.
2. A way to execute all types (Real, virtual-86, and protected-mode) of 32-bit code under a 64-bit operating system (this is similar to Virtual-86 mode under a 32-bit OS)
Re:Quick summary: FDIV approximated. (Score:2)
Intel uses this technique on the i860, giving results accurate to the last couple of bits.
Re:I laughed, I cried... (Score:1)
The whole PSN thing is ridiculous, ignore it.
I shan't use Intel again (Score:1)
After getting burned by Intel -- the OTHER company keeping the entire industry back 10 or 20 years -- I decided I'd had enough. I needed a new computer for college, and I got a Mac. And you know what? My crapola 604e@180MHz can not only be upgraded to a 400MHz G3 (a REAL G3, as opposed to the lame-ass upgrade chips Intel eventually offered), but it will be eventually upgradeable to a G4. How many PCs from early 1997 will be upgradeable to Merced (assuming it is ever actually produced, of course)? [yahoo.com]
Really, the whole Intel paradigm is trash. Why is Motorola doing so poorly if they're desigining much better products? Yes, the Mac OS isn't that great, but that's no reason to harm the beautiful 750 or mmmmm... the 7400. Yum.
Merced users are going to start feeling dumb when the 800 MHz G4 iMacs (starting at ~$1500, I'm sure) start rolling out and everybody's grandma has a computer that toasts that $20k Intel hulk.
Re:I laughed, I cried... (Score:1)
Re:I shan't use Intel again (Score:1)
IA-32 Virtual Mode ?! (Score:1)
Instructions (jumps) for going back and forth between IA-32 and IA-64 are given too, which is nice to mix old/new code.
Re:yeah... well.... (Score:1)
Now, if he had to do a reverse-dns lookup, that would put extra load on the system.
Re:The good news: IA64 sports MMX! (Score:1)
Like everyone else has said, lots of parts in computers have serial numbers, especially on higher level hardware. I've got no real problems with that.
It's Intel's marketing, proclaiming it a way to track users and secure e-commerce, that is not a Good Thing.
thejeff
Re:IA-64 Comments: The Compiler / Financing (Score:2)
One of the things that is interesting about the IA-64 is that the compiled code to be run on it is highly sensitive to the particular architecture of a given chip. Intel's docs say that the architecture is highly scalable, that they'll be able to add new execution units, etc., quite easily, but they don't mention that the choices an EPIC compiler would make would change quite a lot depending on the physical chip details.
As a consequence, we might see things like Just-In-Time compilers become more significant than they already are, since they could make those decisions when code is executed on a particular chip. Depending on how expensive the EPIC logic is to compile to, this might or might not be a big boost to Java, etc.
Pentium 64? (Score:1)
Man, I sure hope they decide to come up with a new brand for IA64!
Re:IA-64 Comments: The Compiler / Financing (Score:2)
Researchers have also toyed with the idea of dual execution, which is a similar idea, only it is done dynamically by the hardware. A simultaneous multithreading machine might do this, for example.
Predication can also be used to eliminate the loop prologue and epilogue when performing software pipelining, resulting in smaller code size.
The slides at the site give some good examples of how to use predication.
Merced and the alpha (Score:2)
If I am right even the *estimated* merced specs are about in line with what you can get in a decent 21264 alpha right now. Unfortunatly I'm not as familiar with other architectures besides the alpha, but that is the current performance leader so its definitly the best to slam intel with.
If everyone is going to have to port thier apps to ia-64 with merced and all that I don't see why they might just not port to alpha at the same time. I don't know much of anything about the actual porting of apps so please correct me if I'm very wrong. From what I have heard the biggest deal in currently porting from x86 to alpha is the move from 32 to 64 bit with data structures and the such. If, as it looks now, most of the merced work is done in the compiler hence everything will need to atleast be recompiled if not re-coded, then this could be a key turning point in the popularity of the alpha. If everything is going to 64bit why not go to one of the fastest, and definitly more stable 64 bit processors, with no backward compatibility crap and built for nothing but pure speed. The only problem I see currently for the world dominance by the alpha is the price, though it seems compaq is starting to try and fix that part too. By no means is a 533 alpha system cheap, but its not too bad when you consider the performance of what you are getting.
But off topic i have gone. Hopefully compaq can position itself in a position to take advantage of the fact that millions, if not billions, of lines of code will need to be re-written and make sure that code is also ported to the alpha. This could be intel's worst mistake yet, trying to force people to change platforms from one where they all but wrote the book to one where they are at a distinct disadvantage.
--
I'm not the devil's advocate, my box just runs at 666
Yeah, but what about IRQs ? (Score:1)
Come'on, even 68000 has 192 interrupt vectors with 5 interrupt levels...
Re:Moron Anonymous Cowards... (Score:1)
This isn't the full IA-64 instruction set (Score:3)
Start, perhaps, but not finish. The document in question is the IA-64 Application Developer's Architecture Guide, which appears not to give all the details needed for low-level OS programming; it says:
and some of those details will presumably be necessary for OS kernel work.
Re:IA-64 Comments: The Compiler / Financing (Score:1)
> The compiler will evaluate a comparison for a
> branch that is always, or never, taken. It'll
> pass that hint along to the processor to help
> avoid a misprediction penalty. (Of course,
> "passing a hint to the processor" means
> embedding the likely answer in the code.)
Though the white paper isn't clear on this, they aren't talking about static branch prediction as a chip feature. The improvement comes when the compiler can't tell which path will be taken.
In this case, on a low-end PowerPC, the compiler will guess. For example, for a loop, it always predicts the loop will be taken. For the high end PowerPC, its hint is used as the initial prediction (weakly predict taken or not taken, see below).
The high-end PowerPC does dynamic branch prediction. It has a LRU cache of 2 bit values for the last N branches taken. 00 means strongly predict not taken, 01 is weakly predict not taken, 10 is weakly taken, and 11 is strongly taken. Each time a branch in the cache is hit, its value is incremented if actually taken, decremented if not.
In both of these cases, branch prediction determines the path that will be speculatively executed. I understood what made the IA-64 special was that it executes *both* paths speculatively and then throws away the changes from the path not taken. In other words, it doesn't do branch prediction at all.
Re:PA Risc (Score:1)
Could be; if I remember correctly, they handled the transition from the 16-bit stack-machine HP 3000's to the 32-bit PA-RISC HP 3000's by doing binary-to-binary translation, and they may plan on handling the PA-RISC to IA-64 transition in the same fashion.
Quick summary: FDIV approximated. (Score:2)
1) Backwards compatible with x86 for applications not OS. Interrupts serviced in IA64 only.
2) Fast register stack & 128 registers. Will be fast for call/ret. But no memory stack.
3) Nice FP dot product & single precision parallel calcs. But no division/sqrt/exp/trans. Approximations via 256 ele lookup-table!
I suspect this chip will underperform P6/K7 at x86, and may underperform 21264 at FP. Then it will need strong OS/app support. Linux?
-- Robert
How does it stack up to other chips (Score:1)
Sounds exciting, wonder what AMD is going to do about this. Shame AMD will probably be the one keeping the x86 arch alive, as much as I like its price/performance ratio, we need to move on
Just my 3.597349574937502 cents
Re:I laughed, I cried... (Score:1)
Die psn, die!
More Cannon for the Fodder (Score:2)
In other CPU news. (Score:1)
Well I have seen alot of comments about how they (/.'er) wished there were other competitors in the x86 field and I just wanted to point out this link to you guys, which I sent up about 11am, but hasn't been posted.
Rise Technologies [rise.com]
"Windows 98 Second Edition works and players better than ever." -Microsoft's Home page on Win98SE.
Re:I laughed, I cried... (Score:1)
Yes, having a board that will accept either alpha or K-7 would be nice. Having a board that will accept BOTH at the same time would be nicer. I'd really like to get the speed of alpha for native processes, without losing the ability to run solitair in WINE. (what else does anyone do with their time anyway?) I'm sure there are more things that can be done too.
I hearby disclaim any acknologiment, monitary or otherwise from any person or other entinty using this idea.
Re:This is a new beast... (Score:1)
Already got one. Alpha and SPARC64 run it.
Making Linux run well on Merced isn't likely to be very hard by itself. Making GCC work well with it will be much harder (with emphasis on "well"--a half-assed job wouldn't be hard).
-EdJust say no (Score:1)
Re:Yeah, but what about IRQs ? (Score:1)
Good question. I may be missing something, but, as far as I can tell, there's no hardware reason why an OS couldn't let multiple PCI devices share the same IRQ (heck, I did much of the PCI support for an OS that did so on hardware not too far from a somewhat fancy PC, namely NetApp's Data ONTAP on the F3xx and F2xx filers).
Perhaps many PC OSes don't support that, but, if so, perhaps those OSes will get fixed for IA-64 (although if Windows 9x is one of those OSes , it may not get fixed, so people who have to reboot their shiny new IA-64 workstation to run some games might be screwed).
Not that I want to ban AC postings, but... (Score:1)
Re:Moron Anonymous Cowards... (Score:1)
Why don't you ban AC's by setting your threshold to 1, and the rest of us won't miss out on that one good post? You have the means at your disposal to solve your problems, but you'd rather complain. Most people wouldn't even have known about the AC situation with this article if you hadn't brought it up and been the highest ranked article for a while. I normally wade through all the -1's, but you don't have to if you don't want to. If you set your threshold low, you have to take the good with the bad.
Of course, an AC could create a login but not provide any public contact information in their user info if they are posting from work. This is what I have done. Only Rob (and my hairdresser) knows for sure...
CPU ID is still there. (Score:2)
Re:How does it stack up to other chips (Score:1)
Howdy!
The only reference to speed I could find was the aim that it "will be 3x faster than a PIII". The basis for this is that it will apparently do 6 gigaflops as oppossed to 2 gigaflops for the PIII.
If I was cynical I'd say that this is probably the best spread (3 times!) they could get for a press release and that gigaflops != SPEC numbers.
If the Merced really has an FPU 3x faster than a PIII that means what? 45SpecFP? 60SpecFP? 2nd quarter of next year? Don't Alphas do that _now_?
Anyone else see any performance numbers?
=tkk
Re:IA-32 Virtual Mode ?! (Score:1)
PA Risc (Score:2)
Cheers,
- Jim
Re:forward binary compatibilty (Score:1)
Well, saying that executable format has nothing to do with processor architecture(s) seems a little strong. The two do relate in quite a few ways.
>Personally, "fat" executable formats don't appeal to me
Me neither. One alternative would be to distribute code "compiled" for some sort of VM and then either interpret it or compile it (user choice) as is done for Java. This is a special case of the more general approach tried by ANDF (Architecture Neutral Distribution Format, for you younger folks) and similar efforts peaking around ten years ago. Some used virtual machines, some encoded parse trees so you could do more global kinds of optimization while compiling ("installing") the result, etc.
There are some really big-time hairy issues involved in all this, but I've never been convinced that the non-adoption of ANDF was really due to technical failings so much as end-user ignorance of the benefits. I would love to see some of these ideas brought back.
Re:Yeah, but what about IRQs ? (Score:1)
Some friendly advice (Score:2)
1) Contacting the ISP of the obnoxious AC is inappropriate, no matter what he or she posted. The 'anonymous' account is offered under the condition of anonymity for whatever purpose - I seem to recall a thread where someone posted anti-minority and Nazi-like propoganda. In bad taste? Yeah. Something Rob should track down the person for? No. The point at which you start doing that, you are no better than they.
2) Spoofing. Everyone knows what it is, everyone knows how to do it. What if the logs show the comments coming from 'www.hp.com'? What do you propose doing at that point, contacting the upstream provider to yank hp.com's access? I hope not.
3) Moderators are here for a purpose. That purpose happens to be knocking inappropriate messages below a certain threshold so that the majority of users do not have to see them.
Rob should be the only one with a complaint here, folks - somebody just inflated the size of his message database by about 5k (whoopie!).
4) This is a _message board_. Come on folks, it's
not like somebody just threw rotten eggs at your house or something. Settle down, take a deep breath, and work it out.
Olorin.
Re:IA-64 Comments: The Compiler / Financing (Score:3)
1. The execution speed is only "halved" (i.e. half the parallel processors are doing something that will be thrown away) until the test completes executing. How long this is depends on the architecture. The way they do their speculative execution, they can keep more of the processor busy at any given time. Sure, you throw out a lot of your work, but you rarely have to start over. What kills execution time is pipeline stalls, which this avoids.
2. You seem to be implying that this is a bad thing. In a "perfect processor" it might be, since you have some execution units doing stuff that won't be used, but compared to other current architectures, this design is a win, since you avoid the problem of mis-predicted branches, which are expensive.
Compare what the IA-64 does to what the PI/PII/PIII do currently: The processor guesses which side of a branch it should take, and starts speculatively executing just that branch's instructions. When the test completes, either:
1. The prediction was correct, and everything moves along as normal
2. The prediction was incorrect, everything is thrown away, and it goes back to follow the other branch. This is very expensive. (on the order of 10-30 cycles, if I remember correctly. The whole pipeline has to be thrown away.)