Re: [DotGNU]Java assembler

[Rhys Weatherley]

Sylvain Pasche wrote:

> Seems there's more work to be done that what I expected. I did not see
> at first that the java assembly was not yet done during parsing
> (ilasm_grammar.y).
> 
> What should be the policy for ilasm output with -mjvm ?
> 
> * A single .class file if there'es only one class in the module, and
> else a .jar
> * always a .jar, as the module might contain several classes/types.
> * a buch of .class files in the cwd (incompatible with -o flag)

"--format jar" or "--format class" can be used to select the
output format.  The default can be based on the file extension
from the "-o" option just like for IL binaries, with "jar" being
the fallback.

I'd recommend against outputting multiple .class files, as
it isn't compatible with the rest of the toolchain.  If you
really wanted it, you can add "--format multi-class" and then
interpret "-o" as a directory name rather than a filename.

> About the java assembly process. Should it create metadata for the
> methods in the same way such as il methods, and then use a metadata
> writer which will ouput Constant pool for each classes
> (meta_java_writer.c or alike ) ?
> One problem with this is that we don't have the constant pool index
> until the metadata translation is done. Which makes it difficult for
> outputing, for example ldc "..." .

There are functions currently called "ILJavaGetInteger",
"ILJavaGetMethod", etc for fetching information from a
class-based constant pool.  There's no reason why you
can't add "ILJavaSetInteger", "ILJavaSetMethod", etc for
building the necessing constant pool entries as you go.

Gopal started work on this a while ago, but became busy
with other things.  He can probably send you the code if
you wish to pursue this.

By necessity, a class cannot be written out until all of
its contents have been processed but it should be possible
to flush the current state after each class is processed
(nested classes may need a little more work).

> Or bypass the metadata while assembling java methods ?

The metadata is necessary to get the skeleton of the
class definitions into memory.  Without it, you will need
to write a parallel class representation, which I don't
recommend.  Two different representations means two
different sets of bugs.  I don't like having to fix the
same problem twice. :-)

Cheers,

Rhys.