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...
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.
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
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.
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.
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--
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 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
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.
Yet another clue: Windows 2000 is a much better OS than Linux. :-)
only if you don't ever turn your computer on
I'm a loner Dottie, a Rebel.
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
Anonymous Coward complains:
The Alpha is an established 64-bit standard, and I can understand its manuals.
Yes, the Alpha is very good.
I cannot understand the manuals for the Merced.
You don't have to. It's the kernel, gcc and glib people who do. Write in C, it's safer.
It is possible, though usually inefficient, to hand-code for the Alpha. It is impossible for the Merced.
Hand coding is never impossible. A big pain in the burro, but not impossible.
Alpha already is running Linux. Not so Merced.
As the article indicates, Merced is already running Linux, to the extent where Merced exists. We're already ahead of the NT and Monterrey projects for Merced.
Why are we wasting time with the Merced? It is nothing but welfare for Intel.
Two reasons. First, we want to support everything, that would include Merced by definition. Second, Merced will have lots of marketting bucks behind it, that will make it popular. We certainly should support the more popular platforms, even if they have deficiencies.
Alpha has been around for years, and it has demonstrated its worth again and again. It is the architecture of the future.
I agree.
Who needs Merced?
Intel does, to survive the future. The rest of us do, because Merced will make 64 bit platforms popular, and in the computer world, popular becomes inexpensive very quickly.
----
----
Open mind, insert foot.
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
Ummm... Merced's going to be much more expensive than Alpha systems. Look at the Xeon.. Surely you can buy an Alpha for a nominal price above that and have a much faster workstation on your hands. And unless i'm mistaken, Merced's going to be positioned above Xeon for the forseeable future.
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
Is doomed. Knowing IBM/SCO,
:).
Which, clearly, you do not. Are you suggesting IBM will port Montery over to the rs/6000? Or are you suggesting they'll ditch the powerpc chip in favor of the ia64? Either way, you're as clueless as you are anonymous.
And, who the hell cares if IBM 'competes' with SGI? SGI isn't exactly a juggernaut of the industry these days..
But I digress. The really interesting thing here is monterey. What _IS_ IBM thinking they're going to do with it? I have a hard time believing they'll dump it, since they're well known for holding onto dead projects till they crumble into dust.
Maybe they just want to get ahold of the specs so they can see how ia64 holds up to the new powerpcs
--
Blue
i browse at -1 because they're funnier than you are.
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.
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
Yup. Intel wants to avoid a repeat of Microsoft's Windows 2000 challenge disaster on their new processor.
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
I forgot to add my sarcasm tags... ;)
Don't lead me into temptation... I can find it myself.
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
IA-64 has been accepted by most of the major companies out there as the standard of the future. It is bigger than just Merced. The port to IA-64 is a big win for Linux.
Whether you _like_ the architecture or not it is probably going to be a powerful force.
The Alpha needs Merced badly. Developers will now, because of Merced, make their software 64 bit compatible. When the software is there and 64 bit capable, then Alpha can compete.
rm -rf microsoft*
For the love of god, I was logged in and it posted as anon. Sheesh. Maybe there /is/ some worth in that preview button. (duck)
SirSlud
"Old man yells at systemd"
Merced's popularity is not guaranteed...yet. Intel has been able to get people to buy 8086-to-Pentium3 up to now, because there's a large installed base that is locked into x86 compatability. The size of the installed base has enabled economy of scale, which has reduced the price to the point where x86 chips are actually desirable even if you're not locked in. That's why so many Linux users (who never really had any serious need for binary compability with 1981 software) are running on x86.
But everything changes when they break compatability. If Merced isn't x86, then both the locked-in and the scale advantages evaporate. Well, the scale advantages don't completely evaporate, because Intel still has the factories, but they play a lessor role.
The upshot is that as Pentiums start coming to an end, this will be the first time in 20 years that many people will actually be able to choose the best CPU based on technical merits rather than market forces. That is exciting! May the best CPU win!
---
Have a Sloppy night!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
...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.
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
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.
How about: A 64-bit addition to 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.
Of course maybe that's just silly.
I may be wrong, but supposedly the Merced will have a 32bit mode. This is similar to what Intel did with the 386. They added 32bit and kept the old 16bit modes for compatibility. This is why you could run 16bit Windows 3.1 on a 32bit processor.
Microsoft never really got away from the 16bit code, even in Windows 98 (supposedly...I have no first hand knowledge of this, but Dr. Dobbs Journal has had articles on it). I wonder if Windows for IA-64 will still have 16bit code and if Intel will include 16bit for very-backward compatibility.
Citizens Against Plate Tectonics
Um, "Mercedes"??? It's a processor, not a car.