From: Godmar Back (gback@cs.utah.edu)
Date: Thu Sep 17 1998 - 01:44:09 EDT
I'm sure Tim is on the list, but for the others, this is a reply
Per Bothner gave to someone asking for a spec of the internals of gcj.
- Godmar
Forwarded message:
> From owner-java-discuss@cygnus.com Wed Sep 16 18:10:06 1998
> Message-Id: <199809162113.OAA17443@cygnus.com>
> To: Jon Olson <olson@mmsi.com>
> cc: java-discuss@cygnus.com
> Subject: Re: Tantalizing gcj Java compiler
> In-reply-to: Your message of "Wed, 16 Sep 1998 09:37:51 PDT."
> <98091609454500.28154@toontown>
> Date: Wed, 16 Sep 1998 14:13:08 -0700
> From: Per Bothner <bothner@cygnus.com>
> Sender: owner-java-discuss@cygnus.com
> Precedence: bulk
>
> > Looks like gcj generates nice assembler code for all our Java class
> > files, but unfortunately I can't find any info on the meta data formats
> > generated by the compiler for classes, methods, etc. I know this
> > is a work in progress, but I really want to know more about the gcj metadata
> > so I can begin work on our embedded support for this compiler. Is there
> > any more info (header files, texinfo docs, etc.) about the metadata emitted
> > by the compiler and the run-time support required to initialize the classes?
>
> There will be header files that will be part of libjava. They will be
> released with libjava. There are various reasons we have to wait,
> but we're working as hard as we can.
>
> I don't think we want to document the formats beyond the header files.
> At least for a while, we consider these internal interfaces, that are
> in a state of flux.
>
> > I really want to know more about the gcj metadata
> > so I can begin work on our embedded support for this compiler.
>
> Well, the compiled code is designed specifically to work with our
> run-time library, and not any other. The compiler could in theory
> be modified to target another run-time environment, but at this
> point that would add more complication than it is worth. (Of course,
> it is free software, so you're free to do it on your own.) Or you
> could modify some other Java environment to match jc1 output, but
> that too is a fair bit of work, especially since the data formats
> won't be stable immediately.
>
> If you want to puzzle out the formats, look for the macros PUSH_FIELD
> (which declares the various fields), and PUSH_FIELD_VALUE (which
> initializes a field to the correct value). But I emphasize again:
> These structures *will* change, and probably fairly soon.
>
> Still, we are very interested in working with other groups,
> but we are mainly interested in partners with either cash or
> who can provide useful and non-legally-encumbered technlogy ...
>
> --Per Bothner
> Cygnus Solutions bothner@cygnus.com http://www.cygnus.com/~bothner
>
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:57 EDT