Willing to join GSoC2011 project "RTEMS port of the GNU Java Compiler (gjc)"

[Joel Sherrill]

On 03/31/2011 12:47 AM, Ralf Corsepius wrote:
> On 03/31/2011 01:55 AM, Chris Johns wrote:
>> On 29/03/11 12:56 AM, Ralf Corsepius wrote:
>>> On 03/28/2011 03:41 PM, Joel Sherrill wrote:
>>>> On 03/19/2011 09:17 PM, 刘杰 wrote:
>>>> This means building and testing gcc. There are scripts in rtems-testing/
>>>> which are used to test C, C++, Ada, and (preliminary) Objective-C on
>>>> RTEMS.
>>>> You will be augmenting those scripts and then fixing whatever is
>>>> required in
>>>> gcc to make GCJ work.
>>> Dumb question: Is GCJ still alive?
>> It seems to be.
> If you say so :-)
>
> It's open source, so anybody can try to use it and has the liberty to
> contribute.
>
> Raises the next question: Is it worth it? I don't know.
>
There are a few benefits.

+ It is another language.  That might attract some users.
+ It brings a large tests suite.  Language run-times and
     large libraries tend to shine the light on missing features
     or bugs in the implementations of POSIX routines. If you
     recall, the Go port found a few
+ GNU Classpath is used on a variety of JVMs.  So supporting
     this would make getting one of those JVMs working easier.
+ GCC Support libraries.  Go made us bring up libffi.  Java
     will make us bring up boehm-gc.  Each time we check the
     box for one of these, the next language comes up easier.
     I added the option to build Objective-C in the past few
     months to my tool test scripts and it just built.  I haven't
     done a run and checked it carefully yet though.  With
     gcc 4.6 close to branching, I wanted to wait.

Personally I like to see large, complex packages with good
test suites ported to RTEMS even if they may or may not
bring millions of users.  They push us to be compliant to
standards and full-featured.  They also add to the
"credibility" of RTEMS as a platform.
> All I know from previous attempts of getting GCJ building for RTEMS,
> this will be challenging.
>
I tried in the past few months.  It appears that boehm-gc is
the first challenge.  Unfortunately, it has to be worked on
on a per CPU basis.

boehm-gcc support about half of the  CPUs that
RTEMS supports.  I see m68k, i386, mips, powerpc,
sparc, m32r, and sh checks in the gcconfig.h file.

We can follow the approach we did with Go last year.
He focuses on i386 so he can compare results
to native GNU/Linux until results are in good shape.
Then try the other CPUs one at a time.

>>> Correct me if I am wrong, but to my knowledge, GCJ is in some kind of
>>> hiatus, because most (all?) major GCC contributors are not using it
>>> anymore.
>> They moved the front end to ejc in 2007. The patches list seem active.
> My knowledge on java is close to NULL ;)
>
I can code a little Java but that's not the main problem.  You
can port a language to RTEMS without having much more than
a reading ability.  I don't think I ever looked at any Go code
during that effort.  The effort is more about adapting the
run-time library to RTEMS.

I would like to find someone from the gcc community to
co-mentor this.  Any suggestions?
> Ralf
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users


-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985