partly making use of prior written text...).
so, for general context, I have my compiler framework which compiles C to a
language I call RPNIL (which is also the name of the compiler which compiles
this language to assembler).
RPNIL is a language with some remaining heritage in languages like FORTH and
PostScript, but is in many ways quite different given the special task it
had been designed for (to define code sequences which are to be compiled to
so, functionally, it serves a role similar to Java Bytecode or .NET CIL, but
differing in that its native form is textual, and with a syntax cosmetically
between that of PostScript and COBOL (it uses a COBOL-like notation for the
toplevel, but uses a PostScript like notation for runnable code).
the language and compiler had been "frozen" for about 1 year as I tried
(without success) to implement a replacement (and I then proceeded to
develop many other areas of the project codebase).
so, recently I started doing several interconnected efforts (they are
related as far as purpose, but the code is disjoint), namely, adding a good
deal of extensions to RPNIL, targetting the JVM to RPNIL, and considering
the possibility of targetting CIL to RPNIL.
now, of course, RPNIL and JBC don't fit exactly, but for most things a minor
amount of crufting has been sufficient (including adding alternate opcodes
to RPNIL which more closely resemble those in JBC and CIL).
actually, RPNIL is a bit "higher level" than JBC, and so in many cases whole
groups of JVM opcodes are merged into a single RPNIL opcode (and sometimes
casts are inserted in order to compensate for the generally untyped nature
of JBC, where JBC specifices types in the operations, whereas RPNIL
specifies types in the values...).
in general though the conversion is fairly straightforwards...
and, among these extensions and awkwardness, was figuring out how to
interface RPNIL and my object system (since it was originally designed for
C, it lacks built in object support).
the eventual considered solution is the use of "self-initializing accessor
thunks", which behave more or less like stub functions (a stub is created
for each field in each accessed class). each stub will in-effect contain a
static variable, which will hold the actual slot or method handle (which
will be loaded the first time the stub is called).
when accessing a slot, if no such stub is listed, it is added to the list
(the code for the stubs is likely to be generated after the code for the
the reason I had used this approach, even though it has a slightly higher
overhead than is ideal, is because it still allows separate compilation
without the need for special linker trickery (although, even as such, it is
necessary for the classes to "exist" in the object system both before
compiling the module, and before running any code in the module, which in
the case of the JVM would mean declaring the classes to the object system
prior to JIT'ing the module...).
in part, the above restriction is because the system doesn't actually define
the classes internally (which would require adding a mirror class/instance
system in the RPNIL compiler), but instead "imports" objects from the
external C/I system and builds against those (this does save, however, when
compiling a module, as it is just like "import this class", rather than
having to declare the enti