Skip to main content

Problems building CDC

9 replies [Last post]
andylarder
Offline
Joined: 2004-03-10
Points: 0

Hi,

I'm building the win32-x86-vc8 version of the cdc in the SVN trunk, and I'm stuck on how to fix the following error:

as ../../src/x86/javavm/runtime/invokeNative_i386.S
bash: gcc: command not found

Obviously gcc isn't installed (I'm using VC8 and cygwin), so I'm guessing this is probably the first time an assembly file is compiled, and make is trying to use gcc rather than the Visual Studio assembler.

Any idea how and where to fix this?

Cheers,
Andy.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cjplummer
Offline
Joined: 2006-10-16
Points: 0

The only optimization option that is not on by default for x86 builds in CVM_JIT. Set it true and leave off debugging options (like CVM_DEBUG=true) and you have the highest performaning build for x86.

Chris

andylarder
Offline
Joined: 2004-03-10
Points: 0

Ok, I'm now getting an error with CVM_JIT_USE_FP_HARDWARE and CVM_JIT set to true:

../../src/x86/javavm/runtime/jit/jitgrammardefs.jcs(268) : error C2065: 'cnt' : undeclared identifier

Message was edited by: andylarder

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> Ok, I'm now getting an error with
> CVM_JIT_USE_FP_HARDWARE and CVM_JIT set to true:
>
> ../../src/x86/javavm/runtime/jit/jitgrammardefs.jcs(26
> 8) : error C2065: 'cnt' : undeclared identifier
>
> Message was edited by: andylarder

FPU support is broken for x86, thus it is disabled. This means that rather than generating floating point instructions, the JIT generates calls to C code that perform the floating point operations (which presumably gcc has compiled to use floating point instructions). Thus, the FPU is still used, but with the overhead of a C call for every floating point operation.

Chris

andylarder
Offline
Joined: 2004-03-10
Points: 0

Oh, ok. It is the PowerPC version I will be eventually interested in using - does the h/w FP support actually work in that one?

Also, a bit of an aside, but there are a few questions relevant to my evaluation that you might be able to help me with:

1/ Does this VM support being able to unload code associated with a classloader?
2/ Does the VM support use of multiply and add opcodes (yes, I know this raises compatibility/conformance issues!)
3/ How easy would it be to add an instruction scheduler for the PowerPC - the architecture I am looking at is in-order execution so this might be important.
4/ Does the vm allow methods to be 'intrinsified' with assembly code?
5/ Is the native memory buffer functionality in the nio package supported?

Thanks again,
Andy.

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> Oh, ok. It is the PowerPC version I will be
> eventually interested in using - does the h/w FP
> support actually work in that one?
>
Yes. I assume you are talking about linux. h/w FP should be enabled by default in the linux-powerpc-yellowdog GNUmakefile.

> Also, a bit of an aside, but there are a few
> questions relevant to my evaluation that you might be
> able to help me with:
>
> 1/ Does this VM support being able to unload code
> associated with a classloader?
Yes. Just like JavaSE, when there are no longer any references to a ClassLoader or any of its loaded Classes, then they are all unloaded after the next full GC.

> 2/ Does the VM support use of multiply and add
> opcodes (yes, I know this raises
> compatibility/conformance issues!)
PowerPC has support for this. Build with CVM_JIT_USE_FMADD=true to get the JIT to use it. Also remove the -mno-fused-madd from the GNUmakefile to get gcc to use it. As you seem to be aware, this will cause TCK failures due to keeping too much precision. It's been a few years since this was built, but I'm guessing it still works. If you have problems, let me know. I can probably resolve them quickly.

> 3/ How easy would it be to add an instruction
> scheduler for the PowerPC - the architecture I am
> looking at is in-order execution so this might be
> important.
Hard. There was one done for ARM. It was too hard to do, is too fragile (and therefore currently broken and disabled) and yielded very little gain (maybe 3% to 5% on Xscale).

> 4/ Does the vm allow methods to be 'intrinsified'
> with assembly code?
See the intrinsics chapter in the Architecutre Guide.

http://java.sun.com/javame/reference/docs/cdc_dynamic_compiler_arch.pdf

Intrinsics can come in the form of special emitter functions that know how to emit code for a method (and as a side affect allow JIT inlining of what would normally be a native method). It also allows the JIT to generate a C call to a C or assembler function, avoiding the overhead of JNI method calls.

> 5/ Is the native memory buffer functionality in the
> nio package supported?
No. This is not part of any JavaME JSR.

regards,

Chris

cjplummer
Offline
Joined: 2006-10-16
Points: 0

gcc is required for the build for assembler files and also for compiling native tools like jcs (if you are doing a CVM_JIT=true build).

Chris

andylarder
Offline
Joined: 2004-03-10
Points: 0

Thanks for that!

Now I've got it built and working (that was easy!), how do I turn on all the build optimisations so I can test the performance on my app (like hardware floating point and any other performance based optimisations)?

Thanks,
Andy.

andylarder
Offline
Joined: 2004-03-10
Points: 0

Ok, so it seems these are set in GNUMakefile and defined in top.mk.

So all that remains is to ask what are all the performance related options, so I don't miss any? I see there is something called CVM_JIT_REGISTER_LOCALS that doesn't appear to be defined, but sounds like it might be relevant - what's that for?

cjplummer
Offline
Joined: 2006-10-16
Points: 0

> Ok, so it seems these are set in GNUMakefile and
> defined in top.mk.
>
> So all that remains is to ask what are all the
> performance related options, so I don't miss any? I
> see there is something called CVM_JIT_REGISTER_LOCALS
> that doesn't appear to be defined, but sounds like it
> might be relevant - what's that for?

This is a JIT optimization that does not work on x86 (and probably would not be all that much help anyway).

Chris