Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Linux IA-64 Resource Portal 43

djmagic writes "SourceForge has opened it's IA-64 portal for porting projects to Linux running on (surprise) IA-64. " It's still a tad sparse, but you should be able to compile on the Compilefarm if you're interested in porting something. There's also a news.com story on the thing.
This discussion has been archived. No new comments can be posted.

IA-64 Resource Portal

Comments Filter:
  • Sizes are strictly a convention and the compiler is free to use any sizes it likes. The Cygnus and SGI compilers used by the Trillian project both use the LP64 convention (longs and pointers are 64-bits, all other sizes follow IA32 conventions). MicroSoft decided to use a compiler that uses the P64 model (pointers are 64-bits, all other sizes follow IA32 conventions).

    The `advantage' of the P64 model is that you get fewer compiler warnings when you compile programs that were originally written for IA32. They could still be semantically wrong but at least the compiler doesn't complain.

    The advantage of the the LP64 model is that there is a native type available for all integer sizes.

    From my comments you can guess which model I believe is the correct one to follow, especially given that my experience has been that Linux applications just re-compile and work on IA64. There has been very little changes required by applications to get them to work. Of course, this is undoubtedly helped by the fact that Linux supports the Alpha.

    --

  • ... you can hear the sound of furniture being thrown around in Seattle, WA.

    I don't think that anyone is going to report it this way, but this just has to be a major black eye to Microsoft. Here we have an operating system that's open for public use, even in a sort-of-a-beta fashion...

    Anyone seen a 64 bit of Windows, anywhere? I think I remember reading something in CNET, or somewhere else, about someone stumbling across some alleged 64 bit version of Windows being demoed at some demo show somewhere out there. That's about it. A production-quality Win-64 is NOT going to ship simultaneously with Itanium, no matter what anyone says otherwise.

    Despite Microsoft's promise to deliver Win64 when Itanium ships, it's nowhere to be seen on horizon. All MS OS builds go through two or three public beta cycles, doesn't anyone remember that? For Win64 to ship with Itanium, we'd have to be on at least the second beta cycle by now.

    My memory's a bit cloudy on this one, but I'm pretty sure that Win95 came out only two or three years after the first 32-bit Intel CPU, so it must be pretty clear to Intel now that they cannot rely on Microsoft software to drive their high-end chips. When Itanium ships, the only production-quality native 64-bit operating systems will be Linux and Monterey. Maybe Solaris, if Sun stops throwing their temper tantrums.

    I can't wait to see how MS is going to react on this one. By the end of the day the story should be picked up by most mainstream 'zines. It should get interesting from that point on.

  • How about open-sourcing the CompileFarm setup and environment so us Alpha guys can put up a couple of systems for folks to compile away? This way the systems look the same from a users standpoint.

    Oh, and you can run benchmarks on ours. :)

    FYI:I work at API

  • Couldn't people just run an IA-64 emulator on their own machine? It would be really slow compared to the real thing, but a 600MHz 686 running an IA-64 emulator might be only a hundred times slower than the real thing. A hundred times slower is still a reasonable speed for many interactive programs that spend most of their time waiting for user input. And you'd still edit and compile your program natively.

    Apparently HP are making an emulator, but I don't know if it will be free (speech or beer). ARM Ltd provide a GPLed emulator for their chips, it would be nice if Intel started doing the same. At the very least, it would show up hardware bugs if a program gave a different result when ran on the (debugged) emulator than on the real CPU.
  • Hmph... I'm just begining Linux asm programming (and asm programing in gerneral). However, the information on Linux asm in general is pretty sparse (most of it seems to really focus on the differences from dos asm for experienced virii programmers going over to Linux ;^) Even the dos asm books i've obtained don't mention much about, say, extended registers on the IA-32 chip (and, from what I've seen, it'll be interesting to know all about, say ESP). Before I want to tackle the 64 bit chip, I would like to learn the basics. If anyone can point me to really good beginners resourses, I would be most appreciative ;^)
    -legolas

    (Hmph... isn't it funny when you do kernel call 2 instead of 3 in an infinite loop... whoops ;^)

    i've looked at love from both sides now. from win and lose, and still somehow...

  • by Submarine ( 12319 ) on Friday May 26, 2000 @05:04AM (#1046572) Homepage

    I'd be interested if some knowledgeable person would explain here the current state of development of IA-64 compilers (gcc in particular).

    IA-64 is peculiar in that respect, not so because it is 64-bit (though this is likely to hurt code that assumes 32-bit int's and pointers... and that's still quite a bit, look at the difficulties with Linux on Alpha). As decribed in Intel's documentation [intel.com], IA-64 is a VLIW (Very Large Instruction Word) architecture where the burden of superscalar pipelining (deciding what assembler instructions can be executed in parallel) lies on the compiler. Let us take a simple example: where you are executing
    imull %edx, %eax
    addl $4, %eax
    the two instructions cannot be scheduled on two parallel pipelines since eax in the second depends on the output of the first. Advanced design allow the CPU to "swap" certain instructions (out-of-order execution).

    From a hardware design point of view, the IA-64 design makes sense: out-of-order scheduling instructions over multiple pipelines in hardware is complicated. For this reason, IA-64 allows the assembly code to specify "bundles" of instructions that can be executed in parallel. The burden is then shifted to the compiler.

    Such a design allows scheduling optimizations far further than the ordinary peephole optimizations (i.e. very local tricks). For instance, in numeric code like this:
    x[i][j]=expression1;
    x[j][k]=expression2;
    the compiler could schedule expression1 and expression2 in parallel, if they are sufficiently simple. Of course, for this to respect the semantics of the program, (i,j) must never be equal to (j,k). Answering such questions mechanically is impossible in general (Rice's theorem, reduction to the Turing machine halting problem). However, there are analysis techniques that can give the right result in most cases (such techniques can also be used to check whether two pointers never point to the same variable, or whether some array bound checks are useless) (an active research topic; see some of the research in the area [di.ens.fr]).

    I would like to know the current state of the art of industrial-grade compilers with respect to this automatic local parallelization techniques.

  • What's really interesting is that not only in Linux going to ship simultaneouly, already what 2 , 3 distros are already available! Linux -rocks-.

    Chris DiBona
    VA Linux Systems


    --
    Grant Chair, Linux Int.
    Pres, SVLUG

  • by [Xorian] ( 112258 ) on Friday May 26, 2000 @05:11AM (#1046574)

    So SourceForge now has compile farm resources for x86 and IA-64. What about the other architectures? Where's the PPC compile farm, the ARM compile farm, the Alpha and MIPS compile farms?

    There's got to be a demand for these among open source developers. Most people don't have that many architectures that they can compile and test on, but most people would like their code to work on as many platforms as possible.

  • IA-64, at least now, only means Itanium. Do we really hate the name Itanium so much that we refuse to call it that? Even the article in which the new name was announced, the title read "Itani-what". The other day, I submitted a story about Itanium prices. It was rejected. If I called it a story about IA-64 prices, Rob would have posted it right away.
  • If you are using Win64, it's:

    sizeof(short) == 2
    sizeof(int) == 4
    sizeof(long) == 4
    sizeof(void *) == 8

    Microsoft says it's for Win32 portability reasons. I think it's brain damaged.

  • Do free software developers really want to be putting there time and effort into helping intel push their IA64 systems onto the market?. Intel have show themselves to be just as evil as microsoft in abusing their power to push other companys out the way, up to now the've failed, no one likes Rambus, and AMD and VIA are doing better than ever. But we seen plenty of what intel is trying for, which is complete control over computer hardware from processors to serial ports. With no else being able to invent or produce anything. Intel will stop at nothing to prevent other companies from making chipsets for its processors, it tring its hardest to take over the graphics card industries, and generally being a monopolistic SOB. If we help to make IA-64 a sucess by giving a early platform to work on, then we've just given Intel the future. If we are lazy and what for someone else to do the work on IA-64, and let sledgehammer and alpha and ultrasparc architures gain market share until intel is small enough not be able a abuse its position then the next 15 years of computer hardware will be much freer and more inovative. Agree, Disagree, Give a Damn?
  • by orabidoo ( 9806 ) on Friday May 26, 2000 @05:58AM (#1046578) Homepage
    ObWonder: Why don't 64-bit platforms have 64-bit ints? I mean, int has historically gone from 16 to 32 bits (was 16 in DOS, at least), so why not 32 to 64?
    the standard answer is:
    • because 'int' is usually for numbers, and you very very rarely need numbers bigger than 2^32 anyway, and
    • because if char is 8bit, short is 16bit and int was 64bit, then there wouldnt' be a standard type with 32 bits, which would be annoying, and particularily silly to leave a gap like that while making int and long the same size
    what this all means is that there's *still* one neat thing that you can assume: on all reasonable systems, sizeof(int) = 4 = 32bit.

    OTOH, if it's true that win64 has 32bit long, now *that* is really ridiculous.

  • I don't think that it is really an issue.

    The most you can expect usually from the C brain damaged type system is something like
    sizeof(short) == 2
    sizeof(long) >= 4
    sizeof(long long) == 8 if it exists..

    In any case, I think that it is the C language which is brain damaged here!!

  • Hi All, I wanted to note some things for developers interested in using this service. First, since sourceforge only caters to OSS projects, it is limited to OSS only.

    I did want to go over the NDA that you have to click through to use the service. Why the NDA? Intel is letting us use IA-64 engineering samples for the compile farm and they don't think that any public benchmarking done on engineering samples is fair. We agreed with them and wanted to see developers get thier hands on a working sample early. You're welcome to disagree, but we wanted to give a heads up to people, so be sure to read the NDA.

    Intel has been pretty cool about this, I am pretty happy to see the GPL liberally sprinkled around an Intel legal document.

    Some points from the NDA (most of the NDA is Intel covering its butt, limitation of liabilities and such):

    In paragraph 3 Intel says the following (and this applies to paragraph 5,8 as well):

    • "You may not reverse engineer, decompile, license or disassemble portions of any Intel Software provided in object code form."
    • The only code that is from Intel in object code form is the BIOS and motherboard controller firmware. There is no other object code on the system. The IA-64 Linux kernel is completely open and has been out of NDA and licensed under the GPL since February.

    Paragraph 4 is the Benchmarking Clause.

    Paragraph 13, this is a tricky thing, they retain the right to receive activity logs of the compile farm, this is so they can verify for Paragraph 4. They are only able to request logs pertaining to the Compile Farm, not any other sections of the site.

    Finally we ask for a brief description of the work you want to perform, this is because we (VA/Sourceforge) may have to throttle usage based on project importance. The persons judging this is Eric Sindelar here at VA. We really don't think we'll have to throttle usage, but we want to have the info available to do so if in fact we need to. As of this writing we already have 30 requests to use the service, so it shouldn't be all that necessary.

    That is the overview that we've come up with, we hope that this will go a long way in finding out any IA-64 issues that your code may have. This will also be good for checking the IA-64 Linux Kernel out in real world conditions. If you have any other questions, pose them here and we'll answer them, or email me directly [mailto]

    Chris DiBona
    VA Linux Systems


    --
    Grant Chair, Linux Int.
    Pres, SVLUG

  • And this surprises you why? M$ has a very entrenched history of brain damaged shit along the lines of "portability".
  • "long long" is not a valid ANSI type. (most things will process it (correctly), however.)

    The general rule is to never assume anything about byte sizes of common types that don't have concrete, defined sizes. "If in doubt, don't."
  • To check for 64 bit cleanness, you could probably get on Compaq's server farm. They have various 64-bit Linuxes running on Alpha processors, and they don't require your project to be open source. If you can compile and run on Alpha, chances are good it will work on the Itanium.

  • by chrisd ( 1457 ) <chrisd@dibona.com> on Friday May 26, 2000 @09:20AM (#1046584) Homepage
    Actually, we've had a hard timne getting hardware from sun, sgi and the like, they are more in demand for the compile farm than Alpha. Either way, if they want to get us machiens to put on the farm, we'd be pleased to do it.

    Chris DiBona
    VA Linux Systems


    --
    Grant Chair, Linux Int.
    Pres, SVLUG

  • It's also a portal to porting apps to Linux!!!!!
  • just wondering if i'm missing something or not.
  • How much work would go into porting the average appliction, like "pico" or "apache" to the IA-64 arch? Does most of the work have to go into the new compiler?

    Just wondering...

    Ryan
  • Hmm... never heard of Linuz before. Must have been using that M$ Word Spellchecker. Not that it would have picked up Lixux anyways. I think if the spellchecker in Word sees Linux, it barfs horribly. Of course... that's windows for ya...
  • That or they're such a kernel hacker, they're more used to typing vmlinuz than Linux. ;)

    :wq!

  • At least Intel isn't going to screw their user base by making fake attempts to show support for other OS's like Apple.
  • LinuZ stands for LINUx Zealots, like us, the avid /. reader!
  • That's the only way I could get it past the spell checker on my own computer *haha* Was to mispell it myself... Hmm... must remember to get more sleep...
  • why all the hype around ia-64? imnsho, it's just another overly complex arch from intel. also, there are already alpha systems available to test code on (eg, compaq's test drive program), for 64bit cleanliness(sp).

    what the world needs is not another overly complicated arch. if you want to go the VLIW way, sun's majc is much cleaner (though, you really need to use java).

    alpha, sparc, mips, and ppc are already better designed and are availiable now. intel's brand name and their $$$ are the only reasons ia-64 may survive.
  • "Yeah, but will it run my windows apps?", says the hopeless idiot.
    --
  • Can anyone use the IA-64 Compile Farm, or does it have to be an open source project? I'm interested because I'm supposed to port to Itanium, but my boss hasn't given me a machine yet. I'm sure he'll dig one up...one week before we ship. I'd like to be ready before then.
    --
    Have Exchange users? Want to run Linux? Can't afford OpenMail?
  • Since access is provided through SourceForge, only open source projects are supported at this time. However, remember that porting to IA-64 Linux is very straight forward. If you are currently running on Linux, all you have to do is make sure your code is 64-bit clean and recompile.
  • AFAIK it has to be an open source project, regardless it has to be approved by Sourceforge, so submit a request to use the IA-64 compile farm and see what they say!
  • It's the compressed version of Linux. Usually preceded by vm... :-)


    --
    The world is divided in two categories:
    those with a loaded gun and those who dig. You dig.
  • Atomic should be transparent on properly written
    code.
    May result in larger executables.
  • Porting is very straightforward. 1) Port to IA-32 Linux 2) Make sure your code is 64-bit clean 3) Recompile for IA-64 Linux Since most open source apps have already done. Assuming that you already have step 1 done. Steps 2 and 3 shouldn't take very long. Apache was one of the first applications ported to IA-64 Linux and it has bee running since last year. Eric Sindelar VA Linux Systems
  • if you're lucky, and its 64bit clean, you can just ./configure ; make ; make install

    Otherwise you have a few hoops to jump through.

    C is famous for its crossplatform abilities.
  • So, Itanium being 64-bit, that would mean:

    sizeof(int) == 4
    sizeof(float) == 4
    sizeof(double) == 8
    sizeof(void *) == 8


    right? (I'm only sure about the first one-- at least that's how big ints are on Alpha)

    ObWonder: Why don't 64-bit platforms have 64-bit ints? I mean, int has historically gone from 16 to 32 bits (was 16 in DOS, at least), so why not 32 to 64?
    1. what this all means is that there's *still* one neat thing that you can assume: on all reasonable systems, sizeof(int) = 4 = 32bit.
    2. OTOH, if it's true that win64 has 32bit long, now *that* is really ridiculous.


    Of course, #1 is way #2 is true. Microsoft knows that backwards compatibility ("app-compat") is king. Win64 aims to be source (and binary?) compatible with Win32 code. Tons of lousy Win32 programmers made the assumption that sizeof(long) == sizeof(int).

  • Intel provided the hardware. VA Linux Systems and SourceForge provided the resources to get the systems up and running. Eric Sindelar VA Linux Systems
  • Actually, as of Monday, May 22, 2000, long long is required by both ISO C and ANSI C.
  • This would seem a big advantage to Itanium's future. I would imagine that Intel are especially pleased to see this kind of thing going on. Does anyone know how sponsered the Itanium Compile Farm is, by Intel? Of course, this kind of thing lends itself SO well to linux/unix. Acheiving this with, windows, say would require so much more resources.
    --
  • Yes, you can use an emulator, but working on real hardware is always better. Emulators are designed to be used before real silicon is available. However, once silicon does become available, the work on the emulator normally slows down (or stops). Therefore, the emulator will never be as up to date as real systems

    Eric Sindelar

    VA Linux Systems

  • It's more of a shell than a portal :-)
  • While your assertions are usually correct, they are not always correct (all of them will be wrong on at least one Cray, for example). What C does guarantee is that:

    CHAR_BIT >= 8
    sizeof(char) == 1
    sizeof(short) * CHAR_BIT >= 16
    sizeof(int) * CHAR_BIT >= 16
    sizeof(int) >= sizeof(short)
    sizeof(long) * CHAR_BIT >= 32
    sizeof(long) >= sizeof(int)
    #if __STDC_VERSION__ >= 199901L
    sizeof(long long) * CHAR_BIT >= 64
    sizeof(long long) >= sizeof(long)
    #endif

    IIRC, sizeof(char), sizeof(short), sizeof(int) and sizeof(long) on at least one of the Crays are all equal to 1, and CHAR_BIT is equal to 32.

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Working...