Slashdot Mirror
IBM joins Trillian project
IBM will be
joining the Trillian project to port Linux to Merced. The other
members of Trillian are Intel, VA Linux Systems, SGI, Hewlett-Packard,
and Cygnus Solutions. Linux will be shown
running on a
simulated Merced today at the Linuxworld conference.
Not so. Merced is x86 compatible. Some one at Intel has even said that they would include a 32 bit CPU on the chip if neccessary in order to keep x86 compatibility. It will be slower than Willamite, but will keep x86. Looks like Merced as far as they eye can see.
A deep unwavering belief is a sure sign you're missing something...
Well, this doesn't say much, but I have seen a preliminary linux port boot under the simulator, on a laptop no less. I was expecting it to boot glacially slow. It didn't. It booted suprisingly fast, in my opinion. Unfortunately, I didn't do any timings.
This was some months ago, and so the laptop was probably a P300 or slower.
To do what, specifically?
To switch between two separate instruction sets, I'll believe. You need more decoding logic, but it can be done fairly easily.
To allow programs to be written in microcode, I doubt - microcode has a very low code density, which leads to many, many problems. RISC is just as easy to optimize, so you don't gain much for your pains.
My alpha runs at 666....and the machine name is goat. A coincidence? You be the judge. :) MUAHHAHAHAHHAHHAHHA Seriously, I love my alpha but it will be nice to hopefully finally get some developers for it considering merced will make most developers atleast think about 64 bit, and that will make moving apps to the alpha much less of a pain.
It's always funny to see the slashdotter's chest's puff up when they crow about Linux -- especially when they don't know what they're talking about.
Here's a clue: A version of NT running on Intel's Merced simulator was demo'd at some Intel press conference many months ago. According to this article, they're just getting Linux limping along on this simulator now.
Another clue: Microsoft has announced that it'll be shipping the 64 bit version of Windows 2000 early next year. They're not waiting for Merced, you'll be able to run 64 bit NT on the Alpha while you're waiting for Intel to get their act together.
Yet another clue: Windows 2000 is a much better OS than Linux. :-)
That waggish quote is in reference to Windows 9x, NT is 32 bit (soon 64 bit) clean.
Really, I don't understand the anti-NT animosity here on slashdot. It's a great unix-like OS that can run all the consumer Windows' binaries.
Although most consortiums have ended in failure, it looks like this Trillian thing (if successful), will spell the end of Microsoft as a vendor of operating systems. Looks like the major players are trying to move the OS from a product that is developed and sold by a single company to one that is developed and distributed by the community of users (and those who would benefit commercially from it). Result : cheaper PCs - not Microsoft tax. Unfortunately, this Trillian thing is under NDA with Intel and that also means that Linus is out of it. So, it looks like Linux development is slowly but inevitably moving out from the grasp of it's creator. Being a software developer myself, I do not envy those who will have to re-merge the final merced kernel with the current one. BTW I don't mind being Anonymous Coward, better than Hopelessly Inefficient : still haven't received registration info from slashdot. Name's Ben and email is bluesky6@ix.netcom.com
Regarding optimisations for 3D-now type special features of x86-like chips:
:)
Where must one make the optimisation? Is it possible to have a compiler that will automatically take advantage of the features? or do you have to explicitly write code into your app that will know what to do? (I've seen this, for example, in mpg123 - there's a compile-time option to use 3dnow if you have an amd chip).
Thanks
Through bad planning, Microsoft is naming their new OS windows 2000. Since not many people would buy windows 64 when they could get version 2000, they have decided to wait for a 2048 bit architecture they can release as windows 2048. Incidentally, this is the projected release date of the product as well.
Nah, I'd prefer "Win64 is a 64-bit rewrite and makeover of a decent 32-bit rewrite and makeover of a 16-bit patch of an 8-bit OS written for a 4-bit processor STOLEN** by a 2-bit company that is threatened by Linux and *BSD who came along not 1 bit too soon." "Windows Millenium* is still a 32-bit shell and extension to a mediocre 16-bit GUI hack for an 8-bit OS written for a 4-bit processor STOLEN** by a 2-bit company who still can't stand 1 bit of competition despite being threatened by Apple, Be, and the X-advocates." *"Millenium" is the internal MS codename for the next version of DOS based Windows (unified Windows? HAH!) **If you know the history of DOS and Windows, you'll understand.
Sure you can: you can program the MMU to restrict RAM virtual addresses to 32 bits in length, and you can also load 32-bit pointers into registers so that they are automatically sign-extended to 64 bits.
DEC (uh, Compaq) has a term for this usage: it is "taso" (for truncated address space option) and it is there to ease porting of crufty old-style "an int is a pointer" code. Does anyone remember the Vax?
One could write an entire operating system in TASO mode. Few have, just 'cause it is so elegant to use 64-bit pointers. But if you have a runtime system with data structures dominated by pointers, using TASO mode can save a lot of space.
Oh, and I've seen NT running on the Alpha. So Microsoft can run 64-bit code. And the IA64 does have compatibility mode for old-school IA32 (nee x86) code.
Nah, I'd prefer
"Win64 is a 64-bit rewrite and makeover of a decent 32-bit rewrite and makeover of a 16-bit patch of an 8-bit OS written for a 4-bit processor STOLEN** by a 2-bit company that is threatened by Linux and *BSD who came along not 1 bit too soon."
"Windows Millenium* is still a 32-bit shell and extension to a mediocre 16-bit GUI hack for an 8-bit OS written for a 4-bit processor STOLEN** by a 2-bit company who still can't stand 1 bit of competition despite being threatened by Apple, Be, and the X-advocates."
*"Millenium" is the internal MS codename for the next version of DOS based Windows (unified Windows? HAH!)
**If you know the history of DOS and Windows, you'll understand.
That's the first time I've ever heard someone call coding in C "safe," without breaking out in giggles. ;)
-jaz
People who use the word "methinks" in written communication are invariably wrong and ought to return immediately to the renaissance fair. Huzzah!
Ok... Their marketing department calls these RISC instructions, and I call them microcode bit vectors. The article you cited points out itself the differences between this and conventional RISC instructions - RISC instructions don't contain as much internal control state information. They also are usually one machine word in size (32 bits on most PCs, 64 bits on most workstations). These bit vectors are much longer, which leads into the main problem with this approach, which I mentioned in other responses - very low code density.
By writing in microcode, you skip any decoding latency that might exist, but you end up having to transfer several times more information than you otherwise would. This means it takes several machine words to specify each instruction, and several bus cycles to load each instruction (full bus speed != one instruction per bus clock). You could put in a wider memory bus, but the same problem applies - your instruction stream bandwidth just went down a lot. As memory bandwidth is one of the main limiting factors for system performance, this will hurt, a lot. Additionally, the instruction cache can suddenly hold far fewer instructions - you either need a bigger cache to compensate, or suffer through many cache misses.
I am very surprised that NextGen actually built a chip using this approach. It's an interesting idea, but as I state in other messages, conventional RISC is almost as easy to decode and doesn't suffer from the code density problems described above.
The question is, does the K7 bus do what the Nx586 bus did and what the Socket 7 motherboard bus did not -- can it bypass the 80x86 decoder?
I strongly doubt it. No mention of this was made in any of AMD's releases, there is no pressing market demand for it, and it would probably _worsen_ performance, as described above. What they _could_ do is allow an additional RISC instruction set, which would accomplish much the same thing, but it is open to question whether the (very substantial) additional design effort would be worth it for their target market.
Intel is doing something similar to this with the Merced, with x86 and VLIW modes, but that design has its own problems.
In a simple RISC pipeline, there is really no microcode per se involved. The decode from instruction to control signals is through much more straightforward circuit-based transformations than a table lookup. I wouldn't really equate a mux based on bits of the instruction to a full-fledged ROM indexing as with microcode. WRT code density, look at MIPS. You need noticeably more DRAM and disk on an MIPS-based workstation than an Intel PC. But I understand what you're getting at. Some people may want to take a look at the MIT LCS's "RAW chip", where explicitly program more, e.g. the routing between functional units.
Will Microsoft be calling the 64-bit version of Windows, NT64? Then all the programs will be required to have the 64 suffix! (For the video-game knowledge challenged Nintendo64 =N64, N64, NT64 get it?)
A deep unwavering belief is a sure sign you're missing something...
From what I've read it sounds like all the quirks in the Pentium are taken into effect and are then optimized for the Pentium (eg. you need a FP add before a FP multiply to make sure the pipeline works) - those will need to be taken out for the K7, or at least dual-coded. Like the IA-64 architecture, the K7 will be alot more compiler dependant. (K7 not to as high a magnitude as the Merced of course.)
--onyx--
They added a new processing mode in which the Merced's new instruction set and register structure are accessible, I think. Ooh, great. EEEAX, EEEBX, etc. Just what we need. Bah.
There is a big difference between simply being able to run x86 programs and being able to run them well. Excuse my language, but if you buy a Merced to run x86 software YOU'RE A FUCKING MORON!
Think about it: the entire point of the Merced is to place the burden of optimizing a processor's operation on the compiler rather than the processor itself. Merced's performance is totatly reliant of the quality of the compiler. In x86 most of the work is done in hardware. But the Merced is not an x86 processor, it is an IA-64 processor with x86 emulation. This means that the Merced will simply lack the hardware to optimize x86 operations. It propably won't be able to do any branch prediction, out of order execution, and will be unable to use more than one pipeline. Basically, it will run like a high clocked 386, if that well. Did I mention that it will also cost a freakin fortune? I don't know why they even bothered to include x86 compatability. It sure as hell isn't worth anything. The Merced needs its own software in order to succeed.
I am not an idiot. Please use my name to email me.
"That's right, I'm quoting myself."
-Upsilon
I am reading a lot of comments about microsoft being 64-bit clueless. I am not sure that's exactly true. Don't they have a neglected version of NT for alpha processors. Isn't alpha 64 bit?
I know alpha and merced are wildly different. I think maybe we need to watch MS a little more carefully.
that's exactly true. Don't they have a neglected version of NT for alpha processors.
Isn't alpha 64 bit?
Yeah, alpha chips are 64bit, but NT isn't. It runs in "32bit emulation mode." Meaning that NT doesn't take full advantage of the architecture, and it also probably means that there are some serious flaws in M$'s code that keep them from easily porting to 64bit. Expect M$ to get left in the dust by Linux on the IA-64.
I agree that the Alpha is a nice processor. I also agree that Merced sucks. McKinley (2nd rev of IA-64 Architecture) will outperform Merced in every respect that matters. So I think that the thread should read "Merced Sucks. Go with McKinley."
Is doomed. Knowing IBM/SCO, they'll try to position Linux as the low-end solution and Monterey as the high end solution. If that happens, they'll be at direct odds with SGI, which apparently is betting the ranch on Linux and will therefore want it to be as fast as possible. Oh yes, we live in interesting times...
As I recall, HP was showing Linux running on an IA-64 simulator at another Linux Expo (also in San Jose) some months ago. Does anyone know how this one is different?
I know this is kind of off the wall, but its true to an extent, think about the current IA32 platform, intels business thrives on making your system appear faster and faster, if MS were coding efficient (read 32bit) operating systems for the consumer market, intel wouldnt sell anywhere near as many high end chips to 'power users'. Even their 32bit code bites as far as speed goes. The great thing about linux is i can still run it on my (old by todays standards) k6-233 and it screams, NT in particular, you're pushing it. By helping out Linux get on Merced at launch along with the other unixes Intel and co secure the server market, while the desktop market is set to make big bucks simply because intel can keep cranking out chips that simply -have- to go faster because MS's software is so inefficient. *shrugs*, maybe I just have a thing for conspiracies
Thinking back to Hitchhikers Guide to the Galaxy... Who was Trillian again? Was she Zaphod's something-or-another? I can't remember anymore...
Photos of bits of the past hiding in the present: afiler.com
if you a) got the wink2 beta, then you would have b) the win2k SDK cds which woudl have full docs to win64 on it
You are mistaken. Linus has been consulting with Intel all along. But Linus is not involved with the low level details, only policy and general design details not subject to NDA. By this time next year, (maybe sooner), Merced with be officially part of the Linux kernel sources.
From the Athlon info at Tom's Hardware it looks like the processor has fewer pipeline quirks than the Pentium line, so K7-specific compiler tricks would be less important.
K7 optimization is still possible. Turn off all Intel-specific instruction order constraints. That will give the compiler more options for other optimizations that depend on reordering.
This is what I see would solve many performance problems. Why can't they manufacture simple RISC-chips that don't reach as high MHz and them just plug something like 32 in a single box. The parallel processing should happend at the source-code level, which means that C must go as a development language and be replaced by something more easily parallelisizable like some functional language (e.g. lisp) or Prolog (maybe Parlog). Add some DSP-chips to do audio and generic stream processing and a specialized 3d geometry processor for the 3d gfix and the gamers would be happy. Why, oh, why does it have to be a single processor ? Make cheaper chips and parallelize.
AC
Yeah... I was just making a parody of the other postings.
click here
Why fight about with arch is best, its how many SPEC's and FLOPS you can get out of it that matters. I dont care if its Alpha, MIPS, AMD or Intel, I pick the fastest one.
Will there need to be any special ports or optimizations necesary to take full advantage of the K7 processor?
I can't wait! No silicon yet but, wow, a simulated merced!
Don't lead me into temptation... I can find it myself.
Intel has the fabs to crank out millions of Merced chips at affordable prices. How many 21264 chips can Alpha Processor Inc. ship? The last time I checked, 21264 motherboards and systems were very expensive.
Think about this for a second. Linux has already more than proven itself capable of compiling on 64 bit architectures, aka alpha and UltraSPARC.
WinNT on the otherhand, can't. It has some major problems, or otherwise, NT/alpha wouldn't run in 32bit emulation mode on the alphas. M$ will most likely have to rewrite massive portions of windows to get a version that takes full advantage of the IA-64 architecture. So while I never plan on buying one, Linux is going to school windows in performance on the IA-64, what should be MickeySoft's home turf. Even though Linux already out performs M$, it will be even more of an advantage for Linux.
Just another victory for Linux. Besides, one of Linux' current strengths is extreme portablity.. Why leave Intel in the dust now? The more hardware supported, the larger the potential install base, and some people are going to buy the Merced chips. Personally, I have been eagerly waiting for this to happen...
Jeff
The Alpha is an established 64-bit standard, and I can understand its manuals. I cannot understand the manuals for the Merced. It is possible, though usually inefficient, to hand-code for the Alpha. It is impossible for the Merced. Alpha already is running Linux. Not so Merced.
Why are we wasting time with the Merced? It is nothing but welfare for Intel. Alpha has been around for years, and it has demonstrated its worth again and again. It is the architecture of the future. Who needs Merced?
-- an Ayn-onymous Coward
The alpha hack^H^H^H^Hport was done after the processor was already available. Seeing as Intel's implementation of IA-64 isn't widely known (it requires an NDA for the info) this can't be a project that a few hackers work on in their spare time.
Besides, IA-64 is a MUCH different architecture than the Alpha. I'd be much more interested to hear about the progress of compilers (which seems to be the most difficult part).
Incidentally, does anyone know if gcc will be able to easily compile on EPIC architectures? This seems like a pretty non-trivial change...
-NooM
Everytime one of the "lead" manufacturers does something, it's always news. Yeah, Alpha has been out there for a while and doing it's thing. Linux has absorbed all those changes and become 64 bit clean. What's the big deal? Tuning for a specific architecture doesn't seem to be a make it/break it deal. Sure it's nice to blow out some random benchmark when you announce but is it really something worthy of this kind of hype? The real coup would be if Intel does a silicon run in Hudson MA on the old Alpha line they bought 8^(
I guess I just don't get why the port is such a major project to take all this public effort. Most of the other ones have been midnight hacks that have gotten apologized for after the fact. I'm more curious as to why it ISN'T done...
...to see how this really turns out. Merced
is still a ways off and I thought it'll be
targeted at enterprise users? Or is it now
a consumer chip?
On the flip side, if this would get more apps
brought over the Linux side this is a great
thing!
I think it's a win-win for Linux. Hopefully
it'll benefit all the supported hardware
platforms.
In the short run I think it'll benefit Linux
by associating it with Intel's 'next greatest
chip' and by promoting more companies to port
apps over.
ed
I'm going into my fourth year of Computer Engineering, focusing on chip design. The short answer is that it isn't possible to bypass the instruction translators. They aren't translators per se, but something closer to macro expanders.
A CISC instruction (or to a lesser extent, even a RISC instruction) is a concise way of saying that you want the chip to do something fairly complex. For both RISC and CISC processors, these instructions have to be expanded out into a series of truly elementary hardware operations for the chip to perform. RISC instructions tend to be a lot simpler, and are a lot closer to the final "microcode" that controls the various parts of the chip, but they still need _some_ decoding to be processed.
The statement that the K7 (or Pentium-whatever) has a "RISC core" is a bit of a misnomer. What they actually do is allow different tasks required by a CISC instruction to be executed independently. This could be thought of as breaking it into a series of equivalent RISC instructions, but no such instructions actually exist (though you could argue that "micro-ops" and "macro-ops" are close).
Short answer, as above: You can't bypass translation and write in native RISC, because there isn't really a native RISC to write in and analogous translation would still be required no matter what sets of opcodes you were using.
Hopefully this was interesting for anyone that read this far
Don't bother getting excited. it runs slower than a 4.77Mhz XT on a 4 way Xeon system with 1GB of ram.
the idea that IBM has joined up the project and that SGI and VA are in already implies huge market share not only for the linux comunity, but pretty much the whole deal. Pentium is loking for a serius commitment from the different vendors primarily to assure AMD's left out of the big 'brandy' computers. ^-compaq: it has Alpha, worse case scenario. Stuck the god damn things... so what we gotta keep rolling! ^-VA,H.P,dell (looks obsssed with seeling the shitty celeron to those who still think is worth something in a serious desktop market)SGI (Alpha for those huge-ass crays): all taken whats left... im sure i forgot some... but that still leaves with a very small market share... enough for AMD to survive without turning recursive? or even survive. im guessing that if the whole Athlon deal goes the way the intel folks want to. the market of options is gonna be 'reduced'.
Microsoft has been working on it, I've read a short blurb here and there. And I wouldn't sell their efforts short.
But the real story is that Intel apparently intends for Linux to be ready from the start, whether Microsoft is ready or not. In the past, MS has had a window of time where they could develop and optimize at their own pace, without having to worry about a competitor beating them to the punch. With Merced, they'll be under pressure im a way they haven't been in the past.
Merced is shaping up to be the watershed platform for Linux. It wouldn't surprise me to see it drmatically outship Windows Whatever in the first year, especially since new Intel CPUs tend to go into servers first.
Remember, Windows was 16 bit for years running on Intel's 32-bit hardware.
-Scott scott@surrealistic.org
I wonder how a beowulf cluster of these will perform ;-)
afaik alpha doesn't have any hardware 32bit support (eg like ia32 and it's 16bit support). it's 64bit addresses all the way.
i guess what MS did was to compile everything with a 32bit address space, and just pad out the rest of the address space.
i don't know the details, but there was a discussion on axp-list about the very same thing: ie how to get apps to run in a 32bit address space on alpha. (eg for netscape which isn't 64bit clean).
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
afaik alpha doesn't have any hardware 32bit support (eg like ia32 and it's 16bit support). it's 64bit addresses all the way.
i guess what MS did was to compile everything with a 32bit address space, and just pad out the rest of the address space in some way.
i don't know the details, but there was a discussion on axp-list about the very same thing: ie how to get apps to run in a 32bit address space on alpha. (eg for netscape which isn't 64bit clean).
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
"NT64 was a 64-bit rewrite of a 32-bit extension to a 16-bit patch of an 8-bit OS written for a 4-bit processor by a 2-bit company that was crushed by Linux, which came along not 1 bit too soon."
----------------------
"This moon-cheese will make me very rich! Very rich indeed!
There is no K5 cabal.
I am not the real rusty.
How about, no? NT is 32bit clean. That quote refers to Win9X
> Why fight about with arch is best, its how many SPEC's and FLOPS you can get out of it that matters. I dont care if its Alpha, MIPS, AMD or Intel, I pick the fastest one.
The problem is that SPEC's and FLOPS don't tell the whole story. How can you tell that the benchmark is totally optimized for a given processor ? For example if the benchmarked algorithms are inherenty sequential then a massively parallel computer will lose to a fast sequential computer. How about LIPS (logical inferences per second)? How well does a generic generic CPU do compared to a prolog-chip ?
AC
GCC is a fairly good compiler for x86, even when compaired to commercial compilers. GCC is really getting better every day for x86, literally.
But if you compare Alphas with True64-UNIX (formarly DEC-UNIX) and commercial compilers to Alphas running Linux using GCC, there is a HUGE gap in preformance. There is a simple solution though... Get the GCC guys some 21264's ASAP ;-)
BTW, IBM is seems to putting faith into other people's CPU's for Linux ports is a popular idea now, check MU for a story on IBM porting Linux to PowerPC 405.
hmm.. and here I am, waiting for a processor that does. Swallowing optional.
No one can understand the truth until he drinks of coffee's frothy goodness.
--Sheikh Abd-Al-Kadir, 1587
How do Intel decide when is Merced ready for shipping? When at least one of the ported OS runs without problem on its beta, prototype and simulator? Now suppose Linux is ready before NT, will Intel launch Merced with Linux first or will they wait for NT? I believe Linux being based on UNIX, a better designed OS, eg. it don't try to integrate everything into its kernel, will be ahead of NT in schedule (unless M$ is already working on NT for Merced ages before VA starts). It'll be interesting to see whether Intel will tie its schedule to the NT's.
From x86.org I'd heard rumour that all that branch prediction stuff was IN the 80386, albeit disabled on normal startup.
:-)
There are all kinds of weird and wacky TR bits that someone's played with and found interesting things.
... not that it makes much difference, I just found it interesting.
Andrew
Right off I could say "Oh, Intel's making an intelligent decision by embracing Linux and helping its development blah blah blah... Intel will gain many more users in the Linux world" (That is until they embed a serial number in it without telling the world) What does M$ think of this? M$ has been a long time butt-buddy with Intel, and knowing what M$ has done in the past, I'd think that the small gain that Intel makes would be overshadowed by the backlash M$ makes.
I am using "microcode" to refer to the final signal patterns on the control lines during each clock, which may not be the standard usage. Re. MUX vs. table lookup, both take a significant amount of time, which is what I am getting at. By making your instruction opcode a huge bit vector specifying the state of all control lines for the current clock and possibly the next few clocks, you could eliminate the decoding, but at the expense of a silly amount of code bloat, which IMO is impractical (among other things you'd need several memory reads to read each opcode).
I readily agree that complicated CISC translation takes longer than RISC translation, but IMO going any farther than RISC gets impractical very quickly.
I've heard plenty about the effort to port Linux to IA-64, but I don't think I've come across a single article on MS's efforts. Surely they are working on it as well.
Now, I know that their development model is in no way open, but I'm still surprised that I haven't heard reports about the transition to Win64 (or whatever it will be called). Perhaps they are so bogged down trying to get W2K to a beta stage so they can finally ship the thing that they aren't focusing on IA-64 yet.
anyone know?
--Lenny
Okay, so it isn't about Trillium, but once MS gets NT64 out the door, this will have to be ported appropriately too:
:) It's a bonafide request that someone port this over to the Merced arch! ;)
Definition of Windows NT:
Wndows NT: n.
32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.
This ain't flamebait!
SirSlud
...is doomed.
Betcha Monterey gets dropped in favour of Linux.
Maybe Sequent or SCO carry on alone, but it'll probably not amount to much.
Yes, baby! - I.b.m.er.
Mercedes an open source microprocessor? I think not. People are forgetting the point of Linux methinks. -kojak
Merced, sweet merced,
where are you? dead?
I've looked far, i've looked long,
your future is like a sad sad song.
My heart wonders to other places,
with Alpha's, K7's, and G4's in clear cases.
Alas, I'm am tired, alas I am sick,
of waiting for a processor that won't suck dick.
Don't lead me into temptation... I can find it myself.
Really, that's why. It's fairly obvious Intel has decided, both by investments and releases that Lintel can both edge into Wintel and also get back at MSFT's encroachment of Intel's "space".
...
But technically? Nah, no real reason.
Realistically, though, if there isn't Lintel stuff for IA-64, MSFT will win somehow. Don't know how, don't know when, but
Will in Seattle
Realistically, we can also bet that there will be a stable even release of Linux for IA-64 before there is a stable release of W2K for IA-64. For mindshare alone, this is critical.
When MSFT can't crank out a fast, efficient, stable release for a new chip as fast as a bunch of chaos coders, they're doomed.
Will in Seattle
Hey sengan, back from a summer of spewing unsubstantiated vitriol? Back to torture us with your insipid diatribes??
These "hey - wouldn't a beowolf cluster of x be cool?" posts are getting really tired.
The nextgen chip (which is what the k6+ as based on) had the ability to do this.
My understanding is that the Merced is x86-compatible. They added a new processing mode in which the Merced's new instruction set and new register structure are accessible, I think.