Re: VM as target, was Is Assembler Language essential

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> wrote in message
news:09-02-095@comp.compilers...
> cr88192 schrieb:
>
>> now, in my "trying to be overly ambitious" thing, I am trying to
>> make my VM accept both Java Bytecode and .NET/CIL (as well as
>> continuing on with what it does already, namely, serving as a
>> dynamic C compiler).
>
> The machines may be incompatible, with regards to e.g. garbage
> collection. Also existing code may rely on the VM specific standard
> libraries, with possibly differing implementations of classes or
> methods of the same signature. You may have to extend the namespaces
> by the name of the IL, in order to prevent such cases, and you may
> have to supply the "standard" libraries - where "standard" means a
> hell of incompatible .NET versions :-(


GC is not really an issue, since I mostly use GC in C allready.
the problem though is that it is conservative GC...


as for class name collisions, this should not be a problem.
the reason is that both provide naming conventions, but both use naming
conventions that place standard classes in different locations.


so:
java.lang.String
javax.swing.JButton
...


and, OTOH:
System.Console
...


so, it is not necessary to separate the namespaces, as they already separate
themselves...




likewise, I am considering the possiblity of writing a new frontend which
will more or less implement C#, although it will compile it directly to
machine code. the main difficulties result primarily from differences in
compilation strategy with C, where C compiles each source file
independently, whereas C# compiles a whole group of source files at once and
uses a more or less shared state.


so, this will require a new frontend (note that JBC and CIL use different
frontends from C as well...), but should leave the backend relatively
intact.




note that much of the needed machinery, such as Class/Instance OO support,
... has already been added to the backend (although, sadly, it still does
not effectively handle either exceptions or tail-calls).


in my existing library code, I did write a crude system based around
thread-local-variables and longjmp, but I am not so sure this would be ideal
(ugly, awkward, not very efficient).




a related issue is that, my code can be linked with code produced by GCC (or
MSVC, which has something similar), and GCC has this issue: many people
think it good practice to compile code with '-fomit-frame-pointer', which
may, technically, break some assumptions that could be made by my compiler
(such as if directly implementing exception unwinding, ...), and sadly, is
common practice within many of the system APIs (as evidenced by gdb's
inability to produce backtraces, ...).


one is about forced to use thread-local-storage, making me think: maybe I
should add features for thread-local-storage to my compiler, making it a
little less of an issue. at the C level, it could be exposed via the
__thread keyword (as in GCC). however, mine will probably not map to GCC's
TLS support (AKA: a __thread variable in my compiler and in GCC would not be
able to see each other due to technical issues...).


decided to leave out my thoughts for the implementation strategy...
in short summary: on Win32 generate some code to directly access the Win32
TLS, then my framework's TLS (GC visible, but depends on my framework, and
raises hairy issues).


current thinking is that I could actually just make use of a magic thunk to
access the TLS, and leave it up to the runtime to work out the
details/generate the thunk (a tradeoff, but oh well...).


but, yes, with a little more efficient TLS support, exception handling
becomes a little less ugly (or likely to kill performance).


OTOH, I could try to make use of Win32's structures for exception handling,
but I am not certain this would be a good idea (and wouldn't work on Linux,
whereas a more generic mechanism could work on both, but would not mix
ideally with MSVC-produced code if both use exceptions...).

Return to the comp.compilers page.
Search the comp.compilers archives again.