Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Intel

IBM joins Trillian project 100

Posted by sengan from the Intel's-only-successful-IA-was-x86 dept.
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.
This discussion has been archived. No new comments can be posted.

IBM joins Trillian project More

IBM joins Trillian project

Comments Filter:
  • 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.
  • The nextgen chip (which is what the k6+ as based on) had the ability to do this.


    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.
  • RISC86 instructions share some characteristics with Pentium microinstructions: They're quite long (the Nx586's eight-chip predecessor used 104-bit RISC86 instructions) and carry vital information of processor states that normally wouldn't be known to a true external RISC instruction. But there's still an important difference: Unlike microcode, NexGen's RISC86 can theoretically support its own assemblers, compilers, and application software. The Nx586 bus can bypass the 80x86 decoder and feed RISC86 instructions directly into the execution stages of the pipeline at full bus speeds.


    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?)
  • 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.)
  • 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 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.
  • 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?


    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...
  • 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

  • K7 (Score:1)

    by Pengo ( 28814 )
    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!

  • Re:K7 (Score:1)

    by coug_ ( 63333 )
    I'm by no means a CPU architecture expert (i hated my computer architecture class), but I do know that the K7, as with all the other K series chips from AMD, is a RISC based processor that uses one or more instruction translators. I'm not sure if it's possible to write code that bypasses the instruction translators, but if it *is* possible, then yes... it'd be nice if some optimizations were made to GCC, etc.
  • 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?

    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

  • Re:Merced Sucks. Go with the Alpha. (Score:3)

    by Gleef ( 86 ) on Tuesday August 10, 1999 @10:16AM (#1753730) Homepage
    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.

    ----

  • Re:K7 (Score:2)

    by Gleef ( 86 )
    From the Athlon info at Tom's Hardware [tomshardware.com] it looks like the processor has fewer pipeline quirks than the Pentium line, so K7-specific compiler tricks would be less important. Of course anything big on 3D graphics (or any other FP or Integer matrix applications) should check if it's a K7 and make use of the new, improved 3DNow instructions.

    ----

  • 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 do know that the K7, as with all the other K series chips from AMD, is a RISC based processor that uses one or more instruction translators. I'm not sure if it's possible to write code that bypasses the instruction translators, but if it *is* possible, then yes...


    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
  • Another reason why this is so important is because of several reasons.
    1) Intel is hyping the chip quite a bit. Compaq doesn't hype the Alpha. So there is generally more information, or rumors, about said chip.

    But in order for them to hype it properly, Intel is going to need an OS that they can show their chip's new (new for Intel) 64 bit processing. Which brings me to point two.

    2)They need to help out the Linux project if they want an affordable OS on their chip when it comes out (affordable being something that the average user will be willing to pay). It isn't like Intel is going to go out and hype that Solaris will run on the Merced chip, and there is no way in the pits of Redmond that MS will get NT 64 out in time.

    3)The article is about how IBM is supporting this. Sure the Intel symbol is what is being used for the article here on Slashdot but the big news is that IBM is helping port Linux over to Merced. This is big news, really big news.

    4)Linux for the Alpha is already out there. There isn't going to be any news discussing porting Linux over to the old Alpha because it already exists. Also, when something does happen to the Alpha chip, Slashdot does report it.
  • I read the Guide about a year ago (and it's on my senior reading list along with Restaurant at the End of the Universe, thankyou public school). As I remember, Trillian was the human woman that Zapod picked up at a party with some line like "You know, I'm a space alien." Arthur was working on picking up Trillian at the time, so he and Zaphod started out on the wrong step.

    adam
  • 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.

  • 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).
  • 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).
  • 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!


    It's there to provide an Intel-brand x86-compatible chip after Intel switches to IA64. Current users who want to upgrade and still want to buy Intel will buy it, which gets them "hooked" on the new architecture. If Intel broke compatibility, they would lose their market. x86 clones would be chosen by the masses, and people who wanted a high-performing non-x86 system would choose other processors.


    If, on the other hand, people can upgrade their x86 "workstations" to Merced "workstations", they can still run their old software, while software written with the Merced in mind gets a speed boost.


    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.


    For the VLIW instructions, yes. However, it wouldn't cost them much space to put in x86 optimizations. Heck, most of them are already present in the Merced hardware - pipelining, superscaling, and branch prediction are still there. x86 emulation would just require a second instruction decoder and a bit of extra glue logic.


    The reason that the compiler is a bugger is that it's difficult to use _VLIW_ properly outside of hand-coded assembly.


    IMO, the Merced will either take a 1.5x speed hit over straight x86 clones, or will require 1.5x as much silicon. I'm betting that Intel will throw extra silicon at it and wind up with a chip that runs x86 code at reasonable speed but that costs twice as much as a Pentium-III to fabricate.


    Did I mention that it will also cost a freakin fortune?


    I strongly suspect that they'll release a cheaper low-end version with smaller cache, just as with the Celeron/Pentium/Xeon spectrum. They need something to offer in the x86 regime, and they need consumers to upgrade to something Merced-compatible if they want to keep their market share while moving on with the Merced. If they don't do this immediately, they'll do it reasonably soon afterwards.

  • How about:

    "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!

  • The reason Alpha/Linux isn't popular is because of GCC.

    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 [current.nu] on IBM porting Linux to PowerPC 405.

  • hmm.. and here I am, waiting for a processor that does. Swallowing optional.

  • 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... ;)
  • 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.
  • 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.


    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.

  • You obviously haven't dealt with the RISC86 architecture. They do have a true RISC instruction set.

    To quote the June 1994 issue of
    Byte [byte.com] magazine:

    In concept, the Nx586 decoder works like the code generator of a compiler, except at a lower level. Just as a C++ compiler converts C code into 80x86 machine code, the Nx586 decoder converts 80x86 machine code into RISC86 code.


    Intel downplays NexGen's RISC86 and says the Pentium does something similar when it decodes complex 80x86 instructions into microcode primitives; in a sense, this is true. Complex instructions are broken down into 88-bit, fixed-length microinstructions that could be regarded as "RISC instructions," and many simple instructions don't require microcode at all because they're hard-wired in silicon. Intel also makes a valid point that code generators in modern compilers tend to avoid complex 80x86 instructions, because they can generate faster-running code by sticking to simpler instructions.

    RISC86 instructions share some characteristics with Pentium microinstructions: They're quite long (the Nx586's eight-chip predecessor used 104-bit RISC86 instructions) and carry vital information of processor states that normally wouldn't be known to a true external RISC instruction. But there's still an important difference: Unlike microcode, NexGen's RISC86 can theoretically support its own assemblers, compilers, and application software. The Nx586 bus can bypass the 80x86 decoder and feed RISC86 instructions directly into the execution stages of the pipeline at full bus speeds. In fact, NexGen already has a RISC86 assembler, although it's for internal use only, since there's obviously no software market for RISC86 binaries.


    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'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
  • The Alpha is an established 64-bit standard, and I can understand its manuals. I cannot understand the manuals for the Merced.

    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.
  • 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

  • [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.

    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!
  • ...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.
  • Microsoft is working on Win64 for a post NT 2000 software release. Some info is available on Microsoft's web site. Do a search for Win64.

    They did some ugly things to the size of C data types to make it easier to port Win32 software to Win64. Longs are still 32 bits and they added a new type for 64 bit integers. Barf.

  • Doesn't matter if the architecture is different to get a hack/hello world OS port up. The Alpha project was done to a large extent in house so the beginnings of it were under the standard employee NDA. The IA-64 port isn't going to be interesting until they decide on the interface chips and someone has something to write actual drivers for. Getting an initial compiler up isn't as tough as the optimizers after it's running. Besides, they can always blame the performance on the emulation.
  • Re: 1

    Alpha isn't one of the pieces Compaq really wanted when Palmer sold out. They wanted the Enterprise desktop and figured they could sell Wintel boxes into it better than Alpha. Hyping Alpha directly competes with their core business. They will quietly continue to sell servers and support to the current customer base while weaning them from it.

    Re: 2

    The MS OS honeymoon is over. Sure they'll jump onboard but the fact that it's an architecture change. MS has it's hands full with the three OS updates it has in the pipe. I seem to remember rumblings of a Unified Windoze OS... 8^)

    Re: 3

    IBM has jumped on the bandwagon in a major way. The DB2 port and the other announcement this afternoon with the Lotus Notes/Domino port (remember there's BLUE underwear under that yellow and black outfit).

    Re: 4

    That was my total point. 64bit is old news but the release makes it sound like a major feature of the port. New chip is new chip is new chip.
  • 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.

  • 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 ...

  • 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.

  • Well, the lag between the Compaq Deskpro 386 and Windows 95 was about nine years. So if you extrapolate, it should occur at about the same time that aliens turn Jupiter into a new star: 2010.



    ---
    Have a Sloppy night!
  • But everything changes when they break compatability. If Merced isn't x86, then both the locked-in and the scale advantages evaporate.


    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.


  • Considering how MS likes to hype all ot their OS upgrades a 2 years in advance, I'd guess their progress for Merced is at least 3 years away from completion. Of course MS products are always a tear late.. so I figure 2004.

    On a serious note I think that like all things Intel IA-64 will be hyped to all hell, and every one will need one. If MS is more then 6 months late with a 64 bit version of NT and Linux for IA-64 is out with the release of Merced I think MS stands a good chance of being left in the dust.
    Ex-Nt-User
  • 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.
  • Um, "Mercedes"??? It's a processor, not a car.

Slashdot Top Deals

We must believe that it is the darkest before the dawn of a beautiful new world. We will see it when we believe it. -- Saul Alinsky

Close