Current Status

Wed Feb 17 12:40:00 GMT 1999

On 1999年2月16日, Tom Tromey wrote:
>>>>>> "Jon" == Jon Olson <olson@mmsi.com> writes:

>I'm curious about your port. What makes it "embedded"? In what way
>is the current compiler not suitable? What runtime are you using?
>
The thing that makes it embedded is some particular extensions that
I've made to GCC to support rommable, position independent code
not supported by the standard GCC ports. We produce alot of microcontrollers
that use both AMD A29K Digital (Intel) StrongARM, and Hitachi Super-H
microprocessors and we heavily rely on g++ to compile code for these
targets. One requirement that we have is the ability to dynamically load
and link modules which execute from flash EPROM. Position independence is
key, hence all text segment symbols MUST be computed relate to the PC and all
data segment symbols MUST be relocated relative to a per-module data segment
base register.
Unfortunately, most dynamic linking mechanisms rely on the ability to
patch the text segment at run-time. Not possible in an embedded environment
which executes modules directly from flash memory.
The runtime that I'm using is one I've built using `gjavah' to generate the
header header files from a mix of our own java code, a bit of Sun's
`jdk', and concrete implementations of native code using g++. I'm gradually
replacing `jdk' modules (they've got a really horrible implementation of
java.lang.String). The embedded OS is the in-house multi-threaded OS we use
for all our products.
 >Where are you putting the write barriers? In the front end? In
the >back end? (We rely heavily on our Java/C++ integration, so I think
>they might be better put further back.)
>>Do you allow multiple write barrier implementations per target? If
>so, how?

Currently, it's just an RTL instruction that gets emitted whenever making an
assignment to a reference variable. It's obvious purpose is to gray out
the rval so that GC will scan it for references. Hence it knows nothing
about the lval and can handle assignments to either field variables,
stack slots, or pseudo-regs. I'm currently just making a function call
to the GC which slows things down a tad but makes it more easily
integrateable with an arbitrary GC implementation.
Without the write barrier, we have to do what `kaffe' currently does in its
GC, lock all threads until GC finishes.
Lately, I've been contemplating how difficult it would be to add a level
of indirection to objects such that object references were fixed handles
to an object table to better support more precise copying collectors. Would be
cool to provide this as a compile time option to both `gcj' and `gjavah'. 
The idea would be that Java objects would exist as two separate
objects. The first object would be a two word object containing a vtable
and a pointer to the object field data. This object would be fixed in size
and location for the life of the object. The second object would be variable
in size and movable to support memory compaction. In reality, this wouldn't
add any to the storage requirements, because all Java objects currently
contain a `vtable' and `sync_info' in their object header. The main trick
is making `gcj' and `g++' recognize the volatility of the reference to the
field data and never cache it. Similarly, the object mobility would give
preemptive multi-threading fits since it could only preempt at known safe
points. Oh well, for now it's just an idea....
>>Can you sign papers for the FSF and contribute your code? Signing
>papers is a prerequisite for any major contribution to end up in the
>core. I believe for the compiler you can use the standard FSF
>paperwork (for the runtime, I don't know).
>
Yes, I'd be happy to contribute my changes. What I'd really like to see
in GCC is the updated exception mechanism I'm using for Java exceptions.
I found the existing range table approach and setjmp()/longjmp() mechanisms
unappropriate for embedded systems. I previously posted a rather lengthy
email regarding my exception handler modifications.
Anyway, I'm not quite ready to contribute the changes quite yet. Although
I have the new exceptions working very nicely for the `gcj' compiler, I haven't
integrated my modifications with `g++' yet. C++ has the annoying misfeature
of allowing the catching of exceptions which get stack allocated and truncated
on their way up the exception stack. Add to that you can throw anything,
including a 1 meg array of objects and C++ exceptions get terribly messy.
My druthers would be to disallow the catching of stack allocated objects
and always just catch object references. Probably wouldn't be ANSI compliant
though ;-(
>Tom
--
Jon Olson, Modular Mining Systems
	 3289 E. Hemisphere Loop
	 Tucson, AZ 85706
INTERNET: olson@mmsi.com
PHONE: (520)746-9127
FAX: (520)889-5790