Kaffe for embedded development?

[Erik Bruchez]

> I was wondering if anyone on the list has yet tried to port Kaffe to
> a real-time operating system (either commercial or home-grown)
> and/or attempted to do any development in an embedded environment?

> In theory, at least, what would be required to do this, other than
> the standard porting of the platform-dependent threads calls?

> Any information about using Kaffe in an embedded and/or real-time
> environment would be greatly appreciated!

We have begun work at the LSL-EPFL to port Kaffe on the RTEMS
executive and a 68EN360 Controller. RTEMS has no Unix-like API and no
filesystem, but TCP/IP networking code is available in recent
snapshots.

If you simply plan to use Kaffe internal threads, you must have
support for some kind of signals (basically in order to implement
Thread.sleep) and some kind of non-blocking I/O (Kaffe then uses
select to check the I/O when it has nothing else to do). We have
hacked this part of Kaffe 0.8.x to check for network events and for
hardware "interrupts", but it is of course not real-time at all (a
running internal thread can prevent any external event to be detected,
unless I'm really wrong or things have changed).

If you don't have a native filesystem, then you must modify the
built-in class loader in order to get your classes from elsewhere
(EPROM, network, ...). Add simple memory allocation to your toolkit,
and that's basically all you need to run the Kaffe VM...

You may want then to look at all java.* native methods in order to
decide what to modify and/or implement depending on what is available
on your system (e.g. in order to use your console input / output, your
networking code, suport for RTC, etc.). I you have a Unix-like API
that should be easy, but more work is needed if it's not the case.

Our first "draft" port does all this, except the signals. Basically it
allows to run simple, multithreaded java programs that are able to
access our custom hardware and to communicate using a console and an
Ethernet network.

Our new port will use the latest RTEMS snapshots and Kaffe 0.9.x. We
will do our best to use a new POSIX threads API available on top of
the RTEMS native threads (tasks). This will eventually solve most
real-time problems (except perhaps for garbage collection) and avoid
the use of asynchronous signals.

By the way, what is the current status of Kaffe and native threads ? I
know that people have begun native threads ports a long time ago, but
is there any working implementation yet ?

Another point is that the JIT for m68k seems to generate FP
instructions and thus can't be used on the 360. Is there currently a
way to disable this feature ?

Hope this helps, and thanks for any clue regarding my two questions.

-Erik