Slashdot Mirror
Linux IA-64 Resource Portal
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.
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, 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).
I would like to know the current state of the art of industrial-grade compilers with respect to this automatic local parallelization techniques.
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.
CVS is teh suck. Use Vesta instead.
- 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 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."
Paragraph 4 is the Benchmarking Clause.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 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
Chris DiBona
VA Linux Systems
--
Grant Chair, Linux Int.
Pres, SVLUG
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.
Chris DiBona
VA Linux Systems
--
Grant Chair, Linux Int.
Pres, SVLUG
Co-Editor, Open Sources
Open Source Program Manager, Google, Inc.