[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Willing to join GSoC2011 project "RTEMS port of the GNU Java Compiler (gjc)"
- Date: Thu, 31 Mar 2011 07:54:45 -0500
- From: joel.sherrill at OARcorp.com (Joel Sherrill)
- Subject: Willing to join GSoC2011 project "RTEMS port of the GNU Java Compiler (gjc)"
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
>>>> 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
> 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
>> 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?
> rtems-users mailing list
> rtems-users at rtems.org
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