[Mono-dev] idea summary: Swing in Mono?...
cr88192 at hotmail.com
Sun Feb 8 16:25:04 EST 2009
----- Original Message -----
From: "Chris Toshok" <toshok at gmail.com>
To: "Stefanos A." <stapostol at gmail.com>
Cc: "BGB" <cr88192 at hotmail.com>; "Michael Hutchinson"
<m.j.hutchinson at gmail.com>; <mono-devel-list at lists.ximian.com>
Sent: Monday, February 09, 2009 6:06 AM
Subject: Re: [Mono-dev] idea summary: Swing in Mono?...
> Yeah, I really don't understand the aim of this thread. It seems you
> are trying to decide how to write a cross VM (of which you are
> *writing* a jvm and CIL vm?), cross platform, cross ui framework. Or
> at least that's what I've understood, anyway. Perhaps being a little
> more specific about things with us would help us understand exactly
> where you're going.
well, I have my "main project", which is basically around 300-400 kloc or so
of misc code (a lot of 3D stuff, ...).
and, my VM effort, which is about 250 kloc.
now, my VM is a VM or sorts, but has a very different architecture from
the partial reason is that my VM (subproject) started off originally as a
script VM, which was then transformed into a dynamic C compiler, and which
then has had ever more functionality added on...
so, C code was compiled at runtime, and over time I added GC, dynamic typing
support, an object system, ... the C remained, but all this additional stuff
became APIs. internally, the C compiler produces code fairly similar to what
might come out of GCC or similar, and at one point, I was benchmarking them
and getting similar performance (although GCC had a clear speed advantage
for floating-point scalar code, ...).
most of the code is implemented in a more-or-less modular fashion (the idea
of one area of code messing with or depending on structs/data/code/...
belonging elsewhere is just distasteful...). and, more so, most APIs have a
more or less defined API (many of which have been influenced in terms of
design and conventions by the likes of OpenGL and POSIX, namely, the empasis
being on abstraction).
performance is also a concern, but as I see it not even performance should
allow violation of modularity (although it may allow designing the API to
allow as much performance as is reasonable).
the compiler in general has components similar to those of a traditional
compiler, and is more or less divided into independent modules along these
lines. for example, my upper compiler produces an IR (I call RPNIL, and it
sort of resembles Forth or PostScript hybridized with COBOL...), then my
middle compiler produces ASM (in an NASM/Intel style syntax), and my
assembler produces objects, and my linker links them (actually, the
assembler and linker share the same library, and are not completely isolated
in terms of their internals).
the frontend of the compiler then orchestrates the process by sending input
into one component, then taking the output from that component and feeding
it into the next, ...
the core of the C compiler remains, but is being gradually reworked so that
it can handle JIT for both JBC and CIL (along with most of the rest of the
framework). granted, both JBC and CIL are fairly similar at this level, but
are a good deal different than what is needed for C.
note that I decided to actually integrate most of the extended functionality
directly into the existing compiler machinery, rather than more-or-less
translating the JBC into something like if the code were written in C (AKA:
bunches of hackery and API calls), because if the compiler supports all this
natively this is cleaner and allows better performance.
so, going forwards, I more or less just implemented a JVM on top of all this
(as another module), but currently it is not yet complete: it does not
handle exceptions and the JIT is not complete, but it does have an
CIL will likely come later than JBC, mostly because JBC is the one requiring
less implementation work, and most of what would go into making JBC work
would be easily adaptable to CIL.
note that the compiler machinery does not directly accept JBC (or later,
CIL) output, nor does it directly accept the specifics of these formats,
more the JIT process (owned by the mini-VM) converts the JBC or CIL into my
compilers' IR, which then goes through all the machinery as before (so, the
internal changes to the compiler are more in terms of adding capabilities to
now, elsewhere in the project, there is a bunch of 3D stuff, and this is
what I use the compiler framework mostly as a big elaborate scripting
now, as I see it, a GUI framework runs on top of a VM, and stuff running on
top of a VM should not depend on the internals of the VM on which it runs
but, as is, I have some GUI code, but it is written in C, and is part of the
3D engine's GL-related utility functions.
I lumped together all the basic drawing stuff (text rendering, GUI,
image/texture loading/saving, ...) into a single library.
then, most of the purely 3D-engine specific stuff (model rendering, 3D
animation, scene graph, ...) into another library.
More information about the Mono-devel-list