Now that the zero-assembler port is committed I’ve been thinking about dropping the ppc-specific one. The plan is to use zero for our other platforms (s390, s390x, ia64 and arm) and there’s no obvious reason to maintain a separate port for ppc and ppc64. This past two days aph and I ported zero to amd64 and I’ve been thinking of ways to integrate zero into the build system so that you can choose to use it on any platform with minimal effort. This will be easier and clearer without a load of ppc-specific stuff knocking around in there. There are a couple of bugs in the ppc-specific port too, bugs I noticed while writing zero, and I just can’t be bothered to fix them.
I did some simple speed tests, the time in seconds taken by jar cf tools.jar:
| ppc | zero | |
|---|---|---|
| 32-bit | 67.6 | 70.3 |
| 64-bit | 67.9 | 69.7 |
Not bad. A look at the call graph shows most of the method calls are interpreted methods, so I’m not sure it’s entirely representative — I’d expect programs doing a lot of native calls to be hit harder — but I like it. I’m interested to know why 64-bit zero is faster than 32 too — that’s not what you’d expect on ppc — but that can wait until I get round to some profiling. I want to get it running on the other platforms first.
Please give a hint to a url/how to obtain the new sourcecode for zero and i will make a try compile and run it on a ARM based “bubba” server.
Thanks! The code is in IcedTea but there’s nothing in the build system to build it. I’ll be doing that over the next couple of days, so if you let me know what your
uname -mis I’ll make sure to add it and let you know when I’m done.$ uname -m
armv4tl
The machine are running Debian 3.1 sarge hopefully i can get all build requirements for iced tea to compile directly on the machine, http://icedtea.classpath.org/wiki/BuildRequirements , or else i have to try cross compile the software.
$uname -m
armv5tejl
I will try setting up a Feudora based ARM system on this AT91SAM9263-EK devkit.
Hmmm, I’ve seen armv5tel too. This mishmash of different names is going to make hacking the build scripts painful. What do all the letters mean anyway?
the different name addon letters specifies the additional instructionset capabilities of the cpu.
t = supports thumb instruction set
j = supports jazelle java bytecode execution (used in many smartphones to speed up java)
e = supports DSP enhancement instructions
etc..
i have no clue what the “l” stands for.
The newer arms have armv6l and armv7l. don’t ask why :)
Other available debian developer machines gave:
archicture uname -m
alpha alpha
powerpc ppc
mips mips
ia64 ia64
hppa parisc64
s390 s390 or s390x
sparc sparc64
so mostly logical, only arm is funny.
I guess I’ll need to make it work with arm*. It’s a pain because most of the build scripts use switch-case things with exact matches for most archs and the default case being ix86, so the wildcard case has already been hogged :)
Gary,
Just found out about your work to make icedtea not dependent on asm stuff today. Very glad to hear it! I am working on getting Fedora running on ia64 and icedtea was one of the packages that looked like it would be a lot of work. Do you know when you expect to have your latest stuff into rawhide? I will try to get this built on ia64 soon.
thanks,
– Doug
Hi Doug,
The main thing preventing it being in Fedora is the lack of a libffi package (bug 431633) but if you wanted to make a start you could build and install the rpms from that bug and grab the IcedTea sources from Mercurial (hg clone http://icedtea.classpath.org/hg/icedtea) and build those. I committed the extra build system files for ia64 (and arm, s390, s390x) for you this morning so it’s basically a matter of patching the openjdk Makefiles. If you look in patches/icedtea-ports.patch you’ll see where I had to add things for ppc and ppc64, but note that Sun had an ia64 port at one stage so the build system already has some ia64 stuff present. What I’d recommend is, for every ppc/ppc64 thing I did in openjdk/hotspot, find the corresponding ia64 bit and change it if necessary (eg, wherever a ppc bit sets an ARCH variable to zero, make ia64 do that too). You shouldn’t have to do much (if anything) in the openjdk/jdk and openjdk/corba directories because the ia64 code in there should Just Work™.
Ok, I think that’s enough for starters :) Let me know if you have problems, I can probably help…
Gary
ARM machines can be found in both big and little endian. At the end of the uname -m on a arm machine the l or b stands for little or big endian
l = little endian
b = big endian
thus my armv5tejl system should compile with -mlittle-endian
Is it necessary to specify
-mlittle-endian? Will it fail without?I have not yet been able to compile hotspot, my last build error included below, the build system still thinks im on a i586 system by default and im currently hacking makefiles to support my arm system.
g++ -DLINUX -D_GNU_SOURCE -DIA32 -DASSERT -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/asm -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/c1 -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/ci -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/classfile -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/code -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/compiler -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/gc_implementation -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/gc_implementation/parNew -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/gc_implementation/shared -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/gc_interface -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/interpreter -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/libadt -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/memory -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/oops -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/opto -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/prims -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/runtime -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/services -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/utilities -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/cpu/x86/vm -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/os/linux/vm -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/os_cpu/linux_x86/vm -I/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/adlc -I../generated -DCOMPILER2 -DCOMPILER1 -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -g -m32 -march=i586 -pipe -w -c -o ../generated/adfiles/adlparse.o /mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/adlc/adlparse.cpp
Assembler messages:
Error: unknown architecture `i586′
Error: unrecognized option -march=i586
cc1plus: error: unrecognized command line option “-m32”
/mnt/usbdisk/openjdk-3b9a53e0ec3c/hotspot/src/share/vm/adlc/adlparse.cpp:1: error: bad value (i586) for -march= switch
make[6]: *** [../generated/adfiles/adlparse.o] Error 1
make[6]: Leaving directory `/usr/src/icedtea-armv5tejl-build/linux-armv5tejl/hotspot/outputdir/linux_i486_compiler2/product’
make[5]: *** [ad_stuff] Error 2
the reason why i cant simply edit the icedtea patchfiles do a make clean and recompile is that it takes about 60h for my machine to make the bootstrap files then comes another 12h digging through openjdk before reaching the hotspot :) So i figured i better fix the openjdk makefiles by hand untill it compiles and then make the changes to the icedtea codebase, by doing this i have only to wait about 30min before reaching hotspot again ;)
Sure, that’s what I do to. By the way, there’s a
hotspotrule in the top-level makefile which should save you 30 minutes :)I’d expect enieythrvg to go on for a while, anyway. On the Kaffe/Classpath/gcj/cacao/IKVM/JamVM/* side the future development will happen with a chance of strongly collaborating with Sun on shared code.On Harmony’s side, probably not so much, though enieythrvg is possible there in the future. Nothing, except current policies, prohibits ASF from working with/on GPLd code. And policies are always up for debate.