Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Intel

Gcc for the IA-64. 50

Posted by Hemos from the code-faster dept.
Anonymous Coward writes "Cygnus will port the gcc compiler (egcs, soon to be renamed gcc3) to the IA-64 architecture, notably for the Linux OS and applications. Check the press release here. " Essentially, Cygns is working with Intel to port GNUPro Software to IA-64 is the gist of deal. GOod to see people planning ahead, I s'pose.
This discussion has been archived. No new comments can be posted.

Gcc for the IA-64. More

Gcc for the IA-64.

Comments Filter:

  • Re:GPL violation? (Score:1)

    by Anonymous Coward

    From what I can tell they are going to SELL GPL'd code BEFORE making the source public. This sounds like a clear violation of the terms of GPL.

    No, it's just bad writing. Cygnus is going to do in-house development on gcc with their programmers under NDAs, and when IA-64 is released and the NDAs terminate, they will release the new version of gcc to the world. GNUPro is the name of the bundle of software (including gcc) that Cygnus sells -- all the press release is saying is that the IA64 port will be part of this bundle as usual.

    Cygnus is staffed mostly by seriously hardcore free-software people; even if the management got zapped by stupid rays and tried to sleaze the GPL, their programmers would all just leave. I don't think you have anything to worry about.

  • MS code is not ANSI C or standard C++ clean. I also believe that GCC/EGCS' support for C++ templets is still less mature than the MS C++ compiler. There is also some other propritary changes that EGCS does not impliment/support. Isn't there some MS changes to C++ syntax to make dealing with Unicode structures easier?

    This also seems to be a problem for WINElib. While a library could be made to make Linux/X11 API compatible with Win16/Win32 code, MS C++ source code compatiblity would still require a compiler which impliments MS changes to the C++ syntax.
  • leefinan wrote:
    All I can say is it's great to see Intel taking OSS seriously

    A you know, Intel is investing in RedHat, so they already acknowledged the existence/importance of OSS. And as GCC/EGCS will be used more and more in the server-market, Intel needs to cooperate with the OSS-community. The server-market will be important to Intel's IA64 sells.

  • What I was trying to convey is that not only is Digital/Compaq not committing to use IA-64, they are also not developing their own VLIW. They did research into it back in the early days of Alpha (after 21064 IIRC).

    Draw your own conclusions.

  • Re:Importance of a good compiler on IA-64 (Score:3)

    by David Greene ( 463 ) on Wednesday April 28, 1999 @09:24AM (#1912560)
    For RISC vendors, they are used to dealing with extremely complex compilers.

    How complex is "extremely complex?" Nowhere near the level of IA-64, I would guess. I found it odd that Taschek would bash HP for their compiler support. I think they have the best chance of producing a decent VLIW-style compiler, given all the research that has come out of HP labs.

    What's interesting is that Digital/Compaq hasn't jumped on the Merced bandwagon, nor have they announced a VLIW architecture of their own. Hmm...

    Having GCC working well on IA-64 will go a long way to further the impact of Linux, especially if GCC works much better than any compiler out of Redmond. Even if Windows 2000 runs on IA-64, if the applications crawl, not too many people are going to choose that OS over another.

    I disagree with this and the meat of Taschek's article. If businesses choose Windows, they will choose Windows. I don't think a compiler will make or break an operating system. Established use and ingrained practices are much larger factors. If a good compiler targeting Windows on IA-64 is not available, Merced will be relegated to a niche market. If the free software community is counting on Merced being the end of proprietary operating systems, we've lost.

    It's also interesting that people assume Microsoft will be providing the IA-64 compiler for Windows. Intel is producing their own compiler. They're having problems, but chances are there will be more than one IA-64 compiler for Windows.

  • I don't work for Cygnus, but here's what it sounds like to me:

    -- Cygnus is getting early specs from Intel under NDA to write their compiler now. Once the new architecture is publicly available, the NDA will expire and Cygnus can release the code. The GPL does not affect you if you keep your modifications private.

    -- Cygnus is in business to sell gcc. They charge companies for it - quite a bit actually - which includes not just the gcc binaries, but also supports and regular software updates. The gcc software is still GPL'd. Though I think Cygnus does sell some proprietary add-on products. Think of them as a Red Hat for gcc, only charging a lot more money.
  • Posted by Mike@ABC:

    How much do you want to bet that Intel will buy up Cygnus inside of a year? They already worked together to tune Linux for Intel Pentium workstations, and now they're working on the IA-64 architecture. Intel is increasingly Linux-friendly (one of their execs is a keynote speaker at the next LinuxWorld) and Cygnus is a key player in making sure that Linux runs well on Intel's architecture. I think Intel has seen the writing on the wall, and they have a tendency to buy up useful companies.

    Just a thought. We'll see.

  • Seems kind of stupid to rename it from egcs to gcc3.

    They should go with either straight old gcc or leave it as egcs. What's the point of introducing yet another name for a GNU compiler? Either it's gcc or it isn't. If it isn't, then keep it egcs. If it's the new GNU compiler, then call it gcc. What could the possible advantage be to introducing yet another compiler name?
  • Those are two different questions.

    The answer to the first is, very good.

    The answer to the second is, pretty good.
  • IA64 is rumored to be quite different from current 64-bit architechtures.
  • The concept of "porting" GCC to something so different from current 32-bit machines as IA64 is going to be a major strain on the backend. Getting performance to even the current GCC standard (ie good but not best-in-class) will take at least a couple o years once hardware is available.

    Why? EGCS (the next gcc [fsf.org]) already supports several 64-bit architectures like Alpha and UltraSparc, and incorporates the Haifa scheduler [cygnus.com] which can be a big performance boost.

  • What could the possible advantage be to introducing yet another compiler name?

    gcc3 isn't going to be the name of the compiler driver executable, but of the compiler itself, just as the current gcc is gcc release 2.

    EGCS currently internally identifies itself as gcc 2 (e.g.
    gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)
    ), but it contains many improvements compared to FSF gcc 2.8.x that together IMHO justify bumping its version number to gcc 3.

  • well they said they had GNU/Linux working already on IA64 a while back

    I must've missed that. Could you give a reference?

    well intel will want to keep all of its dirty little secrets of the compiler to itself or anybody can reproduce the silicon easy peasey because the machine is dumb and the compiler knows all !!

    There are other ways of keeping people from implementing your instruction set architecture, e.g. patents; there are a couple of patents that might apply to IA-64 implementations, namely US patent 5638525 [ibm.com] and US patent 5859999 [ibm.com].

    (I also wouldn't assume there's no cleverness in the silicon; punting a lot of the work to the compiler doesn't necessarily mean getting a CPU "so simple even a child could do it".)

  • Very often, you get a specific client that asks for improvements in the compiler, and pays for it. So they get back their compiler, and for a while it's unavailable to the public at large.

    ...unless the client decides to give the compiler away to the public, which they may choose to do - or may choose not to do. The GPL doesn't let Cygnus keep the client from doing so; it also doesn't oblige the client to do so. (A clarification, in case anybody argues that the GPL requires that the compiler be available to the public from Day One, not a disagreement with the points you make, which are correct.)

  • Question (Score:1)

    by law ( 5166 )
    How good is gcc/egcs at compiling? I mean how optimum is it on x86 stuff.
  • People are using "port" to mean practically anything these days. Porting is modifying software so that it will run on a new architecture. Not just rewriting it or adding new features. Not rewriting it to use a different API. Don't even get me started on the abuse of the preposition "to" in "write to an API".

    Of course, porting will need to be done to get gcc to RUN on a new architecture even as a crosscompiler. However, adding support for compiling stuff for that new architecture is NOT porting - you could be writing a cross compiler.

    Don't let the MS weenies confuse people with their cunning terminological inexactitude! :)

  • The compiler we call "GCC" right now is GCC version 2.x, or gcc2 for short. The compiler currently called "EGCS" will become version 3.x of GCC, or gcc3 for short.

    It is also worth noting that EGCS' current version numbers are 2.9x.xx, which implies that they are pre-release versions of 3.0.

    So, in short, EGCS will be the new GCC, and will be called, simply, GCC. In saying "egcs will become gcc3", they mean that egcs will become the new version of GCC.

    Hope that helps!
  • John Taschek over at PCWeek has an interesting editorial [zdnet.com] about just how important getting a good compiler will be for all OS's, not just Linux. He suggests that MS is going to have serious problems with the port, since the EPIC architecture is vastly different from the traditional Intel CISC architecture that MS is used to. For RISC vendors, they are used to dealing with extremely complex compilers.

    Having GCC working well on IA-64 will go a long way to further the impact of Linux, especially if GCC works much better than any compiler out of Redmond. Even if Windows 2000 runs on IA-64, if the applications crawl, not too many people are going to choose that OS over another.
  • Cygnus is possibly the company that has contributed the MOST to the GNU projects.

    They are a service society, they make money by pandering to their customer wishes.

    Very often, you get a specific client that asks for improvements in the compiler, and pays for it. So they get back their compiler, and for a while it's unavailable to the public at large.

    Then the code gets contributed to gcc, and everyone in the free software arena is free to use it.

    There is a small delay in between, that is perfectly reasonable (on the order of three to six months). The FSF doesn't work different, you have releases, and then there are in-between states for various projects to which you don't necessarily have access.

    One other area where Cygnus makes money is service and tools. Their development environment can be sold, and their expert advice as well.
  • Hello ?

    There's now lots of stuff in gcc/egcs (threads, frame-unwinding) that NEEDS to be ported for other architectures (not mentionning binutils issues)

    This has *no* relationship to simply writing a new backend to gcc. Yep, both are needed to make egcs work on a new machine.

    `Porting' is a nice blanket term that covers this nicely.
  • egcs is a fairly good C/C++ compiler, especially considering the range of architecture it works on.

    Specialized products can beat it. For instance, KAI C++ is known to be much better for heavy numerical templates (check Blitz++).

    egcs is getting better at handling x86. It's definitely not perfect, especially since egcs aims at architectures with a wide range of general registers, and this is definitely not the case with x86...

    Considering its architecture, finding when to spill registers out to the stack or how to keep stuff in registers is sometimes a bit hard. Current snapshots are much better at that game than the egcs-1.1 series.
  • John Taschek over at PCWeek has an interesting editorial about just how important getting a good compiler will be for all OS's, not just Linux. He suggests that MS is going to have serious problems with the port, since the EPIC architecture is vastly different from the traditional Intel CISC architecture that MS is used to. For RISC vendors, they are used to dealing with extremely complex compilers.

    He seems to have forgotten that MS already has NT for Alpha - the compiler issues are obviously not such a big deal for them.

    ---
  • well they said they had GNU/Linux working already on IA64 a while back the thing is that with IA64 all of the Brains is in the compiler

    so ?

    well intel will want to keep all of its dirty little secrets of the compiler to itself or anybody can reproduce the silicon easy peasey because the machine is dumb and the compiler knows all !!

    Hmm so whats going on

    ??

    anybody

    cheers john
  • The article says that Cygnus will release source code sometime in 2000
    when IA-64 specs become publically available, suggesting that
    they have promised Intel not to release the source before that time.
    This is consonant with the GPL as long as they do not release binaries
    either. But then the work Cygnus will do till the source-code release
    is not after the bazaar development model since only employees of
    Cygnus will be doing it.

    Is that about right?

  • According to this article [sunworld.com] at SunWorld, "As of this week [published April 8, 1999], the Monterey alliance has completed Monterey's 64-bit kernel, 64-bit memory model, endian neutral (non-byte-order specific) commands and libraries, 64-bit C compiler, and journaled files system."

    The article also mentions that HP has run "successful tests of the Oracle 8i database on an HP-UX based IA-64 simulator."

    At least regarding the compiler (and 64-bit kernel / memory model, I would think), Linux is not far behind. I believe that these vendors are hoping that IA-64 will allow them to place some more distance between their products and Linux. I also think that they have another thing coming.


    Let the code run free.

  • It's great to see Intel cooperating on such an important project. Having the gcc compiler for that architecture is vital for the development of Linux on the platform. All I can say is it's great to seeIntel taking OSS seriously.

  • At least Intel has made a great innovation in the seventies. Haven't they invented the microprocessor??
  • the proposed Linux port to IA-64

    What about an actual port? One of my duties as an HP booth-dweeb at LinuxExpo was showing Linux booting into user space on a IA-64 simulator. Linux was compiled on a GCC compiler with a crude IA-64 code generator. Recall that HP is co-inventor and co-creator of IA-64: Intel and Hewlett-Packard ... first public disclosure of their 64-bit architecture [zdnet.com].

  • ...but it's all "cc" to me :)
    There's a (bad) country/western song in there somewhere.
  • IIRC, there was the pgcc project, an egcs derivative where they experimented with specific optimizations for the Pentia. I haven't checked up on them recently, though, and the URL I have is no longer valid.
    -jgj
  • Intel has a history of supporting GCC for new chips. I was involved with a 1989 project where Intel gave money and machines to RMS to get GCC running well on the 386 as part of a plan to get Mach ported (when SystemV and Xenix were the only games in town). Intel's position was simple: all the 386 compilers suck - maybe with a small dose of cash (especially compared with what they paid Green Hills) these longhairs will come up with something.

    The concept of "porting" GCC to something so different from current 32-bit machines as IA64 is going to be a major strain on the backend. Getting performance to even the current GCC standard (ie good but not best-in-class) will take at least a couple o years once hardware is available.

Slashdot Top Deals

Don't panic.

Close