Java cross-compiler to AVR target (?!)

["E. Weddington" <ericw at evcohs dot com>]

Hello All!

Ok, this is a weird one.

I don't know hardly anything about Java, but I build a GNU toolset for 
the AVR target hosted on Windows.
(WinAVR: <http://winavr.sourceforge.net/>) This toolset contains GCC for 
C and C++.

So, I thought, "I wonder if I could build the Java compiler?"

So I tried it, using Cygwin but for --host=mingw32, --build=mingw32, 
version 3.4.2, and it built!

Well, ok, so the configure did say:

This configuration is not supported in the following subdirectories:
    target-libiberty target-libstdc++-v3 target-libffi target-boehm-gc 
target-zlib target-libjava

The first 2 subdirs are known. I would assume that libffi, boehm-gc, 
zlib, libjava all pertain to java.

When I look in my installation /bin directory I now see:
avr-gcj.exe
avr-gcjh.exe
avr-grepjar.exe
avr-jar.exe
avr-jcf-dump.exe
avr-jv-scan.exe

The weird thing is that I also see:

avr-avr-gcjh.exe

which also has the same file size as avr-gcjh.exe.

Now, I *highly doubt* that any JVM would fit into an Atmel AVR (8-bit 
RISC, largest variant: ATmega128, 128K Program, 4K SRAM). But I'm 
intrigued by the fact that gcj can compile java source into native 
machine code.

So with all this in mind a few questions (and please forgive if these 
are naive):

1. Would the Java compiler be "screwed up" or "incomplete" without those 
other subdirectories being built?

2. Would it even matter, given the target, if those subdirectories were 
not being built?

3. I'm sure most of the standard Java libraries don't apply to an 
embedded processor. But, all that would be required to control the AVR, 
is to be able to read/write to memory-mapped registers and to flip bits 
at the byte level (like C bitwise operators). Is this at all feasible in 
Java?

4. Any idea what's with the oddly named "avr-avr-gcjh.exe" installed file?

And if you could CC me in any replies as I'm not subscribed to this 
list. Thanks.

Eric Weddington